XSS : Crash Course

Purpose of this post is to explain different types of XSS and prevention mechanisms through multiple self paced exercises


  • JDK 1.7+ and Maven

Lab Setup

Clone :https://github.com/Prakhash/XSSSession
go to the XSSSession folder and execute “mvn tomcat7:run” to start the web application.
openup : http://localhost:8080/XSSSamples/

Example1 : Reflected

This example is to demonstrate the Reflected XSS attack

Reflected XSS occurs when an untrusted user data is sent to the web application and immediately echoed back as an untrusted content. Then, as usual, the browser receives the code from the web server response and renders it.

Clearly this type of XSS deals with the server side code.

open up http://localhost:8080/XSSSamples/reflected.jsp
Try with : <script>alert(1)</script>, you will observe the popup and also you will observe request is logged in the server console

Example2 : Persitent

This example is to demonstrate the Persitent XSS attack

Persitent XSS flaws are very similar to Reflected XSS however,rather than the malicious input directly reflected into the response, it is stored within the web application.

Once this occurred,then this can be echoed anywhere in your application and might be available to all users

open up http://localhost:8080/XSSSamples/Persitent.jsp
Try with : <script>alert(1)</script>.

Now check the stored data in the URl http://localhost:8080/XSSSamples/showDataStored.jsp,you will observe the popup when ever you are visiting to this URL.

Example3 : domAttack

This example is to demonstrate the DOM XSS attack

This form of xss attack only within the client side code. Generally this vulnerability lives within the DOM environment, and does not reach server-side code

open up http://localhost:8080/XSSSamples/domAttack.jsp
Try with the payload :<img src=”http://s1.dmcdn.net/C0N7k/1280x720-zCz.jpg"/>

you can observe an output similar to below, and if you analyze the page source of domAttackWrongPage.jsp page, you can identity the DOM elements belongs to domAttackWrongPage.jsp got manipulated with this injection.


This challenge is to demonstrate, identifying exploiting XSS using different inputs

open up http://localhost:8080/XSSSamples/Unprotected.jsp, and first try with the : <script>alert(1)</script> and analyze the page source

From the page source, you can identify there should be another </script> element added in order to close the first <script> element already available in the jsp page, you can do the exploitation using <script>alert(1)</script> only after closing the first <script> tag, So modify the script by adding </script> as follows </script><script>alert(1)</script>.

Now you will be able to exploit it.

Example5: WithInputValidation.

This example is to demonstrate, having input validation only will not helpful to prevent XSS attacks, we need proper output escaping too

Here in the input field available in the URL “http://localhost:8080/XSSSamples/WithInputValidation.jsp” , you cannot provide any inputs which contains the following characters “^[^<>]+$” as those are restricted for the input.

So the challenge is sending a post request to the “validated” servlet by passing the input validations

To exploit , you can host another webpage(Find here)which is very similar to WithInputValidation.jsp(not having pattern validation and “http://localhost:8080/XSSSamples/validated” as the action value).

So now if you submit the payload <script>alert(1)</script> to the newly hosted page, the request will be sent to http://localhost:8080/XSSSamples/validated, and you can observe the popup.

Example6 and Example 7: WithOutputEscaping and WithSPOutputEscaping

This examples are to demonstrate preventing XSS with Output Escaping.

In WithOutputEscaping example we can observe, when providing<script>alert(1)</script>, that will get printed in “http://localhost:8080/XSSSamples/escaped” page as it is, anyhow that will not get reflected. This is due to a the output escaping. By going through the page source, we can observe the behavior of the output escaping.

In WithSPOutputEscaping is demonstrating specific output escaping techniques applied for various languages.

Example8: WithContentSecurityPolicy

This example is to demonstrate the use of “Content-Security-Policy” header.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks[1]

In the example, there are no input validation and output escaping is done. If your browser is CSP compatible, then you will not be able to do any script injection to the particular input field.

Most of the latest browsers are CSP compatible. Anyway it is not advisable to always depend on CSP.


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP