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 66: Line 66:
  
 
== References ==
 
== References ==
 +
'''Whitepapers'''<br>
 +
* [1] Author1, Author2: "Title" - http://www.ietf.org/rfc/rfc2254.txt<br>
 +
* [2]...<br>
  
=== Whitepapers ===
+
'''Tools'''<br>
=== Tools ===
+
* Author: "Title" - http://www.owasp.com <br>
  
  
 
{{Category:OWASP Testing Project AoC}}
 
{{Category:OWASP Testing Project AoC}}

Revision as of 11:14, 13 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents


Brief Summary

Cross site scripting is an attack on a client (yes you) which uses vulnerablities in websites a user may visit. 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

....

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