Unmasking XSS: Understanding Cross-Site Scripting Attacks

Hope this blog helps you understand XSS vulnerability

Prerequisites

1.Basic Understanding of HTML:

• Knowledge of HTML structure and tags.
• Familiarity with common HTML elements like <img>, <script>, <input>, etc.

2. JavaScript Fundamentals:

• How JavaScript is embedded and executed within HTML.
• Basic syntax of JavaScript, such as event handlers (onerror, onclick, etc.).
• Understanding of the alert() function.

3. How Web Browsers Interpret HTML and JavaScript:

• Understanding how web browsers render HTML and execute JavaScript.
• How browsers handle user input and display it back on web pages.

What is XSS?

Commonly known as cross-site scripting (XSS), Cross-Site Scripting (XSS) is a type of security vulnerability typically found in web applications. Occurs where an attacker can inject arbitrary JavaScript to be executed.

Types of XSS :

There are three primary types of XSS attacks, each posing unique risks to web applications:

1. Stored XSS (Persistent XSS)
   Stored XSS occurs when malicious scripts are injected into a website’s stored content — such as in a comment or forum post. When other users access this content, the script runs in their browsers, often leading to session hijacking or identity theft.
2. Reflected XSS (Non-Persistent XSS)
   Reflected XSS attacks involve sending malicious scripts via URL parameters or form inputs. When the server processes and reflects the input without proper validation, the script is executed in the victim’s browser. These attacks are often carried out through phishing emails or maliciously crafted links.
3. DOM-Based XSS
   In DOM-based XSS, the vulnerability exists in the client-side code (JavaScript). Here, the malicious script manipulates the Document Object Model (DOM) in the user’s browser without any involvement from the server. This type of XSS is particularly tricky because it does not leave traces in server logs, making it harder to detect.

Let us see a example shall we ?

Consider a web application that allows users to add a to-do list of tasks. When a user submits a task, the application displays it on the homepage without validating or sanitizing the input.

An attacker can exploit this by posting a script, like <script>alert("You are HACKED!!")</script>. As a result, a pop-up appears in the browser of any user who views the page, demonstrating a successful XSS attack.

This shows how dangerous XSS can be when input is not properly handled.

Let us see it in action shall we😎

First let us pass a normal string and see how does the web application process it.

So as we can see here, On the left, there is a simple web interface for adding items to a to-do list, with an example task “Do yoga” already present. On the right, the developer tools are open, showing the HTML structure of the to-do list. The list (ul) has an ID of "todolist", and an item (li) containing the task "Do yoga."

The functionality of the of the “user input” here is to take the input and then display it on the homepage. But as a hacker I must start thinking is this functionality properly implemented, Could I make the web application do something it is not intended to do.

So I start checking if the web application properly validate or sanitize user input. I would do this by passing html tags and seeing if it is vulnerable to “HTML Injection”.

Note: If you do not know what is “HTML Injection” you could read about it here.

As we can see in the updated list on the left side, the application did not sanitize or validate the input, resulting in the injected HTML being executed. This causes the phrase “You Are Hacked” to be displayed prominently on the page in a large heading format. The developer tools confirm this behavior, showing the injected <h1> tag in the HTML structure.

So now we can test further if the web application is vulnerable to “XSS”. Let us pass a payload to check this.

Payload : A payload in the context of cybersecurity refers to the piece of data or code that is delivered or executed as part of an attack. It is the “active” part of the exploit that actually performs the malicious action or delivers a harmful outcome.

Payload we are using : <img src=x onerror=”alert(‘XSS ATTACK’)”>

• <img> tag: This is the HTML tag used to display an image on a web page. It has a required attribute src (source), which specifies the location of the image file.
• src=x: Here, instead of providing a valid image source (like a URL), x is given as the value. Since "x" is not a valid image file, the browser will fail to load the image.
• onerror attribute: The onerror event handler is triggered whenever an error occurs while loading an image, such as when the image file is missing or invalid (which in this case it is, because x is not a valid image source).
• alert('XSS ATTACK'): When the error occurs, the code inside the onerror handler is executed. In this case, it calls the alert() function, which creates a pop-up box displaying the message "XSS ATTACK."

So as we can see the web application is vulnerable to XSS attack. Hope this example well explained how can a XSS vulnerability be found. And what does it do.

Note: It might look like reflected XSS vulnerability, But it is a DOM based XSS as the web application is not making any request to the server and nothing is sent by the server. It is a vulnerability in the client side.

Check list to see if a web application is vulnerable to XSS :

1. Is your input reflected in the response?
2. Can we inject HTML?
3. Are there any weaknesses in the Content Security Policy (CSP)?
4. Can we use events (e.g. onload, onerror)?
5. Are there any filtered or escaped characters?
6. Is your input stored and then later rendered?
7. Can you inject into non-changing values (e.g. usernames)?
8. Is any input collected from a third party (e.g. account information)?
9. Is the version of the framework or dependency vulnerable?

Learning resources:

If you have come all the way here reading the blog “THANK YOU”, I hope you learnt something from this blog. Further I would like you people to explore more about XSS and practice it. It could all be done in this website provided below.

• PortSwigger: https://portswigger.net/web-security/cross-site-scripting
• OWASP: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/07-Input_Validation_Testing/README

I hope this blog helped you understand XSS. Feel free to share your thoughts in the comments — what can be improved, and what topics you’d like to see covered next!