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 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment

Security: Chrome browser not respecting no-referrer meta tag

Reported by tann...@gmail.com, May 28 2016

Issue description

VULNERABILITY DETAILS
Chrome browser isn't respecting the no-referrer policy:

<meta name="referrer" content="none">

There are claims that Chrome does indeed support this tag since version 29 (http://caniuse.com/#feat=referrer-policy)

Here is linked spec of referrer policy: http://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-state-no-referrer

When tested in Firefox the no-referrer policy works as designed.

DANGERS
This is often used to hide sensitive data in URLs (such as the tokens in password reset pages) if a user clicks any external links on the page, OR if any assets are loaded to the page automatically.

VERSION
Tested on:
Windows 7 x64 Ultimate SP 1
Chrome 49.0.2623.112 m Stable
Chrome 51.0.2704.63 m Stable

OSX 10.9.5
Chrome 50.02661.102

REPRODUCTION CASE
Create a link or load assets on a page with the no-referrer meta tag. Open the "network" tab of developer tools, and look under the "Request Headers" section. You will see your current URL listed as the "Referer"

Here is an jsfiddle example: https://jsfiddle.net/8tucuyjn/

Hope this gets resolved soon, thanks!
- Tanner

 

Comment 1 by est...@chromium.org, May 28 2016

Why are you providing "none" in the content attribute instead of "no-referrer"? Is there documentation somewhere that says that should work? If you change it to "no-referrer", then your example works as expected: https://jsfiddle.net/mer054hc/

Comment 2 by est...@chromium.org, May 28 2016

Cc: est...@chromium.org
Labels: Needs-Feedback

Comment 3 by tann...@gmail.com, May 28 2016

Ah yes no-referrer works as expected. However using "None" is pretty widely documented and should be supported. It's supported in Firefox, iOS Chrome, iOS Safari, and desktop Safari (IE doesn't support either). Linked is the documentation (and attached are screenshots) that gives the false impression of it being supported.


https://moz.com/blog/meta-referrer-tag
https://www.w3.org/TR/referrer-policy/#referrer-policy-state-none

Not official by any means, but it's just a note to show this is a common mistake (http://stackoverflow.com/a/32803924/5865423)
mozDocumentation.PNG
25.2 KB View Download
w3Documentation.PNG
44.4 KB View Download
Project Member

Comment 4 by sheriffbot@chromium.org, May 29 2016

Labels: -Needs-Feedback Needs-Review
Owner: est...@chromium.org
Thank you for providing more feedback. Adding requester "estark@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Comment 5 by ClusterFuzz, May 29 2016

Status: Assigned (was: Unconfirmed)

Comment 6 by mea...@chromium.org, May 31 2016

It looks like there isn't a security vulnerability here, as the correct value (no-referrer) works.

estark: Should this be a feature request instead, to allow "None" as a valid value?
Project Member

Comment 7 by ClusterFuzz, May 31 2016

Labels: Missing_Severity-1 Missing_Impact-1

Comment 8 by tann...@gmail.com, May 31 2016

I’m not sure how this isn’t a security issue. I agree, I mis-titled the thread causing some confusion. However, there is quite a bit of documentation regarding this (even w3 written by Google), and claiming that this is indeed a valid value for that field. Every other major browser supports it including Chrome on iOS, however it’s ignored on Chrome desktop. If desktop Chrome never supported this value I’m not sure why there’s misleading w3 spec written on it. If they did support it at one point, I’m not sure why it was removed after wide adoption. Thanks,

- Tanner

Comment 9 by mea...@chromium.org, May 31 2016

If it's in the spec, then sure, it makes sense to treat is as a security bug. I'll leave it to estark to decide.
Cc: -est...@chromium.org mkwst@chromium.org jochen@chromium.org
Components: Blink>SecurityFeature
Labels: -Missing_Severity-1 -Missing_Impact-1 -Needs-Review Security_Severity-Low Security_Impact-Stable OS-All Pri-2
Huh, that's weird that 'none' is in the working draft of the spec as a valid policy. At some point it disappeared from the editor's draft (https://w3c.github.io/webappsec-referrer-policy/) and I'm not sure why. Maybe there's some mention of it in the public-webappsec archives, I'll go searching...

In the meantime I think we should perhaps leave this open as a low severity security bug.
Labels: Hotlist-EnamelAndFriendsFixIt
Cc: est...@chromium.org
Owner: jochen@chromium.org
this was removed in https://github.com/w3c/webappsec-referrer-policy/commit/d99bd4a72fec089aa5e4c81922aa2e9cb640fa96 - looks like an accident indeed.
Project Member

Comment 14 by bugdroid1@chromium.org, Nov 16 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6e49f4b3376d278aa09186ad5200732f0cd8365

commit e6e49f4b3376d278aa09186ad5200732f0cd8365
Author: Jochen Eisinger <jochen@chromium.org>
Date: Thu Nov 16 17:29:09 2017

Add back support for "none" referrer policy

It's a legacy keyword that was accidentially removed

BUG= 615608 
R=estark@chromium.org

Change-Id: I1bf4d87d999f35b30beca644b4dec6712ac2d388
Reviewed-on: https://chromium-review.googlesource.com/772234
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517114}
[modify] https://crrev.com/e6e49f4b3376d278aa09186ad5200732f0cd8365/third_party/WebKit/Source/platform/weborigin/SecurityPolicy.cpp
[modify] https://crrev.com/e6e49f4b3376d278aa09186ad5200732f0cd8365/third_party/WebKit/Source/platform/weborigin/SecurityPolicyTest.cpp

Status: Fixed (was: Assigned)
Project Member

Comment 16 by sheriffbot@chromium.org, Nov 17 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-0
Labels: M-64
Labels: Release-0-M64
Labels: CVE-2018-6052
Project Member

Comment 22 by sheriffbot@chromium.org, Feb 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
Labels: CVE_description-missing

Sign in to add a comment