What is Cross Site Scripting? (XSS)
- Introduction to Hacking
- History of Cryptography
- Why Privacy Matters
- Supercookies in the Wild
- Ultimate Guide to SSL for the Newbie
- How Internet Security and SSL Works
- Man in the Middle Hacking and Transport Layer Protection
- Cookie Security and Session Hijacking
- What is Cross Site Scripting? (XSS)
- What is Internal Implementation Disclosure?
- Parameter Tampering and How to Protect Against It
- What are SQL Injection Attacks?
- Protection Against Cross Site Attacks
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
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.