New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Fixed
Closed: Feb 2013
EstimatedDays: ----
NextAction: ----
OS: All , Mac
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 173906: document.referrer leakage with XSS Auditor page block

Reported by, Feb 3 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11

Steps to reproduce the problem:

What is the expected behavior?

What went wrong?

Did this work before? N/A 

Chrome version: 23.0.1271.101  Channel: n/a
OS Version: OS X 10.8.2

Comment 1 by, Feb 3 2013

Interested in triaging, Tom?

Comment 2 by, Feb 3 2013

Reporter is saying that for pages which contain mode=block; it is trivial to fake an injection by including part of the page in an unused URL paramater (we do this for testing all the time), and that the final result is an about:blank page.  Do this in an iframe, and the about:blank page inherits the parent's origin.  Clever.

I've not tried it, but I'm reasonably certain this works based upon the explanation.

The fix is to give the page a unique origin (in the shouldTreatAsUniqueOrigin() sense).  I'm not sure we can do that with about:blank, so we may have to move this to another palce.

Comment 3 by, Feb 3 2013


Comment 4 by, Feb 3 2013

Yes. But technically it's not compulsory to change origin because *only* leaking and precious value is document.referrer. If we could steal POST params from action=about:blank it would be much more dangerous..
Thus I think working around by clearing document.referrer will simplify the fix

Comment 5 by, Feb 3 2013

Not only mode=block  btw
i can make action=about:blank for any form and trick user to click submit, then obtain document.referrer

Comment 6 by, Feb 4 2013

Yeah, we should put the blocked page into a unique origin.

Comment 7 by, Feb 4 2013

@homakov - FYI, this bug might have been eligible for an award under the chrome vulnerabilities reward program had it been reported to us directly, but is no longer eligible since you have already blogged about it.  Next time, see and if you'd like to be considered for an award.

Comment 8 by, Feb 4 2013

really? hypothetically what would reward be lol

Comment 9 by, Feb 4 2013

Labels: SecImpacts-Stable SecImpacts-Beta SecSeverity-Low OS-All Mstone-24
Status: Assigned

Comment 10 by, Feb 5 2013

sev low? I just wrote exploit to steal any access_token from any client_id which facebook user authorized. This is a big deal: private info, posting on wall etc.
P.S. since im not getting bounty is there a way to forward that money to charity :) and, hall of fame, no?

Comment 11 by, Feb 5 2013

No, once it's been publicly disclosed, all this is off the table.  Since it was subsequently triaged as severity low, it is unlikely it would have met the criteria.

Comment 12 by, Feb 5 2013

No, once it's been publicly disclosed, all this is off the table.  Since it was subsequently triaged as severity low, it is unlikely it would have met the criteria.

Comment 13 by, Feb 5 2013

ok, good to know. (i created another bug about switching off auditor for location fragment)

Comment 14 by, Feb 5 2013

@tsepez: given that it sounds like this enables theft of certain types of token, I wonder if Medium severity might be appropriate?

Comment 15 by, Feb 5 2013

up to you but.. There are lots of OAuth2 implementation and Single Sign On that allows to bounce user back with custom payload. Custom payload is code from final page. Stolen token = stolen account.

This is PoC for facebook auth + chrome. Choose any app user has authorized previously and steal his private data, access_token, post on the wall etc:

Comment 16 by, Feb 5 2013

sure, i already reported facebook about the critical vulnerability. My post on blogspot doesn't disclose real world vulnerabilities, i will publish them only when all of them will be fixed.

Comment 17 by, Feb 5 2013

@abarth: how about navigating to something like "data:text/html,Blocked by XSSAuditor" instead of about:blank?

Comment 18 by, Feb 5 2013

@tsepez how does X-Frame-Options block work? Because it looks just same - redirect to about:blank but referrer is not accessible? Is there any trick used for it? It could be same here

Comment 20 by, Feb 7 2013

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: Fixed
Fixed in

Comment 21 by, Feb 7 2013

Labels: Merge-Approved reward-topanel

Comment 22 by, Feb 12 2013

Labels: -Mstone-24 -Merge-Approved Mstone-26 Release-0
This can go into Chrome 26.

Comment 24 by, Feb 20 2013

Labels: -Mstone-26 -reward-topanel Mstone-25 Merge-Approved
@homakov: unfortunately, you've blogged widely before we patched the issue to Chrome stable.
As you can see, I had added the "reward-topanel" label to this bug in order to internally suggest we should reward this clever piece of work. I now have to revoke that label :(

Still, these XSS Auditor bugs are interesting and pretty impressive so you should drop me an e-mail if you are currently interested in job opportunities.

Comment 25 by, Feb 20 2013

Wow, i am not very familiar with labels so i thought there is no way to get bounty for this issue.. i just wanted to prove that it's severe, for myself :)

Comment 26 by, Feb 20 2013

Oops, I see @tsepez already said the same thing in #c7, I think I'm just confusing things :)

Yeah, you've put together a decent bug chain.

We're still happy to reconsider the severity rating if we got it wrong. Would this Chrome bug ever trigger on a well-written web site or can it only be abused in the presence of bugs (e.g. Facebook's OAuth2 bugs?)

Comment 27 by, Feb 20 2013

depends on API complexity. Such comprehensive providers like facebook, they always have hooks to use it.
But i nevermind about severity, just posted a link here to demonstrate :)

Comment 28 by, Feb 20 2013

So all that's missing is a link to your resume ;-)

Comment 29 by, Feb 20 2013

haha, i have a short one with plain history:
ruby, web security :)

Comment 30 by, Feb 20 2013

@homakov - re: "still not patched" - we were wondering if you have tested using the dev channel of chrome (26.0.1410 or better), and whether this issue remains for you.

Comment 31 by, Feb 20 2013

@tsepez i mean it's not patched on people's computers. For example mine is Version 24.0.1312.57
Pretty sure it's patched on trunk, it's obvious from diff.

Though, because of data extraction issue this patch will be refactored I guess to use different origin.

Comment 32 by, Feb 20 2013

@homakov - we expect that a contributing factor in your FB exploit is the use of http:// links, rather https://.  Are you able to make this work against an SSL flow?  (We consider passing tokens over http:// an issue in itself).

Comment 33 by, Feb 20 2013

Labels: -Release-0 -Merge-Approved Release-1 Merge-Merged

Comment 34 Deleted

Comment 35 by, Feb 20 2013

Not understood your question, but https pages don't set document.referrer. In my exploit final page is http:// but first page is https. This happenede because "authorize" page must be HTTPS according to oauth2 specs, but "website" can be whatever.

Comment 36 by, Mar 2 2013

Labels: CVE-2013-0909

Comment 37 by, Mar 10 2013

Project Member
Labels: -Type-Security -SecImpacts-Stable -SecImpacts-Beta -SecSeverity-Low -Mstone-25 Security-Severity-Low Security-Impact-Stable Security-Impact-Beta M-25 Type-Bug-Security

Comment 38 by, Mar 21 2013

Project Member
Labels: -Security-Severity-Low Security_Severity-Low

Comment 39 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 40 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Beta Security_Impact-Beta

Comment 41 by, Nov 18 2013

Labels: -Restrict-View-SecurityNotify
Bulk release of old security bug reports.

Comment 42 by, Jun 14 2016

Project Member
Labels: -security_impact-beta

Comment 43 by, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 44 by, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 45 by, Oct 2 2016

Labels: allpublic

Comment 46 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment