Google engineers plot to mitigate prototype pollution

The initiative to establish a clear boundary between JavaScript objects and their prototypes is gaining traction.

Software engineers at Google have introduced a proposal aimed at addressing prototype pollution, a vulnerability type that poses significant risks to web security.

This issue stems from a flaw in the JavaScript language that enables attackers to manipulate objects that are outside their control or access. The challenge arises due to the absence of a distinct separation between runtime data-holding objects and their defining prototypes.

BACKGROUND Prototype pollution: An underrated vulnerability affecting JavaScript applications

The proposal, which is backed by Google and has been submitted for review to TC39, the technical committee responsible for JavaScript standards, seeks to establish a boundary between JavaScript objects and their prototypes. This approach aims to “eliminate pathways that allow attackers to traverse from objects to prototypes”.

Technical insights regarding the proposal are available on GitHub.

Introduction of Secure Mode

According to the GitHub documentation, the proposal introduces an opt-in secure mode that restricts access to prototypes through string property keys, mandating that they be accessed via methods like Object.getPrototypeOf or newly proposed symbol property keys.

Santiago Diaz, a co-author of the proposal, commented: “Our objective is to disrupt known exploitation methods while ensuring compatibility with existing codebases, thereby facilitating widespread adoption of the mitigation across the internet.”

Recently, TC39 approved the progression of the proposal from stage 0 to stage 1 in its five-phase journey toward formal ratification.

Diaz elaborated: “This recognition from TC39 signifies that prototype pollution is a pressing issue worthy of investigation and hopefully resolution. Over the coming months, we will refine various aspects of the proposal and undertake engineering work to strike an appropriate balance of trade-offs, aiming for broad acceptance among TC39 members and developers.”

Once a proposal reaches stage 4, it is finalized, allowing browser vendors to implement corresponding changes. “This indicates to developers that they can start integrating the new mitigation methods into their production environments,” concluded Diaz.

Symbol-Based Solution

Gareth Hayes, a security researcher at PortSwigger, expressed interest in the proposal’s approach.

“The core of this proposal is to counteract prototype pollution by allowing developers to effectively remove properties such as __proto__ through secure coding mechanisms,” Hayes articulated.

“The use of symbols enables sites to retain functionality related to __proto__ without risk, ensuring that attackers cannot introduce these symbols as it would necessitate JavaScript execution.”

While the Google proposal is not without precedent, previous methods to prevent unintended alterations to prototypes—such as Object.freeze, preventExtensions, and seal—are hampered by several drawbacks that complicate their implementation, as highlighted in Google’s descriptive blog post.

RELATED Prototype pollution-like bug variant discovered in Python