Introduction to Cross-Site Scripting

Cross-Site Scripting (XSS) is a security vulnerability that primarily stems from inadequate input validation and output encoding within web applications. For bug bounty hunters, XSS is one of the most lucrative and frequently reported vulnerabilities, often fetching significant rewards due as it is easy to find and can have a massive impact.

The sheer prevalence [widespread existence] of XSS is evidenced by its consistent inclusion in the OWASP Top 10 list of the most critical security risks to web applications over the last decade.

This type of vulnerability exists because developers fail to implement strict validation controls across all data entry points in an application. While XSS is traditionally found in HTML forms where users interact directly with the application, vulnerable inputs can also originate from:

• Interactions between other applications.
• Environmental variables.
• External data sources.

A Client-Side Focus

One of the most curious and defining characteristics of XSS is its focus on the client side. Most other common web vulnerabilities target the application itself, exploiting the backend [the server-side code and database] to cause a failure.

In contrast, XSS attacks inject malicious code—usually JavaScript—into a web page viewed by another user. The attack is successful when the victim’s web browser executes the malicious script, meaning these attacks require user interaction to be successful.

Understanding the Core XSS Types

The primary and most fundamental types of XSS attacks are categorized based on how the malicious script reaches and is executed by the victim’s browser.

The Attack Taxonomy

1. Reflected Cross-Site Scripting

Reflected XSS, sometimes referred to as First-Order XSS, is a non-persistent vulnerability. It is executed at the exact moment a user clicks a malicious link or submits a specially crafted [skillfully made, often deceptive] form.

The malicious script is immediately “reflected” off a web application server and delivered to the user. It most commonly affects GET requests, where the input is sent via the URL parameters.

Impact Explained Through an Example

Imagine a scenario where a user, like your grandmother, receives a phishing email that appears to be from her bank. The email offers a promotion and contains a link. The user, checking the address bar, confirms the bank’s valid domain name, seemingly following good security practices.

However, the link itself contains a malicious payload [the harmful code being delivered], such as:

www.bankforoldpeople.com/access?account='>

www.bankforoldpeople.com/access?account='>

