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

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

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

This is Part 2 of a series of blogposts to 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 part of the series contains the solutions for the next 4 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/

Exercise 3

In a lot of web applications, data from external third party apps can be made part of your target application using a sink without sanitising the received response. In such cases, the third party application’s XHR endpoint then has the ability to inject malicious code into your target application. Even in cases where the XHR response comes from the same site, you need to verify how the data ended up on the server. In modern applications apps collect untrusted data from different sources and store them in a server side database and eventually this untrusted data finds it’s way into the target application causing a persistent DOM XSS.

This exercise involves a XHR request to a JSON endpoint that reflects data to the client. The reflected data is then added to the sink HTMLElement.innerHTML allowing execution of arbitrary code.

1. Enter a random string in the text box on the Exercise page and click on Execute Payload button.

2. The data is being reflected by a JSON endpoint at https://domgo.at/data.json?payload=thanos

3. View the flow of the data from source to sink using Sboxr under Code Execution window

4. We can see exactly what from the JSON response is used in the sink and create an exploit.

5. To exploit, pass the string <img src=1 onerror=alert(document.domain)> in the text box

Exercise 4

Similar to XHR responses, trusting websocket data to be benign regardless of where it comes from can lead to DOM XSS issues.

This exercise involves a websocket request to a secure websocket endpoint that reflects data to the client. The reflected data is then added to the sink HTMLElement.innerHTMLallowing execution of arbitrary code.

1. Enter a random string in the text box on the Exercise page and click on Execute Payload button.

2. The data is being reflected by a Websocket endpoint at wss://domgo.at/ws

3. View the flow of the data from source to sink using Sboxr under Code Execution window

4. We can see exactly what from the response is used in the sink and create an exploit.

5. To exploit, pass the string <img src=1 onerror=alert(document.domain)> in the text box

Exercise 5

Communication channels like XHR, fetch API, websockets or postMessage are often overlooked but can often end up as DOM XSS sources. Especially, if the data is coming from a different origin. Trusting data in a response and rendering/evaluating it via a sink can lead to DOM XSS issues and as an analyst you have to lookout for these sources.

This exercise involves a postMessage that sends user controlled payload to a window.onmessage event handler and sinking the data to HTMLElement.innerHTMLallowing execution of arbitrary code.

1. Enter a random string in the text box on the Exercise page and click on Execute Payload button.

2. The source of the data in this case is a Window Message from https://domgo.at(same origin).

3. View the flow of the data from source to sink using Sboxr under Code Execution window

4. We can see exactly what from the response is used in the sink and create an exploit.

5. To exploit, pass the string <img src=1 onerror=alert(document.domain)> in the text box

Exercise 6

Another interesting source of untrusted data is browser storage sources which include localStorage, sessionStorage and IndexedDB. Although DOM Storage cannot be controlled by an attacker directly (unless there is an XSS already in the app), an attacker may be able to introduce malicious data into a storage source via other HTML elements or JS sources. This data can end up in a sink from the storage source and cause a DOM XSS.

A good example of this would be a DOM XSS on a Twitter sub domain — https://hackerone.com/reports/297968

In this exercise, the source of the data is HTML LocalStorage. JS in the page reads data from localStorage and sinks it into HTMLElement.innerHTML allowing execution of arbitrary code.

1. Enter a random string in the text box on the Exercise page and click on Execute Payload button.

2. The source of the data in this case is HTML localStorage.

3. View the flow of the data from source to sink using Sboxr under Code Execution window

4. We can see exactly what from the response is used in the sink and create an exploit.

5. To exploit, pass the string <img src=1 onerror=alert(document.domain)> in the text box

That’s all for this post. We will continue the exercises in Part 3 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. XMLHttpRequest (XHR) MDN — https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
4. window.postMessage() MDN — https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
5. WebSocket API MDN — https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
6. The Fetch API MDN — https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
7. Web Storage API MDN — https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

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.