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

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

Testing for Topic X vulnerabilities:
...
Result Expected:
...

Gray Box testing and example

Testing for Topic X vulnerabilities:
...
Result Expected:
...

References

Whitepapers
...
Tools
...