Automating Discovery and Exploiting DOM (Client) XSS Vulnerabilities using Sboxr — Part 1

Identifying DOM XSS issues

You can read part 2 here — https://blog.appsecco.com/automating-discovery-and-exploiting-dom-client-xss-vulnerabilities-using-sboxr-part-2-3b5c494148e0

You can read part 3 here — https://blog.appsecco.com/automating-discovery-and-exploiting-dom-client-xss-vulnerabilities-using-sboxr-part-3-2ea910dfb429

This series of blogposts show how you can identify DOM XSS issues using Sboxr on Single Page or JavaScript rich applications. As examples, we solved the 10 exercises at the DOM XSS playground at https://domgo.at and created simple Proof of Concept exploits for the detected issues.

This post contains the setup instructions and solutions for the first 2 exercises. The remainder of the exercises will be covered over additional posts we will release. We will also release a gitbook that contain the solutions for all the exercises on the Appsecco books portal at https://appsecco.com/books/

Update: The gitbook is out at our Books portal -https://appsecco.com/books/automating-discovery-and-exploiting-dom-client-xss/

So what is a DOM XSS / Client XSS?

Throughout the history of Cross Site Scripting vulnerabilities, DOM or client side XSS has held a special place in the hearts of pentesters and developers alike. This variant of XSS is notoriously easy to miss using standard detection techniques and relatively easy to manifest in JS heavy applications.

OWASP defines it as type of XSS where the attack payload is executed as a result of modifying the DOM environment in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

Simply put, a Client XSS vulnerability occurs when user input from a DOM source (like location.hash) finds it's way to a DOM sink (like HTMLElement.innerHTML). There are multiple sources in DOM and there can be multiple sinks as well depending on how complex the JS is and the implemented functionality.

Detecting DOM XSS manually or by doing a code review can take a lot of time. A technique that would work is by sending the traffic from the server through a tool that can inject it’s own JS to monitor DOM changes and enumerate all sources and sinks simply by browsing the site.

Enter Sboxr

Sboxr is a tool for testing and debugging web applications, especially JavaScript heavy apps. Sboxr works by sitting in between the browser and the server and injecting it’s own JS code (called DOM sensor) that monitors the JS usage, sources, sinks, variable assignments, function calls etc. when the site is being used. It then presents, via its web console, a view of the various flows that user controlled data took in case the data ends up in an execution sink.

Setting up Sboxr and Chrome

We used a Ubuntu 18.04 to setup our attack toolchain along with Chrome 72. The following steps will get you setup:

1. Obtain a licensed copy of Sboxr from the vendor website — https://sboxr.com/
2. Sboxr requires the .NET Core SDK to run which can be installed on Linux by following the instructions at https://dotnet.microsoft.com/download/linux-package-manager/ubuntu18-04/sdk-current. For Windows, follow the instructions at https://dotnet.microsoft.com/download
3. Once installed, start Sboxr by running dotnet Sboxr.dll
4. This will start the Sboxr web interface on port 3333 (for management and analysing discovered issues) and port 3331 will be the proxy port.
5. If you wish to chain Burp or other interception proxies, browse to http://localhost:3333/console and click on HTTP Sensor to set the IP address and port for an upstream proxy (Burp or OWASP ZAP for example).

Once this is setup, we need to configure our browser to send traffic to Sboxr (which can then forward to Burp or OWASP ZAP).

Sboxr does not support SOCKS proxies yet, so you will need to chain using Burp or OWASP ZAP to socksify the traffic.

HTTPS sites may not work correctly with Sboxr as there is no certifcate to import. So we use Chrome with the --ignore-certificate-errors flag (we noticed that Firefox has trouble understanding the network.stricttransportsecurity.preloadlist option in about:config to disable HSTS checks, so we sticking to Chrome for now).

On Linux, use the following command

mkdir -p ~/.chrome;/opt/google/chrome/chrome -incognito --ignore-certificate-errors --proxy-server=http=http://localhost:3331\;https=http://localhost:3331 --user-data-dir=~/.chrome

On Windows, the following would work (assuming standard installation paths)

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -incognito --ignore-certificate-errors --proxy-server=http=http://localhost:3331;https=http://localhost:3331 --user-data-dir="C:\Users\%Username%\AppData\Local\Temp\TestChromeProxy"

Let’s Detect and Exploit DOM XSS

For this part of the post, we will work with a Client XSS playground setup by the creators of Sboxr to practice our detection and exploitation skills for Client XSS vulnerabilities.

Navigate to https://domgo.at to get started.

The following are the solutions for each of the exercises obtained using Sboxr alongwith simple Proof of Concept exploits crafted based on the source and sinks. These exploits can be used to create your own PoCs when submitting bug reports as they allow the reader to see user controlled data being executed.

Exercise 1

1. Browse to https://domgo.at/ and click on Exercise 1 from the left pane for the first exercise in the Chrome that was started with the command line options.
2. Switch to the Sboxr console and click on Code Execution in Sboxr sidebar

3. From the HTML context it is evident that the Source of Data is the location.hashproperty and the sink that causes the execution is HTMLElement.innerHTML

4. Clicking on the View Code Execution image icon opens up the code execution details window.

5. By clicking the View event location details sniper icon, we can see exactly where in the JS our data was used by the sink HTMLElement.innerHTML

6. To show that the location.hash property is exploitable, we pass JS via the source and let it reach the sink to see it executed.

7. The solution for this exercise would be to pass <svg onload=alert(document.domain)> via the location.hash property. The final exploit PoC would be - https://domgo.at/cxss/example/1?payload=abcd&sp=x#<svg%20onload=alert(document.domain)>

Exercise 2

1. Click on Exercise 1 from the sidebar to load Exercise 1
2. Click on Exercise — 2 from the sidebar to load the 2nd exercise. The clicks are required instead of directly browsing to the URL because the source in this exercise is the document.referrer property.
3. We follow the same steps as the previous exercise and start by clicking on Code Execution in Sboxr sidebar

4. We see from the vulnerable code that if a parameter called payload is available in the URL of the referrer, then this is extracted and passed to the sink.

5. We can build our exploit using the following simple HTML page. Save this as exercise2.html and host it locally (nginx/Apache/python/node/anything). Navigate to it using http://127.0.0.1/exercise2.html?payload=<svg%20onload=alert(document.domain)>

<html>
    <body>
        <h2>PoC for Exercise 2 of https://domgo.at</h2>
        <script>
            window.location="https://domgo.at/cxss/example/2"
        </script>
    </body>
</html>

6. The page will load and immediately redirect to the exercise page and since the referrer property was user controlled code execution is possible.

That’s all for this post. We will continue the exercises in subsequent posts over the next few days. See you soon!

If you liked this article, please let us know in the comments. Until next time!

Happy Hacking!!

References:

1. Sboxr — https://sboxr.com
2. DOM/Client XSS — https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#DOM_Based_XSS_.28AKA_Type-0.29
3. Chrome Command Line Switches — https://dev.chromium.org/developers/how-tos/run-chromium-with-flags

At Appsecco we provide advice, testing, training and insight around software and website security, especially anything that’s online, and its associated hosting infrastructure — Websites, e-commerce sites, online platforms, mobile technology, web-based services etc.