How secure is your Recruitment website? Part 5 - Cross-site scripting (XSS)


Posted By: Dmitry Kulshitsky, 8:00am Tuesday 30 March 2010

According to OWASP, cross-site scripting (XSS) flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

XSS is the most prevalent web application security flaw. But what does it mean? Let’s have a look!


How does it work?

XSS attack involves three parties – the attacker, the victim (client) and the web site. A web site has an XSS flaw when it includes attacker supplied data in a page sent to the victim’s browser without properly validating or escaping that content. Attacker supplied data can be a piece of HTML or JavaScript code (hence – scripting). This code will be embedded into the web page by the vulnerable web application and sent to the victim’s browser.

Please note that the affected web site is NOT hacked as such. None of the web pages were modified by the attacker and all information in your database is still intact. What attacker controls is the content that gets sent back to the victim.


Consider the following scenario

You have a web page that is meant to welcome a logged in user:

http://www.YourRecruitmentWebSite.com/loggedIn.asp?name=Bill

Inside this page you have a piece of code that reads the “name” parameter from the query (URL) string and prints it back to the user:

Welcome, <%=Request.QueryString(“name”)%>

In our case the output that victim’s browser receives will be:

Welcome, Bill

So far, so good...But what will happen if we modify the name parameter to look something like this:

http://www.YourRecruitmentWebSite.com/loggedIn.asp?name=<script>alert(‘xss’);</script>

In this case the output will be:

Welcome, <script>alert(‘xss’);</script>

The victim’s browser would interpret this response as an HTML page containing a piece of JavaScript code. This JavaScript will be executed by the victim’s browser and the victim will see a popup window with the word ‘xss’ in it.

A piece of JavaScript supplied by the attacker was embedded into the web page by the vulnerable web application and sent back to the victim.

This is a cross-site scripting attack in its simplest form.


What is the impact?

An attacker can use XSS to do the following:
The most common method of using XSS involves tricking a victim into opening a maliciously coded page, which uses JavaScript code to open a vulnerable HTML page on the user’s local computer – often located in the directory where cached pages are stored, or perhaps a pop-up window – enabling the script to run commands with the same level of permission as the user. With this type of access, a hacker can easily corrupt a user's data, steal personal information, or take control of the user’s computer

E.g. an attacker can send a phishing e-mail to your clients purporting to be from your company asking them to change their passwords. This e-mail will contain a link to your web site with some extra code that will (by means of XSS) capture user name and password and quietly send it to the attacker’s web site.


Am I vulnerable to XSS?

Information used by your web application can arrive from multiple trusted and untrusted sources:
If you don’t validate user input and don’t encode (‘escape’) output you are most likely vulnerable to XSS.

There are many free and commercial tools available that can assist you in finding XSS problems automatically. You can use a free version of the Acunetix Web Security Scanner can scan your web site for XSS related issues.


How do I prevent XSS?

It is quite easy to prevent XSS issues from happening. All input data has to be verified and validated to be safe. Output needs to be properly encoded (‘escaped’) before it is included in the resulting output.

Escaping is the primary means to make sure that untrusted data can't be used to convey an injection attack. There is no harm in escaping data properly - it will still render in the browser properly. Escaping simply lets the interpreter know that the data is not intended to be executed, and therefore prevents attacks from working.

Don’t reinvent the wheel. All major platforms have standard security libraries that you should use. E.g. if your web site is Microsoft .Net based then consider using Microsoft AntiXSS library.

Guest blog post by Dmitry Kulshitsky, Security Architect at SEEK.