This is supported by security analyst Micha Bentkowski’s discoveries, which he reported in a blog article titled Google Roulette published yesterday (16 November).
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.
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.
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.”