\n","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:","[email protected]”>","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.","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\n[…]\n\nContent-Disposition: form-data; name=\"uploadfile1\"; filename=\"C:\\Documents and Settings\\test\\Desktop\\test.txt\"\nContent-Type: text/plain\n\ntest\n","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\"\nContent-Type: text/html\n\nalert(document.cookie)\n","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.","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 back-end system. The following steps are recommended:","Use front-end application and enter input with special/invalid characters","Analyze application response(s)","Identify presence of input validation controls","Access back-end 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:","PHP","ASP","JSP","$_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.","Tools","PHP Charset Encoder(PCE)\nPCE helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.","Hackvertor\nHackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).","BeEF\nBeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.","XSS-Proxy\nXSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.","Burp\nBurp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.","XSS Assistant\nGreasemonkey script that allow users to easily test any web application for cross-site-scripting flaws.","OWASP Zed Attack Proxy (ZAP)\nZAP 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.","References","OWASP Resources","XSS Filter Evasion Cheat Sheet","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: “CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests”","Amit Klein: “Cross-site Scripting Explained”","Gunter Ollmann: “HTML Code Injection and Cross-site Scripting”","CGISecurity.com: “The Cross Site Scripting FAQ”","\r\n Watch\r\n Star\r\n ","\r\n The OWASP® Foundation works to improve the security of software through its community-led open source software projects, \r\n hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.\r\n","WSTG Contents (v4.1)","0. Foreword by Eoin Keary","1. Frontispiece","2. Introduction","2.1 The OWASP Testing Project","2.2 Principles of Testing","2.3 Testing Techniques Explained","2.4 Manual Inspections and Reviews","2.5 Threat Modeling","2.6 Source Code Review","2.7 Penetration Testing","2.8 The Need for a Balanced Approach","2.9 Deriving Security Test Requirements","2.10 Security Tests Integrated in Development and Testing Workflows","2.11 Security Test Data Analysis and Reporting","3. The OWASP Testing Framework","3.1 The Web Security Testing Framework","3.2 Phase 1 Before Development Begins","3.3 Phase 2 During Definition and Design","3.4 Phase 3 During Development","3.5 Phase 4 During Deployment","3.6 Phase 5 During Maintenance and Operations","3.7 A Typical SDLC Testing Workflow","3.8 Penetration Testing Methodologies","4. Web Application Security Testing","4.0 Introduction and Objectives","4.1 Information Gathering","4.1.1 Conduct Search Engine Discovery Reconnaissance for Information Leakage","4.1.2 Fingerprint Web Server","4.1.3 Review Webserver Metafiles for Information Leakage","4.1.4 Enumerate Applications on Webserver","4.1.5 Review Webpage Comments and Metadata for Information Leakage","4.1.6 Identify Application Entry Points","4.1.7 Map Execution Paths Through Application","4.1.8 Fingerprint Web Application Framework","4.1.9 Fingerprint Web Application","4.1.10 Map Application Architecture","4.2 Configuration and Deployment Management Testing","4.2.1 Test Network Infrastructure Configuration","4.2.2 Test Application Platform Configuration","4.2.3 Test File Extensions Handling for Sensitive Information","4.2.4 Review Old Backup and Unreferenced Files for Sensitive Information","4.2.5 Enumerate Infrastructure and Application Admin Interfaces","4.2.6 Test HTTP Methods","4.2.7 Test HTTP Strict Transport Security","4.2.8 Test RIA Cross Domain Policy","4.2.9 Test File Permission","4.2.10 Test for Subdomain Takeover","4.2.11 Test Cloud Storage","4.3 Identity Management Testing","4.3.1 Test Role Definitions","4.3.2 Test User Registration Process","4.3.3 Test Account Provisioning Process","4.3.4 Testing for Account Enumeration and Guessable User Account","4.3.5 Testing for Weak or Unenforced Username Policy","4.4 Authentication Testing","4.4.1 Testing for Credentials Transported over an Encrypted Channel","4.4.2 Testing for Default Credentials","4.4.3 Testing for Weak Lock Out Mechanism","4.4.4 Testing for Bypassing Authentication Schema","4.4.5 Testing for Vulnerable Remember Password","4.4.6 Testing for Browser Cache Weaknesses","4.4.7 Testing for Weak Password Policy","4.4.8 Testing for Weak Security Question Answer","4.4.9 Testing for Weak Password Change or Reset Functionalities","4.4.10 Testing for Weaker Authentication in Alternative Channel","4.5 Authorization Testing","4.5.1 Testing Directory Traversal File Include","4.5.2 Testing for Bypassing Authorization Schema","4.5.3 Testing for Privilege Escalation","4.5.4 Testing for Insecure Direct Object References","4.6 Session Management Testing","4.6.1 Testing for Session Management Schema","4.6.2 Testing for Cookies Attributes","4.6.3 Testing for Session Fixation","4.6.4 Testing for Exposed Session Variables","4.6.5 Testing for Cross Site Request Forgery","4.6.6 Testing for Logout Functionality","4.6.7 Testing Session Timeout","4.6.8 Testing for Session Puzzling","4.7 Input Validation Testing","4.7.1 Testing for Reflected Cross Site Scripting","4.7.2 Testing for Stored Cross Site Scripting","4.7.3 Testing for HTTP Verb Tampering","4.7.4 Testing for HTTP Parameter Pollution","4.7.5 Testing for SQL Injection","4.7.5.1 Testing for Oracle","4.7.5.2 Testing for MySQL","4.7.5.3 Testing for SQL Server","4.7.5.4 Testing PostgreSQL","4.7.5.5 Testing for MS Access","4.7.5.6 Testing for NoSQL Injection","4.7.5.7 Testing for ORM Injection","4.7.5.8 Testing for Client Side","4.7.6 Testing for LDAP Injection","4.7.7 Testing for XML Injection","4.7.8 Testing for SSI Injection","4.7.9 Testing for XPath Injection","4.7.10 Testing for IMAP SMTP Injection","4.7.11 Testing for Code Injection","4.7.11.1 Testing for Local File Inclusion","4.7.11.2 Testing for Remote File Inclusion","4.7.12 Testing for Command Injection","4.7.13 Testing for Buffer Overflow","4.7.13.1 Testing for Heap Overflow","4.7.13.2 Testing for Stack Overflow","4.7.13.3 Testing for Format String","4.7.14 Testing for Incubated Vulnerability","4.7.15 Testing for HTTP Splitting Smuggling","4.7.16 Testing for HTTP Incoming Requests","4.7.17 Testing for Host Header Injection","4.7.18 Testing for Server Side Template Injection","4.8 Testing for Error Handling","4.8.1 Testing for Error Code","4.8.2 Testing for Stack Traces","4.9 Testing for Weak Cryptography","4.9.1 Testing for Weak SSL TLS Ciphers Insufficient Transport Layer Protection","4.9.2 Testing for Padding Oracle","4.9.3 Testing for Sensitive Information Sent via Unencrypted Channels","4.9.4 Testing for Weak Encryption","4.10 Business Logic Testing","4.10.0 Introduction to Business Logic","4.10.1 Test Business Logic Data Validation","4.10.2 Test Ability to Forge Requests","4.10.3 Test Integrity Checks","4.10.4 Test for Process Timing","4.10.5 Test Number of Times a Function Can Be Used Limits","4.10.6 Testing for the Circumvention of Work Flows","4.10.7 Test Defenses Against Application Misuse","4.10.8 Test Upload of Unexpected File Types","4.10.9 Test Upload of Malicious Files","4.11 Client Side Testing","4.11.1 Testing for DOM-Based Cross Site Scripting","4.11.2 Testing for JavaScript Execution","4.11.3 Testing for HTML Injection","4.11.4 Testing for Client Side URL Redirect","4.11.5 Testing for CSS Injection","4.11.6 Testing for Client Side Resource Manipulation","4.11.7 Testing Cross Origin Resource Sharing","4.11.8 Testing for Cross Site Flashing","4.11.9 Testing for Clickjacking","4.11.10 Testing WebSockets","4.11.11 Testing Web Messaging","4.11.12 Testing Browser Storage","4.11.13 Testing for Cross Site Script Inclusion","5. Reporting","Appendix A. Testing Tools Resource","Appendix B. Suggested Reading","Appendix C. Fuzz Vectors","Appendix D. Encoded Injection","Appendix E. History","Upcoming OWASP Global Events","Corporate Supporters","Become a corporate supporter","HOME","PROJECTS","CHAPTERS","EVENTS","ABOUT","PRIVACY","SITEMAP","CONTACT","\r\n OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided without warranty of service or accuracy. For more information, please refer to our General Disclaimer. OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright 2024, OWASP Foundation, Inc.\r\n "]}
You're viewing a past version of the Web Security Testing Guide project. For the latest stable version, visit /stable.
This website uses cookies to analyze our traffic and only share that information with our analytics partners.
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 web 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.
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 back-end 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
Figure 4.7.2-1: Stored Input Example
The HTML code of index2.php where the email value is located:
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.
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.
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.
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/plain
test
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.
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 back-end system. The following steps are recommended:
Use front-end application and enter input with special/invalid characters
Analyze application response(s)
Identify presence of input validation controls
Access back-end 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:
PHP
ASP
JSP
$_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.
Tools
PHP Charset Encoder(PCE)
PCE helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.
Hackvertor
Hackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
BeEF
BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.
XSS-Proxy
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
Burp
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.
OWASP Zed Attack Proxy (ZAP)
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.
The OWASP® Foundation works to improve the security of software through its community-led open source software projects,
hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.