Tighten 'same site' checks to include 'scheme'. #449
Conversation
This patch introduces 'schemelessly same site' on both 'host' and 'URL', moves 'same site' to URL, and tightens it by requiring a scheme match in addition to a registrable domain match. This, hopefully, will create stronger security boundaries in places where we perform "same site" checks, while giving us the flexibility to grandparent in existing behavior we decide to keep. Partially addresses #448.
|
(Nevermind, I apparently already had a fork of the repo lying around. :) ) |
| <p>Two <a for=/>URL</a>s, <var>A</var> and <var>B</var> are said to be | ||
| <dfn for=url>schemelessly same site</dfn> with each other if <var>A</var>'s | ||
| <a for=url>host</a> is <a for=host>schemelessly same site</a> with <var>B</var>'s | ||
| <a for=url>host</a>. |
There was a problem hiding this comment.
A URL's host can be null. So probably needs to be about as complicated (or you need to assert a certain scheme).
|
I ran into the same confusion today writing an explainer where I wanted to use "same site" and "site isolation" to mean the same thing. I'm happy to try to drive this change over the finish line, but I can't understand @annevk's outstanding review comment. (In particular the second sentence seems to be missing some words.) |
|
Sorry, I meant about as complicated as the comparison done above for hosts. In that you have to null check host before comparing and returning false if a host is null. Also, reading the original issue again the idea was that we'd also define same-site for origins in HTML and defer the URL comparison to that. Meaning that for a URL you first compute the origin and then see if it's same-site. Also, HTML has this "agent cluster key" concept. Should we define that as "site" and also define "schemeless site" so we can talk about these things concretely without referring to the comparisons? |
|
Those all seem like reasonable things to do. The definitions for "site" and "schemeless site" seem like they should be able to be done in the URL spec. If we changed same-site (and probably schemelessly-same-site) to operate on origins I'm unsure whether it'd still be useful to have definitions for URLs in this spec. |
|
The usage in https://fetch.spec.whatwg.org/#cross-origin-resource-policy-check could be done on top of origins entirely. HTML's https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to is also used by WebAuthn, but uses registrable domain and public suffix directly (and has to). I think HTML's algorithm could be used for cookies too, reading https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.1.3. HTML's agent stuff would be a little cleaner if you could obtain a site from an origin (i.e., "obtain an agent cluster key" renamed). No other uses come to mind, but it seems like you had at least one other and maybe Mike knows more. |
This patch introduces 'schemelessly same site' on both 'host' and 'URL',
moves 'same site' to URL, and tightens it by requiring a scheme match in
addition to a registrable domain match. This, hopefully, will create
stronger security boundaries in places where we perform "same site"
checks, while giving us the flexibility to grandparent in existing
behavior we decide to keep.
Partially addresses #448.
Preview | Diff