Testing for Reflective XSS - Part 1

Reflected XSS, also known as Reflected Cross-Site Scripting, is a dangerous vulnerability that occurs when a web application includes user input in its output without proper validation or encoding. Reflected XSS allows attackers to inject malicious scripts that are then executed in the context of the victim's browser.

Identifying and understanding how reflected input parameters are vulnerable is crucial in ensuring the security of web applications. By following a systematic approach and using tools like Arjun, Param Miner, and Paramspider, security researchers can uncover hidden parameters and potential points of exploitation.

Preventing XSS requires proper input validation, output encoding, and awareness of where user input is reflected within the HTML context. Today, we'll cover best practices to prevent a reflective XSS attack to help developers protect their applications from the risks posed by this attack.

What is Reflected XSS?

Reflected XSS is a type of Cross-Site Scripting where the malicious script is injected via user input and immediately reflected back in the web page’s response. This occurs when input is improperly validated and included in the output without proper encoding.

Finding the Reflected Input Parameter

To begin, understand the application's functionality and identify all input vectors, such as URL parameters, forms, and headers. Test these points using simple, unique strings to determine if the input is reflected in the response. Use browser developer tools to inspect the responses and confirm reflections. Once you have identified the points where inputs are reflected, you can proceed to test for XSS vulnerabilities.

GET /search?query=test1234 HTTP/1.1
Host: example.com
User-Agent: test1234
Referer: https://example.com/previous-page
Cookie: session=test1234; user=test1234

Manual Identification

To identify reflected input parameters in a web application, follow these steps:

1. Identify Input Vectors

• Locate Input Fields: Identify all the places in the application where user input can be provided. This includes URL parameters, form fields, and HTTP headers.

2. Choose a Unique String

• Simple Test Payload: Use a unique string as a basic payload to help identify reflected parameters. For example, use “test1234”.

3. Inject string into Parameters

• URL Parameters: Add the test payload to different URL parameters and observe the responses.
  • Example: http://example.com/search?q=test1234
• Form Fields: Enter the payload in various form fields and submit the forms.
• HTTP Headers: Modify headers like “User-Agent”, “Referer”, and “Cookie” to include the payload.

4. Analyze Responses

• View Source Code: Use the browser’s developer tools to view the HTML source code of the response. Look for the injected string in the response.
• Highlighted Reflection: If the string appears in the HTML, the parameter is likely reflected.

5. Confirm Reflection

• Context Reflection: In View-Source ensure the reflection of user input “test1234” appears in a context where we can potentially break the HTML context.

Automated Testing

• Automated Tools: Use tools like OWASP ZAP or Burp Suite to automate the process of injecting payloads and analyzing responses.
  • OWASP ZAP: Use the Active Scan feature to automatically test for reflected parameters.
  • Burp Suite: Use Intruder to send multiple payloads to different parameters and analyze the reflected responses.

Open Source Tools:

1. Arjun

Purpose: Arjun helps find hidden GET and POST parameters in endpoints.

Installation: Install from https://github.com/s0md3v/Arjun

Usage:

• Identify Hidden Parameters:

  arjun -u http://example.com

• Scan Multiple URLs:

  arjun -i urls.txt -o results.json

2. Param Miner

Purpose: Param Miner, a Burp Suite extension, discovers hidden and unlinked parameters.

Installation: Install Param Miner from the Burp Suite BApp Store.

Usage: Right-click on the target in Burp Suite → extensions → param Miner → guess params.

Analyze the requests in extensions → param Miner → output

3. Paramspider

Purpose: Param Spider fetches the parameters from the web archive.

Installation: Install from https://github.com/devanshbatham/ParamSpider

Usage:

• Finding Parameters from web archive:

paramspider -d example.com

• Customize Search:
  • Use options like l to limit the scope and p to specify a particular parameter.

Paramspider will show you the parameters and where exactly you can fuzz.

Enumeration for Reflection Context

In HTML context, string reflection refers to situations where a web page includes user-supplied input in its HTML output without the proper sanitization or encoding, such as within HTML tags. This lack of procedures can potentially lead to Cross-Site Scripting (XSS) vulnerabilities. Let’s look at some examples.

Reflection: In Between Tags

• Suppose you have a search form on your website where users can enter a search query. If a user searches for “test1234”, the URL might look like this:

