Google engineers plot to mitigate prototype pollution

The initiative to establish a clear separation between JavaScript objects and their blueprints is gaining traction.

Engineers at Google have introduced a plan aimed at addressing prototype pollution, a significant security vulnerability affecting web applications.

Prototype pollution is a JavaScript flaw that enables attackers to manipulate objects without direct control over them during runtime. This issue is rooted in the absence of a clear distinction between objects that store data and their blueprints which dictate their behavior.

BACKGROUND Understanding Prototype Pollution: A Significant Yet Overlooked Threat to JavaScript

The proposal supported by Google has been forwarded for approval to TC39, a technical committee dedicated to the evolution of the JavaScript language. Its objective is to create a protective boundary separating JavaScript objects from their blueprints, effectively neutralizing pathways that would typically allow attackers to bridge the gap between the two.

Detailed technical specifications for the proposal are available on GitHub.

Introducing an Opt-in Secure Mode

The GitHub documentation outlines a secure mode that developers can opt into, which would eliminate access to prototypes via string property keys, mandating instead the use of methods (such as Object.getPrototypeOf) or a new type of symbol-based property keys.

Santiago Diaz, one of the proposal’s co-authors, stated: “Our aim is to dismantle known exploitation methods, while ensuring maximum compatibility with current codebases, facilitating widespread adoption on the internet.”

Last week, TC39 approved the transition of the proposal from stage 0 to stage 1, marking the advancement to the next phase in its structured journey toward ratification.

Diaz further clarified: “This progression indicates that TC39 recognizes pollution as a critical problem worthy of investigation and resolution. In the upcoming months, we will refine specific elements of the proposal and engage in the necessary engineering to achieve an optimal balance of trade-offs, making it appealing for both TC39 members and general developers.”

Upon reaching its final stage (stage 4), the proposal will be formally recognized, allowing browser vendors to implement relevant changes. This will signal to developers the readiness to adopt the new mitigation strategies in their production environments.

Symbol-Based Solution

Gareth Hayes, a security researcher at PortSwigger, expressed enthusiasm regarding the proposals.

“The proposal aims to inhibit prototype pollution by empowering developers to remove certain properties, such as __proto__, through code that activates a secure mode while preserving site functionality,” Hayes explained.

“Symbols are proposed as a mechanism that allows sites to maintain __proto__ functionality without jeopardizing security, as providing these symbols would necessitate JavaScript execution, which an attacker cannot perform.”

This initiative from Google is not unprecedented, as previous attempts to prevent unintended prototype alterations, including methods such as Object.freeze, preventExtensions, and seal, have encountered various limitations that hinder their deployment, as highlighted in Google’s blog post detailing these drawbacks.

RELATED Discovery of a Prototype Pollution-like Vulnerability in Python