Remember a Login Cookie problem with a Chrome update

cause

The environment

First of all, let me introduce the basic information: one of the company’s business systems is H.xxx.com, and the login page is passport.xxx.com, which is embedded through iframe.

In a local development environment, the service system supports only HTTP. Therefore, the corresponding access address is http://h.xxx.com and the login interface is https://passport.xxx.com.

So this is a cross-protocol situation.

The problem

One day, some students log in to the system and always prompt “you have not logged in, please log in B station”, and not everyone has this problem.

After a series of checks, the only difference is that Chrome version is inconsistent (some other browsers are also ok).

The case

After the upgrade from V88 to V89, the default value of the schemeful same-site rule built in Chrome is enabled. As a result, cross-protocols are identified as cross-sites and cookies cannot be delivered.

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

In Chrome 80, the default value for SameSite has been changed to Lax.

The concept of Same – Site

Partial eTLD+1 consistency can be called same-site.

The consistency of Scheme and eTLD+1 parts is called schemeful SAME-site

Here are some examples of schemeful same-site:

Origin A	Origin B	schemeful same-site
www.example.com:443	www.evil.com:443	Cross-site: the domain name is different
	login.example.com:443	Schemeful same-site: Allows different subdomain names
	www.example.com:443	Cross-site: different protocols
	www.example.com:80	Schemeful same-site: Allows different ports
	www.example.com:443	Schemeful same-site: Exact match
	www.example.com	Schemeful same-site: Allows different ports

Schemeful Same-Site

Schemeful same-site is the advanced version of same-site, defined with two dimensions: protocol + domain name. For further Understanding, you can browse this article: Understanding ‘same-site’ and ‘same-origin’.

This means that website.example and website.example are cross-site to each other.

If your Site already uses HTTPS entirely, then Schemeful SAME-site won’t have any impact, otherwise you should upgrade to HTTPS as soon as possible.

If your project uses both HTTP and HTTPS, it’s important to understand the rules, and I’ll cover some scenarios and their cookie behavior.

Previously, you could set SameSite=None; Secure to allow the transfer of cookies across protocols. The authors recommend not using this temporary solution, but deploying HTTPS across the site as soon as possible, and indeed, like the login problem, you never know what the browser will surprise you with next.

Browser-related Settings

Schemschemeful same-site configuration portals are available on Chrome and Firefox.

Chrome 86Go ahead, modifychrome://flags/#schemeful-same-siteOptions forEnabledThat is, enable.
Firefox 79Go, turn it onabout:configModify thenetwork.cookie.sameSite.schemefulOptions fortrue.

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

However, an attacker can still tamper with cookies through insecure HTTP protocols, affecting HTTPS pages that also use cookies.

Schemschemeful same-site was born.

Common cross-protocol scenarios

Navigation jump

The previous two cross-protocol page jumps with the same domain name allowed cookies with SameSite=Strict.

Now different protocols are considered cross-sites, so cookies set to SameSite=Strict are blocked.

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

Loading child resources

Major browsers block active mixed content, such as scripts and iframe. Chrome and Firefox browsers are trying to upgrade or block passive mixed content.

Subresources include images, IFrames, XHR and Fetch requests

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

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

And even if HTTPS can load HTTP resources, all cookies are blocked.

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

POST form submission

Previously, cross-protocol POST requests could carry cookies set to SameSite=Lax or SameSite=Strict.

Now only cookies 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 to test on a web page

Developer tools on Chrome and Firefox already support this configuration and will prompt you on the console.

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

Navigation issues:

“Migrate Entirely 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.

Sub-resource 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.

For details, see Testing and Debugging Tips for Schemeful same-site.

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 site.example/ because the scheme does not match.”
“Cookie cookie_name has been treated as cross-site against site.example/ because the scheme does not match.”

FAQ

My page is already used`HTTPS`Why do we still see it`issues`?

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

One solution is to use HTTP strict-transport-Security (HSTS) + includeSubDomain.

With HSTS + includeSubDomain, browsers will automatically replace secure protocol access even if your page contains unsafe links.

If I can’t upgrade to HTTPS

You can adjust the SameSite Settings to relax the restrictions.

onlySameSite=StrictthecookiesWhen blocked, you can adjust toSameSite=Lax
Set toStrictorLaxthecookiesWere stopped, and at the same timecookiesIs sent to securityURLOf, set toNoneThen it goes into effect.

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

Cookies that do not have the SameSite attribute are treated as 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 public account: Lake Sword, find out more about me.