記一次Chrome更新帶來的登陸Cookie問題

事件原由

環境

首先介紹下基本信息：公司的某個業務系統是h.xxx.com，登陸走的經過iframe嵌入的網頁passport.xxx.com。

本地開發環境下，業務系統只支持http協議，因此對應訪問地址爲http://h.xxx.com，登陸接口始終是https://passport.xxx.com。

這樣就是一個跨協議的狀況了。

問題

某一天，有同窗登陸系統後始終提示「你未登陸，請先登陸B站」，並且並非全部人有該問題。

通過一系列排查，發現惟一的區別只有Chrome瀏覽器版本不一致（使用部分其餘瀏覽器也是沒有問題的）。

結案

從v88升級到v89後，Chrome瀏覽器內置的schemeful-same-site規則默認值改成啓用，致使跨協議也被認定爲跨站(cross-site)，cookies沒法傳遞。

臨時解決方案：地址欄打開chrome://flags/#schemeful-same-site，將選項設置爲Disabled。

在 Chrome 80版本， SameSite的默認值被改成 Lax。

Same-Site 的概念

eTLD+1部分一致就能夠稱之爲same-site。

scheme和eTLD+1部分一致則被稱爲schemeful same-site

下面是一些schemeful same-site的案例：

Origin A	Origin B	schemeful same-site
https://www.example.com:443	https://www.evil.com:443	cross-site: 域名不一樣
	https://login.example.com:443	schemeful same-site: 容許子域名不一樣
	http://www.example.com:443	cross-site: 協議不一樣
	https://www.example.com:80	schemeful same-site: 容許端口不一樣
	https://www.example.com:443	schemeful same-site: 徹底匹配
	https://www.example.com	schemeful same-site: 容許端口不一樣

Schemeful Same-Site

Schemeful Same-Site 是 same-site 的進階版，經過協議+域名兩個維度來定義，若是想深刻了解下，你能夠瀏覽這篇文章：Understanding 'same-site' and 'same-origin' 。

這意味着 http://website.example 和 https://website.example 相互之間是跨站(cross-site)的。

若是你的網站已經所有使用HTTPS，那Schemeful Same-Site不會有任何影響，不然應該儘快升級到HTTPS。

若是你的項目同時使用HTTP和HTTPS，那就頗有必要了解相關規則，接下來將介紹一些場景以及與之對應的cookie行爲。

之前能夠經過設置 SameSite=None; Secure來容許 跨協議的 cookies傳輸，原做者建議不要使用這個臨時解決方案，應該儘快全站部署 HTTPS，事實上也確實是這樣的，就像前文的登陸問題，你永遠不知道瀏覽器給你的下一個「驚喜」是什麼。

瀏覽器相關設置

Chrome和Firefox上提供了schemeful-same-site的配置入口。

• Chrome 86 開始，修改chrome://flags/#schemeful-same-site選項爲Enabled便是啓用。
• Firefox 79 開始，打開about:config修改 network.cookie.sameSite.schemeful選項爲true。

在之前的瀏覽器更新中，爲了防止跨站請求僞造(CSRF)攻擊，已經將SameSite=Lax設置爲默認項。

然而攻擊者仍是能經過不安全的HTTP協議篡改cookies，影響到也使用一樣cookies的HTTPS頁面。

schemeful-same-site也就應運而生。

常見的跨協議場景

導航跳轉

以前兩個跨協議同域名的頁面跳轉是容許攜帶設爲SameSite=Strict的cookies。

如今不一樣協議被認定爲跨站(cross-site)，因此設爲SameSite=Strict的cookies就被阻擋了。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	✅ Allowed	✅ Allowed
SameSite=None;Secure	✅ Allowed	⛔ Blocked

加載子資源

主流瀏覽器都會阻止 active mixed content（主動型混合內容） ，如 scripts、 iframe。 Chrome和 Firefox瀏覽器正在嘗試升級或阻止 passive mixed content(被動型混合內容)。

子資源（subresources）包括圖片，iframes 以及 XHR、Fetch請求

以前若是一個頁面加載了跨協議的資源，他們之間是能夠共享設爲SameSite=Strict、SameSite=Lax的cookies。

然而如今二者通通被瀏覽器阻止，沒法傳輸共享。

另外即便HTTPS可以加載HTTP資源，全部的cookies仍是會被阻止。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None;Secure	✅ Allowed	⛔ Blocked

POST表單提交

之前跨協議的POST請求是能夠攜帶設爲SameSite=Lax或SameSite=Strict的cookies。

如今只有設置爲SameSite=None的cookies能夠在表單請求時被髮送。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Blocked	⛔ Blocked
SameSite=Lax	⛔ Blocked	⛔ Blocked
SameSite=None;Secure	✅ Allowed	⛔ Blocked

如何在網頁上測試

Chrome和Firefox上的開發者工具都已經支持相關配置，而且會在控制檯給出提示。

Chrome 86版本開始，DevTools->Issue顯示關於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.

子資源加載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.

詳情能夠閱讀 Testing and Debugging Tips for Schemeful Same-Site。

Firefox 79版本開始，network.cookie.sameSite.schemeful設置爲true後，控制檯也會呈現相關信息：

• "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

個人網頁已經使用HTTPS，爲何還會看到issues？

極可能是網頁內的一些連接或資源仍是指向不安全的地址。

其中一個解決辦法就是使用 HTTP Strict-Transport-Security (HSTS) + includeSubDomain。

使用 HSTS + includeSubDomain 方案以後，即使你的頁面裏還存在不安全的連接，瀏覽器會自動替換安全的協議訪問。

若是我沒法升級到HTTPS

能夠調整SameSite的設置，放寬限制。

• 只有SameSite=Strict的cookies被阻止時，你能夠調整爲SameSite=Lax
• 設置爲Strict或Lax的cookies均被阻止，同時cookies是發送到安全URL的，把設置爲None後就能夠生效。

若是cookies沒有設置SameSite屬性？

沒有SameSite屬性的cookies，會被當成SameSite=Lax處理。

WebSockets

Same-site:

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

Cross-site:

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

本文主要內容來自：Schemeful Same-Site

關注公衆號：湖中劍，找到更多關於個人內容。