Cross-Site Scripting (XSS) is one of the most common vulnerabilities that web applications face today. XSS attacks occur when an attacker injects malicious scripts into web pages viewed by others, which can lead to significant security risks such as data theft, session hijacking, and unauthorized access. Understanding XSS and its different types is essential for web developers and security professionals alike. In this article, we will explore the primary types of XSS attacks—Reflected XSS, Stored XSS, and DOM-Based XSS—with examples and demos.
What is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) is a security vulnerability that allows attackers to inject malicious scripts into trusted websites. These scripts are executed in the context of the user’s browser and can cause a variety of issues, including:
- Stealing sensitive data: Cookies, session tokens, and other private data can be captured by the attacker.
- Session hijacking: Attackers can impersonate the user by hijacking their session.
- Phishing attacks: Attackers can trick users into divulging personal information.
There are three main types of XSS attacks: Reflected XSS (Non-Persistent or Type I), Stored XSS (Persistent or Type II), and DOM-Based XSS (Type-0 XSS).
Types of XSS Attacks
1. Reflected XSS
Reflected XSS, also known as Non-Persistent XSS, occurs when malicious input is reflected off a web server without being stored. In this case, the malicious script is immediately executed as part of the web page in the user’s browser. This type of attack is commonly seen in search forms, URL parameters, and other inputs where user data is reflected back without proper sanitization.
Demo of Reflected XSS
To demonstrate reflected XSS, let’s consider the DVWA (Damn Vulnerable Web Application) lab.
- Login to DVWA with valid credentials.
- Navigate to the Reflected XSS section and set the security level to low.
- Enter the following payload into the textbox:
<script>alert('Reflected XSS')</script>
- Click Submit. The payload executes, triggering a popup with the message “Reflected XSS.”
In a real-world scenario, attackers often use reflected XSS to steal sensitive data. For instance, if an attacker wants to fetch a user’s cookie, they can execute the following payload:
<script>alert(document.cookie)</script>
Once submitted, the cookie value will be displayed in the popup, demonstrating how an attacker can steal session data.
2. Stored XSS
Stored XSS, also known as Persistent XSS, is a more dangerous variant of XSS. In this case, the malicious payload is stored in the web server’s database, file system, or other persistent storage mechanisms. When a user accesses the affected page, the script is automatically executed, potentially compromising multiple users.
Demo of Stored XSS
In a demo using DVWA, follow these steps:
- Navigate to the Stored XSS section after logging into DVWA.
- Enter the following payload into the input form:
<script>alert('Stored XSS')</script>
- Submit the form. The payload will be stored in the database.
- Whenever the page is accessed, the script will be executed, displaying a popup with “Stored XSS.”
Stored XSS attacks can affect all users who view the compromised content. For example, if the attacker cannot use a standard script tag (due to filtering), they may try an alternative payload:
<img src="x" onerror="alert('Stored XSS 2');"/>
This payload uses an image with a broken link and triggers the alert using the onerror attribute. When saved, this payload will execute whenever the page is visited, displaying the popup with the message “Stored XSS 2.”
3. DOM-Based XSS (Type-0 XSS)
DOM-Based XSS is a less well-known type of XSS attack. Unlike Reflected and Stored XSS, DOM-Based XSS occurs when the vulnerability exists in the Document Object Model (DOM) of the browser rather than the web server. This type of attack relies on manipulating the DOM in the user’s browser via JavaScript, and it doesn’t require any server-side involvement. The attack occurs when client-side scripts dynamically generate HTML based on user input, without properly validating or sanitizing that input.
How DOM-Based XSS Works
DOM-Based XSS is particularly tricky to detect because it doesn’t generate server logs or responses, making it harder to trace. Instead, it relies on vulnerabilities in the client-side code, where user inputs can modify the DOM in an unsafe way.
For example, a website may include JavaScript that reflects URL parameters into the page content. If an attacker can control the URL parameter, they may inject malicious JavaScript into the DOM and execute harmful actions.
How to Protect Against XSS Attacks
XSS attacks are preventable with proper security practices:
- Sanitize user inputs: Always sanitize and validate inputs to prevent malicious data from being executed.
- Use HTTPOnly cookies: This helps prevent attackers from accessing session cookies via JavaScript.
- Content Security Policy (CSP): Implementing a CSP can prevent malicious scripts from being loaded from unauthorized sources.
- Encode output: Always escape or encode user data when displaying it back on the page to ensure it’s treated as data, not code.
- Use secure coding practices: Regularly update and patch libraries, and avoid using unsafe JavaScript functions.
Conclusion
XSS attacks are a significant threat to web security, and understanding the different types of XSS is crucial for safeguarding applications. Reflected and Stored XSS are more commonly encountered, but DOM-Based XSS presents a unique challenge due to its client-side nature. By taking the necessary precautions, developers can protect their users from these potentially devastating attacks. Always ensure proper input validation, output encoding, and security best practices to mitigate the risks associated with XSS.
