This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Cross site scripting"

From OWASP
Jump to: navigation, search
(References)
Line 4: Line 4:
  
 
== Brief Summary ==
 
== Brief Summary ==
Cross site scripting is an attack on a client (yes you) which uses vulnerablities in websites a user may visit.
+
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 is commonly used in Phishing and identity theft attacks. The key to a vulnerable cross-site script is such that (in a nutshell):
 
The web site or web application redisplays text inputted by the user without any/proper data validation. When script (javascript normally) is entered as a
 
  
parameter value it is redisplayed to the user or to anyone that activates a link to redisplay the inputted data.
+
== Description of the Issue ==
  
== 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.
  
....<br>
 
  
 
===How to Test===
 
===How to Test===
Line 67: Line 64:
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
* [1] Author1, Author2: "Title" - http://www.ietf.org/rfc/rfc2254.txt<br>
 
* [2]...<br>
 
  
 
'''Tools'''<br>
 
'''Tools'''<br>
* Author: "Title" - http://www.owasp.com <br>
 
  
  
 
{{Category:OWASP Testing Project AoC}}
 
{{Category:OWASP Testing Project AoC}}

Revision as of 12:28, 13 November 2006

[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.

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.


How to Test

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(‘Hello’)</script>

The HTML output from this last request would look like:

<h1>Could not find: </h1><script>alert(‘Hello’)</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 'Hello' in it.

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

Gray Box testing and example


References

Whitepapers

Tools



OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents