Exploiting XSS - Injecting into Scriptable Contexts

In our article "Exploiting XSS - Injecting in to Direct HTML" we started to explore the concept of exploiting XSS in various contexts by identifying the syntactic context of the response. In this article we demonstrate some methods of modifying your input when injecting into various scriptable contexts.

Script

Methodology_Attacking_Users_XSS_Script_1

Suppose that after inputting a benign string (asdfghjkl) to each entry point in an application, the returned page contains a variation on the following:

<script>var a ='asdfghjkl'; var b = 123; </script>

Methodology_Attacking_Users_XSS_Script_2

Here, the input you control is being inserted directly into a quoted string within an existing script. To craft an exploit, you could terminate the quotation marks around your string, terminate the statement with a semicolon, and then proceed to your desired JavaScript:

'; alert(document.domain); var foo='

In the example we are injecting into double quotes, and so use the following payload (note that spaces are URL-encoded within the payload using the + character):

";+alert)document.domain);+var+foo="

Methodology_Attacking_Users_XSS_Script_3

Finally, check that the payload appears as expected in the response.

You can then use Burp's "Request in browser" function" to test the response in your browser.

Testing Reflections in a Tag Attribute Containing a URL

Methodology_Attacking_Users_XSS_Script_4

Suppose that after inputting a benign string (asdfghjkl) to each entry point in an application, the returned page contains the following:

<a href="asdfghjkl">Click here ...</a>

 

 

 

 

Methodology_Attacking_Users_XSS_Script_5

Here the string you control is being inserted into the href attribute of an <a> tag. In this context, and in many others in which attributes may contain URLs, you can use the javascript: protocol to introduce script directly within the URL attribute:

javascript:alert(1);

In this example we have had to URL-encode the colon and add a double forward slash to comment out the remainder of the script.

Methodology_Attacking_Users_XSS_Script_6

Check that the payload appears unmodified in the response, before testing the exploit in your browser.

You can use Burp's "Request in browser" function to perform this check.

 

Methodology_Attacking_Users_XSS_Script_7

Here we can see a portion of the payload in the browser's URL display and the POC for our exploit.

It is also worth noting that in this example, the payload will fire when the "Back to album" button is clicked via the application's "Navigation" console. You can observe in the screenshot above that the link is labeled "Back to album" in the response.