本篇內(nèi)容主要講解“分析Cookie SameSite屬性及其在ASP.NET項(xiàng)目中的應(yīng)用”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“分析Cookie SameSite屬性及其在ASP.NET項(xiàng)目中的應(yīng)用”吧!

10年積累的做網(wǎng)站、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有犍為免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

一、Cookie SameSite屬性介紹

就像大家已經(jīng)知道的，一旦設(shè)置Cookie之后，在Cookie失效之前瀏覽器會(huì)一直將這個(gè)Cookie在后續(xù)所有的請(qǐng)求中都傳回到Server端。我們的系統(tǒng)會(huì)利用Cookie這個(gè)特性做很多事情，但通常我們會(huì)在Cookie中存放加密的用戶身份，在Server端根據(jù)此身份檢驗(yàn)用戶是否有權(quán)限進(jìn)行相應(yīng)操作。

發(fā)送Cookie時(shí)，以往瀏覽器并不檢測(cè)當(dāng)前地址欄上的域(Domain)是不是和這個(gè)Cookie所屬的域是否相同。惡意用戶會(huì)利用這個(gè)問(wèn)題巧妙設(shè)計(jì)一個(gè)站點(diǎn)，誘導(dǎo)用戶點(diǎn)擊從而造成跨站點(diǎn)請(qǐng)求偽造攻擊(CSRF)。

為了解決這個(gè)問(wèn)題， 國(guó)際互聯(lián)網(wǎng)工程任務(wù)組（IETF)提出了一個(gè)SameSite的草稿標(biāo)準(zhǔn)，Chrome 51開始支持此功能，但從Chrome 80 Stable版本開始啟用一個(gè)較嚴(yán)格(Lax)的默認(rèn)設(shè)置。

二、什么是跨站點(diǎn)請(qǐng)求偽造攻擊(Cross-Site Request Forgery Attack，CSRF)

CSRF攻擊簡(jiǎn)單而言就是惡意用戶通過(guò)巧妙偽造請(qǐng)求從而盜用合法用戶的身份進(jìn)行惡意操作。

比如你開發(fā)了一個(gè)非常厲害的系統(tǒng)，系統(tǒng)中某些操作只有特定的人登錄之后才有權(quán)限使用：

yourdomain.com/snap

[Authorize("Thanos")]
[HttpPost]public ActionResult Snap(){    ///dangerous, will destroy the world.}

因?yàn)橄到y(tǒng)要檢驗(yàn)身份和權(quán)限，除非惡意用戶能破解登錄系統(tǒng)以Thanos身份登錄，否則是沒(méi)有辦法調(diào)用這個(gè)方法的。

但是惡意用戶可以偽造一個(gè)像下面這樣的頁(yè)面，惡意用戶通過(guò)發(fā)郵件或者通過(guò)跨站點(diǎn)腳本攻擊(XSS)等方式誘導(dǎo)具有權(quán)限的用戶點(diǎn)擊頁(yè)面上的某些Button。如果具有權(quán)限的用戶剛好已經(jīng)登錄，一旦點(diǎn)擊按鈕，系統(tǒng)則會(huì)以這個(gè)用戶的身份觸發(fā)上面危險(xiǎn)的操作Snap()。

malicioususer.com/fancypage

...
    ...

當(dāng)然，微軟 ASP.NET是通過(guò) AntiForgeryToken來(lái)解決這個(gè)問(wèn)題，不過(guò)這個(gè)不是這篇blog討論的主題。

三、Cookie的SameSite屬性

為了解決上面到的Cookie的安全問(wèn)題，Chrome從版本51增加了一個(gè)新的Cookie屬性SameSite, 以控制Cookie是否能在跨站點(diǎn)的情況下傳送。

Cookie所屬的域名如果和瀏覽器地址欄中的域名不一致，則認(rèn)為是跨站點(diǎn)。另外，當(dāng)你的站點(diǎn)被iframe嵌在第三方站點(diǎn)時(shí)也被認(rèn)為是跨站點(diǎn)。

這個(gè)屬性有三個(gè)屬性值：

1. None

   如果你需要在任意跨站點(diǎn)情況下都使用某個(gè)Cookie，則需要將這個(gè)Cookie的SameSite設(shè)置為None. 但這里需要注意的是一定要同時(shí)設(shè)置Cookie的Secure，也就是需要使用https訪問(wèn)時(shí)才能關(guān)閉SameSite功能. 如果沒(méi)有標(biāo)明為secure, Chrome 80及以上會(huì)拒絕設(shè)置這個(gè)Cookie。

   set-cookie: samesite=test; path=/; secure; SameSite=None

