Technology blog::Life hacks::Linux::Hardware::Gaming

What is Cross Site Scripting? (XSS)

The importance of checking input before using it

By , 10th February 2016 in Privacy & Security

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 websites. 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 be 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 for 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 <script />.

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.

Further Reading
Comments

There are no comments for this post. Be the first!

Leave a Reply

Your email address will not be published.