Abstract

When it comes to Web applications, the amount of vulnerabilities that may exist is undeniable. Since OWASP Top Ten 2007, Cross-Site Scripting (XSS) is amongst the most common flaws, both for it's easy exploitability and for it's significant impact for vulnerable applications.

After 14 years this kind of vulnerability is still evidenced in OWASP Top Ten 2021, composing the A3-Injection category

How does "Cross-Site Scripting" work?

In programming, a script is a series of instructions that tell a program what to do. In the Web application scenario, once it doesn't validate the information sent to the server, a malicious agent may inject custom scripts that will change the website's behaviour. It is worth mentioning that the browser can't tell between legitimate code and malicious code in this situation.

Thereby, the XSS vulnerability differs from other Web attacks, once it does not target directly the compromised app, but the users that browse to the affected solution. By using Javascript code injection on a Web page, an attacker may overcome the Same-Origin policy, which is designed to separate different websites from each other, besides the possibility of accessing cookies, session tokens and other sensitive information stored by the browser for the Website usage.

What is JavaScript?

JavaScript is a programming language that allows complex items implementation on Web pages, given that a regular Web page would only show static content. When a Web application shows interactive maps, 2D/3D graphs, animations, among other similar resources, JavaScript is surely involved. By using the "cupcake" analogy, it is the third cake layer in the standard Web technologies, of which HTML and CSS compose the first two layers.

• HTML is the markup language used to structure and give meaning to the Web content. By defining paragraphs, headers, content tables, or inserting images and videos on the page.
• CSS is the style rule language used to apply style to the HTML content. By defining background colors and fonts, and positioning the content into multiple columns.
• JavaScript is the programming language that allows creation of dynamically updated content, controlling multimedia, animated images, among other actions.

XSS vulnerable code example

<?php
        $search = $_GET['q'];
        echo "No results were found for " . $search;
?>

The image bove is an example of a code snippet that is vulnerable to XSS, once there is no validation of the *q parameter receveid through a GET request.*

XSS impact

• Redirect users to malicious websites;
• Capture keystrokes from users;
• Access browser history and clipboard content from users;
• Execute browser-based exploits (for example, crashing the browser);
• Obtain cookie information from users;
• Steal the login session token, allowing the attacker to interact with the application as the victim without having their credentials;
• Force the user to send attacker-controlled requests to a server;
• Change the contents of a webpage;
• Deceive the user for them to disclose their password to the application or other applications;
• Infect the victim with another malicious code by using a browser vulnerability, potentially taking over the victim's device.

Types of Attack

There are three types of Cross-Site scripting attacks, and despite having similarities amongst each other, their level of scope and danger are quite different. They are:

Reflected XSS

Reflected XSS is the most common and simple form of the three XSS types. It is the easiest to execute and the easiest to be detected. It is actually the only type that can be identified.

Also known as non persistent attack, it requires that the victim click on malicious links prepared with the attacker's script. The victim's browser sends the payload request to the server and it is "reflected" to the victim through an infected page.

The attacker does not need to to violate the application itself, they just need to convince the victim to click on infected links, which makes this attack a mix of social engineering and luck.

A very common example of this kind of attack is in search fields on websites, where a user inputs some information for the search, which will be displayed on the page. If the application doesn't validate this data correctly, an attacker may add Javascript code to this search field, thus executing this code.

Stored XSS

The Stored XSS overcomes the Reflected XSS limitation, which needs to be actively initiated every time by a malicious link. Stored XSS allows the attacker to inject scripts permanently into the application, thus infecting every user that accesses it. For this reason, it is also known as persistent XSS attack

Imagine that a contact/comments section of an application does not validate correctly the messages sent by the users. If an attacker inserts malicious code into these comments, this code will be executed by the browser of any users that accesses the page.

Stored XSS attacks are more complex than the reflected ones, once the attacker needs to identify a website with:

• Enough traffic to make the attack worth;
• A security vulnerability that can be leveraged by stored XSS attacks.

Once the perfect scenario is identified, a cyber criminal will be able to affect a much greater number of victims. Any person that visualizes an infected website will receive the malicious scripts on their browser, and when the script is executed, the characters that compose it are not shown in plain text on the compiled page. For that reason, the Stored XSS attack is almost impossible to detect. There are no alert signs that will raise suspicion.

DOM-Based XSS

The DOM-Based (Document Object Model) consolidates when a malicious agent modifies the interaction between the browser and the websites that the user access, changing the way the victim reacts to the sent data. While reflected and stored XSS attacks affect the HTML on the server side, the DOM-Based attacks ignore that and focus exclusively on the browser activity.

Once the attacker can intercept the process in which client-side Javascript sends its data to the Web application, they can change the way the application works on their browser.

How to protect yourself (Client)

• Disable scripts on pages where they're not needed or disable them completely;
• Avoid clicking on links from suspicious e-mails or posts in message forums;
• Access websites by directly typing their URL on your browser, instead of clicking third party links;
• Keep the software updated in order to benefit from the latest bug fixes and security patches. Regularly updating the software will significantly reduce the vulnerabilities that make Web applications prone to XSS attacks;
• Audit applications to determine which are needed and which are rarely used;

How to protect yourself (Server)

Attacks related to the A03:2021-Injection happen due to a non sanitization of information sent to the server, both on the data input from user and on the retrieval of data from the server. There are countless methods to validate the input and output of information. OWASP suggests the usage of libraries that provide the sanitization for HTML code for the languages PHP http://htmlpurifier.org/, JavaScript https://github.com/ecto/bleach and Python https://pypi.org/project/bleach/.

Another methods for prevention:

• Never use eval();
• Add security headers againt XSS
  • X-XSS-Protection: 1; mode=block Activates protection on the browser;
  • X-Content-Type-Options: nosniff Prevents Javascript code from being inserted on images or elements attributes;
  • Content-Security-Policy: script-src The most important one, that avoids basically any potential XSS input;
• Add the HttpOnly and Secure flags on session cookies.