search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.12k stars 332 forks source link

Privacy-preserving HSTS #920

Open annevk opened 5 years ago

annevk commented 5 years ago

Related to #904, #917, we should consider HSTS as well. Per https://webkit.org/blog/8146/protecting-against-hsts-abuse/ Safari has this.

What's written down there is not entirely unambiguous so I hope @bfulgham or @johnwilander can elaborate. In particular, is it really the top-level domain or the public suffix? It also seems like it might only consider HSTS when it's delivered with a top-level navigation?

johnwilander commented 5 years ago

We actually don’t double-key HSTS. Instead, we 1) restrict setting HSTS to only the first party registrable domain and the first party exact domain, and 2) we don’t apply HSTS to third party requests to domains we are blocking cookies for.

johnwilander commented 5 years ago

We’ve restricted setting HSTS to the first party since 2013 IIRC. But you could set it for any subdomain that matched the registrable domain. That’s what changed more recently, as outlined in the blog post you refer to.

annevk commented 5 years ago

Thanks John! Does that mean that if 1.2.EXAMPLE requests 2.EXAMPLE in a subresource the latter is allowed to set HSTS because it's same-site with the former and therefore still first party and also the first party registrable domain? And the former is allowed to set HSTS because it's the exact domain? But a subresource 0.1.2.EXAMPLE would not be allowed to set HSTS even though it's same-site?

johnwilander commented 5 years ago

Precisely.

MattMenke2 commented 5 years ago

The Chrome team has discussed internally what to do about this. There was pretty strong sentiment that it was valuable to learn HSTS information from all subresources, even from cross-origin requests, but we could get by with only applying them to top level navigations (without any storage isolation key).

Within the next year, the plan is to auto-upgrade all HTTP resources made in HTTPS contexts, so that just leaves us HTTP requests to HSTS domains made in HTTP contexts, and whether we want to apply HSTS to those as well - we could double-key the HSTS information for those, and just do a cross--double-key check for navigations.

annevk commented 5 years ago

https://w3c.github.io/webappsec-mixed-content/level2.html does help and would thwart the attack described on the WebKit blog. Attackers could still play with navigations, but that's much more visible.

johnwilander commented 5 years ago

https://w3c.github.io/webappsec-mixed-content/level2.html does help and would thwart the attack described on the WebKit blog. Attackers could still play with navigations, but that's much more visible.

As pointed out by Matt, auto upgrade of passive mixed content only fixes the problem on HTTPS pages. HSTS super cookies still work on HTTP pages.

annevk commented 5 years ago

I did not mean to imply that's not relevant. Another alternative there might be that HSTS becomes a secure context feature.

MattMenke2 commented 5 years ago

We've also considered just not applying HSTS to resources on an HTTP page - simpler and probably good enough, but that would mean we'd be making HTTP requests to entries in the HSTS-preload list, which seems suboptimal. We could only upgrade requests for sites in the preload list, but that would make the preload list more powerful than it already is, which seems not great.

mikewest commented 5 years ago

We talked about https://github.com/mikewest/strict-navigation-security at TPAC. It seems relevant to this conversation.

annevk commented 4 years ago

@johnwilander I have another question. If I navigate to example.com and that embeds elsewhere.invalid in a frame. Both attempt to set HSTS, does only example.com succeed?

The blog post focuses primarily on subdomains which throws me off a bit.

johnwilander commented 4 years ago

@johnwilander I have another question. If I navigate to example.com and that embeds elsewhere.invalid in a frame. Both attempt to set HSTS, does only example.com succeed?

The blog post focuses primarily on subdomains which throws me off a bit.

I don’t know what the “invalid” TLD signals, but Safari only allows first parties to set HSTS and has done so since 2013, I believe.

This basic rule was mentioned in our email to IETF WebSec: https://mailarchive.ietf.org/arch/msg/websec/t_R00ZDVHrBmroEX989GeaXdejE/

annevk commented 4 years ago

@johnwilander thanks, and now that you block cross-site cookies, does that mean no cross-site fetch will have HSTS upgrading? Do you do anything special for HSTS preloads?

johnwilander commented 4 years ago

@johnwilander thanks, and now that you block cross-site cookies, does that mean no cross-site fetch will have HSTS upgrading? Do you do anything special for HSTS preloads?

The logic is still that if cookies are blocked for a cross-site load, then (dynamic) HSTS is ignored. Since all cross-site cookies are blocked by default, so is cross-site (dynamic) HSTS.

I write dynamic HSTS above since the preload list is always respected. Preloaded HSTS cannot be used for setting a super cookie.