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

在安徽等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供做網(wǎng)站、成都網(wǎng)站制作 網(wǎng)站設(shè)計制作專業(yè)公司,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站制作,安徽網(wǎng)站建設(shè)費用合理。

一、Cookie SameSite屬性介紹

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

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

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

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

CSRF攻擊簡單而言就是惡意用戶通過巧妙偽造請求從而盜用合法用戶的身份進行惡意操作。

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

yourdomain.com/snap

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

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

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

malicioususer.com/fancypage

...<form action="yourdomain.com/snap">
    <input type="Submit" value="This is cool, click me"/></form>...

當然，微軟 ASP.NET是通過 AntiForgeryToken來解決這個問題，不過這個不是這篇blog討論的主題。

三、Cookie的SameSite屬性

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

Cookie所屬的域名如果和瀏覽器地址欄中的域名不一致，則認為是跨站點。另外，當你的站點被iframe嵌在第三方站點時也被認為是跨站點。

這個屬性有三個屬性值：

1. None

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

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

2. Strict

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

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

   但這個嚴格模式也限制了一些被認為是安全的鏈接操作，比如：

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

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

3. 你點擊這個link，但因為Cookie被設(shè)置為Strict模式，當?shù)竭_審批頁面時，HR系統(tǒng)沒有收到任何Cookie，這時會認為你沒有登錄，而直接跳轉(zhuǎn)到登錄頁面。在要求不是非常嚴格的情形下，可以認為這不是我們所期望的行為。因為只是跳到鏈接指向的頁面并不是像POST操作修改數(shù)據(jù)。這需要通過下面的Lax屬性解決這個問題。

3. Lax

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

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

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

四、瀏覽器兼容性

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

五、如何修改ASP.NET程序

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

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

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

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

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

本文標題：分析CookieSameSite屬性及其在ASP.NET項目中的應(yīng)用-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://www.chinadenli.net/article24/dhcpje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、ChatGPT、面包屑導(dǎo)航、網(wǎng)站策劃、網(wǎng)站收錄、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)