A prototype pollution bug in the Chromium project allowed attackers to bypass Sanitizer API, a built-in browser library for removing potentially malicious code from user-controlled input sources.
Prototype pollution is a type of JavaScript vulnerability that allows attackers to exploit the rules of the programming language to change an application’s behavior and compromise it in various ways.
Reported by security researcher Michał Bentkowski, the bug highlights the challenges of preventing client-side prototype pollution attacks.
Client-side prototype pollution
Prototype pollution can happen both on the client side (browser) and server side (Node.js servers). Bentkowski, who has done extensive research on the topic, discovered the new bug while exploring client-side prototype pollution vulnerabilities in Chromium.
The Sanitizer API was added to Chromium browsers to support native sanitization as a replacement for third-party libraries such as DOMPurify.
According to Bentkowski’s findings, if the JavaScript object Sanitizer is instantiated with an empty object as argument, it will trigger an internal mechanism that bypasses the sanitization flow. Bentkowski told The Daily Swig that the empty object causes the browser “to traverse the prototype chain”.
As proof of concept, Bentkowski showed that the API misses sanitizing a JavaScript snippet embedded in an SVG object. Once the supposedly sanitized SVG is inserted into the page, the JavaScript code is executed.
In his report, Bentkowski notes that for the vulnerability to work, the browser’s #enable-experimental-web-platform-features must be enabled.
“My guess is that there’s a low amount of people with this flag enabled,” Bentkowski said. “However, the Sanitizer API is enabled by default in Chrome 105 (released at the end of August), so the impacted user base is now greater.”
Bug or feature?
The discussion thread on the Chromium bug tracker shows some of the complexities of drawing the boundaries on prototype pollution bugs. Manipulating prototypes is one of the features that make JavaScript flexible and versatile, which means that hardening applications against prototype pollution attacks will always require meticulous efforts by web developers.
As one security researcher noted in the discussion thread, the prototype pollution vector is not something that should be addressed in Sanitizer API.
“Environments that have their Object prototypes polluted are already compromised, and I don’t think selectively hardening chosen web APIs against that would offer much practical benefit, and it may only offer a false sense of security, at the expense of API cognitive complexity,” the researcher wrote.
“Before reporting the bug I was unaware that there exists a WebIDL spec that specifically defines that the prototype chain must be traversed by Web APIs,” Bentkowski said.
“This means that in fact, it is a feature, and this cannot be changed right now because that would be backward-incompatible; that is, many applications would be broken.”
Developers, therefore, need to identify and remove all gadgets that pollute prototypes from user-controlled sources.
Nonetheless, Bentkowski’s discovery did result in some fixes. “[The bug] only worked on the SVG example. In the end, this was the real bug in the submission,” he said.
“Prototype pollution by itself was considered a ‘feature’. However, it shouldn’t have been possible to bypass the Sanitizer by the specially constructed configuration object.”
Source: https://portswigger.net/daily-swig/prototype-pollution-bug-in-chromium-bypassed-sanitizer-api
