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
Testing for Cross site scripting
OWASP Testing Guide v2 Table of Contents
This article needs to be written or reviewed.
Please contact Matteo Meucci if you are interested to contribute.
This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.
Cross Site Scripting (XSS) vulnerabilities
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.
How to Test
Black Box testing
Example: A search function on a web application: When the "Search" button is pressed a 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 interprited at part of the page markup (ie Javascript) rather than it being simply a value inputted by the user.
Lets 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>