W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

[referrer] HTTPS->HTTP

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 24 Oct 2014 16:29:01 +1100
Message-Id: <69FC5777-732A-4980-920D-285FA6B68B48@mnot.net>
To: WebAppSec WG <public-webappsec@w3.org>
Reading the ED of Referrer [sic :)].

HTTP/1.1 <http://httpwg.github.io/specs/rfc7231.html#header.referer> says:

> A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol.

The Referrer spec makes it possible to relax this. 

The minor issue here is that these specs will not conflict; I think that can be resolved by filing an errata against RFC7231 to add an appropriate "unless..." clause there.

The bigger issue, however, is whether this is a good idea at all. In particular, "unsafe-url" removes this prohibition completely, for an *entire* page. 

This is likely to create a situation where those providing third-party functionality want/require referers, so they tell HTTPS sites to set "unsafe-url" or face a functional (or financial) penalty; now not only the intended content but all other fetches from the page will send a referer.

I understand that there's a delicate balance here; if referers aren't sent at all, sites may be reluctant to move to HTTPS (although one might just say that the sites they're linking to should move to HTTPS!). The question is whether there's a net improvement to Web security.

Arguably, origin-only and origin-when-cross-origin might get that balance right; I question whether unsafe-url and always (which isn't well-documented, btw) do.

Has this been discussed yet?

Regards,



--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 24 October 2014 05:29:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC