1397509 - Referrer policy bypass with srcdoc

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

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/61.0.3163.79 Safari/537.36

Steps to reproduce:

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


Actual results:

https://shhnjk.com/ gets referrer


Expected results:

Referrer shouldn't be sent because website sets referrer policy meta tag as well as attribute. srcdoc is not considered in scope of referrer policy via meta nor attribute, bypassing referrer policy.

Comment 1

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

Sorry, meta referrer was malformed. Below is the correct PoC.

https://test.shhnjk.com/reftest.html

Comment 2

[Daniel Veditz [:dveditz]]

Does the spec say to propagate the referrer policy into srcdoc? In theory the srcdoc could use a <meta> tag to set its own policy and maybe that's what is expected.

Comment 3

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

https://www.w3.org/TR/referrer-policy/#referrer-policy-delivery-nested
"The HTML Standard and Fetch Standard define how nested browsing contexts that are not created from responses, such as iframe elements with their srcdoc attribute set, or created from a blob URL, inherit their referrer policy from the creator browsing context or blob URL."

So at least, meta tag should prevent referrer leakage.

Comment 4

[Franziskus Kiefer [:franziskus]]

This looks like an issue. I don't think we have any tests for srcdoc (neither do the web platform tests). Given that Firefox implements referrer policies for iframes it should probably apply them to srcdoc as well. But this might also need some clarification in the spec and web platform tests.

Comment 5

[Daniel Veditz [:dveditz]]

The section Jun linked to is "non-normative", but I couldn't find a corresponding place in HTML. Maybe Fetch §4.1 "Main Fetch" step 6 is saying this?

"If request’s referrer policy is the empty string and request’s client is non-null, then set request’s referrer policy to request’s client’s referrer policy. [REFERRER]"

In the absence of any clear normative text, the non-normative text quoted in comment 3 is pretty clear.

Comment 6

[Daniel Veditz [:dveditz]]

Franziskus: what about populating an about:blank document, either through document.write() or DOM manipulation? Those should also inherit the referrer policy (whether it's an iframe or a window.open() new tab). Do they? Seems like the creation/inheritance would happen at the same place for both cases.

Comment 7

[Franziskus Kiefer [:franziskus]]

Hm, looks like there's actually one test for srcdoc [1] (that Firefox fails).

> what about populating an about:blank document, either through document.write() or DOM manipulation? Those should also inherit the referrer policy (whether it's an iframe or a window.open() new tab). Do they?

Running a quick check that seems to work fine. We don't have tests for it though I think.

[1] http://wpt.fyi/referrer-policy/generic/subresource-test/image-decoding.html

Comment 9

[Daniel Veditz [:dveditz]]

See also https://test.shhnjk.com/refpol.html from bug 1397064 comment 10

Comment 11

[Daniel Veditz [:dveditz]]

Christoph: This one is fixed, right? bug 1539875 is different and not fixed, though.

Comment 12

[Christoph Kerschbaumer [:ckerschb]]

Yes this one was fixed by Bug 1534681, and in particular by consulting ReferrerInfo::ShouldResponseInheritReferrerInfo.

It seems Bug 1539875 is still a problem.

Comment 13

[:Gijs (he/him)]

Going to mark this as fixed based on comment #11 / comment 12. Christoph, tagging you to revert if I missed something. :-)

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

(In reply to :Gijs (he/him) from comment #13)

Going to mark this as fixed based on comment #11 / comment 12. Christoph, tagging you to revert if I missed something. :-)

I should have done that when answering in Comment 12 - thanks!

Comment 15

[:Gijs (he/him)]

Hm, forgot to press this button, apparently.