Security: Chrome doesn't inherit tag <meta content='origin' name='referrer'> for CSS resource requests
Reported by
santika...@gmail.com,
Apr 3 2018
|
|||||
Issue descriptionMedium 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.
,
Apr 3 2018
,
Apr 4 2018
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@.
,
Apr 4 2018
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
,
Jul 12
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 |
|||||
Comment 1 by mmoroz@chromium.org
, Apr 3 2018Components: Blink>SecurityFeature>Referrer
Labels: Security_Severity-Low M-67 Security_Impact-Stable Pri-2
Owner: yhirano@chromium.org
Status: Assigned (was: Unconfirmed)