XSS Contexts
As someone who has worked in Web App Penetration Testing for some time now, one thing I never fully understood was how expert testers know how or when to try certain payloads in order to trigger XSS. In my eyes, knowing the right payload just meant knowing enough about web browsers, client side JavaScript, and bypass techniques to make something work. While this is partially the case, what may be more crucial to getting the results you are looking for.
This article is going to explain the concepts of "XSS Contexts" as best as this tired man can.
Know Contexts, Save Time
If you aren't familiar with XSS contexts, essentially all this means is thinking about where the payload will land in the browser and then what techniques to use based off this information.
For example, most search applications return "No results found for 'search term here'" after hitting the return button. If you use the developer console to look at the underlying html and see that the input reflects between two <h1> tags, immediately you know of a few good options to hopefully trigger XSS (terminate the h1 tag early and inject a <script> tag).
Common Contexts
- Between HTML Tags
- Inside HTML Tag Attributes
- Injection into existing JS script tag
- Injection into Template Literals
- Client Side Template Injection
We will go over each of these in the coming article.
XSS in between two HTML Tags
When looking to perform any sort of XSS, there are two things you need to see:
- Location: The location within the response where the attacker-controllable data appears
- Input Validation: Any input validation or other processing that is being performed on that data by the application
- This essentially means, identify the encoding its using and then determine how that encoding can be manipulated to trigger JS
Once you have these pieces of information you can begin fuzzing to see what is and isn't allowed.
When the XSS context is between two HTML tags, the best strategy you will have will be attempting to terminate one of the tags.
For example, if the user data ends up between <h1> tags, maybe try injecting an </h1> tag to close out the <h1> tag, then add a line of JavaScript in order to trigger XSS.
Almost always, that will be the strategy, after that it is just a matter of what kind of data you can pass to the application and what the application will allow.
XSS Between Tag Attributes
Inside of HTML tags are tag attributes. If the user controlled input is not sanitized properly, it may allow the attacker to manipulate the DOM or inject other pieces of information into the browser leading to XSS.