Tim TrottTim TrottAlways hope, never expect

What is Cross Site Scripting? (XSS)

By , Wednesday 10th February 2016 in Security & Privacy

In this tutorial we are going to learn about Cross Site Scripting, or XSS as it is sometimes known. We'll look at the concept of untrusted data and input sanitisation.

So what exactly is untrusted data? Well, it's any piece of data in which the integrity cannot be verified, the intent may be malicious or can include payloads such as SQL injection. Cross site scripting can even be used to distribute binary data containing malware.

This untrusted data can come from many sources, but the main source is from the user, either via a query string in the URL, posted in a form submit or as we've seen previously by manipulating the raw HTTP request. We must also consider the possibility that your own database contains untrusted data - for example storing form submit content in the database.

What is a Cross Site Scripting attack?

A cross site scripting (XSS) attack is a type of injection whereby malicious scripts are injected into normally safe and trusted web sites. These scripts can perform actions such as logging keystrokes, downloading and installing malware, stealing personal information or some other action which may be of detriment to the user.

How are Cross Site Scripting attacks performed

In the most basic Cross Site Scripting attack, a script (usually a javascript include tag to a script on a remote server) is submitted as part of a form tag, it could be a username in a registration page, comments on a blog post or any other piece of data submitted on a form which is then sent to other users. If the input is not properly sanitised, this script tag will then be rendered out to any users visiting that page.

Another attack vector is through the use of search queries. A typical behaviour for a website search box is to redirect to a search engine friendly search page which contains the search term in the URL. So, for example if you search for "camera" you may well get redirected to the search page "/search/camera/". The page may also contain some fancy programming which extracts this search term, performs the search and shows some text saying something like "Here are your results for 'camera'". If this url parameter is not properly sanitised, then a malicious script could then be injected and rendered to the page. It's then simply a matter for the malicious user to then use a URL shortener for this crafted url and to distribute it on social media. Any users then clicking a link to your site with the malicious search parameter in the url will compromised.

Persistent XSS attacks

Persistent XSS is an attack not through the URL but is instead injected into your database. This type of attack is commonly used in blog comments by spammers and malicious hackers. Each time a visitor accesses the compromised page, the malicious script is downloaded and executed on their browser. This type of attack doesn't rely on a user clicking on any links to get to a page, nor does it rely on crafted query strings. The attack is already in your database from an earlier, presumably missed input sanitisation.

How to prevent Cross Site Scripting

Untrusted data will most likely come from a url parameter, or a post data parameter.

There are several methods to preventing XSS. The most common, simplest and effective method is to use input sanitisation. This involves identifying data that could be used as a malicious attempt and remove or replace it.

Examples of potentially untrusted data includes the use of < > ' / " \ and ; characters. These are often used to inject script tags into pages or to launch SQL injection attacks. We'll see more of these when we look at parameter tampering.

Another method is to employ a whitelist or blacklist approach to processing inputs. A Whitelist is very explicit: "This is what we know is good, so we're only going to allow these. A blacklist on the other hand is very implicit: "This is what could be bad so everything else must be ok"

Another essential sanitisation method in addition to input sanitisation is to encode the output as well. This will prevent things like script tags from being rendered, instead they will be shown as harmless text and not executed. For example the opening script tag would be encoded to &lt;script /&gt;.

Most frameworks and platforms have built in methods for sanitising input and encoding outputs. Please research these functions for your platform or framework.

The X-XSS_Protection header is another protection mechanism in modern browsers. Because XSS attacks conform to a fairly simple pattern - loading a script from another remote server, browsers can be instructed to detect XSS attacks and block or warn about them. You cannot rely on this however, you still need to implement input sanitising and output encoding, this is just another level of security.

My website and its content are free to use without the clutter of adverts, tracking cookies, marketing messages or anything else like that. If you enjoyed reading this article, or it helped you in some way, all I ask in return is you leave a comment below or share this page with your friends. Thank you.

About the Author

Tim Trott

Tim is a professional software engineer, designer, photographer and astronomer from the United Kingdom. You can follow him on Twitter to get the latest updates.

Leave a Reply

Your email address will not be published.