Prototype Pollution Cheat Sheet

[Taneka Tarring]

Thiscross-site scripting (XSS) cheat sheet contains many vectors that can help you bypass WAFs and filters. You can select vectors by the event, tag or browser and a proof of concept is included for every vector.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

We know many of you are web penetration testers and often interact with the Node JS or JS engine running websites which may have some vulnerabilities undercover but you miss them out. Overcoming this gap between you and that hidden vulnerability, we are bringing you all the possible detection techniques for the Server Side Prototype Pollution.

Earlier it was only discovered on the client side which may run a child process based function to provide remote code execution. Now with the new era of it, it is now a Server Side Prototype Pollution where the JS server is misused to execute system commands and other impacts. Even messing with the application may lead to the DOS or other serious vulnerabilities.

Testing the Client Side Prototype Pollution was easy because if you refresh the page everything disappears and we can reset it to original. In this case, the application is effected on the server side and if any damage occurs then it can not be undone which may harm the application on the next level causing serious damage to it.

This article shall help you to test the web applications for it with several techniques of the detection and possible ways to find this vulnerability and confirm it in a very safer way. We are hopeful that you like reading the article. You can also use this as the permanent cheatsheet.

JavaScript has a prototypal inheritance system, which means that objects are extended by using a prototype object. This prototype object is inherited from the object's constructor, and the inheritance chain continues until the JavaScript engine reaches the null prototype, which signifies the end of the chain. In JavaScript, most objects inherit from Object.prototype via a child object, such as String, Array, or Number.

SSPP is a vulnerability that occurs when a server-side application fails to properly validate user-supplied data that is used to construct JavaScript objects. This can lead to unintended modifications to the object's prototype, which can be exploited by attackers to execute arbitrary code or gain unauthorized access to data on the server or client-side.

The impact of Server-Side Prototype Pollution (SSPP) vulnerability is that it allows attackers to modify the behavior of server-side applications by injecting malicious code into the application's object prototypes. This can lead to unintended consequences, such as execution of arbitrary code or unauthorized access to sensitive data. The impact can be severe, ranging from complete system compromise to data exfiltration, depending on the application and the level of access the attacker is able to obtain.

This cookie value obviously controls a property name somewhere in their code and reflects the value from the object, but because this uses the constructor property, it's reflecting the Object constructor.

If there is a POST or PUT request to API with JSON request and response are good candidates of test cases. In this case you can utilize following example to pollute the global Object.prototype with an arbitrary property as following

If the website is vulnerable to this, this would append "foo" in JSON response and allow the user to be admin assigned from the server side as originally added in developed response bypassing API validation for Admin check, in case if any.

This works with the combination of UTF-8 and UTF-7. We supply UTF-7 value and UTF-8 does not convert the value keeping it original unreadable string. Then we tend to modify the Content-type to UTF-7 and it responds with the string converted into its original form as following.

In the process of researching common modules, the researcher identified the CORS module as a potential target for detecting prototype pollution. The CORS module is frequently used to add CORS configuration to JSON endpoints, making it a valuable target for testing. The researcher used a customized version of Node to detect interesting properties, including the exposedHeaders property. This property can be used to define which headers are returned in an Access-Control-Expose-Headers directive by specifying an array of values, which are then reflected in every response.

This method of detection involves checking the status property of a response, and then changing the status code using the polluted property if it falls within a certain range specified in an if statement. By selecting an uncommon status code, this can be a reliable method for detecting vulnerabilities in a web application.

During the investigation of web application security vulnerabilities, the Express framework was found to have a subtle way to detect prototype pollution. By sending an OPTIONS request and checking if the HEAD method is excluded from the response, one can identify the presence of the vulnerability. The exclusion of HEAD from the response can be an indicator of prototype pollution since it's a method that is not commonly used and its exclusion can indicate tampering with the request object. This technique can be used to further confirm the existence of prototype pollution in web applications built with the Express framework.

The author has explored techniques for detecting prototype pollution in servers, which include subtle changes in behavior and reflection of JSON objects. Two methods were found for the latter approach. The first method involves using the __proto__ property with a string value. If the app is vulnerable, the __proto__ property won't be reflected and the string value will produce no exceptions. Otherwise, the __proto__ property will be reflected. The detection relies on the app reflecting the keys and values provided. A sample probe is given as follows:

Some Node sinks can be exploited like exec(), fork(), execsync(). We can reliably create a DNS interaction if a vulnerable sink was used. Following payload works in multiple Node JS sinks and hit back the DNS on the given link by creating a DNS interaction with it.

This would cause a DNS interaction on id.oastify.com as a bonus that not only detects that the app is vulnerable but also provides you with a means of exploiting it. Since if you can control the inspect command line argument then you can get RCE via a devtools connection. There is no need to attempt to inject shell commands.

To avoid false positives while testing for prototype pollution, the hostnames need to be obfuscated. However, some techniques like using $ and single quotes did not work on Windows. After experimenting, it was discovered that double quotes can be used on all platforms (Mac, Windows, and Linux) to obfuscate hosts in command line arguments.

We discussed several techniques to discover Server Side Prototype Pollution. However it should be considered that this may cause some serious damage to the web server as it can not be refreshed unlike client side prototype pollution, the payload should be considered and checked to avoid any DOS or any other serious damage to the website. So many safe techniques to discover the SSPP has been discussed above.

Prototype pollution is an injection attack that targets JavaScript runtimes. With prototype pollution, an attacker might control the default values of an object's properties. This allows the attacker to tamper with the logic of the application and can also lead to denial of service or, in extreme cases, remote code execution.

Unfortunately, stressed by looming deadlines and chased by ever-demanding stakeholders, startup.io engineers did a bad job of securing their API. They never had time to schedule a meeting with their AppSec team to help with the design and they later ignored all the issues reported by the security scanners. As a result, their API contains many bugs and vulnerabilities--one of which is prototype pollution.

What happened here? We will dive into the code a bit later. For now, we can deduce that we were able to override the toString method, just like we did before with the role attribute. Whenever the JavaScript runtime invokes toString() it expects it to be a method. But, it is no longer a method after our change (it is a dad joke now, i.e. a string literal), so the whole web server crashes, resulting in 500 errors.

When we create an empty object in JavaScript (for example, const obj = ), the created object already has many attributes and methods defined for it, for instance, the toString method. Have you ever wondered where all these attributes and methods come from? The answer is the prototype.

Many object-oriented languages, for example Java, use classes as blueprints for object creation. Each object belongs to a class, and classes are organized in parent-child hierarchies. When we call the toString method on an object, the language runtime will look for the toString method defined on the class a given object belongs to. If it cannot find such a definition, it will look for it in the parent class, then its parent class, until it hits the top of the class hierarchy.

So, where is the risk associated with prototypes? Well, here comes the critical part. Most objects share the same (default) prototype! For example, all objects created via the literal or the new Object() constructor will share the same prototype unless we explicitly override it. Consider our code snippet. a and b are unrelated objects, yet their __proto__ attributes point to the same object.

3a8082e126