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

Issue 828218 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug-Security



Sign in to add a comment

Security: Chrome doesn't inherit tag <meta content='origin' name='referrer'> for CSS resource requests

Reported by santika...@gmail.com, Apr 3 2018

Issue description

Medium severity

Limiting "referer" header behaviour is necessary to not leak full URL + Query String to 3rd parties. For example when liking external images, css, javascripts, etc, which several times are stored in CDNs (or 3rd parties, typical for paid fonts).

I analyzed a site which is using properly the header <meta content='origin' name='referrer'>.
To my knowledge this is the most supported way of changing referrer behaviour to a full site.

Tested in OS X Sierra 10.12.6 (16G1212)
Version 65.0.3325.181 (Official Build) (64-bit)
Firefox Quantum 59.0.2 (64-bit)


VULNERABILITY DETAILS
In most cases the meta tag works properly, just sending the domain in this case, but when a resource is loaded using a CSS, the "Referrer Policy" "origin" is replaced with the default "no-referrer-when-downgrade", which causes the CSS full URL to go in the "referer" header.
Some site might send user ids in the CSS as parameter to customize the view of the user.
like
https://site.com/static/view.css?user=id
"id" could be PII, like a phone number or email address.
If in the customization options the user can choose external pictures, like for an avatar stored in a random site, that site could be receiving the "id", even if the meta <meta content='origin' name='referrer'> is present.

VERSION
Chrome Version: 65.0.3325.181 (Official Build) (64-bit) stable
Operating System: OS X Sierra 10.12.6 (16G1212)

REPRODUCTION CASE
The site tested was https://authy.com
looking at view-source:https://authy.com/
you can see this CSS referenced.
<link rel='stylesheet' id='app-css'  href='https://authy.com/wp-content/themes/authy/assets/styles/app.css?ver=20180213' type='text/css' media='' />

Here
https://authy.com/wp-content/themes/authy/assets/styles/app.css?ver=20180213
you can see there are resources being loaded (e.g. a bunch of svg files).

When requesting those svg files, Chrome is leaking the referer. Firefox is not, it's inheriting the "referer" policy to those requests, which should be the expected behaviour.

You can see both in the attached screenshots.
In this example the leak is not to some 3rd party, but given the "Referrer Policy" Chrome is adopting, it won't prevent it.

Thank you.
 
Chrome-bug-report-Chrome.png
466 KB View Download
Chrome-bug-report-Firefox.png
857 KB View Download
Cc: clamy@chromium.org mkwst@chromium.org est...@chromium.org
Components: Blink>SecurityFeature>Referrer
Labels: Security_Severity-Low M-67 Security_Impact-Stable Pri-2
Owner: yhirano@chromium.org
Status: Assigned (was: Unconfirmed)
Labels: OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac OS-Windows
Cc: yhirano@chromium.org
Owner: jochen@chromium.org
This seems related to https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/YkXg6ZkW2Bs/6aDLAs0qBwAJ and https://chromium.googlesource.com/chromium/src/+/57c4423dceffc997459ae34640abdfc1f067cc2e so I'm assigning this to jochen@.
Status: WontFix (was: Assigned)
indeed, this is working as spec'd

To control the referrer header send from CSS documents, the CSS document needs to be delivered with a referrer policy header
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 12

Labels: -Restrict-View-SecurityTeam 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