Client-side prototype pollution in third-party libraries
Description
This lab is vulnerable to DOM XSS via client-side prototype pollution. This is due to a gadget in a third-party library, which is easy to miss due to the minified source code.
Reproduction and proof of concept
Load the lab in Burp’s built-in browser.
Enable DOM Invader and enable the prototype pollution option.
Open the browser DevTools panel, go to the DOM Invader tab, then reload the page.
Observe that DOM Invader has identified two prototype pollution vectors in the hash property i.e. the URL fragment string.
Click Scan for gadgets. A new tab opens in which DOM Invader begins scanning for gadgets using the selected source.
When the scan is complete, open the DevTools panel in the same tab as the scan, then go to the DOM Invader tab.
Observe that DOM Invader has successfully accessed the
setTimeout()
sink via thehitCallback
gadget.Click Exploit. DOM Invader automatically generates a proof-of-concept exploit and calls
alert(1)
.
https://0a76003f03e6226bc0df1817002a00bc.web-security-academy.net/#constructor[prototype][hitCallback]=alert%281%29
Disable DOM Invader.
In the browser, go to the lab’s exploit server.
In the Body section, craft an exploit that will navigate the victim to a malicious URL:
<script>
location="https://0a76003f03e6226bc0df1817002a00bc.web-security-academy.net/#__proto__[hitCallback]=alert%28document.cookie%29"
</script>
Test the exploit on yourself, making sure that you’re navigated to the lab’s home page and that the
alert(document.cookie)
payload is triggered.Go back to the exploit server and deliver the exploit to the victim to solve the lab.
Exploitability
An attacker will need to use DOM Invader to identify a prototype pollution and a gadget for DOM XSS; and use the exploit server to deliver a payload to the victim that calls alert(document.cookie)
in their browser.
Although it’s technically possible to solve this lab manually, using DOM Invader is recommended as this will save a considerable amount of time and effort.