Google Roulette: Developer console trick can trigger XSS in Chromium browsers

Reading Time: 3 Minutes

Malicious actors can stage cross-site scripting (XSS) attacks across the subdomains of a website if they can trick users of Chromium browsers into entering a simple JavaScript command in the developer console.

This is according to the findings of security researcher Michał Bentkowski who presented his findings in a blog post published yesterday (November 16) titled Google Roulette.

While the bug is hard to exploit and Google has decided not to patch it, it is an interesting case study on the complexities of browser security.

Same-origin policy, site isolation

Chromium browsers have several safeguards to prevent XSS attacks. The Same-Origin policy feature prevents scripts in one browser tab from accessing cookies and data from another domain.

The Site Isolation feature, on the other hand, gives a separate process to each domain to prevent different websites from accessing each other’s memory space in the browser.

However, it is worth noting that Same-Origin and Site Isolation do not apply to subdomains.

Therefore, two browser tabs that are on, say, https://workspace.google.com and https://developer.google.com will run on the same process and are considered to be of the same origin (google.com).

Developer console scripts

The browser’s protection mechanisms apply not only to on-page scripts but also to scripts running in the browser’s developer console. However, the developer console has access to certain extra functions that are not available to on-page scripts.

One of these functions is debug(), which sets breakpoints on specific events, such as when a function is called.

Two things are interesting about debug(). First, it has an optional argument that allows you to replace the breakpoint functionality with a custom JavaScript code. And second, when you use the developer console to define a debug() event on a webpage, it persists across page refreshes and even carries to other subdomains of the same origin in the same tab.

How does lead to XSS? First, Bentkowski set up a page that contained two malicious functions.

The first one is the XSS payload, which iterates across the subdomains of the current origin and runs a proof-of-concept script (in this case an alert() popup).

The second one is a getter function called magic() that defines a debug() event for the appendChild function (which happens many times during a page load) and reloads the page.

Since debug() needs to be explicitly called from the developer console, the page displays a message that prompts the user to call magic() from the developer console. After that, the XSS cycle is triggered and goes through any number of subdomains defined in the payload function.

A video containing a proof-of-concept can be found here.

Impact and fix

“I see it more as an interesting technical bug than something exploitable in the real world,” Bentkowski told The Daily Swig. “In my opinion, the user interaction required by this attack makes it not really feasible for attackers.”

There are, however, two scenarios where this bug can become concerning, according to Bentkowski.

First are websites where users can create their own subdomains. In this case, a user can create a malicious page and trick visitors into triggering the XSS function on their own subdomain.

A second scenario is when there is an XSS vulnerability on one subdomain and the attacker wants to escalate it to others through the developer console.

Bentkowski reported the bug in 2020 and Google has apparently decided not to fix it. “The issue isn’t currently assigned to anyone so it doesn’t look like we can expect the patch soon,” Bentkowski said.

However, Google agreed to allow Bentkowski to make his findings public, telling him that since the bug is no longer exploitable via Chrome Extensions, it is no longer a security issue.

“I still think that there might be some ways to escalate it that I failed to discover, and maybe you, my dear readers, will have some better ideas,” Bentkowski wrote on his blog.

Are u a security researcher? Or a company that writes articles or write ups about Cyber Security, Offensive Security (related to information security in general) that match with our specific audience and is worth sharing?

If you want to express your idea in an article contact us here for a quote: [email protected]

Source: portswigger.net

Source Link