Referrer and cross-origin CSS

[annevk]

This is somewhat related to #409 and depends on the outcome of w3c/ServiceWorker#719.

The question is mostly how the service worker can set the correct referrer for these kind of resources if it were only allowed to set same-origin URLs.

(I'm assuming setting referrer to any URL would not fly.)

[mikewest]

Without thinking about it too hard, setting the referer header to any same-origin URL is probably ok, given that it's already in the SW's power to do so.

[annevk]

That doesn't solve the problem for cross-origin CSS, "no-cors" or "cors".

[annevk]

@jeisinger ^^

[jeisinger]

what about letting the service worker not change the referrer at all?

requests created from the service worker get the URL the service worker was loaded from as referrer with whatever referrer policy the CSP set.

if a service worker gets a fetch object from somewhere else, the referrer of that fetch object applies instead.

[annevk]

The tricky thing with that is that while you can reuse Request objects, you can also override a bunch of things on it using fetch(). We could leave the referrer intact, but I wonder if there's any problem if the other fields do change.

E.g. the referrer points to some CORS CSS resource, but the method used is POST. That kind of thing is not possible today.

[jeisinger]

i guess when we update the target url, we should update the referrer according to the referrer policy, that's all, no?

[annevk]

Here's the scenario I'm worried about: a CORS CSS resources lives at https://cdn.example/css (c). It loads https://fonts.invalid/font (f). The document is at https://document.example/ (d) and the service worker at https://document.example/sw (sw). Without sw the referrer for f would be c. Currently with sw the referrer for f is sw. We could make it c again by copying the referrer over from event.request, but the sw has new features that allow it to make new kinds of requests f has never seen before. So if f has some logic based on c, sw can now be used to mount attacks by making requests that would be impossible to make from c normally.

[sicking]

Why not only copy the referrer if the SW "executes" the Request object that it received in the onfetch event?

And otherwise require that the referrer is of the origin of the SW.

I.e. if sw does fetch(event.request) then we'd use the referrer of c. Independent of what sw then does with the resulting Response. If sw creates a Request in any other way, the referrer would be the URL of sw.

[annevk]

Yeah, I think that's what we should do. And if you pass a dictionary as in fetch(event.request, {...}) we'd reset the referrer to be that of the service worker.

[annevk]

That still leaves the question of how Fetch' referrer feature should work. Only allow policy values (as with the proposed referrer="" attribute) or allow it to be set to any same-origin URL? (If it's missing we'd default to copying the referrer so the cross-origin referrer values you get with CSS remain working as per above.)

[sicking]

Given that <meta referrer> only provides a default policy, but then allows that policy to be overridden on a case-by-case basis it makes sense to me to do the same in SWs. I.e. I see no problem with allowing the SW to set an explicit referrer no matter what default policy the main document has.

Maybe it's as simple as making the Request object not contain a referrer if the document asked for one not to be sent, either though default policy or though policy on the specific element. If the SW then does fetch(event.request), then that lack of referrer is what's used.

But if the SW creates its own Request, then we'd use the default policy of the SW.

Either way, if the SW explicitly sets a referrer, then that should be allowed as long as the referrer url is same-origin with the SW.

Only pity is that there's nothing like <meta referrer> in SW. You have to use a CSP header. Maybe there should be API for applying more strict CSP in a global.

[jeisinger]

i'd rather not allow same origin urls: we'd (again) run into problems like some.site/~user1 vs some.site/~user2 etc..

[sicking]

That's already possible. A page on some.site/~user1 can open some.site/~user2 in an <iframe> and then inject a <script> element which does an XHR request to wherever.

[jeisinger]

fair enough.

it collides, however, with the per-page suborigin thing the WebAppSec group is working on as well, where ~user2 could restrict itself to a different suborigin that ~user1 no longer can access. Would we in that case query ~user2 somehow before we allow the sw on ~user1 to set its referrer to ~user2?

[annevk]

How does that proposal deal with pushState()?

[jeisinger]

that is an excellent question

[annevk]

So yeah, with pushState() I can create any same-origin referrer I want: https://dump.testsuite.org/referrer-and-pushstate/test.html

[annevk]

This is now fixed in Fetch with whatwg/fetch@3a21ed3.

Outstanding work for Referrer Policy is summarized in #409 (comment).