Client Side Prototype Pollution
Discovering using Automatic tools
The tools https://github.com/dwisiswant0/ppfuzz, https://github.com/kleiton0x00/ppmap and https://github.com/kosmosec/proto-find can be used to find prototype pollution vulnerabilities.
Moreover, you could also use the browser extension PPScan to automatically scan the pages you access for prototype pollution vulnerabilities.
Debugging where a property is used
Finding the root cause of Prototype Pollution
Once a prototype pollution vulnerability has been identified by any of the tools, and if the code is not overly complex, you might find the vulnerability by searching for keywords such as location.hash
, decodeURIComponent
, or location.search
in the Chrome Developer Tools. This approach allows you to pinpoint the vulnerable section of the JavaScript code.
For larger and more complex codebases, a straightforward method to discover the vulnerable code involves the following steps:
Use a tool to identify a vulnerability and obtain a payload designed to set a property in the constructor. An example provided by ppmap might look like:
constructor[prototype][ppmap]=reserved
.Set a breakpoint at the first line of JavaScript code that will execute on the page. Refresh the page with the payload, pausing the execution at this breakpoint.
While the JavaScript execution is paused, execute the following script in the JS console. This script will signal when the 'ppmap' property is created, aiding in locating its origin:
Navigate back to the Sources tab and select “Resume script execution”. The JavaScript will continue executing, and the 'ppmap' property will be polluted as expected. Utilizing the provided snippet facilitates the identification of the exact location where the 'ppmap' property is polluted. By examining the Call Stack, different stacks where the pollution occurred can be observed.
When deciding which stack to investigate, it is often useful to target stacks associated with JavaScript library files, as prototype pollution frequently occurs within these libraries. Identify the relevant stack by examining its attachment to library files (visible on the right side, similar to an image provided for guidance). In scenarios with multiple stacks, such as those on lines 4 and 6, the logical choice is the stack on line 4, as it represents the initial occurrence of pollution and thereby the root cause of the vulnerability. Clicking on the stack will direct you to the vulnerable code.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fmiro.medium.com%2Fmax%2F1400%2F1*S8NBOl1a7f1zhJxlh-6g4w.jpeg&width=768&dpr=4&quality=100&sign=7de3adb9&sv=1)
Finding Script Gadgets
The gadget is the code that will be abused once a PP vulnerability is discovered.
If the application is simple, we can search for keywords like srcdoc/innerHTML/iframe/createElement
and review the source code and check if it leads to javascript execution. Sometimes, mentioned techniques might not find gadgets at all. In that case, pure source code review reveals some nice gadgets like the below example.
Example Finding PP gadget in Mithil library code
Check this writeup: https://blog.huli.tw/2022/05/02/en/intigriti-revenge-challenge-author-writeup/
Recompilation of payloads for vulnerable libraries
HTML Sanitizers bypass via PP
This research shows PP gadgets to use to bypass the sanizations provided by some HTML sanitizers libraries:
sanitize-html
dompurify
Closure
References
Last updated