The Purple Team Journey by Ozz961

href Attribute XSS Using javascript: URI Scheme Cross-Site Scripting (XSS) is often associated with injecting HTML tags or breaking out of script contexts, but a less obvious and equally dangerous variant occurs when user input is directly inserted into HTML attributes such as href . In particular, when applications fail to validate URL schemes, attackers can exploit the browser’s support for JavaScript URIs to execute arbitrary code. This technique is commonly referred to as attribute-based XSS via javascript: URLs . In a typical vulnerable application, user input is used to populate an anchor tag dynamically. For example: <a href="USER_INPUT">Click here</a> If the application does not properly validate the input before inserting it into the href attribute, an attacker can supply a malicious value such as: javascript:alert(1) When rendered by the browser, the HTML becomes: <a href="javascript:alert(1)">Click here</a> At first glance, thi...

Stored XSS into href Attribute with Double Quotes HTML-Encoded Stored Cross-Site Scripting (Stored XSS) is one of the most dangerous classes of web vulnerabilities because the malicious payload is persisted on the server and served to multiple users. Unlike reflected XSS, which requires a victim to click a crafted link, stored XSS executes whenever a user visits the affected page. In this lab scenario, the vulnerability occurs inside an anchor ( <a> ) element’s href attribute, where user input is stored and later rendered with double quotes encoded , but without proper validation of the URL scheme. This creates a subtle yet powerful attack vector. To understand the issue, consider a typical application feature such as a comment system or profile field where users can submit a website link. The application stores this input and later renders it inside an anchor tag like this: <a href="USER_INPUT">View profile</a> In an attempt to prevent injection, the app...

     🧠 Reflected XSS into Attribute with Angle Brackets HTML-Encoded Reflected Cross-Site Scripting (XSS) remains one of the most common web vulnerabilities, especially when user input is embedded into HTML without proper context-aware encoding. This lab demonstrates a nuanced case where input is reflected into an HTML attribute , and although angle brackets are encoded, the application is still vulnerable due to improper handling of quotation marks and event attributes. The application reflects user input in two places. The first reflection point is inside an <input> element’s value attribute: <input type="text" placeholder="Search the blog..." name="search" value="ATTACKER_INPUT"> The second reflection appears in the page header: <h1>0 search results for 'ATTACKER_INPUT'</h1> At first glance, the presence of HTML encoding for angle brackets ( < and > ) may give the impression that the application is sec...

DOM-based Cross-Site Scripting (DOM XSS) continues to be one of the more subtle yet impactful vulnerabilities in modern web applications. Unlike traditional XSS, which involves server-side injection, DOM XSS arises entirely within the browser when client-side JavaScript mishandles untrusted data. A particularly interesting variant appears when user-controlled input from the URL fragment ( location.hash ) is passed into a jQuery selector and processed dynamically through a hashchange event. This combination creates a powerful and often overlooked attack surface. In many web applications, developers use the URL fragment identifier (the portion after # ) to control client-side behavior such as navigation, filtering, or tab switching. For example, a page might update its content based on the current hash value, allowing users to navigate without triggering a full page reload. To achieve this, developers often bind a function to the hashchange event, which fires whenever the fragment iden...

 DOM-based Cross-Site Scripting (DOM XSS) is a client-side vulnerability that arises when JavaScript takes untrusted input and places it into a dangerous execution context in the browser. A subtle but important variant of this issue occurs when user-controlled input is written into the href attribute of an anchor ( <a> ) element using jQuery . Unlike classic innerHTML -based XSS, this form relies on browser URL handling rather than HTML parsing. In this scenario, the application reads data from location.search , which contains the query string portion of the URL. Since this value is entirely controlled by the user, it must always be treated as untrusted input. The vulnerability is introduced when this input is directly assigned to the href attribute of a link without validation. A typical pattern looks like assigning a parameter such as returnpath from the URL into an anchor element, effectively allowing the user to control where that link points. The issue becomes criti...

 DOM-based Cross-Site Scripting (DOM XSS) is a vulnerability that occurs entirely on the client side when a web application takes untrusted input and writes it into the Document Object Model (DOM) in an unsafe way. Unlike reflected or stored XSS, there is no server-side injection involved. Instead, the issue exists in the JavaScript code running in the browser, which makes it harder to detect if you are not actively reviewing frontend logic. A common source of DOM XSS is location.search , which contains the query string portion of the URL. For example, in a URL like https://example.com/page?search=test , the value ?search=test is accessible through location.search . Since this value is fully controlled by the user, an attacker can modify it to include malicious content. When developers fail to properly validate or sanitize this input, it becomes a reliable entry point for exploitation. The vulnerability becomes exploitable when this untrusted input is passed into a dangerous sink ...

DOM XSS in document.write Sink Using location.search DOM-based Cross-Site Scripting (DOM XSS) is one of the most important vulnerability classes in modern web security because it occurs entirely on the client side. Unlike reflected or stored XSS, where the server plays a direct role in injecting malicious content into responses, DOM XSS happens when insecure JavaScript running in the browser processes user-controlled input in an unsafe way and inserts it into the page as executable code. One of the most common and educational examples of this vulnerability is DOM XSS in a document.write sink using location.search as the source . This pattern is widely used in security labs because it clearly demonstrates how client-side JavaScript can transform simple URL input into executable JavaScript inside the browser. Understanding this vulnerability requires breaking it down into three core components: source, sink, and execution context . Understanding the Core Components 1. Source: locat...

Stored XSS into HTML context with nothing encoded is a more severe and persistent variant of cross-site scripting compared to reflected XSS. While reflected XSS requires immediate user interaction with a crafted request, stored XSS is saved on the server and later delivered to multiple users whenever the affected content is retrieved. This makes it especially dangerous because it turns a single injection point into a reusable attack that can impact many victims over time. In this type of vulnerability, user input is stored in a backend system such as a database, comment section, forum post, profile field, or any content management system. Later, when that stored data is displayed to users, it is inserted into the HTML response without proper encoding. Because of this lack of output encoding, the browser interprets the stored input as executable HTML and JavaScript. The key condition that makes this vulnerability possible is the same as reflected XSS: the application does not encode u...

Reflected XSS into HTML context with nothing encoded is one of the most fundamental web security vulnerabilities, and it is often used as the first serious example when learning how client-side attacks work. It demonstrates a direct failure in output handling where user-controlled input is inserted into an HTML response without any encoding or sanitization, allowing the browser to interpret it as executable markup instead of inert text. To fully understand this vulnerability, it is important to break it down into three core ideas: reflection, HTML context, and lack of encoding. Each of these contributes to the final exploitability of the issue, and together they create a condition where arbitrary JavaScript can be executed in the victim’s browser under the context of a trusted website. At its core, reflected XSS occurs when an application takes input from an HTTP request and immediately includes it in the response. This input may come from query parameters, form submissions, or even HT...