Remember the login Cookie issue with the Chrome update

cause

The environment

First, the basics: One of the company’s business systems is h.xxx.com, which is logged in to a web page, passport.xxx.com, embedded in an iframe.

Under the local development environment, the business system only supports HTTP protocol, so the corresponding access address is http://h.xxx.com, and the login interface is always “.

So this is a cross-protocol situation.

The problem

One day, after some students log in the system, they always prompt “you are not logged in, please log in B station first”, and not all of them have this problem.

After a series of checks, the only difference was that the Chrome version was inconsistent (some other browsers were also fine).

The case

When you upgrade from V88 to V89, the schemeful same-site rule built into the Chrome browser is enabled by default, resulting in cross-protocol being considered cross-site and cookies not being delivered.

Temporary solution: address bar Open chrome://flags/#schemeful same-site and set the option to Disabled.

in
Chrome 80Version,
SameSiteThe default value of
Lax.

The concept of Same – Site

An ETLD +1 partial agreement is called a same-site.

If the Scheme is consistent with the ETLD +1 part, it is called schemeful same-site

Here are some schemeful same-site examples:

Origin A	Origin B	schemeful same-site
https://www.example.com: 443	https://www.evil.com: 443	Cross-site: Different domain name
	https://login.example.com: 443	Schemeful same-site: Allow subdomains to be different
	http://www.example.com: 443	Cross-site: Different protocol
	https://www.example.com: 80	Schemeful same-site: Allow different ports
	https://www.example.com: 443	Schemeful same-site: A schemeful same-site
	https://www.example.com	Schemeful same-site: Allow different ports

Schemeful Same-Site

Schemeful same-site is an advanced version of same-site, defined by protocol + domain. If you want to learn more about it, you can check out this article: Understanding ‘same-site’ and ‘same-origin’.

This means that
http://website.example 和
https://website.exampleIt is cross-site with each other.

If your Site is already using HTTPS, Schemeful same-site won’t make any difference, or you should upgrade to HTTPS as soon as possible.

If your project uses both HTTP and HTTPS, it’s important to understand the rules. Here are some scenarios and the cookie behavior associated with them.

It used to be possible by setting
SameSite=None; SecureTo allow
Across the agreementthe
cookiesTransport, the authors recommend not using this temporary solution and should be deployed across the site as soon as possible
HTTPSJust like the log-in problem above, you never know what the browser is going to surprise you with.

Browser Settings

Configuration entry for schemjocked-same-site is available on Chrome and Firefox.

Chrome 86Go ahead and modifychrome://flags/#schemeful-same-siteOptions forEnabledThat’s enabled.
Firefox 79Here we go, openabout:configModify thenetwork.cookie.sameSite.schemefulOptions fortrue.

In previous browser updates, SameSite=Lax was set as the default to protect against cross-site request forgery (CSRF) attacks.

However, an attacker can still tamper with cookies over the insecure HTTP protocol, affecting HTTPS pages that also use the same cookies.

Schemjet-same-site was born.

Common cross-protocol scenarios

Navigation jump

The previous two page transitions across protocols and domains allow cookies with SameSite=Strict.

Cookies that are set to SameSite=Strict are blocked because the different protocols are now considered cross-site.

	HTTP and HTTPS	The HTTPS – HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	✅ charges	✅ charges
SameSite=None; Secure	✅ charges	⛔ Blocked

Load subresource

Major browsers block it
active mixed content(active mixed content), such as
scripts,
iframe.
Chromeand
FirefoxThe browser is trying to upgrade or block
passive mixed content(Passive mixed content).

Subresources include images, iframes, and XHR, FETCH requests

Previously, if a page loaded cross-protocol resources, they could share cookies with SameSite=Strict and SameSite=Lax.

However, both are now blocked by the browser and cannot be shared.

In addition, all cookies will be blocked even if HTTPS is able to load HTTP resources.

	HTTP and HTTPS	The HTTPS – HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None; Secure	✅ charges	⛔ Blocked

POST form submission

Previously POST requests across protocols could carry cookies set to SameSite=Lax or SameSite=Strict.

Now only cookies that are set to SameSite=None can be sent on form requests.

	HTTP and HTTPS	The HTTPS – HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None; Secure	✅ charges	⛔ Blocked

How do I test on a web page

Developer tools on Chrome and Firefox already support this configuration and will indicate it on the console.

Starting with Chrome 86, devtools-> Issue displays a highlighted reminder about Schemeful same-site.

Navigation issues:

Migrate grate to HTTPS to continue having cookies sent on same-site requests A warning that the cookie will be blocked in a future version of Chrome.
“Migrate entirely to HTTPS to have cookies sent on same-site requests” — A warning that the cookie has been blocked.

Subresource loading issues:

“Migrate entirely to HTTPS to continue having cookies sent to same-site subresources” or “Migrate entirely to HTTPS to Continue allowing cookies to be set by same-site subresources” — Warnings that the cookie will be blocked in a future version of Chrome.
“Migrate entirely to HTTPS to have cookies sent to same-site subresources” or “Migrate entirely to HTTPS to allow Cookies to be set by same-site subresources” — Warnings that the cookie has been blocked. The latter warning can also appear when POSTing a form.

Read Testing and Debugging Tips for Schemeful Same-Site for details.

Firefox version 79, network. Cookies. SameSite. Schemeful is set to true, the console will also present relevant information:

“Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match.”
“Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match.”

FAQ

My web page is already in use`HTTPS`, why do you still see it`issues`?

It is likely that some of the links or resources in the page still point to an unsafe address.

One solution is to use HTTP strict-transport-security (HSTS) + IncludeSubdomain.

After using HSTS + IncludeSubdomain, the browser will automatically replace the secure protocol access even if there are unsecured links in your page.

If I can’t upgrade to HTTPS

You can adjust the Samesite Settings to relax restrictions.

onlySameSite=StrictthecookiesWhen blocked, you can adjust toSameSite=Lax
Set toStrictorLaxthecookiesBoth were blocked at the same timecookiesIs sent to securityURL, set toNoneThen it can take effect.

if`cookies`There is no set`SameSite`Attribute?

Cookies that do not have the SameSite attribute will be treated as if they were SameSite=Lax.

WebSockets

Same-site:

wss:// connection from https://
ws:// connection from http://

Cross-site:

wss:// connection from http://
ws:// connection from https://

The main content of this article is from: Schemeful same-site

Follow the official account: Huzhong Jian, find out more about me.