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

Issue 605451 link

Starred by 3 users

Issue metadata

Status: Fixed
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

CSP 'referrer' directive ignored for preload requests

Reported by, Apr 21 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36

Steps to reproduce the problem:
write a html page like this
header("Content-Security-Policy: referrer origin-when-crossorigin");
<link href="" rel="stylesheet" type="text/css" />
<img src="">
<img src="">
<img src="" rel=”noreferrer”>
<iframe src=""></iframe>
<script src=""></script>
var xmlhttp;
xmlhttp = new XMLHttpRequest();'').send();

set the csp header:
Content-Security-Policy: referrer origin-when-crossorigin
Content-Security-Policy: referrer origin-when-cross-origin

view this html page in chrome, and you will see that we can bypass the csp policy by using img/script/link tags

What is the expected behavior?
the resource requested from the webpage with csp header set  should not send the entire referer

What went wrong?
A tag href/JS ajax/iframe-src/Object-data/embed-src will follow the referrer policy in CSP header.
but, style-link-href/img-src/script-src can bypass the csp referer policy header.

we find that the csp policy in meta tag works fine ,like this:
<meta http-equiv="Content-Security-Policy" content="referrer origin-when-cross-origin">
we think  csp header should be the same with meta tag

Did this work before? N/A 

Chrome version: 50.0.2661.75  Channel: beta
OS Version: OS X 10.11.2
Flash Version: Shockwave Flash 21.0 r0

Comment 1 by, Apr 21 2016

affected all platform besides OSX

Comment 2 by, Apr 21 2016

Components: Blink>SecurityFeature
Labels: -OS-Mac Security_Severity-Low M-50 Security_Impact-Beta OS-All
Status: Assigned (was: Unconfirmed)

Comment 3 by, Apr 21 2016

Assigning to estark@, since referer is in her realm.

Comment 4 by, Apr 21 2016

Status: Started (was: Assigned)
This is a preload issue. We pick up a document's referrer policy from meta tags if we scan one while preloading, but we don't use a referrer policy set via header. Looks like we just need to be using document->getReferrerPolicy() here:
Project Member

Comment 5 by, Apr 22 2016

Labels: -Security_Impact-Beta Security_Impact-Stable

Comment 6 by, Apr 25 2016


Comment 7 by, Apr 25 2016


Comment 9 by, Apr 28 2016

Status: Fixed (was: Started)
Summary: CSP 'referrer' directive ignored for preload requests (was: CSP Header bypass)
Updating title to be more specific
Project Member

Comment 11 by ClusterFuzz, Apr 28 2016

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 12 by, Apr 28 2016

Thank you for your quick response to this security issue.
How can i get a CVE number, could you assign it?  : )
Labels: reward-topanel

CVE-IDs are only assigned where the bug is in a stable build (this issue in in stable) and the bug meets the severity for a reward. We'll take this to our reward panel and let you know if it meets the threshold for a reward and a CVE-ID.

Comment 15 by, May 10 2016

all right, this issue bypass the chrome W3C standard security policy , i think it should be assigned a CVE-ID. any way , waiting for your conclusions , thank you~ 

Comment 16 by, Jun 1 2016

is there any conclusion?
Labels: -reward-topanel reward-unpaid Reward-500
Congratulation, the panel has decided to award $500 for this bug.  Our finance team will be in touch in the new few weeks with more details.
Labels: -reward-unpaid reward-inprocess

Comment 19 by, Jul 18 2016

Thank you very much, i recieved a email from your finance team. i'll follow the steps in the email. so , is there a CVE-ID assigned or acknowledgment later ?  :)  hope for that
Labels: -M-50 Release-0-M52 M-52
Labels: -Security_Severity-Low Security_Severity-Medium
Project Member

Comment 22 by, Jul 21 2016

Labels: Merge-Request-53
+awhalley@ whether to take this merge in for M53 Dev release on Tuesday (07/26).
Humm - this should already be in 53 (commit was at 390264, 53 branched at 403382).  

+mbarbella@ - a sheriffbot hiccup or me getting the wrong end of the stick?
This is related to the same issue we discussed yesterday (it's trying to request a merge to beta using stable + 1 instead of the actual beta milestone). I should be able to fix this later today.
+awhalley@, do we need a merge to M52?
Nope, already in M52.

Comment 28 by, Jul 22 2016

Labels: -Merge-Request-53 Merge-Review-53 Hotlist-Merge-Review
[Automated comment] Commit may have occurred before M53 branch point (6/30/2016), needs manual review.
Labels: -Merge-Review-53
Per comment #24, this is already in M53 branch 2785. So removing "Merge-Review-53" label. 
Labels: CVE-2016-5135
Labels: -Hotlist-Merge-review
Project Member

Comment 32 by, Aug 4 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 33 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 34 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted
Project Member

Comment 37 by, Jul 28

Labels: -Pri-2 Pri-1

Sign in to add a comment