2. Strict

   顧名思義，這是嚴(yán)格模式，就是在任何情況下都不允許跨站點(diǎn)發(fā)送Cookie。

   這個(gè)設(shè)置顯然是可以解決上面所提到的CSRF問(wèn)題。因?yàn)楫?dāng)訪問(wèn) malicioususer.com/fancypage 頁(yè)面時(shí),當(dāng)前域是 malicioususer.com, 但user點(diǎn)擊button提交時(shí)的action是指向另外一個(gè)域 yourdomain.com，這是兩個(gè)不同的域，瀏覽器將不回傳yourdomain.com下面的Cookie。這會(huì)極大的提高我們系統(tǒng)的安全性。

   但這個(gè)嚴(yán)格模式也限制了一些被認(rèn)為是安全的鏈接操作，比如：

1. 你先登錄了公司HR系統(tǒng)，假設(shè)該系統(tǒng)將所有Cookie的SameSite都設(shè)置為strict.

2. 你用Web郵件系統(tǒng)收到了要求你到HR系統(tǒng)做審批操作的郵件，這封郵件帶了一個(gè)link，直接鏈接到HR系統(tǒng)中審批的頁(yè)面；

3. 你點(diǎn)擊這個(gè)link，但因?yàn)镃ookie被設(shè)置為Strict模式，當(dāng)?shù)竭_(dá)審批頁(yè)面時(shí)，HR系統(tǒng)沒(méi)有收到任何Cookie，這時(shí)會(huì)認(rèn)為你沒(méi)有登錄，而直接跳轉(zhuǎn)到登錄頁(yè)面。在要求不是非常嚴(yán)格的情形下，可以認(rèn)為這不是我們所期望的行為。因?yàn)橹皇翘芥溄又赶虻捻?yè)面并不是像POST操作修改數(shù)據(jù)。這需要通過(guò)下面的Lax屬性解決這個(gè)問(wèn)題。

3. Lax

   Lax是比Strict稍寬松的模式，如果我們要允許跨站點(diǎn)鏈接傳Cookie或FORM用GET Method提交時(shí)跨站點(diǎn)傳Cookie， 則可以將這些Cookie的SameSite設(shè)置為L(zhǎng)ax. Lax在Chrome 80成為默認(rèn)設(shè)置，Lax既防止了CSRF也確保了正常的跨站點(diǎn)鏈接，是適合大多數(shù)站點(diǎn)的，可以解決上面HR系統(tǒng)安全中提到問(wèn)題。

   如果你的站點(diǎn)需要被iframe嵌套在第三方站點(diǎn)，這時(shí)你還是需要將Cookie設(shè)置為None。

   這里也想到一點(diǎn)是，如果你的MVC Action只期望接受POST方法，那么一定要加上HttpPost Attribute,以避免造成意外的安全問(wèn)題。

四、瀏覽器兼容性

如下圖示目前主流瀏覽器都已經(jīng)支持SameSite，雖然 IE 11不支持，但我測(cè)試之后發(fā)現(xiàn)這個(gè)Cookie本身還是沒(méi)有丟失，只是缺失了安全保護(hù)功能。

五、如何修改ASP.NET程序

下面總結(jié)的步驟是適用于基于ASP.NET開發(fā)的系統(tǒng)。微軟官方白皮書對(duì)這些屬性設(shè)置做了詳細(xì)的說(shuō)明，也可以參考 官方白皮書。

1. .NET Framework 4.7.2 或4.8才開始支持SameSite, 在HttpCookie增加了SameSite的屬性。所以需要安裝.NET Framework 4.7.2以上SDK, 并且需要安裝開發(fā)電腦和服務(wù)器上。

2. 安裝 Windows 2019/11/19累積更新補(bǔ)丁，請(qǐng)見 KB Articles that support SameSite in .NET Framework,也需要安裝在開發(fā)電腦和服務(wù)器上。沒(méi)有安裝這個(gè)補(bǔ)丁之前，如果SameSite為None, .NET Framework并不輸出這個(gè)屬性到Broswer, 但Chrome 80及以后將未設(shè)置默認(rèn)為L(zhǎng)ax，因此造成不一致的行為，所以需要安裝這個(gè)補(bǔ)丁以明確輸出None。

3. 在Chrome地址欄輸入: chrome://flags/, 將下面兩項(xiàng)設(shè)置為Enabled。開啟這兩項(xiàng)設(shè)置是因?yàn)椴皇撬械腃hrome都默認(rèn)啟用了這兩項(xiàng)設(shè)置，Chrome只是在逐漸將這兩項(xiàng)開啟到Chrome的user. 所以開發(fā)時(shí)為了重現(xiàn)問(wèn)題，最好是顯式開啟。
   chrome://flags/#same-site-by-default-cookies
   chrome://flags/#cookies-without-same-site-must-be-secure

到此，相信大家對(duì)“分析Cookie SameSite屬性及其在ASP.NET項(xiàng)目中的應(yīng)用”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！