成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Cookie的SameSite了解吧,那SameParty呢?

開發 前端
對三方cookie的限制一是為了瀏覽器安全,但在國外推動的更重要原因是個人的隱私安全。但不論是出于什么目的,這種改變都會對當前的業務架構造成很大的影響。

大家好,我是年年!

今天介紹的是三方cookie相關的內容,本文會講清:

  1. 什么是三方cookie?
  2. same-site的變化是什么,對我們的業務有什么影響?
  3. 為什么有了same-site,還需要same-party?

什么是三方cookie

三方指的是非同站,這個同站和同源協議中的源origin不同,它的要求更寬松。

同源協議中的源是由「協議+域名+端口」三者一起定義的,有一個不同就不算同源,而同站只受域名的約束,并且還不要求一模一樣——只要「有效頂級域名+二級域名」相同,都算同站。

有效頂級域名是由Mozilla維護的一份表格,其中包括.com、.co.uk、.github.io等。所以ai.taobao.com和www.taobao.com是同站的,因為它們的頂級域名(.com)+二級域名(.taobao)相同。

現在知道了什么是站,就可以很簡單區分了:

打開開發者工具的application,domain一列中顯示和當前域名不同的就是三方cookie。

如何攜帶三方cookie

cookie的攜帶是瀏覽器自動的操作,規則是「不認來源,只看目的」,下面會講清這句話的意思。

cookie下發

首先,需要先了解cookie的下發,服務端會將其下發到瀏覽器,方法是通過響應頭中的set-cookie字段。

里面還包括一些配置屬性,關鍵的是其中的domain。

domain

指定cookie未來使用時,可以被攜帶到哪些域名。其值可以設置為當前服務端的父級域名或其本身,比如ai.taobao.com設置的cookie的domain可以為.taobao.com,所設置值的所有子域名都可以使用,比如www.taobao.com。

如果不設置,會默認為當前域名ai.taobao.com,并且只有自己可以使用,子域名sub.ai.taobao.com都不能使用,適用范圍就小了很多,所以一般都會設置。

但是不能設置為跨站點的.baidu.com,也不能是頂級域名.com。

其余的屬性還有這些:

1.path:指定cookie未來使用時,可以被攜帶到合法域名的哪些URI。和domain很像,也只能設置為當前路徑的父級路徑或其本身,設置值的所有子路徑都可以訪問。

2.expire/max-age: 指定cookie的有效期,其中expire是一個絕對時間,max-age是相對時間,單位是秒,兩者同時存在時,max-age優先級更高;如果兩者都沒有,則為會話級別的cookie,即用戶關閉瀏覽器時失效。

Set-Cookie: id=nian; Expires=Wed, 30 Aug 2022 00:00:00 GMT; Max-Age=3600

3.secure:只能在HTTPS環境中被下發以及攜帶。

4.http-only:禁止客戶端腳本通過 document.cookie 獲取 cookie,避免 XSS 攻擊。

5.還有下面會重點講解的same-site和same-party。

Cookie攜帶

上面提到,cookie的domain字段很關鍵,它規定請求哪些域名才會攜帶,注意,這里指的是請求目的地的域名。

舉個例子,首先我通過響應頭在瀏覽器中設置了一個cookie,domain是.a.com。

set-cookie: id=nian; domain=.a.com;

現在有三個請求:

  1. 網頁www.a.com/index.html的前端頁面,去請求接口www.b.com/api。
  2. 網頁www.b.com/index.html的前端頁面,去請求接口www.a.com/api。
  3. 網頁www.a.com/index.html的前端頁面,去請求接口www.a.com/api。

有點繞,可以暫停思考10秒,哪個請求會帶上之前設置的cookie呢?

答案是2、3都會帶上cookie,因為cookie的取用規則是去看請求的目的地,2、3請求的都是www.a.com/api命中domain=.a.com規則。

這就是「不認來源,只看目的」的意思,不管請求來源是哪里,只要請求的目的是a站,cookie都會攜帶上。

通過這個案例也可以再回顧一下:3的這種情況的叫第一方cookie,2的這種情況叫第三方cookie。

限制三方cookie的攜帶

「不認來源,只看目的」規矩在2020年開始被打破,這種變化體現在瀏覽器將same-site:lax設置為默認屬性。

chrome操作比較平緩,目前可以手動設置same-site:none恢復之前規則。

但在safari中如果這樣設置,會被當作same-site:strict。

可以看到,在safari中使用的全是第一方cookie,直觀的體驗就是在天貓登錄完,打開淘寶,還需要再登錄一次。

也就是說現在cookie的取用是「既看來源,又看目的」了。

SameSite

上面提到的same-site是cookie的一個屬性,它制約第三方cookie的攜帶,其值有三個none、strict、lax。

  1. strict代表完全禁止三方cookie,這是最嚴格防護,可以避免被CSRF攻擊,但缺點也很明顯,像天貓、淘寶這種同屬一個主體運營的網站不得不重復登錄。
  2. none代表完全不做限制,即之前「不認來源,只看目的」的cookie取用原則。
  3. Lax則是折中,在某些情況下會限制三方cookie的攜帶,某些情況又放行,這也是瀏覽器的默認值(包括safari)。

在safari,same-site的默認值是lax,如果把它設置為same-site:none,會適得其反,被當作strict處理。

SameSite的修改

可以這么理解,瀏覽器將same-site的默認值從none調整到了lax。

same-site:lax的具體規則如下:

而在這之前是會全部發送的。

SameSite修改帶來的影響

像a鏈接這種,沒有受到影響,依舊會帶上三方cookie,這樣可以保證從百度搜索中打開淘寶,是有登錄狀態的。

但是對大部分業務的影響是巨大的,比如監控埋點系統。

埋點監控SDK是用圖片的src去做請求的發送的,從上面的表格可知,變成lax后默認不發送了,這時用戶的身份便無法確認,UV也沒法統計了。

為什么埋點監控用會圖片的src,之前詳細寫過一篇文章,戳??這里??。

為了解決這些問題,大部分公司目前的解決方案是設置same-site:none并且配合secure,就可以像以往一樣,繼續攜帶第三方cookie。

但這不是版本答案。

SameParty

上面說到,為了繞開瀏覽器對三方cookie的限制,保障業務的正常,我們的解決方式是把same-site又設置回none。

但這不是長久之策,一來,瀏覽器把same-site的默認值從從none調整到lax可以避免CSRF攻擊,保障安全,可我們為了業務正常運行,卻又走了回頭路;二來,chrome承諾2022年,也就是今年,會全面禁用三方cookie,屆時和在safari一樣,我們沒法再用這種方法去hack。

如果我們不想使用same-site:none,或者說,未來用不了這種方式了,same-party將是我們的唯一選擇。

什么是 SameParty

繼續沿用阿里系的例子,same-party可以把.taobao.com、.tmall.com和.alimama.com三個站合起來,它們設置的cookie在這個集合內部不會被當作第三方cookie對待。

首先需要定義First-Party集合:在.taobao.com、.tmall.com和.alimama.com三個站的服務器下都加一個配置文件,放在/.well-know/目錄下,命名為first-party-set。

其中一個是“組長”,暫定為.taobao.com,在它的的服務器下寫入。

// /.well-know/first-party-set
{
"owner": ".taobao.com",
"members": [".tmall.com", ".alimama.com"]
}

另外兩個是組員:

// /.well-know/first-party-set
{
"owner": ".taobao.com",
}

并且,在下發cookie時,需要注明same-party屬性:

Set-Cookie: id=nian; SameParty; Secure; SameSite=Lax; domain=.taobao.com

這樣,我們打開.tmall.com的網站,向.taobao.com發起AJAX請求,都會帶上這個cookie,即使當前的same-site屬性是lax,因為這集合中的三個域名都會被當作一個站對待,也就是說,在瀏覽器眼中,這個cookie現在就是第一方cookie。

而不在集合中的baidu.com發起的AJAX請求則不會帶上。

需要注意的是,使用same-party屬性時,必須要同時使用https(secure屬性),并且same-site不能是strict。

結語

對三方cookie的限制一是為了瀏覽器安全,但在國外推動的更重要原因是個人的隱私安全。但不論是出于什么目的,這種改變都會對當前的業務架構造成很大的影響。

same-site:lax變成默認是一個暫時的預警,它限制了特定場景下的第三方cookie使用。目前處于比較柔和的過渡期,因為在大部分瀏覽器中,我們可以簡單地將它調整回same-site:none來解除這些限制,和以前一樣暢通無阻。

但未來這項限制終將無法脫下,same-party才是版本答案,有了它,我們可以靈活定義哪些站屬于業務意義上的“第一方”,哪些才是我們想要的“第三方”。

責任編輯:姜華 來源: 前端私教年年
相關推薦

2021-09-26 09:56:24

CookieSameParty前端

2022-03-22 14:52:05

Cookie瀏覽器

2021-12-13 11:54:13

SetEs6接口

2019-10-23 09:02:49

BIONIO單線程

2018-04-28 19:01:54

JavaScript數組Promise

2024-04-29 13:50:00

2021-06-15 07:32:59

Cookie和Sess實現跨域

2018-02-24 10:41:09

邊緣計算云計算

2022-03-02 07:43:32

JWTJWEJWA

2021-03-01 11:55:36

硬盤SSDHHD

2020-01-10 08:01:00

TCP四次揮手三次握手

2020-01-10 09:51:23

TCP惡意攻擊

2022-09-15 12:41:43

微服務后端前端

2009-07-06 16:05:50

JSP特點

2020-01-08 11:24:01

TCP三次握手協議

2021-12-09 07:22:52

索引下推前綴

2020-11-06 17:34:30

Python開發工具

2021-07-12 07:01:39

AST前端abstract sy

2024-01-15 06:42:00

高并發熱點賬戶數據庫

2019-07-11 08:54:24

Redis安全策略
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 久久69精品久久久久久久电影好 | 成人精品一区二区 | 91视频正在播放 | 中文字幕视频一区二区 | 男女视频在线免费观看 | 国产精品久久久久aaaa | 欧美成人二区 | 天天天天天天天干 | 亚洲综合电影 | 国产69精品久久久久777 | 在线视频一区二区 | 欧美精品在线一区 | 操亚洲 | 日本成人区 | 中文在线视频观看 | 国产精品成人一区二区三区 | 国产精品一区二区三区久久久 | 一区二区精品电影 | 欧美在线a | 免费亚洲婷婷 | 一级黄色淫片 | 黄在线 | 久久精品这里精品 | 成在线人视频免费视频 | 久久国产精品99久久久久久丝袜 | h网站在线观看 | 一区二区三区在线 | 乳色吐息在线观看 | 亚洲一区综合 | 亚洲精品1区2区3区 91免费看片 | 久久久久亚洲 | 99精品电影 | 天天操网 | 亚洲一区二区视频 | 欧美xxxx色视频在线观看免费 | 国产片侵犯亲女视频播放 | 91在线区| 亚洲一区在线免费观看 | 99re在线视频 | 97精品国产一区二区三区 | 亚洲欧美中文日韩在线 |