What is Cross-Site Scripting (XSS) and how could it be used?

Cross-site scripting (XSS) is one of the most common threats open to attack in modern web applications today. According to some reports, this could be as high as 47.9% of all sites being susceptible [1] [3] and is ranked as the 3rd highest issue with web applications by OWASP a research group into web vulnerabilities.

How cross-site scripting works is very simple in principle but could be very effective as a method of making a server or client run malicious code.

Simply an attacker would locate a susceptible page, add their malicious code to either an input box located on the page or by crafting a URL with the malicious code embedded, much like a query string would contain user variables. The page is then sent to the server and the server will execute the code once the server renders its response page. This could either be persistent and stored on the target server (usually in a database) or be run once when a malicious link is clicked.

In more detail there are 3 types of XSS;

Firstly, there is a stored XSS attack which is persistent, this is where the attacker’s commands are sent to the server and usually stored in a database but could possibly be stored in a victim’s browser. Each time the page is then rendered on a server the malicious content is then retrieved from the database and rendered into the page.

Second, a reflected attack, where the malicious content is included into the victim’s URL. The code is then run on the victim’s browser after being returned from the server.

Finally, a DOM based attack where a malicious link is crafted to make the browser redirect you away from the legitimate site by altering the Document Object Model (DOM).

The easiest way for me to show this is to put it in action, so I have created a simple VBScript website that stores comments in an access database.

Once a malicious comment is entered the server will render a new page. When this comment is being rendered to the page it creates an alert box appearing to the user.

Although the example is quite trivial the dangers of having these vulnerabilities exposed on a web application could mean an attacker stealing a user’s cookie, possibly giving them access to a restricted site. A full site redirection to either a spam website, ad or more worryingly a phishing site which could pose as legitimate and steal account details. Stealing sensitive variable data about a victim that would otherwise be hidden from view or getting GPS or camera data if the browser was enabled to allow this.

Luckily most modern web servers such as IIS and Apache have some protections built in. For IIS check that you are running IIS 6 or higher and request validation is turned on in your “web.config” file. For apache disable Trace HTTP requests, set cookies with HttpOnly flags and turn on X-XSS-Protection in the server configuration file.

To harden your applications from the majority of these attacks is relatively simple and OWASP provides a very comprehensive list of factors to minimise the risk of theses attack [2] but for a quick summary.

Never put untrusted data into locations they could be run as code.

Make use of escaping in HTML fields to not let the browser run code seen in these sections.

Validate your users inputs to try and mitigate any untrusted data from making it through

Use available libraries to make use of sanitising any data before using it.

Use the HTTP only tag to stop any .NET or JavaScript from accessing the cookie making it less vulnerable to attack.

Now could be the time to test your own web applications and see if you or your customers may be vulnerable to this kind of threat. More details on XSS and how to avoid it can be found below: