JavaScript, the backbone of many web applications today, brings with it flexibility and potential. At the core of its architecture, every element we interact with is essentially an object, each with its own unique properties and methods.

The Role of Prototypes in JavaScript

Prototypes allow JS to share attributes or properties between different objects. Every object in JS has a prototype object associated with it, which gives that object its own properties. In other words, an object in JS inherits all the properties of its prototype. And this prototype can be accessed by referencing the __proto__ property attached to the object.

In JavaScript's dynamic environment, objects don't exist in isolation. They often share properties, and this sharing is made possible by 'prototypes'. Think of prototypes as ancestral blueprints from which objects inherit properties. This inheritance link can be seen by looking into an object’s '__proto__' property.

However, like many methodologies, this shared inheritance has its downsides. This is where we can find a vulnerability called Prototype Pollution. It's like messing with a family tree, changing traits or qualities that should be passed down to the next generation (or in this case, objects). While this might seem harmless, in the wrong hands, it can be used to change properties that shouldn't be touched.

More details about Prototype Pollution itself you can find on Portswigger blog https://portswigger.net/web-security/prototype-pollution:

What's more concerning is that Prototype Pollution can set the stage for more serious vulnerabilities. It’s like the first domino in a long chain - push one, and the rest will follow. On the client side, in our case, the result is DOM Cross-Site Scripting (XSS). But for server-side situations, the risks are even higher, especially with threats like remote code execution.

How to find Prototype Pollution in a tested application?

Finding out if an application is vulnerable usually starts with tools like Burp Suite. Using this tool, an auditor checks if he or she can add new properties to a JavaScript prototype. Once that’s done, this prototype mixes with another object, leading to potential exploitation.

For example, an attacker might change the 'div' array in a URL, and when checking the console, he or she might see their injected value at the end of an array, showing a successful property change.

It is important, that to exploit prototype pollution, you need a source and a gadget. A prototype pollution gadget occurs when a site uses a property in a dangerous way without filtering.

Looking for Prototype Pollution

We need to start with overriding the JavaScript prototype:

At this point, we can draw two conclusions:

A property is added to the div array in the URL, with record 100 having the value "test".

In the console, after referencing the global prototype of the objects, an array of 101 elements is visible, with the value "test" at the end.

It could look interesting, but how does this connect to DOM XSS? It can be found manually, but tools like Burp Suite’s DOM Invader module are very helpful here. It looks for spots that allow a DOM XSS attack through prototype pollution.

We mentioned about gadget in “How to find Prototype Pollution in a tested application?” section, in our case the gadget turned out to be a standard XSS payload:

The code can be passed to the application using the following URL:



Vulnerability verification:



Step by step exploitation

Since we found the vulnerability now it is the time for real-life scenario exploitation. The practical exploitation is to redirect the victim to the URL prepared by the attacker.

1. Prepare JavaScript code to display the https://[REDACTED] domain login form in the /account/login endpoint:



2. Encode the code from step 1 using URL Encoding:



3. The code can be passed to the application using the following URL:



4. After clicking above link victim will see the login form:



5. Once the login credentials are provided, they are sent to the attacker's server:


Protection methods

It is recommended to validate all the data received from the user (to reject the values that are inconsistent with the template/format of a given field – whitelist approach) and then encode it on the output in relation to the context in which it is embedded.

For this purpose, it should be verified whether the framework used by the application has built-in functions that implement the described recommendation.

Make sure that keys such as __proto__, constructor, and prototype are properly filtered when linking objects.

When creating objects, it is recommended that you use Object.create(null) to ensure that the object does not inherit from the global prototype Object.prototype, and therefore is not susceptible to prototype pollution (client-side prototype pollution).

#CyberSecurity #PenetrationTesting #Vulnerability #WebSecurity #PentestChronicles