Reflected Cross-Site Scripting
Let’s start to understand the details of a reflected cross-site scripting vulnerability. We are going to hear about the basic description of the vulnerability and how to search for it.
What is reflected cross-site scripting?
Reflected XSS is occurring if a malicious Javascript payload is delivered via an HTTP request, which is then immediately executed in the victim’s browser. The payload is not stored in that case.
Let’s break this down a bit. Many web applications allow a user to insert data into an input field.
As everybody in the world loves good food, let’s have a look at a recipe-sharing application. A user can search for his/her favorite dish and a list of items is returned.
Example: You want to find a recipe and find this search bar!
Let’s go and search for our favorite dish: A pepperoni pizza!
GET /recipe/search?searchItem=pepperoni+pizza HTTP/1.1
Host: example.com
The search for a pizza yielded the desired result!
An attacker could right now try to use that same request for malicious purposes. He could e.g. test the application by trying to insert an HTML <script> tag.
GET /recipe/search?searchItem=<script>alert("What%20is%20your%20favorite%20pizza?")</script>pepperoni+pizza HTTP/1.1
Host: example.comIf the application does not perform input sanitization or any output encoding, the attacker could end up seeing something similar to this:
Now that an attacker has proof that the application is vulnerable against XSS, he would have to lure his/her victim into clicking the maliciously crafted URL.
How do you search for reflected cross-site scripting vulnerabilities?
Let’s look at ways how you can manually search for reflected XSS vulnerabilities. There are also automated tools that can help you on the way. We are covering those in our “Hacking Tools” section.
Manually testing for XSS is a very time-consuming task. Firstly, we need to identify every single way a user can input data, which then gets processed by the application. Some possible ways are:
Inside an HTTP request, via
URL parameters
Message body parameters
HTTP headers
The URL file path
Secondly, we need to check if the input that we have provided is coming back in the direct HTTP response for the request sent. To ease this process, you can send an alphanumeric string (e.g. t9e8s7t6) to the application. Make sure that your string is randomly chosen and not a word that is in use by the application.
Next up, you have to monitor the HTTP response and check for the selected alphanumeric string. If you get a result, you know that your input is reflected in the server’s response. However, this is not an immediate indicator for XSS at this point.
As a next step, you have to figure out in which context your input is getting reflected (e.g. within HTML tags, inside an event handler, etc.). Depending on the context, you can start to try sending various XSS payloads to the application (more on that in the next paragraph).
How do you test for reflected cross-site scripting?
XSS vulnerabilities come in various different shapes. There is no one golden payload that works in every case. On the one hand, you can go ahead and try payloads listed on pages like OWASP’s XSS filter evasion cheatsheet. On the other hand, it is not recommended to spread payloads over an application that you don’t understand.
It’s important to understand that specific cross-site scripting payloads do not just work for either reflected, stored, or DOM-based vulnerabilities. There is a lot of common ground, which is why we are summarising attack vectors in this article.