Client-side prototype pollution in third-party libraries | Jan 18, 2023

Introduction

Welcome to my another writeup! In this Portswigger Labs lab, you’ll learn: Client-side prototype pollution in third-party libraries! Without further ado, let’s dive in.

Overall difficulty for me (From 1-10 stars): ★☆☆☆☆☆☆☆☆☆

Background

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. Although it’s technically possible to solve this lab manually, we recommend using DOM Invader as this will save you a considerable amount of time and effort.

To solve the lab:

Use DOM Invader to identify a prototype pollution and a gadget for DOM XSS.
Use the provided exploit server to deliver a payload to the victim that calls alert(document.cookie) in their browser.

This lab is based on real-world vulnerabilities discovered by PortSwigger Research. For more details, check out Widespread prototype pollution gadgets by Gareth Heyes.

Exploitation

Use DOM Invader to identify a prototype pollution and a gadget for DOM XSS

Enable DOM Invader:

In Burp Suite Browser, you can use the Burp Suite extension:

Then turn on DOM Invader:

After that, turn on prototype pollution in attack types:

Finally, open Devtool and go to DOM Invader tab:

We can see that there are 2 sources. One is using __proto__[property], another one is using constructor.

Let’s click “Test” on the first source:

Then, go to “Console” tab in Devtool, and verify the global Object.prototype:

It worked!

Now, we can click the “Scan for gadgets” button:

In here, the DOM Invader found 1 sink called setTimeout(1).

Let’s click the “Exploit” button!

It worked!

Payload:

/#__proto__[hitCallback]=alert(1)

Finally, we can craft a HTML payload that trigger the DOM-based XSS payload!

<html>
    <head>
        <title>Client-side prototype pollution in third-party libraries</title>
    </head>
    <body>
        <iframe src="https://0aca001a03c2b291c133bcd300da0067.web-security-academy.net/#__proto__[hitCallback]=alert(document.cookie)"></iframe>
    </body>
</html>

Then host it on the exploit server and deliver it to victim:

What we’ve learned:

Client-side prototype pollution in third-party libraries