Site icon The Cybersecurity Daily News

Google Roulette: XSS in Chromium browsers can be activated by a developer console trick

XSS in Chromium browsers

An example of how difficult browser cybersecurity is. Suppose bad actors can fool Chromium browser users into submitting a straightforward JavaScript command in the developer console. In that case, they can launch cross-site scripting (XSS) assaults throughout the subdomain of a site.

This is supported by security analyst Micha Bentkowski’s discoveries, which he reported in a blog article titled Google Roulette published yesterday (16 November).

Also read Chromium’s prototype pollution bug disregarded the Sanitizer API

The problem is challenging to exploit, and Google has chosen not to repair it. But it is nonetheless a fascinating case study on the difficulties of maintaining browser security.

Same-origin policy, site isolation

The Chromium browsers have several protections against XSS attacks. The script in one browser window cannot access cookies. And other data from some different domains thanks to the Same-Origin policy feature.

On the contrary, the Site Isolation feature offers each domain its own process to stop various websites from visiting one another’s memory space in the browser.

Same-Origin and Site Isolation do not cover subdomains; it should be noted.

Also read A Google Chrome Bug Allows Sites To Write To The Clipboard Without Prompting

Two browser tabs open on, for example, https://workspace.google.com and https://developer.google.com, will thus run on the same processes and be regarded as having the same origin (google.com).

Developer console scripts

The browser’s safety features apply to both on-page scripts and scripts executing in the developer console of the browser. On-page scripts cannot access several additional features that are exposed to the developer console.

Debug() is among these functions; it places breakpoints on particular occasions, for instance, when a function is invoked.

Debug is intriguing in two ways (). First, using an optional argument, you may substitute your own JavaScript code for the breakpoint functionality. Second, when you define a debug() event on a website using the developer console, it survives page refreshes and even spreads to other subdomains of the exact origin in the same tab.

What causes XSS, and how? First, Bentkowski created a page with two malicious scripts on it.

The first is an XSS payload that loops through the current origin’s subdomains and executing a (PoC) proof of concept script (in this case, an alert() popup).

The second one is a getter method named magic() that reloads the page and defines a debug() event for the appendChild function, which is run repeatedly during a page load.

The page displays a warning asking the user to use magic() from the developer console because debug() must be explicitly called from the developer console. The XSS cycle then starts and iterates across many subdomains as specified in the payload function after that.

Impact and fix

Bentkowski said, “I regard it more as a fascinating technical defect than something exploitable in the actual world. “In my perspective, this technique is not practical for attackers because it necessitates user participation,”

However, as per Bentkowski, there are two circumstances in which this defect can be problematic.

Websites that allow users to build their own subdomains come first. In this scenario, a person may design a malicious page and deceive users into activating the XSS function within their own subdomain.

A second situation occurs when a Cross-site scripting vulnerability exists solely on a single subdomain. And the adversary wants to use the developer console to elevate it to additional subdomains.

Bentkowski discovered the flaw in 2020, and it appears that Google has chosen not to patch it. We can’t anticipate the patch very soon because the problem isn’t currently allocated to anyone, according to Bentkowski.

Nevertheless, Google permitted Bentkowski to publish his findings and informed him that the flaw wasn’t any longer a security risk because Chromium Extensions could no longer be used to exploit it.

Bentkowski posted on his blog, “I still think there may be some methods to escalate it that he failed to discover. And maybe you, my beloved readers, will have some good suggestions.”

Reference

Exit mobile version