Exploiting Client-side Prototype Pollution - arg.js
Table of Contents
First of all, a big shoutout to the challenge author. All the challenges in this set are available here.
##
Analysis
Going through the challenge source, we can see that two JavaScript files are imported.
| |
arg-1.4.js is a popular library for parsing URL parameters. And main.js has the following content.
| |
We can see that main.js uses Arg library to parse location.hash and uses URLSearchParams to parse query strings.
A function vulnParams is defined that does the following:
- Parses
location.hashusing Arg library. - Tries to check if
type(which is parsed using URLSearchParams) is a defined indata. - Update the content of
vulnwith the contents ofdata[type]
This initially seems to be safe as there is no way to control the data being injected into the HTML. Accessing https://ppvl.whoisbinit.me/lab2/?type=big#big gives an expected result.
##
Exploit 💥
arg.js is vulnerable to prototype pollution. You can read more about it here. This repository has a collection of client side prototype pollution bugs with popular libraries.
We have a similar scenario as mentioned in the PoC. The only difference is that, Arg.parse takes location.hash.substr(1) as parameter.
With #__proto__[exploit]=polluted, we can pollute the prototype. With this, window.exploit and data.exploit will have a value polluted.
Now, we need to escalate this into an XSS. For that, we have,
| |
We can see that the value of data[<x>] is appended directly to HTML, and <x> could be controlled. Utilizing the prototype pollution that we have previously identified, we have:
| |
##
Final Payload
| |
Thanks for reading. 👋