When first I found this bug I was under the impression it could be an UXSS. Quickly after I reported I started to realize that this wasn't as exploitable though.
The issue per se was extremely easy to reproduce:
- Create an HTML file that looks like and save it (e.g. chrome.html)
<h1>Hi</h1>
<script> alert(document.domain)</script>
- Now supposing the file is saved under (in MacOS) /Users/xxx/Downloads/chrome.html open the file from hard disk in this way:
file://mail.google.com/Users/xxx/Downloads/chrome.html
Note: mail.google.com is arbitrary . This can be any domain (hence is universal) - Observe the document.domain alerted is mail.google.com!
- Observe the cookies transported are the one associated with *.google.com domain :
Now this looked really weird to me and I reported as an UXSS. Pretty quickly though was cleat that the file: URL has a unique origin hence:
- doesn't gain access to things that it frames
- doesn't gain access to cookies on the hostname it asserts (even if the Cookie extensions shows it!!)
- The cookies are NOT even transmitted over the wire!
So no UXSS :(
Said that the Google Chrome Team thought that there is still something weird going on (at least with the extensions). Indeed was clear that UX and Extensions API got confused when file: URLs have hostnames. Now I am not a big expert of Chrome codebase but the reason behind it seemed to be that stuff outside of WebKit used GURL::GetOrigin() to get the security origin rather than SecurityOrigin. This is not the case anymore and fixed in Chrome 50.0.2661.75.
So as Mathias Karlsson said some time ago do not shout hello before you cross the pond :)
Comments