When the user clicks the link, the bank’s web server takes the unvalidated input from the account parameter and includes it directly in the resulting page displayed to the user. The browser, seeing the unclosed tag ('>) followed by the tag, executes the attacker’s code. The result could be:

• The theft of the user’s session cookies.
• Redirection to a malicious login page to steal credentials.
• The automatic execution of an unauthorized transaction.

2. Stored Cross-Site Scripting

Stored XSS, also known as Persistent XSS or Second-Order XSS, is significantly more dangerous because the malicious attack string is permanently stored in a data storage component, typically a database.

The attack requires two distinct steps:

1. The attacker injects a malicious string into a form (e.g., a comment section, a user profile field, or a message board).
2. The application accesses this information and shows the malicious string to any user who views that stored data, causing the script to execute repeatedly in their web browser.

A Real-World Scenario

In a reported incident, a security researcher targeted an application where developers had bypassed the security features of the Laravel framework, choosing to write input-handling code using PHP directly. This lapse created a vulnerability.

The researcher used a tool like Burp Suite’s Intruder to insert a malicious string into customer profile fields, which were stored in a MySQL database. The application’s purpose was to allow customers to view revenue generated by marketing campaigns.

The failure occurred when customers accessed the application:

• The application searched the database for the profile information.
• It read the malicious string from the stored data.
• It displayed a series of alert pop-ups to the users for each affected field, rendering the application unusable due to the overwhelming quantity of alerts.

This demonstrates Stored XSS: the malicious payload was persisted in the database and then served to many unsuspecting users.

3. DOM-Based Cross-Site Scripting

In Reflected and Stored XSS, a data source interacts with the application server to insert a value. DOM-based XSS is different because the server is often not involved in the actual attack execution.

In this type of attack, the vulnerability lies entirely within the client-side script itself.

Understanding the Document Object Model (DOM)

To grasp DOM-based XSS, an understanding of the Document Object Model (DOM) is necessary.

The DOM is an interface for HTML and XML documents that allows scripts to access and modify the structure, style, and content of a document. It structures a web page into a series of nodes and objects, connecting the document with programming languages, most notably JavaScript.

The Client-Side Vulnerability

In a DOM-based XSS attack:

1. The user sends a crafted URL containing the malicious code (e.g., in a URL fragment or query parameter).
2. The server processes the request, but does not include the injection in the response body.
3. Instead, a client-side script in the user’s browser processes the response and pulls data from the DOM (e.g., from the URL’s hash or query string) without proper sanitization.
4. The script then executes the malicious injection, which was never sent from or processed by the server.

For instance, consider a script that reads a message parameter from the URL and writes it directly to the page:

script>
    // Get the part of the URL containing the parameters
    var message = document.location.search.substring(1); 
    
    // Write the unvalidated message into the page's HTML
    document.getElementById("output").innerHTML = message; 
script>

If the value for message is a malicious string, the script will show the attack to the user in the browser. The malicious string never originated from the server’s code; it was entirely processed on the client side using a property contained within the DOM.

Other Important XSS Variations

While the three types above form the basis of all XSS attacks, the bug bounty community uses additional terms to describe specific contexts or exploitation methods that are crucial for reporting.

Blind XSS

Blind XSS occurs when an application reads data from a data source that is shared with one or more other applications. This is essentially a form of Stored XSS, but the attacker is “blind” to the direct result of their payload because they cannot see the victim’s application.

For example:

• A public-facing application accepts customer feedback, which is stored in a database.
• An internal administrative application reads that same database to display the feedback to an employee.
• If an attacker injects a malicious payload into the public feedback form, the script will be executed when an internal administrator (the “blind” victim) views the feedback in their secure panel.

The payload is stored via one application but executed via another, often granting the attacker access to a high-privilege account.

Flash-Based XSS

Years ago, a technology called Flash (developed by Adobe, now deprecated and largely obsolete) was widely used for creating dynamic websites and interactive content. Because Flash allowed graphic designers and inexperienced users to create forms and routines without deep programming knowledge, many Flash-based applications suffered from a lack of input validation.

An XSS vulnerability found in these applications was historically referred to as Flash-based XSS. Today, these are simply considered standard XSS vulnerabilities that were present in applications built on the Flash platform.

Self XSS

Self XSS describes a scenario where a user is tricked into auto-executing an XSS attack on their own web browser. The vulnerability is not in the injection point but in the potential for social engineering.

The victim copies and pastes a malicious script (or payload) into their browser’s console, causing the XSS to execute on their own session. Although the user is “hacking themselves,” the goal is to steal sensitive information like cookies or session tokens which are then forwarded to the attacker.

While once considered low-risk, security researchers have demonstrated that this can be successfully exploited through sophisticated social engineering vectors. For a deeper dive into this, the presentation Self XSS we’re not so different you and I is available for review: Self XSS we’re not so different you and I.

Detecting Cross-Site Scripting (XSS) Bugs

Detecting XSS vulnerabilities fundamentally involves testing every user-controlled input to determine how the web application processes and displays the data in its response. The primary tool used for this process is an HTTP Proxy, such as Burp Suite or OWASP ZAP.

The Core Detection Strategy

The detection process is systematic and focused on analyzing the application’s response to special input characters.

1. Using an HTTP Proxy

The first step is to route all application traffic through an HTTP Proxy. This allows a security professional to intercept, analyze, and modify every HTTP request made by the application being assessed.

The goal is to analyze each input field by field by modifying the content with basic testing strings.

2. The Basic XSS Test String

The most basic and essential test string used to check for XSS is often.

script>alert('XSS')script>

This string attempts to execute a simple JavaScript function (alert()) that, if successful, will display a pop-up box, confirming the vulnerability.

3. Tip: Identify Reflected Inputs

A crucial tip for finding input validation vulnerabilities is to note that any input taken from the user and immediately shown back to them in the application’s response is susceptible to a vulnerability.

For example, when a user submits a comment, the application might respond with:

• “Thank you for your comment, [Username]!”

The value of the [Username] parameter is a direct reflection of the user’s input, making it a high-priority target for testing.

Step-by-Step Character Analysis

To confirm an XSS vulnerability, a hacker or tester must understand how the application handles special characters that are fundamental to HTML and JavaScript syntax.

Step 1: Inputting Special Characters

Insert a string of special characters that are commonly used in HTML and JavaScript code into the target input field. These characters are critical because an application must properly encode [convert a character into a different format] them to prevent script execution.

A common test string includes:

 ' " / ;

 > ' " / ;

These characters are used to:

• and >: Open and close HTML tags.
• ' and ": Define string boundaries and attribute values.
• /: Close tags and define paths.
• ;: End JavaScript statements.

Step 2: Examining the Application’s Response

After submitting the special characters, immediately examine the HTML source code of the application’s response. This is the most critical step.

A secure application should encode or sanitize these characters, preventing them from being interpreted as code. For example, a properly secured application might convert the string to:

Step 3: Verifying Unsafe Character Handling

If, upon checking the HTML source code of the response, you find that the application is showing the special characters just as they are (e.g., is reflected as and not <), this is a strong indicator of a vulnerability.

When the browser parses the unencoded characters, it interprets them as executable HTML or JavaScript, meaning a successful XSS payload can be injected.

Evading Security Measures: Bypassing XSS Input Validation Controls

While many modern web applications implement security measures like input validation, sanitization, and output encoding to prevent Cross-Site Scripting (XSS) injections, these controls can often be circumvented [skillfully avoided or overcome] by a determined attacker or bug bounty hunter. Bypassing these filters typically involves creative use of encoding, character modification, and dynamic string construction.

Common Testing Strings and Wordlists

To automate the detection process, security researchers use comprehensive lists of known malicious strings, or payloads. These strings are designed not only to trigger a simple XSS alert but also to test for vulnerabilities in SQL Injection, and other forms of code injection.

A Library of Payloads

Here is a list of common strings you can use to detect various injection vulnerabilities:

test\>

http://
test

Slack Stored XSS via Markdown Editor

This report details a high-impact Stored XSS vulnerability in a critical enterprise collaboration tool.

Vulnerability Description

The vulnerability was identified within Slack’s real-time document-editing feature for text posts. This feature allows multiple team members to collaborate on a document simultaneously.

1. When a document is uploaded, it is stored in the /files/ directory of the Slack domain.
2. The XSS was triggered in the editing mode when a user modified a post that contained a link with a JavaScript URI payload.
3. The core of the vulnerability relied on catching modifications from the WebSocket and injecting the malicious payload there.

The Exploit Mechanism

The attacker used the following test URL, which pointed to the file:

https://marqueexss.slack.com/files/marqueexss/F0283AA4K

The goal was to embed a malicious link behind a piece of text, such as:

This payload listed as javascript:alert(“XSS”) is the vulnerable code with a link embedded behind it.

Since direct injection of the javascript:alert("XSS") payload into the text was filtered, the attacker bypassed the control by injecting the payload into a WebSocket notification. When multiple users edit a document, their changes are communicated via WebSocket messages.

The attacker executed the following steps:

1. Delete an existing link behind the target text.
2. Press Ctrl + Z to undo the deletion.
3. Put the link back using the editor.
4. Capture the WebSocket request that communicated this change.
5. Modify the request to insert the malicious JavaScript URI payload (JavaScript:alert(\"XSS\"%29) into the links parameter of the WebSocket JSON payload.

This successfully stored the payload within the document’s link metadata. When other team members viewed or edited the document, the malicious link would execute the JavaScript, compromising multiple users.

Key Learning from this Report

• Test Non-Traditional Inputs: An XSS vulnerability does not have to be in a parameter that is visible in the original HTTP request. Bug hunters must test all requests, including those generated by WebSockets or internal application logic.
• Turning Self-XSS into Stored XSS: The reporter initially leveraged a client-side action (undo/redo) but went to great lengths to document and prove that the vulnerability resulted in a Stored XSS that could affect other users, significantly increasing its impact and bounty value.

Trello DOM-based XSS via Wistia Integration

This report is an excellent example of finding a vulnerability not in the target application, but in a third-party service that the application relies on.

Vulnerability Description

Trello, which utilizes boards and cards for project management, integrates with Wistia for embedding videos. The XSS vulnerability was found in how Trello utilized Wistia’s video embedding mechanism, specifically in a vulnerable Wistia JavaScript library (fast.wistia.net/assets/external/E-v1.js).

The attack was a DOM-based XSS because the injection was executed by the user’s browser (client-side) using URL parameters, not by the Trello server.

The Exploit Mechanism

The vulnerability was triggered by combining two specific URL parameters used in the Wistia embedding process:

1. wchannel Parameter: Used to load external JavaScript from the vulnerable Wistia libraries.
2. callback Parameter: Used to control the output of the script being loaded.

The attacker crafted a URL that chained these two parameters together, forcing the Wistia script to include and execute a malicious payload in its output.

A typical exploitation URL looked like this:

https://fast.wistia.com/embed/medias/[video_id].json?callback=[controlled output]

The full malicious URL payload, when executed on Trello’s guide subdomain, demonstrated the vulnerability:

https://trello.com/guide/customize.html?wchannel=../../../../embed/medias/1yqpy8ics4.json%3fcallback%3dalert(1)%253bvar%20x%3d%27%253bx(//%23

This payload resulted in an XSS alert box being displayed on various Trello subdomains (e.g., trello.com/guide, blog.trello.com, help.trello.com), demonstrating the wide reach of the reflected attack.

The vulnerability was significant because it functioned as a reflected XSS and could potentially compromise Trello and all other websites using the vulnerable Wistia video integration, such as Olark and WordPress.

Key Learning from this Report

Creative Payload Crafting: Success depended on crafting a payload that utilized the third-party parameters (wchannel and callback) to achieve code execution in the target environment (Trello).

Test Third-Party Integrations: The most important lesson is that bug bounty hunters must look beyond the target application’s code and test all third-party libraries, widgets, and integrations (e.g., video players, comment sections, analytics scripts). A vulnerability in a third-party script can easily become an exploitable vulnerability on the host domain.

Shopify XSS: SVG Whitelist Bypass

This report demonstrates how a seemingly secure file upload feature can be bypassed using cleverly crafted XML within a Scalable Vector Graphics (SVG) file, leading to a high-impact Stored XSS that spans multiple domains.

Vulnerability Description

Shopify allows developers to create applications for their platform, including sales channel extensions. Developers can upload icon images for these apps in formats like JPG, GIF, and SVG (Scalable Vector Graphics).

Shopify had a file extension whitelist in place (meaning only approved extensions like .svg were allowed), but the SVG decoding was not properly implemented at the endpoint.

The vulnerability allowed an attacker to upload a maliciously crafted SVG file that contained an XSS payload using XML entities.

The Exploit Mechanism: SVG Payload

The attacker used the following SVG code, which leverages an external entity within the Document Type Definition (DTD) to define and execute the XSS script:

svg [
sp "">
spx "">
%spx;
]>
&elem;

DOCTYPE >svgstrong> [
!ENTITY % strong>spstrong> "script>alert(1)script>">
!ENTITY % strong>spxstrong> "!ENTITY % elem '%sp;'>">
%spx;
]>
&elem;

When this SVG icon was uploaded and then accessed by a victim, the browser would:

1. Parse the SVG file.
2. Process the DTD, which defines an entity (sp) containing the XSS payload ().
3. Execute the entity reference &elem;, which resolves to the XSS payload.

XSS in Major Applications

To conclude the discussion on Cross-Site Scripting, here are several real-world examples, extracted from actual bug bounty reports, that illustrate the variety and impact of XSS vulnerabilities found in major applications.

1. Shopify Wholesale (Reflected XSS via “Magic URL”)

This report demonstrates how a vulnerability can exist even without a visible parameter name, relying on the application’s unique URL routing.

The Exploit

The vulnerability was found in the application’s custom URL structure, sometimes referred to as a “Magic URL,” where each path segment (or “word”) in the URL is treated as an input parameter by the backend routing logic. This is common in applications that auto-generate URLs, like blogs or online stores.

The attacker was able to inject an encoded payload into the path segment:

• %27%3Balert%28%27XSS%27%29%3B%27 decodes to ' ; alert('XSS') ; '

When the server failed to validate or encode this path segment before reflecting it into the HTML, the script executed, confirming a Reflected XSS.

Original Report Link: https://hackerone.com/reports/106293

2. Shopify Gift Card Cart (Reflected XSS in Form Data)

This report highlights the importance of testing every field within a form submission, even those related to file uploads.

The Exploit

The bug hunter discovered that the Artwork file parameter, sent within a multipart/form-data POST request (typically used for file uploads), was vulnerable to XSS. By inserting JavaScript code into this field’s value, the script was reflected back to the user, proving the lack of input validation on file metadata fields.

Original Report Link: https://hackerone.com/reports/95089

3. Shopify Currency Formatting (Stored XSS)

This bug is a slightly more complex example of Stored XSS, found in an administrative configuration panel.

The Exploit

The researcher discovered that fields used to customize the display of the store’s currency formatting and personalized links did not properly validate user input.

1. The attacker injected a malicious script into these customization fields.
2. The script was stored in the application’s database.
3. When any user (potentially including a store administrator) accessed the application, the saved, unvalidated data was retrieved and rendered, causing the script to execute.

This type of bug can lead to admin-level session compromise.

Original Report Link: https://hackerone.com/reports/104359

4. Yahoo Mail (Stored XSS via Auto-Generated HTML)

This high-value report demonstrates how XSS can be introduced through the application’s own auto-generated code snippets.

The Exploit

The vulnerability was in the Yahoo Mail editor. When a user clicked to “Attach files from computer,” Yahoo Mail automatically generated an HTML snippet of code to represent the attachment within the email body.

The auto-generated HTML included a vulnerable data-url parameter. The attacker crafted an email where the attachment link pointed to a malicious JavaScript URI:

<a href="...a.txt" data-url='javascript:alert("XSS")'>...</a>

a href="...a.txt" data-url='javascript:alert("XSS")'>...a>

By injecting the payload into the data-url attribute, the script was stored as part of the email content. When the victim viewed the email in the vulnerable editor, the browser executed the script. This is particularly dangerous as it turns the email client itself into a vector for a Stored XSS attack.

Original Report Link: https://klikki.fi/adv/yahoo2.html

5. Google Image Search (Reflected XSS with Time Delay)

This example is notable for its use of an obscure XSS execution vector—requiring a user action (pressing the Tab key) and a time delay.

The Exploit

When a user opened an image in Google Search using the “Open in new tab” option, a complex URL was generated that included the image source in the imgurl parameter.

The researcher found that the imgurl parameter could be manipulated to contain a JavaScript URI payload using the url parameter within the final redirect chain:

...&url=javascript:alert(1)&psig=...

The unusual part was the execution. The XSS was not launched immediately. The browser required the user to press the Tab key to interact with the element containing the vulnerable script. After a short period of time following this interaction, the XSS script was executed. This demonstrates that even delayed or interaction-dependent script execution can constitute a valid and reportable XSS vulnerability.

Original Report Link: https://mahmoudsec.blogspot.com/2015/09/how-i-found-xss-vulnerability-in-google.html

Summary of XSS Detection and Mitigation

The real-world examples and technical discussions highlight crucial lessons for security professionals:

Persistence and Variants: Be persistent and use a wide range of payload variants and encodings (URL, HTML, Base64). Developers often use simple blacklists that can be easily circumvented. Finding a bypass just requires time and creative testing.

XSS is an Input Validation Error: All XSS vulnerabilities ultimately derive from a fundamental lack of proper input validation and output encoding controls on the server-side.

Test All Inputs: Review not just the fields in standard HTML forms, but all input data in an application, including:

URL path segments (Magic URLs).

GET request parameters.

Hidden form fields and file metadata.

Parameters used in the application’s control flow.

Utilize an HTTP Proxy: Always use an HTTP proxy (like Burp Suite or OWASP ZAP) to analyze and modify HTTP requests, allowing you to bypass client-side security controls and test the back-end logic directly.