GitLab

"Leave Secure Cookies Alone" refers to step 12 in Section 5.4 of RFC
6265bis:
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-5.4

If an insecure URL attempts to set a cookie that is "equivalent" to a
preexisting Secure cookie, then that set attempt is rejected.

This CL:
 - Fixes a bug in our calculation of "equivalence" for these purposes,
   which was not correctly computing domain-matching described in
   Section 5.1.3 of the RFC. (See example below.)
 - Adds (perhaps excessively) exhaustive tests for this behavior.
 - Adds comments clarifying the situation.
 - Renames variables to make the direction of the comparison clearer,
   as this is an asymmetric comparison.

Example:

Before this CL: If https://foo.com/ has set a secure host cookie

  cookie=secure; secure

then we allowed an insecure host cookie to be set by http://a.foo.com/:

  cookie=insecure

This cookie should be rejected, according to the spec, because
a.foo.com and foo.com are domain-matching.

Bug: 1069804
Change-Id: I002f9ffd7cf8523a2f4291525db2939306028d7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2143865
Commit-Queue: Lily Chen <chlily@chromium.org>
Reviewed-by: Maksim Orlovich <morlovich@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#762005}