Introduction to XSS

Do you remember when the Microsoft Exchange server was found to have a vulnerability that allowed for a Reflected Cross-Site Scripting (XSS) attack? This RXSS could have led to unauthorized access to email accounts, phishing attacks, and other actions that could change the state of the affected application. XSS attacks pose an especially grave danger, as they enable attackers to execute malicious code within the user's browser, potentially resulting in the theft of sensitive information or even complete account takeover. Nevertheless, Microsoft has addressed the issue by releasing a patch to fix the vulnerability. This underscores the importance of keeping software up-to-date and regularly checking for security vulnerabilities.

In this blog, we will learn :

1. What is Cross-site scripting (XSS)?

2. Types of XSS

3. How to find XSS vulnerabilities proactively?

4. How to prevent XSS

What is Cross-site scripting (XSS)?

XSS stands for Cross-Site Scripting, a type of security vulnerability that allows attackers to inject malicious scripts into a web page viewed by other users.

What happens if a web application has XSS? When a user visits an application that has a cross-site scripting vulnerability, the attacker's script gets executed by the user's browser. Unfortunately, this allows the attacker to get their hands on sensitive information such as login credentials, session tokens, or personal data. This can also enable other malicious actions, such as manipulating the content of the page, redirecting the user to a malicious website, or infecting the user's system with malware. The possibility of danger is endless!

XSS has multiple layers to it. Let’s deep dive into the types of XSS in the next section.

Types of Cross-site scripting (XSS)

There are three types of XXS:

1. Reflected XSS:

In 2019, a security researcher discovered a reflected XSS vulnerability in Google Translator. This vulnerability let attackers inject harmful code into translated text, which could then be run when other people viewed it. Check this image below!

Reflected XSS is a type of cross-site scripting vulnerability that occurs when an application echoes back user input in the response without properly validating or encoding it. This attack typically involves an attacker crafting a malicious link or form containing a script. When the victim clicks the link or submits the form, their browser executes the script.

Example Scenario: Suppose you have an API endpoint that retrieves a list of articles based on a search query. The server then returns the list of articles in a JSON response that includes the article title, author, and content. Here's an example of the vulnerable code that echoes back the user input without proper encoding or validation:

In this example, the $search_query variable is not sanitized or validated, and it is directly included in the JSON response returned to the user, making it vulnerable to reflected XSS attacks. Now how does the attacker perform reflected XSS here? An attacker could craft a malicious URL that includes a script as the query parameter. See below:

What happens if a user sends the request? The victim's browser executes the script, displaying an alert box with the message "XSS". An attacker can use this to steal the victim's session cookies, passwords, or other sensitive data or perform other malicious actions. Dangerous!

Don’t worry! you can prevent this by using input validation in your code. Here’s how you can sanitize and validate all user input and encode any special characters before including them in the response.

For example, the following code snippet uses the htmlspecialchars function to sanitize the user input:

In this improved code , the htmlspecialchars function expertly encodes any special characters in the user input, such as < and >, before including it in the JSON response. This input validation technique effectively prevents the browser from mistakenly interpreting the input as HTML or JavaScript code and displaying it as plain text instead. Read on as I will be discussing more techniques of input validation throughout the blog.

2. Stored XSS:

In 2018, a security researcher discovered a stored cross-site scripting (XSS) vulnerability in Snapchat that allowed attackers to inject malicious code into business.snapchat.com. The vulnerability could have allowed an attacker to steal user credentials or perform other malicious actions.

Stored XSS, also known as persistent XSS, is a cross-site scripting attack where the malicious code is permanently stored on the target Application's database or server. Unlike reflected XSS, where the malicious code includes in response to a user's request, stored XSS attacks can affect all users who access the vulnerable page or resource. Stored XSS attacks occur when an attacker can submit malicious data to a website, such as through a form or comment field, that is then stored and displayed to other users.

Example Scenario: Suppose you have an API endpoint that allows users to submit comments on an article. The server then stores the comments in a database and returns them in a JSON response, including the comment text and author. Here's an example of the vulnerable code that stores the user input without proper encoding or validation:

The $comment_text and $author variables are not sanitized or validated in this example. They are directly included in the JSON response returned to the user, making it vulnerable to stored XSS attacks. An attacker could craft a malicious comment that includes a script like below:

The payload is an HTML img element with the src attribute set to x, which is not a valid image source. When the browser tries to load the image, the onerror event is triggered because the image cannot be loaded, and the JavaScript code inside the onerror attribute is executed.

In this case, the JavaScript code sets the src attribute of the img element to a URL that includes the victim's cookies as a parameter. The document.cookie property is a string that contains all of the cookies associated with the current document, including the session cookie that identifies the user to the web application.

The URL in the payload points to a web server controlled by the attacker (http://192.168.0.1:8888/), and the cookies are included as a query string parameter (?cookies=<cookie_value>).

When the payload is injected into a vulnerable web page, and a victim visits the page, their browser will send a request to the attacker's server, including their session cookie as a parameter. The attacker can then use this cookie to impersonate the victim and perform actions on their behalf within the web application. Account takeover!

Don’t worry! you can prevent this by using input validation in your code. Here’s how you can sanitize and validate all user input and encode any special characters before storing them in the database.

For example, the following code snippet uses the htmlspecialchars function to sanitize the user input:

In this case, we sanitize the $_POST['comment'] and $_POST['author'] variables using the htmlspecialchars function with the ENT_QUOTES and UTF-8 parameters to escape any special characters that could be interpreted as code by the browser.

3. DOM XSS:

In 2022, a security researcher discovered a DOM-based cross-site scripting (XSS) vulnerability on the TikTok advertising platform ads.tiktok.com. The vulnerability allowed an attacker to inject malicious code into the platform's landing page and execute it within the user's browser. This could have potentially allowed an attacker to steal user data or perform other malicious actions.

DOM-based Cross-site scripting (DOM XSS) is a type of cross-site scripting vulnerability that occurs in the Document Object Model (DOM), which is the data representation of a web page in the browser. In a DOM-based XSS attack, the malicious payload is executed due to modifying the DOM environment in an unsafe way rather than through a traditional injection into the HTML source code or reflected in a response from the server.

The payload in a DOM-based XSS attack is often included in the URL or as part of the client-side code, and it is typically executed when the victim interacts with the page in a specific way. For example, the payload may be triggered when the victim clicks on a link, submits a form or enters text into an input field.

Here's an example of a DOM-based XSS vulnerability in JavaScript:

In this example, the user is prompt to enter their name into an input field and click a button to submit the form. When the user clicks the button, a JavaScript function called greet() executes. This function retrieves the value of the name input field and uses it to generate a personalized greeting message, which is displayed on the page.

However, there is a potential vulnerability in this code. If an attacker can manipulate the value of the name input field to include a script tag, they can inject malicious code into the page and execute it in the victim's browser. For example, an attacker could enter the following input:

In this example, the attacker injects a script tag into the page that displays an alert box with the text "XSS!".

Here's an example of how input validation and output encoding can prevent DOM-based XSS vulnerabilities in JavaScript:

Here, the developer has updated the greet() function to include input validation and output encoding in this example. The input validation step removes script tags from the name input field, preventing injected scripts from executing. The output encoding step uses the encodeURIComponent() function to encode the value of the name variable, preventing any special characters from being interpreted as executable code.

Using input validation and output encoding is one way to prevent DOM-based XSS vulnerabilities.

It's important to keep in mind that the attack scenarios and code snippets presented above are simplified illustrations for developers to understand the preventions of XSS vulnerability. The validation/prevention process may be more complex in real-world scenarios.