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.hash
using Arg library. - Tries to check if
type
(which is parsed using URLSearchParams) is a defined indata
. - Update the content of
vuln
with 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. 👋