1397064 - (CVE-2017-7842) Referrer leaked even after setting referrer policy attribute

Status: RESOLVED FIXED

(Core :: DOM: Security, defect)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

1. Go to https://test.shhnjk.com/refpol.html


Actual results:

Referrer is leaked to cross-origin website.


Expected results:

https://bugzilla.mozilla.org/show_bug.cgi?id=1264165 added support for referrer policy attributes. But somehow <link> sends 2 requests, 1 with referrer and 1 without referrer, which bypasses this policy.

Comment 1

[Franziskus Kiefer [:franziskus]]

Not sure where this is coming from. But this seems to be fixed in 57. I can reproduce it in 55 and 56 but 57 (Nightly) sends only a single request without referrer.
Christoph, unless you think this should be uplifted I'd let it ride the trains. We should keep an eye on it though as I don't know what fixed or caused this issue.

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

I tested this using FF55 as well as a recent pull from mozilla-central.

Using FF55:
I see two requests, one leaking the referrer, one not.
Since the testpage from comment 0 is using:
<link href="//www.whatismyreferer.com" rel="stylesheet" referrerpolicy="no-referrer">
and since that meta referrer is not applied to preloads that seems like expected behavior to me.

Using latest mozilla-central:
I only see one request which does not leak the referrer. I don't know what happenend, but it seems we are not performing a preload for that request anymore.

Either way, I think the behavior described in comment 0 is expected behavior.

Comment 3

[Daniel Veditz [:dveditz]]

Not sure I agree: if we have a referrer policy to block referrers, or a CSP to block content loads, or mixed content blocking to block mixed content, the preloader shouldn't get to willy-nilly ignore those constraints. In this case the referrerpolicy is right there on the element itself.

Comment 4

[Daniel Veditz [:dveditz]]

This bug is probably on the way to being closed "works for me", but can we add a referrer policy test that makes sure we don't get two referrers, or that if we do they are both following the appropriate policy? Probably want to try different kinds of elements (some are more likely to be preloaded than others).

Comment 5

[Franziskus Kiefer [:franziskus]]

Since Firefox doesn't seem to use the referrer policy attribute in pre-loads those tests would fail. I opened bug 1399780 to investigate the general issue. This specific one seems "fixed".

Comment 6

[Thomas Nguyen (:tnguyen)]

Bug 1384493 is landed that fixed referrerpolicy attr in speculative loading link (preload style) in ff 57. The possible reason you will see 2 requests before landing this bug because speculative loading ignored the referrerpolicy attr, then the attr will be parsed later. We will consider they are 2 different requests (due to different referrer) then decide not to reuse, send again.

Comment 7

[Daniel Veditz [:dveditz]]

Seems fixed, probably by bug 1384493

Comment 8

[Al Billings [:abillings - ex-MoCo]]

Jun, we've had a report from someone else in bug 1434791 (using your test page!) that this is broken again. Can you take a look at see if this is still fixed since it happened accidentally before?

Comment 9

[Jun (Request needinfo for comment, I ignore other updates)]

For me, it's fixed in Firefox 58.01 (stable) and Nightly (60.0a1).

But it's weird, I haven't tweeted the PoC link (https://test.shhnjk.com/refpol.html). Maybe I'm hacked :D

Comment 10

[Jun (Request needinfo for comment, I ignore other updates)]

Ahh, I got it. The link you saw in bug 1434791 is Chrome bug which got fixed a week ago in https://bugs.chromium.org/p/chromium/issues/detail?id=763194

I didn't bother reporting it to Firefox because Firefox has worse bug (bug 1397509), which was marked as low :)