Google engineers plot to mitigate prototype pollution

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

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

Prototype pollution is a flaw within the JavaScript programming language, enabling attackers to manipulate objects outside their control at runtime. This flaw stems from the absence of a distinct separation between objects (which store data during execution) and their blueprints (which define their behavior).

BACKGROUND Prototype pollution: An overlooked yet critical bug affecting JavaScript applications

The proposal, supported by Google and currently under review by TC39—a technical committee focused on JavaScript standards—aims to establish a clear boundary between JavaScript objects and their prototypes, effectively removing the pathways that allow attackers to exploit this relationship.

For those interested in the specifics, technical details of the proposal are available on GitHub.

Opt-in Secure Mode

As outlined in the GitHub documentation, the proposal also introduces an opt-in secure mode that renders prototypes inaccessible via string property keys, requiring alternate methods like Object.getPrototypeOf or newly proposed symbol property keys for access.

Santiago Diaz, one of the proposal’s co-authors, shared his insights with The Daily Swig: “Our objective is to disrupt established exploit methods while maintaining compatibility with existing codebases, thus encouraging widespread adoption across the internet.”

Recently, TC39 has approved the proposal’s progression from stage 0 to stage 1, marking a key development in its journey toward ratification.

Diaz further noted, “The importance of this advancement is TC39’s acknowledgment of prototype pollution as a significant issue deserving attention. In the coming months, we will refine the proposal’s specific elements and collaborate on engineering solutions that balance trade-offs, ensuring it meets the needs of TC39 members and developers alike.”

Once a proposal reaches the final stage (stage 4), it will be recognized as finalized, allowing browser vendors to implement necessary changes. “This will subsequently prompt developers to begin adopting the new mitigation strategies in their production environments,” concluded Diaz.

Symbol Solution

Gareth Hayes, a security researcher at PortSwigger, the parent company of The Daily Swig, has shown interest in these proposals.

“This proposal aims to prevent prototype pollution by empowering developers to eliminate properties like __proto__ through code that activates a secure mode and removes those properties,” explained Hayes.

“Using symbols allows sites to retain __proto__ functionality, ensuring that sites operate without issue while preventing attackers from supplying these symbols unless JavaScript execution is involved.”

This initiative is not the first of its kind, yet existing methods to prevent unwanted prototype changes, such as Object.freeze, preventExtensions, and seal, come with drawbacks that hinder their broader implementation, as detailed in Google’s blog post outlining these limitations.

RELATED Prototype Pollution-like Bug Variant Identified in Python