Site icon The Cybersecurity Daily News

Chromium’s prototype pollution bug disregarded the Sanitizer API

Sanitizer API

The problem illustrates difficulties in blocking client-side assaults. An attack-bypassing Sanitizer API, a built-in browser library for eliminating potentially harmful code from user-controlled input sources. This was made possible by a prototype pollution problem in the Chromium project.

A specific kind of JavaScript flaw known as prototype pollution enables attackers to manipulate an application’s behavior and hack it in a number of different ways.

The flaw, which was discovered by security researcher Micha Bentkowski, emphasizes the difficulties in guarding against client-side prototype pollution attacks.

Client-side prototype pollution

Both the server side and the client side (browser) are susceptible to prototype pollution (Node.js servers). While investigating client-side prototype pollution vulnerabilities in Chromium, Bentkowski, who has conducted a substantial study on the subject, found a new flaw.

In place of external libraries like DOMPurify, the Sanitizer API was added to Chromium browsers to provide native sanitization.

Bentkowski’s research indicates that if the JavaScript object Sanitizer is constructed with an empty object as an argument, an internal mechanism will be triggered that will avoid the sanitization flow. According to Bentkowski, an empty object forces the browser to “travel the prototype chain.”

Bentkowski demonstrated that the API fails to sanitize a JavaScript snippet inserted in an SVG object as proof of concept. The JavaScript function runs once the purportedly cleaned SVG has been added to the page.

According to Bentkowski’s report, the browser’s #enable-experimental-web-platform-features must be activated in order for the vulnerability to function.

According to Bentkowski’s estimation, not many users have this flag activated. However, the user base affected is now larger because Chrome 105 (August 2022) has the Sanitizer API activated by default.

Bug or feature?

Some difficulties in defining the parameters for prototype pollution bugs are illustrated in the discussion thread on the Chromium bug tracker. Because one of the aspects that makes JavaScript adaptable and versatile is its ability to manipulate prototypes. Web developers will always have to put forth great care in protecting applications from prototype pollution assaults.

Sanitizer API shouldn’t handle the prototype pollution vector, as one vulnerability researcher pointed out in the discussion thread.

The researcher claimed that Environments with contaminated Object prototypes are already compromised. I don’t think selectively hardening chosen web APIs against that will offer much practical advantage and may merely offer a false sense of security, at the expense of API cognitive complexity”.

The prototype chain must be traversed by Web APIs, according to a WebIDL specification, which Bentkowski says he was unaware of before reporting the error.

In fact, it is a feature, and it cannot be modified at the moment because doing so would break many programmes.

Therefore, designers must recognize and eliminate all devices that taint prototypes from user-controlled sources.

Bentkowski’s revelation did, however, lead to some fixes. “Only the SVG example was affected by the problem. This turned out to be the submission’s actual bug, he claimed.

“Prototype pollution was regarded as a ‘feature’ on its own. Bypassing the Sanitizer should not have been possible thanks to the carefully designed configuration object, though.

Reference

Exit mobile version