This page may be out of date

We haven't updated it for a while because we're busy working on new, improved content to help you get the most out of Burp Suite. In the meantime, please note that the information on this page may no longer be accurate.

Visit our Support Center

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.



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>


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):



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


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>






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:


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.


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.



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.