• After processing this input, the web application includes it in the HTML response:

In this instance, the system reflects the string in the HTML context between HTML <h1> tags. Sometimes, the reflection might occur within a <p> tag, <title> tag, or even a <div> tag, depending on the application.

Reflection: Attribute Value

When an application reflects user input within an HTML attribute without proper sanitization or encoding, it creates XSS vulnerabilities. For instance, if an application directly reflects your input like test1234 in a tag such as <input type="text" value="test1234">, you can inject an XSS payload to execute malicious scripts.

Input: https://abc.com/?search=test1234

Reflected Output:

• Input: https://abc.com/?search=test1234
  • The user input from the GET-based “search” parameter is reflected in two places within the HTML context.

We identified two primary reflection points:

• Reflection 1: The user input is reflected between HTML tags, specifically <h1>. Other tags where input might be reflected include <p>, <strong>, <head>, and more.
• Reflection 2: The user-supplied input is reflected in the attribute value. There could be different possibilities for exploitation depending on the input, such as if type=hidden.

After this, we proceed to step 2 to understand how the input is being encoded and how to break the context in both reflection cases.

Step 2: Understanding the HTML Context

The purpose of this step is to understand what is being blocked or filtered by the application.

• Input: https://abc.com/?search=test1234<
  • This input includes a starting angle bracket < and double quotes ", which are crucial to disrupt the HTML contexts for Reflection 1 and Reflection 2.

We need to observe how the reflection would appear in the application’s “view-source:” if there is no filtration of the user’s potentially harmful input.

Step 3: No Sanitization in Both of the Reflections

In this case, no encoding of special characters is happening. It is noticeable that our second special character’s color is changed in the Reflection 2 which can be considered as the valid syntax of HTML.

• Input: https://abc.com/?search=test1234<img+src=x></img>"
  

The color change in Reflection 1 indicates that the <img> tag we entered is interpreted as valid HTML. In contrast, the color of the user input in Reflection 2 remains the same, suggesting the input is not interpreted as HTML.

After this, we understand how we can break the syntax in these two cases when the input is getting encoded in URL encoding or getting sanitized.

Step 4: Performing XSS in Reflection 1

Input:  https://abc.com/?search=test1234<img+src=x+onerror=alert('Cobalt')></img>"autofocus=""onfocus="alert('Cobalt')"

In this case, the payload is:

• <img>: This is an HTML image tag used to embed an image in the web page.
• src=x: This is an attribute of the image tag. src stands for source, which is used to specify the URL of the image. Here, x is a non-existing source, which will fail to load.
• onerror: This is an event attribute which executes JavaScript code when an error occurs while loading an external file (in this case, an image).
• alert('Cobalt'): This is a JavaScript function that displays an alert box with the message ‘Cobalt’. This function executes when the onerror event triggers due to the failure of the image load.
  

Step 5: Performing XSS in Reflection 2

• Input: https://abc.com/?search=test1234<img+src=x></img>"autofocus=""onfocus="alert('Cobalt')"
  

In this case, our attributes autofocus and onfocus are successfully injected as a valid HTML syntax.

The payload is broken down as follows:

• <input type="text" name="search" id="search" value="test1234&lt;img src=x&gt;&lt;/img&gt;"> is an input field of type text with the name and id “search”.
• autofocus is an HTML attribute that specifies that the input field should automatically get focus when the page loads.
• "onfocus="alert('Cobalt')"" is an HTML attribute that triggers a JavaScript alert with the message”Cobalt” when the input field gets focus.
  

The XSS in Reflection 2 is also successful. We have seen just two very basic cases of enumerating the XSS issue; there are numerous ways to bypass the advanced WAF. It is suggested to learn the basics of JavaScript to understand more about the XSS.

How to Prevent XSS?

• Ensure you remove or escape harmful characters from user input.
• For example, strip out or encode <, >, &, and ".

• Properly encode any user-supplied input before reflecting it in the HTML response.
• Convert special characters to their respective HTML entities. For instance, " should become &quot;.

• Implement secure frameworks that handle input sanitization and output encoding automatically.
• Avoid directly inserting user input into the HTML structure.

Final Thoughts

Testing for XSS threats is important. Instead of just throwing a lot of random payloads into an application, take the time to check each piece of input. This way, you’re sure to catch any weak spots.