XSS(Cross Site Scripting)

What is XSS(Cross Site Scripting)?

Cross-Site Scripting (XSS) is a security vulnerability found in web applications that allows attackers to inject malicious scripts into web pages viewed by other users. These scripts, typically written in JavaScript, can be executed in the context of a victim’s browser, enabling the attacker to steal sensitive information, such as cookies, session tokens, or other personal data. XSS vulnerabilities arise when user input is improperly validated or sanitized before being included in a web page’s content.

 This can lead to unauthorized actions on behalf of the user, defacement of websites, or the spread of malware. XSS exploits the trust a user has in a legitimate website, manipulating it to perform unintended actions. Proper input validation, output encoding, and the use of security headers like Content Security Policy (CSP) are crucial in mitigating XSS attacks.

In this blog, we will learn about and perform XSS, explore its types, and provide a detailed real-time example.

Basically, there are three types of XSS:-

1. 1.Stored XSS
2. 2.Reflected XSS
3. 3.DOM-Based XSS.

Let’s understand each of them in detail with examples.

1. Stored XSS:- Stored XSS (Persistent XSS) is a type of Cross-Site Scripting attack where the malicious script is permanently stored on the target server, such as in a database, forum post, comment field, or user profile. When other users view the affected page, the stored script is executed in their browsers without their knowledge, leading to various potential security breaches. This type of attack is particularly dangerous because it can repeatedly impact multiple users without any additional action from the attacker. The persistent nature of the script allows it to continuously exploit users who access the compromised content.

Real Time Example:–

Imagine a forum where users can post comments. If the comment section doesn’t properly sanitize user input, an attacker could post a comment with a hidden JavaScript payload. This payload could, for example, steal cookies or login credentials. When other users view the comment, the malicious script executes in their browsers, potentially leading to unauthorized access to their accounts or other malicious activities.

Okay, let’s try this attack on a website.

We are using the XSS payload <script>alert(‘You have been hacked!’)</script>. After posting a comment with this payload, we check if it gets stored and displays a pop-up window.

In the pop-up, we see the number 1 because we placed the number 1 in the payload inside the alert in the comment box.

Here, we can see that our text has been successfully stored in the database, which is displayed here. This demonstrates how stored XSS works.

• Reflected XSS:-  Reflected Cross-Site Scripting (Reflected XSS) is a type of security vulnerability found in web applications. It occurs when an attacker injects malicious scripts into a web request, and the server reflects that script back to the user’s browser without proper validation or encoding. Unlike stored XSS, where the malicious script is stored on the server, reflected XSS is more transient, typically occurring in response to an immediate user action, such as clicking a link. Because the attack relies on the user’s interaction with a crafted link or form, it can be exploited through phishing or social engineering tactics. If successful, the attack allows the malicious script to execute in the victim’s browser, potentially leading to the theft of sensitive information, such as session cookies or personal data.

Real Time Example:- Imagine a scenario where a website has a search feature, and the user types a query into the search bar. The site displays the search results along with the user’s query in the URL and on the page. An attacker could craft a malicious URL, such as www.example.com/search?q=<script>alert(‘XSS’);</script>, and convince the user to click on it. When the website processes the request, it reflects the malicious script directly into the HTML response without proper validation, causing the script to execute in the user’s browser. As a result, instead of seeing the expected search results, the user sees a pop-up with “XSS,” indicating that the attacker’s script has been executed.

Let’s try this attack on a website.

Here, we have entered the payload in the search box to perform a reflected XSS attack, and now, just click on the search button.

Now we can see that a pop-up appeared on the screen when we clicked the search button.

• DOM Bassed XSS:- DOM-Based Cross-Site Scripting (DOM XSS) is a type of XSS vulnerability where the attack is executed entirely in the browser through the Document Object Model (DOM). Unlike reflected or stored XSS, DOM XSS occurs when the client-side script in the web page manipulates the DOM in an unsafe way, using data from user input. This makes it a client-side issue, as the malicious script is never sent to the server but is executed directly in the user’s browser. DOM XSS often arises due to inadequate input validation or improper handling of user data in JavaScript code, making it critical to scrutinize how client-side scripts interact with the DOM. Effective mitigation requires rigorous validation and encoding practices to prevent attackers from injecting harmful scripts into the page.

Real Time Example:- Consider a website that displays a personalized greeting based on the name parameter in the URL, such as www.example.com/welcome.html?name=John. If an attacker crafts a malicious URL like www.example.com/welcome.html?name=<script>alert(‘XSS’);</script> and tricks the user into visiting it, the website’s JavaScript code, which retrieves the name parameter directly from the URL, may insert it into the DOM without proper validation or encoding. This can cause the browser to execute the injected script, resulting in a pop-up with “XSS” instead of the expected greeting. Such vulnerabilities can lead to serious consequences like session hijacking, phishing attacks, or unauthorized redirects to malicious sites.

Let’s try this attack on a website.

Here, we enter this payload to perform the DOM XSS and see if it works. To test it, just click the search button.

We received the pop-up, which indicates that the DOM XSS is working fine. Now, we’ll check it in the console.

In the console, we can see our payload, which confirms that DOM XSS has been successfully performed.

Conclusion:- Effectively mitigating XSS vulnerabilities requires a comprehensive approach. Implementing proper input validation, output encoding, and secure coding practices are essential. Additionally, employing Content Security Policies (CSP) can further strengthen defenses. By integrating these measures, you can significantly reduce the risk of stored, reflected, and DOM-based XSS attacks and enhance the overall security of your web applications.