Ben Dickson November 17, 2022 at 13:16 UTC
Updated: Nov 17, 2022 2:10 PM UTC
A case study in the complexity of browser security
This is according to the findings of a security researcher Michal Bentkowski who presented his findings in a blog post published yesterday (November 16) titled Google Roulette.
Although the bug is difficult to exploit and Google decided not to fix it, it is an interesting case study in the complexities of browser security.
Same-origin policy, site isolation
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 should be noted that Same-Origin and Site Isolation do not apply to subdomains.
Therefore, two browser tabs that are, for example, at https://workspace.google.com and https://developer.google.com will run on the same process and are considered to be from the same origin (google.com) .
Developer console scripts
Browser protection mechanisms apply not only to scripts on the page, but also to scripts running in the browser. developer console. However, the developer console has access to some additional functions that are not available to scripts on the page.
One such function is , which sets breakpoints on specific events, such as when a function is called.
DO NOT MISS CSRF in Plesk API Enabled Server Takeover
How does it lead to XSS? First, Bentkowski created a page containing two malicious functions.
The first is the XSS payload, which traverses the subdomains of the current origin and runs a proof-of-concept script (in this case, a popup).
The second is a called getter function that sets an event for the function (which occurs multiple times when loading a page) and reloads the page.
Because it must be explicitly called from the Developer Console, the page displays a message prompting the user to call 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 repair
“I see it more as an interesting technical bug than something exploitable in the real world,” Bentkowski said. The daily sip. “In my opinion, the user interaction required by this attack makes it not really feasible for attackers.”
There are, however, two scenarios in which this bug can become concerning, according to Bentkowski.
First, 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 a subdomain and the attacker wants to push it to others through the developer console.
Bentkowski reported the bug in 2020 and Google apparently decided not to fix it. “The issue is currently not attributed to anyone, so it doesn’t look like we can expect the fix anytime soon,” Bentkowski said.
However, Google agreed to allow Bentkowski to make his findings public, telling him that since the bug is no longer exploitable through Chrome extensions, it is no longer a security issue.
“I still think there might be ways to make it worse that I haven’t discovered, and maybe you, my dear readers, will have some better ideas,” Bentkowski wrote. on his blog.
YOU MIGHT ALSO LIKE Mastodon users are vulnerable to password theft attacks