In our previous tutorial of Stored Cross Site Scripting, we learned what Stored XSS was and how it works. Today we will learn more abou tStored XSS and how to find a website is vulnerable to a Stored XSS attack. Let’s have a basic preview of how Stored XSS works, a recap of what we learned in our previous tutorial. Below are the basic steps involved:

1. Identify data entry points from where data is keyed into database.
2. Analyze the HTML code of input web forms for potential vulnerability.
3. Verify that input web form is vulnerable to Stored XSS.

The above process is somewhat similar to what we learned in the Reflected XSS Tutorial. Let’s learn each of the above points in detail to understand the Stored XSS attack.

Identification of Data Entry Points

The very first step is to identify all the data entry points from where a user can key data into a database i.e. from where all pages data is updated into database. Typical examples of stored user input can be located in:

1. File Manager: Application that allows users to upload files, for example avatars, images, documents etc.
2. Settings or Preferences: Pages that allow users to set preferences.
3. Forums: application that allows exchange of posts.
4. Comments on Blogs: blogs allowing users to submit comments
5. Shopping Carts: application that allows users to store items into cart which they can view later.
6. User profiles: Where user enters his/her info so that others can view it.
7. Logs: application that maintains user inputs in form of logs.

Every application which accepts data as input from the user and stores it somewhere in its database is a potential entry point into the system.

Analyze the HTML Code for Tracing Vulnerability

Most website or web applications use HTML tags and Javascript for storing input from the user. Finding vulnerability is one thing but understanding the base line is another. So let’s first learn how input is stored in a web page or application.

Consider an example of normal login form of any portal which has login functionality say xyz.com; its logging snippet will look something like below if you inspect the HTML code.

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”>

We are interested in the value of “value” tag. In the above case, the hacker has to identify a way to inject the arbitrary code outside the input tag as shown below:

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”>Arbitrary Malicious Code Snippet <!– />

 

Verify Input Web Form for Stored XSS Vulnerability

This step involves verification of input validations and filtering criteria of web application. Suppose we inject the below code in above login snippet:

<script>alert(document.cookie)</script> or %3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

Then above login snippet will become something like below:

<input id=”Email” name=”Email” placeholder=”Email” value=”abc@email.com” spellcheck=”false” class=”” ENGINE=”email”><script>alert(document.cookie)</script>

Now if the input from the user is not correctly validated by the web owner then the above code will result into a popup containing cookie values. If you get a pop up with cookie values then it means the website is vulnerable to stored XSS and now you can inject whatever you wish (browser executable script).

Now every user will get this popup when he/she will reload the infected website or web page.

Stored XSS can be exploited by advanced JavaScript exploitation frameworks like XSS Proxy, BeEF, Backframe etc.

That’s all for today! In our next tutorial we will learn how to use BeEF framework to exploit Stored XSS in any webpage, so stay connected.