As information security analysts, cross-site scripting usually means an alert box with some arbitrary number being shown on the screen.  But the risk involved with these attacks is far more serious than an annoying little pop up.  In 2009, Twitter became the victim of a cross-site scripting worm that exploited a stored cross-site scripting vulnerability. This spread between users, posting updates and promoting the hacker’s website.  In another example, a web mail provider called StrongWebmail offered a $10,000 prize to anyone who could gain access to the CEO’s email account.  An attacker exploited a stored cross-site scripting vulnerability in the application that allowed arbitrary JavaScript code to be executed.  The attacker sent a suitable email to the CEO, and when the email was open the script executed, compromising the CEO’s session.

But let’s start at the beginning.  There are 3 types of cross-site scripting vulnerabilities:

• Reflected – a very common type of cross-site scripting.  Typically a page will take a parameter and render it with in the HTML response. The injection is not permanent. This involves crafting a request with the embedded JavaScript that is reflected to any user who makes the request.
• Stored – a less common type of cross-site scripting that occurs when data submitted by the attacker is stored within the application.  Attacks again stored cross-site scripting vulnerabilities usually include two requests: first the attacker posting some crafted data containing the malicious code, and then the victim unknowingly executing the code. These are usually more serious vulnerabilities.
• DOM-Based – This type is slightly different from the previous two.  A user requests a crafted URL supplied by the attacker containing embedded JavaScript.  The server’s response does not contain the attacker’s script in any form.  When the user’s browser processes the response, the script is executed anyways. This is possible because the script can access the browser’s DOM (Document Object Model).

So now that we know the different types of cross-site scripting vulnerabilities, what is the real risk of them?

• Virtual Defacement – This involves injecting malicious data into a page of a web application to feed misleading information to users.  I’ve seen cases where it displays a page saying “You’ve been hacked!”. Attacks can also inject elaborate content and navigation into the site.
• Trojan Functionality – The attacker may go beyond virtual defacement and inject working Trojan functionality into the application, trying to trick users into preforming some kind of action.  This might include a fake page to enter credit card information.
• Session Hijacking – An attacker can steal valid session tokens and log into the application as that user.  We saw this in the StrongWebmail example.

So cross-site scripting is more than just an alert box on the screen.  Serious risks come with all types of cross-site scripting vulnerabilities.  Later we’ll talk about interesting places to look for these vulnerabilities besides open parameters.