Reflected
Last updated
Was this helpful?
Last updated
Was this helpful?
This can lead to unauthorized actions, data theft, or redirection to malicious sites, as the script runs in the context of the trusted website.
The example below is based on OffSec's course.
This type of XSS is often found in GET requests and is based on the fact that the user trusts the domain. The application below has a search functionality where the search term is passed through a GET request and the s parameter. It is also reflected on the page via a div element (Figure 1).
A good starting point for finding XSS, is to first test for HTML injection as it has less potential for error. However, being able to inject HTML doesn't guarantee an XSS vulnerablity (Figure 2).
Since the app is vulerable to HTML injection, we can proceed testing for XSS (Figure 3).
If our target clicks the link that includes the payload, it will be executed on their browser.
In this case, the server initiates the appending of the payload (Figure 4) and the client just executes it.
The impact of Reflected Client, aka DOM-based, XSS is similar to that of Reflected Server XSS, although the discovery and payload may differ. The payload is appended on the client-side rather on the server-side, and this mean that we can't enumerate Client XSS by intercepting the traffic and reviewing the server's response. Instead, we need to let the browser render the page fully and check if the payload has worked. The application we are testing includes a GET request with the parameter name which seems to be vulnerable to HTML injection (Figure 5).
Testing for XSS seems unsuccessful, although the payload seems to be appended correctly (Figure 6).
Diving into the Network tab and reading the HTTP response, we can see that the string returned is Welcome, User! which is not what we get on our browser (Figure 7).
Scrolling down the JS file, we can find that two more resources are loaded (Figure 8).
Diving deeper into the survey.js file, we find out that it sets the innerHTML of the welcome DOM element to the value set in the name parameter. This is where our payload gets injected.
In this web application, there is a search functionality and the search term is reflected back into the page within HTML tags (Figure 11).
When our payload is inside HTML tags, we can simply add new HTML tags to trigger it. It seems that there is a blocking specific tags (Figure 12).
Trying the <body> tag results in another verbose error message (Figure 14).
We can repeat the same process and enumerate allowed attributes (Figure 15).
Now, all we have to do is delivering our XSS payload to the victim via the exploit server.
This time the search keyword ends up within a block of code (Figure 16).
The example below is based on OffSec's course.
According to , HTML specifies that a <script> tag inserted with innerHTML should not execute and it suggests using the <img> tag instead (Figure 10).
The example below is based on PortSwigger's lab.
We can create a tag wordlist using PortSwigger's , and fuzz the application to see which tags are allowed (Figure 13).
The example below is based on PortSwigger's lab.
We can treat this similar to an and try injecting JavaScript code to the search keyword (Figure 17).
survey.js file.
