From 16677c361d58ca75d794814eb9fb70e45f7d9dd5 Mon Sep 17 00:00:00 2001
From: Mike West <mkwst@chromium.org>
Date: Fri, 13 Sep 2019 12:06:58 +0200
Subject: [PATCH] Tighten 'same site' checks to include 'scheme'.

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 whatwg/url#448.
---
 url.bs | 115 +++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 71 insertions(+), 44 deletions(-)

diff --git a/url.bs b/url.bs
index fdf9c54d..7f94ec5d 100644
--- a/url.bs
+++ b/url.bs
@@ -346,50 +346,6 @@ obtain <var>host</var>'s <a for=host>registrable domain</a>, run these steps:
  </table>
 </div>
 
-<p>Two <a for=/>hosts</a>, <var>A</var> and <var>B</var> are said to be
-<dfn for=host export>same site</dfn> with each other if either of the following statements are true:
-
-<ul class=brief>
- <li><p><var>A</var> <a for=host>equals</a> <var>B</var> and <var>A</var>'s
- <a for=host>registrable domain</a> is non-null.
-
- <li><p><var>A</var>'s <a for=host>registrable domain</a> is <var>B</var>'s
- <a for=host>registrable domain</a> and is non-null.
-</ul>
-
-<div class=example id=example-same-site>
- <p>Assuming that <code>suffix.example</code> is a <a for=host>public suffix</a> and that
- <code>example.com</code> is not:
-
- <ul>
-  <li><p><code>example.com</code>, <code>sub.example.com</code>, <code>other.example.com</code>,
-  <code>sub.sub.example.com</code>, and <code>sub.other.example.com</code> are all <a>same site</a>
-  with each other (and themselves), as their <a for=host>registrable domains</a> are
-  <code>example.com</code>.
-
-  <li><p><code>registrable.suffix.example</code>, <code>sub.registrable.suffix.example</code>,
-  <code>other.registrable.suffix.example</code>, <code>sub.sub.registrable.suffix.example</code>,
-  and <code>sub.other.registrable.suffix.example</code> are all <a>same site</a> with each other
-  (and themselves), as their <a for=host>registrable domains</a> are
-  <code>registrable.suffix.example</code>.
-
-  <li><p><code>example.com</code> and <code>registrable.suffix.example</code> are not
-  <a>same site</a> with each other, as their <a for=host>registrable domains</a> differ.
-
-  <li><p><code>suffix.example</code> is not <a>same site</a> with <code>suffix.example</code>, as
-  it is a <a for=host>public suffix</a>, and therefore has a null
-  <a for=host>registrable domain</a>.
- </ul>
-</div>
-
-<p class=warning>Specifications should prefer the <a for=/>origin</a> concept for security
-decisions. The notion of "<a for=host>public suffix</a>", "<a for=host>registrable domain</a>",
-and "<a>same site</a>" cannot be relied-upon to provide a hard security boundary, as the public
-suffix list will diverge from client to client. Specifications which ignore this advice are
-encouraged to carefully consider whether URLs' schemes ought to be incorporated into any decision
-made based upon whether or not two <a for=/>hosts</a> are <a>same site</a>. HTML's <a>same
-origin-domain</a> concept is a reasonable example of this consideration in practice.
-
 
 <h3 id=idna>IDNA</h3>
 
@@ -2473,6 +2429,77 @@ background information. [[!HTML]]
 </dl>
 
 
+<h3 id=site>Site</h3>
+
+<p>Two <a for=/>hosts</a>, <var>A</var> and <var>B</var> are said to be
+<dfn for=host export>schemelessly same site</dfn> with each other if either of the following statements are true:
+
+<ul class=brief>
+ <li><p><var>A</var> <a for=host>equals</a> <var>B</var> and <var>A</var>'s
+ <a for=host>registrable domain</a> is non-null.
+
+ <li><p><var>A</var>'s <a for=host>registrable domain</a> is <var>B</var>'s
+ <a for=host>registrable domain</a> and is non-null.
+</ul>
+
+<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>.
+
+<p>Two <a for=/>URL</a>s, <var>A</var> and <var>B</var> are said to be <dfn for=url>same site</dfn>
+with each other if the following statements are both true:
+
+<ul class=brief>
+  <li><var>A</var> is <a for=url>schemelessly same site</a> with <var>B</var>
+  <li><var>A</var>'s <a for=url>scheme</a> is <var>B</var>'s <a for=url>scheme</a>
+</ul>
+
+<p class=warning>Specifications should prefer the <a for=/>origin</a> concept for security
+decisions. The notions of "<a for=host>public suffix</a>", "<a for=host>registrable domain</a>",
+"<a for=url>schemelessly same site</a>", and "<a for=url>same site</a>" cannot be relied-upon to
+provide a hard security boundary, as the public suffix list will diverge from client to client.
+Specifications which ignore this advice are encouraged to prefer "<a for=url>same site</a>" checks
+to "<a for=url>schemelessly same site</a>" checks, as the latter would bucket both secure and
+non-secure URLs together in ways that can undermine the security boundary a given check aims to
+create.
+
+<div class=example id=example-same-site>
+ <p>Assuming that <code>suffix.example</code> is a <a for=host>public suffix</a> and that
+ <code>example.com</code> is not:
+
+ <ul>
+  <li><p><code>https://example.com/</code>, <code>https://sub.example.com/</code>,
+  <code>https://other.example.com/</code>, <code>https://sub.sub.example.com/</code>, and
+  <code>https://sub.other.example.com/</code> are all <a for=url>same site</a> (and therefore also
+  <a for=url>schemelessly same site</a>) with each other (and themselves), as their
+  <a for=host>registrable domains</a> are all <code>example.com</code>, and their schemes are all
+  <code>https</code>.
+
+  <li><p><code>http://non-secure.example.com/</code> is <a for=url>schemelessly same site</a> with
+  the group above, as its <a for=host>registrable domain</a> is also <code>example.com</code>, but
+  its scheme does not match, so it is not <a for=url>same site</a>.
+
+  <li><p><code>https://registrable.suffix.example/</code>,
+  <code>https://sub.registrable.suffix.example/</code>,
+  <code>https://other.registrable.suffix.example/</code>,
+  <code>https://sub.sub.registrable.suffix.example/</code>, and
+  <code>https://sub.other.registrable.suffix.example/</code> are all <a for=url>same site</a> (and
+  therefore also <a for=url>schemelessly same site</a>) with each other (and themselves), as their
+  <a for=host>registrable domains</a> are <code>registrable.suffix.example</code>, and their schemes
+  are all <code>https</code>.
+
+  <li><p><code>https://example.com/</code> and <code>https://registrable.suffix.example/</code> are
+  neither <a for=url>schemelessly same site</a> nor <a for=url>same site</a> with each other, as
+  their <a for=host>registrable domains</a> differ.
+
+  <li><p><code>https://suffix.example/</code> is not <a for=url>same site</a> with
+  <code>https://suffix.example/</code>, as it represents a <a for=host>public suffix</a> directly,
+  and therefore has a null <a for=host>registrable domain</a>.
+ </ul>
+</div>
+
+
 <h3 id=url-rendering>URL rendering</h3>
 <!-- See https://www.w3.org/Bugs/Public/show_bug.cgi?id=27641 for context -->