Reflected DOM XSS

Description

This lab demonstrates a reflected DOM vulnerability. Reflected DOM vulnerabilities occur when the server-side application processes data from a request and echoes the data in the response. A script on the page then processes the reflected data in an unsafe way, ultimately writing it to a dangerous sink.

To solve this lab, create an injection that calls the alert() function.

Approach

After accessing the lab, I searched for any abnormal scripts in the page source code but found nothing suspicious. However, when I used the search functionality, I noticed that my input data was reflected in the response, but there was no obvious script handling this, suggesting the involvement of an external JavaScript file. By inspecting the response, I found a call to an external JavaScript file:

<script src='/resources/js/searchResults.js'>

Upon checking the contents of searchResults.js, a few lines caught my attention:

function search(path) {
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (this.readyState == 4 && this.status == 200) {
            eval('var searchResultsObj = ' + this.responseText);
            displaySearchResults(searchResultsObj);
        }
    };
    xhr.open("GET", path + window.location.search);
    xhr.send();

The script creates an XMLHttpRequest object and sets up an event handler that checks the readyState and status of the request. It then uses the eval function to evaluate the response text, which is highly dangerous. The eval function evaluates JavaScript code represented as a string and executes it, making it a prime entry point for an XSS attack.

To exploit this vulnerability, I needed to manipulate the response that gets passed to eval. I used Burp Suite to intercept the requests and found that the search GET request was followed by another GET request:

GET /search-results?search=ichyaboy HTTP/2
Host: 0a2200cf0462bb2480d021d8005f00f7.web-security-academy.net
Cookie: session=GAkmINq2h7RXY5n8wJcDQUaN95ZZ8Bms
...

The endpoint /search-results matches what the script is doing, and it returns the following response:

HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 38

{"results":[],"searchTerm":"ichyaboy"}

This JSON response is then passed to the JavaScript script where it gets evaluated as a string inside eval. To exploit this, I needed to craft a payload that would escape the " and inject my malicious code. I came up with the following payload:

\";alert(1)}//

This payload would lead to the following response:

HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 45

{"results":[],"searchTerm":"\\"-alert(1)}//"}

What this payload does is escape the " to break out of the current string context, insert the alert(1) function, and close the JSON object while commenting out the rest of the line to prevent syntax errors.

When I entered this payload into the search bar, an alert box popped up, indicating that the XSS attack was successful and the lab was solved.