XSS in Chromium browsers can be triggered by a developer console trick
This is supported by security researcher Micha Bentkowski’s findings, which he reported in a blog post titled Google Roulette that was 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 a number of protections against XSS attacks. Scripts in one browser tab are unable to access cookies and other data from another domain thanks to the Same-Origin policy feature.
On the other hand, the Site Isolation feature gives each domain its own process to stop various websites from accessing each other’s memory space in the browser.
Subdomains are not covered by Same-Origin and Site Isolation, it should be noted.
Two browser tabs that are open on, for example, https://workspace.google.com and https://developer.google.com will therefore run on the same process and be regarded as having the same origin (google.com).
Developer console scripts
The safety features of the browser are applicable to both on-page scripts and scripts running in the developer console of the browser. On-page scripts cannot access several additional features that are exposed to the developer console.
Debug() is one of these functions; it places breakpoints on particular occasions, like when a function is invoked.
How does it lead to XSS? First, Bentkowski set up a page that contained two malicious functions.
The first is an XSS payload that loops through the current origin’s subdomains and executes a 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 is then started and iterates across as many subdomains as were specified in the payload function after that.
Here is a video that shows a proof-of-concept in action.
“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.”
A second situation is when an XSS vulnerability exists on one subdomain and the attacker wants to use the developer console to escalate it to additional subdomains.
The flaw was discovered by Bentkowski in 2020, and it appears that Google has chosen not to patch it. It appears that 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 was no longer a security risk because Chrome Extensions could no longer be used to exploit it.
Bentkowski posted on his blog, “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.
Suggest an edit to this article
Stay informed of the latest Cybersecurity trends, threats and developments. Sign up for our Weekly Cybersecurity Newsletter Today.
Remember, CyberSecurity Starts With You!
- Globally, 30,000 websites are hacked daily.
- 64% of companies worldwide have experienced at least one form of a cyber attack.
- There were 20M breached records in March 2021.
- In 2020, ransomware cases grew by 150%.
- Email is responsible for around 94% of all malware.
- Every 39 seconds, there is a new attack somewhere on the web.
- An average of around 24,000 malicious mobile apps are blocked daily on the internet.