Cross-Site Scripting (XSS)

What Is It?

Imagine you have the ability to alter the behaviour of a web page to your liking to a small (or large) subset of users. No browser plugin installation necessary, the page and it’s behaviour is yours to mess with as you see fit. You control what the user sees, the information they can send (and who it goes to), potentially including session information.

This is the kind of power an XSS vulnerability has. With JavaScript, it is possible to almost completely alter the contents of a page or even redirect users to your own page for nefarious deeds.

How does it work?

Generally speaking, it relies on a few fundamental things:

1) That the application repeats user-inputted data. Doesn’t have to be immediate, and doesn’t have to be the same user doing the inputting as the one to fall victim.

2) That the application fails to effectively separate the inputted data from the existing HTML or JavaScript code (or that such separation is possible to bypass)

There are three main types of XSS.

Reflected XSS

This is where you put the XSS code into a HTML request and have it immediately execute on the responding page. For GET-based XSS flaws, a direct link can be provided to the victim but for POST-based flaws, you’d have to trick them into inputting the XSS code themselves. You can do this by claiming the code is a secret coupon for infinite nachos or something.

Stored XSS

This is where you send your XSS code to an application in a form where it can be stored and brought up later – think something like a Facebook comment. Once the page with the XSS code, the code will execute immediately.

DOM-Based XSS

This one is a little different in that instead of exploiting bad handling of HTML code in the server’s responses, we’re exploiting bad handling of user input within the legitimate JavaScript code of the application. Imagine you’re typing into a search bar and as you type a bit of JavaScript changes a bit of text to reflect what you type. If you manage to get some Javascript code running in this reflected bit of text, you’ve got yourself a DOM-Based XSS

Testing for XSS

The simplest test one can do for XSS is to enter the following code into an input field or POST/GET request variable:

<script>alert('XSS')</script>

This defines a JavaScript block of code that presents a message box window saying ‘XSS’. Alternatively, if you’re looking to persuade someone that an XSS can do real damage, try the following:

<script>alert(document.cookie)</script>

This instead loads the document cookies (or at least the ones without the flag ‘HttpOnly’) into the message box. If those don’t work, you can try the following:

- javascript:alert('XSS')
- <iframe src='javascript:alert("XSS")' />

Among a long list of other potential XSS bypass strings.