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.
- 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.
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.*
- 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 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.
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.
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.
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)
Another methods for prevention:
- Never use eval();
- Add security headers againt XSS
X-XSS-Protection: 1; mode=blockActivates protection on the browser;
Content-Security-Policy: script-srcThe most important one, that avoids basically any potential XSS input;
- Add the HttpOnly and Secure flags on session cookies.