Gareth Heyes has been hacking browsers for over 15 years, and one of his goals was to find an SOP bypass or information leak in every major browser. Chrome was the only browser left standing…until now. This post explains how he took advantage of a Chrome data leak flaw that had been dormant for nearly 5 years. 

It all began when one of their Academy labs on dangling markup injection failed. Gareth previously blogged about this, which resulted in a CSP bypass. Setting an iframe location to about:blank allows the user to read the name property of the cross-domain window. Normally, you wouldn’t be able to do this because the Same Origin Policy protects cross-domain windows (SOP). SOP is a browser feature that prevents websites from reading data from one another, such as facebook.com reading data from google.com. 

Bypassing CSP was fantastic, but there may be more vulnerabilities to discover, as many properties were leaked when the about:blank location was set. I started with Hackability Inspector, a security-focused enumerator. Then I added an iframe to another domain that contained another iframe. Next, I set the location of the subframe on the cross-domain window in the main inspector window: 

x.contentWindow[0].location='about:blank'; 

I changed the input of the main inspector window to inspect the cross domain iframe window after setting the location and hitting return: 

x.contentWindow[0] 

He examined the properties, suspecting that some data was leaking somewhere. He discovered numerous properties after scrolling down the list. Then he began filtering the properties that he assumed would contain interesting information and, to his surprise, discovered access to the document object. 

x.contentWIndow[0].document 

The Process

He kept filtering for well-known properties like documents. An effective URL was set to “about:blank”. He then remembered the baseURI property and filtered it, discovering that it contained cross-domain information: 

This property holds information about the full URL, that can be obtained from different subdomains. Assume attachments.example.com can read the entire URL of oauth.example.com and steal OAuth tokens if it has at least one iframe and is frameable. He confirmed that by changing the external URL with hash or query string parameters, they could read from a different subdomain and decided to notify Google. 

Google investigated the issue after Gareth simplified the proof of concept and discovered that the baseURI issue had been known since 2017: 

 // TODO(tkent): Referring to ParentDocument() is not correct.  See 
   // crbug.com/751329. 
   if (Document* parent = ParentDocument()) 
     return parent->BaseURL(); 

Although the baseURI property reported an incorrect URL, no one had demonstrated a security vulnerability until now. He could use this bug to obtain cross-domain information by using a framed page with an existing iframe. Google rewarded him $2000 for this flaw. 

Proof of concept 

Conclusion 

This problem demonstrates how minor flaws, such as incorrectly assigned properties, combine with existing techniques to reveal cross-domain information. When enumerating, look for properties that include external URLs, as these can lead to cross-domain information disclosure. 

Reference