Testing for Cross site scripting

[Up]
OWASP Testing Guide v2 Table of Contents

Brief Summary

Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. It should be stressed that although thevulnerability exists at the web site, at no time is the web site directly harmed

Description of the Issue

Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – theattacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or anyother sensitive information, which can identify the client with the web site. With the token of thelegitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user.

Black Box testing and example

---

A search function on a web application: When the "Search" button is pressed an HTTP request is sent:

GET http://www.weaksite.com/page.jsp?id=09586&searchparam=my%20favorite%20colour

This request is a typical GET request with a search parameter "searchparam". searchparam contains the search criteria/payload for the search.

The result of the search is returned to the user, redisplaying the search criteria entered: The HTML returned by the server after performing a search (acting on the http request includes:

<h1>Could not find: </h1>my%20favorite%20colour

You can see that the user input passed via the searchparam query string parameter was probably placed in a string variable on the server and inserted by

the Web application into a customised <h1> tag.

If the application is not validating input server-side (forget client-side validation, thats not security!!), an attacker could abuse this in many ways: one can make the searchparam value to be interpreted as part of the page markup (ie Javascript) rather than it being simply a value inputted by the user.

Let's try:

GET http://www.weaksite.com/page.jsp?id=09568&searchparam=</h1><textarea></textarea>

Here searchparam terminates the <h1> tag with </h1> this effectivley breaks out of a line of HTML. Then the addition on the string <textarea></textarea> is actually interprited as a piece of HTML markup and a text area field shall be

displayed.

Taking this a step further:

again, breaking out of the <h1> tag:

GET http://www.weaksite.com/page.jsp?id=10&lang=en&searchparam=</h1><script>alert(‘brennan’)</script>

The HTML output from this last request would look like:

<h1>Could not find: </h1><script>alert(‘brennan’)</script>

The browser would interpret the java script as part of the page as opposed to user input and execute and alert box with the word 'brennan' in it.

<h1>Could not find: </h1><script>alert(‘brennan’)</script>

It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a CSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for CSS attacks use the alert function, which makes it very easy to detect its success.

---

References

Whitepapers

Tools

---

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents