Google engineers plot to mitigate prototype pollution

Plan to create boundary between JavaScript objects and their blueprints gathers momentum

Software engineers at Google have put forward a proposal that promises to clamp down on prototype pollution, a class of vulnerability that has become a scourge of web security.

Prototype pollution is a JavaScript language flaw that allows attackers to manipulate objects they don’t control or don’t have access to at runtime. The problem arises from the lack of a clear boundary between objects (which are used to hold data at runtime) and their blueprints (which determine how those objects should behave).

BACKGROUND Prototype pollution: The dangerous, underrated bug impacting JavaScript applications

The Google-backed proposal – which has been submitted for ratification to TC39, a technical working group – aims to create a boundary between JavaScript objects and blueprints. The technology works by “removing the pathways that allow attackers to jump from objects to blueprints”.

Technical details of the proposal have been posted on GitHub.

Opt-in secure mode

As explained in the GitHub post, the “proposal seeks to mitigate prototype pollution by introducing an opt-in secure mode that makes prototypes impossible to access using string property keys, instead requiring they be accessed with methods (Object.getPrototypeOf) or the proposed new symbol property keys”.

Santiago Diaz, co-author of the proposal, told The Daily Swig: “The goal is to break known exploit techniques, while being as compatible as possible with existing codebases, so that the mitigation can be adopted widely on the internet.”

TC39, a working group responsible for maintaining the JavaScript specification, last week gave the green light to proceed from stage 0 to stage 1, beginning the next phase in its five-part journey towards ratification.

Diaz explained: “The significance of this is that TC39 sees pollution as a problem worth looking into (and hopefully solving). Over the course of the next months, we’ll be iterating on the specific aspects of the proposal and doing the engineering to find the right balance of trade-offs and hopefully make it palatable both for TC39 members and for developers to adopt.”

Once a proposal reaches the final stage (stage 4), the proposal is deemed final and browser vendors can make changes in their software. “This in turn, signals [to] developers to start adopting this new mitigation and roll it out to production,” Diaz concluded.

Symbol solution

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

“This is a proposal to prevent prototype pollution by giving the developer the ability to remove properties like __proto__ by executing some code that enables a secure mode and removes these properties,” Hayes said.

“They propose using symbols to enable the site to continue to use __proto__ functionality so a site doesn’t break and an attacker couldn’t supply these symbols as it would require JavaScript execution.”

The Google proposal is not the first of its kind. However, existing solutions for preventing unintentional changes to prototypes like Object.freeze, preventExtensions, and seal have a number of “downsides that make them difficult to deploy”, according to Google’s blog post, which outlines these drawbacks.