資訊專(zhuān)欄INFORMATION COLUMN
摘要：本文給大家介紹另一種防的方法。第三方請(qǐng)求開(kāi)始前我們先了解一下第三方請(qǐng)求，什么樣的請(qǐng)求被稱(chēng)為第三方請(qǐng)求簡(jiǎn)單來(lái)說(shuō)就是在一個(gè)網(wǎng)頁(yè)上發(fā)起一個(gè)不同源的請(qǐng)求，那么我們可以稱(chēng)為第三方請(qǐng)求。這一切都不需要做生命周期的管理，也不用擔(dān)心會(huì)丟失或被中途被篡改。
前言
網(wǎng)站通常會(huì)使用 cookie 來(lái)記錄用戶(hù)的登錄狀態(tài)，但并非安全，因?yàn)?cookie 被允許在第三方網(wǎng)站（也不僅限于第三方）發(fā)起的請(qǐng)求中攜帶，因此利用這一點(diǎn)可以達(dá)到 CSRF 攻擊。本文不再對(duì) CSRF 的原理作過(guò)多闡述，點(diǎn)擊這里了解CSRF 。
如果別人問(wèn)起防 CSRF 的方法有哪些，大家通常會(huì)說(shuō)出：Token + Referer，該方案在業(yè)界已經(jīng)非常成熟。當(dāng)一個(gè)問(wèn)題有了解決辦法后，就很人有人會(huì)去了解別的方案，我想聽(tīng)聽(tīng)不同的聲音。
有位社會(huì)人曾經(jīng)說(shuō)過(guò)：有趣的靈魂萬(wàn)里挑一。
本文給大家介紹另一種防 CSRF 的方法。
第三方請(qǐng)求開(kāi)始前我們先了解一下第三方請(qǐng)求，什么樣的請(qǐng)求被稱(chēng)為第三方請(qǐng)求？簡(jiǎn)單來(lái)說(shuō)就是在一個(gè)網(wǎng)頁(yè)上發(fā)起一個(gè)不同源的請(qǐng)求，那么我們可以稱(chēng)為第三方請(qǐng)求。
在一個(gè)頁(yè)面上發(fā)起一個(gè)第三方請(qǐng)求可以分為有 異步請(qǐng)求 和 同步請(qǐng)求：
1、異步請(qǐng)求 指的是在當(dāng)前頁(yè)面上通過(guò) script、 link、img、fetch、XHR 等方法發(fā)起的請(qǐng)求，這些都不會(huì)讓頁(yè)面發(fā)生變化，也不會(huì)打開(kāi)新的頁(yè)面。
2、同步請(qǐng)求 指的是在當(dāng)前頁(yè)面點(diǎn)擊 標(biāo)簽，或 提交、 JS 調(diào)起的 location.href、window.open() 等方式發(fā)起的請(qǐng)求，這些方式可能會(huì)使當(dāng)前頁(yè)面刷新或者打開(kāi)新的頁(yè)面。
通過(guò) a.com 的頁(yè)面發(fā)起 a.com 的請(qǐng)求，會(huì)帶上第一方 cookie (first-party cookie)。
通過(guò) a.com 的頁(yè)面發(fā)起 b.com 或 c.com 的請(qǐng)求，會(huì)自動(dòng)帶上第三方 cookie (third-party cookie)
CSRF 就是利用第三方請(qǐng)求會(huì)帶上第三方 cookie 的弱點(diǎn)來(lái)達(dá)到在一個(gè)不信任的域下也可以達(dá)到的危險(xiǎn)操作。
正如文章開(kāi)頭所說(shuō)的防 CSRF 可以直接上方案 Token + Referer，但是人家 Google 就是要改變世界，怎么說(shuō)？ Google 提了一份草案 ，給 cookie 新增 SameSite 屬性，通過(guò)這個(gè)屬性可以標(biāo)記哪個(gè) cookie 只作為同站 cookie （即第一方 cookie，不能作為第三方 cookie），既然不能作為第三方 cookie ，那么別的網(wǎng)站發(fā)起第三方請(qǐng)求時(shí)，第三方網(wǎng)站是收不到這個(gè)被標(biāo)記關(guān)鍵 cookie，后面的鑒權(quán)處理就好辦了。這一切都不需要做 token 生命周期的管理，也不用擔(dān)心 Referer 會(huì)丟失或被中途被篡改。
SameSite 的應(yīng)用SameStie 有兩個(gè)值：Strict 和 Lax:
SameSite=Strict嚴(yán)格模式，使用 SameSite=Strict 去標(biāo)記的 cookie 在任何情況下（包括異步請(qǐng)求和同步請(qǐng)求） 都不能作為第三方 cookie。
SameSite=Lax寬松模式，使用 SameSite=Lax 去標(biāo)記的 cookie 在異步請(qǐng)求 和 form 提交跳轉(zhuǎn)的情況下 都不能作為第三方 cookie。
現(xiàn)在給 b.com 的 cookie bbb1 設(shè)置一波看看效果。
document.cookie="bbb1=1; SameSite=Strict"; document.cookie="bbb2=2; SameSite=Lax"; document.cookie="bbb3=3;";
注：為了代碼簡(jiǎn)潔，這里就不再設(shè)置 domain，path，expires 什么的了。
設(shè)置完畢后，馬上打開(kāi) Chrome 調(diào)試面板看看 cookie：
我們可以看到這里 cookie bbb1 的 SameSite 一列被設(shè)置了 Strict，bbb2 被設(shè)置了 Lax ，說(shuō)明設(shè)置成功了。
在 a.com 頁(yè)面中試著異步請(qǐng)求 b.com
// a.html
打開(kāi)宇宙最強(qiáng)抓包工具 whistle 抓包看看 bbb1 和 bbb2 有沒(méi)有被帶到 b.com
我們可以看到 bbb1 和 bbb2 沒(méi)有被帶到 b.com ，只看到了 bbb3，很完美。
再看看同步請(qǐng)求：
這里在 a.com 頁(yè)面上寫(xiě)了一個(gè) 標(biāo)簽。
// a.html open b.com
通過(guò)抓包結(jié)果我們可以看到 bbb2 被 設(shè)置了 SameSite=Lax 后，在同步請(qǐng)求的方式下，是可以把 cookie bbb2 帶到 b.com 的，而 bbb1 依然沒(méi)有被帶上。
Strict or Lax ?那么問(wèn)題來(lái)了，兩種模式我們應(yīng)該分別在什么場(chǎng)景下使用呢？
登錄態(tài)關(guān)鍵的 cookie 都可以設(shè)置為 Strict。
后臺(tái)根據(jù)用戶(hù)的登錄態(tài)動(dòng)態(tài)新建一個(gè)可以用于校驗(yàn)登錄態(tài)的 cookie ，設(shè)置為 Lax ，這樣的話(huà)對(duì)外推廣比如微博什么的，你希望用戶(hù)在微博上打開(kāi)你的鏈接還能保持登錄態(tài)。
如果你的頁(yè)面有可能被第三方網(wǎng)站去 iframe 或 有接口需要做 jsonp ，那么都不能設(shè)置 Strict 或 Lax。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/11399.html
摘要：與攻擊相比，攻擊往往很少見(jiàn)，因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少。不過(guò)，這種受信任的攻擊模式更加難以防范，所以被認(rèn)為比更具危險(xiǎn)性。通過(guò)實(shí)時(shí)升級(jí)系統(tǒng)快速同步最新漏洞，避免零日攻擊。 現(xiàn)在，我們絕大多數(shù)人都會(huì)在網(wǎng)上購(gòu)物買(mǎi)東西。但是很多人都不清楚的是，很多電商網(wǎng)站會(huì)存在安全漏洞。比如烏云就通報(bào)過(guò)，國(guó)內(nèi)很多家公司的網(wǎng)站都存在 CSRF 漏洞。如果某個(gè)網(wǎng)站存在這種安全漏洞的話(huà)，那么我們?cè)谫?gòu)物的過(guò)程中...
摘要：盡管這樣，我們還沒(méi)有形成很多的安全準(zhǔn)則。在這篇文章中，我會(huì)分享一些關(guān)于提高安全性方面的技巧。注跨站腳本攻擊發(fā)生這種情況時(shí)，攻擊者注入可執(zhí)行代碼的響應(yīng)。這樣可能會(huì)被跨站點(diǎn)腳本攻擊。 毫無(wú)疑問(wèn)，Node.js現(xiàn)在是越來(lái)越成熟。盡管這樣，我們還沒(méi)有形成很多的安全準(zhǔn)則。 在這篇文章中，我會(huì)分享一些關(guān)于提高Node.js安全性方面的技巧。 不用eval，贏得朋友 你不僅僅要避免使用eval ...
摘要：但最近又聽(tīng)說(shuō)了另一種跨站攻擊，于是找了些資料了解了一下，并與放在一起做個(gè)比較。腳本中的不速之客全稱(chēng)跨站腳本，是注入攻擊的一種。 XSS：跨站腳本（Cross-site scripting） CSRF：跨站請(qǐng)求偽造（Cross-site request forgery） 在那個(gè)年代，大家一般用拼接字符串的方式來(lái)構(gòu)造動(dòng)態(tài) SQL 語(yǔ)句創(chuàng)建應(yīng)用，于是 SQL 注入成了很流行的攻擊方式。...
摘要：眾所周知軟件測(cè)試分為四大類(lèi)型，分別是功能測(cè)試自動(dòng)化測(cè)試安全測(cè)試和性能測(cè)試，而安全測(cè)試是在功能測(cè)試和自動(dòng)化測(cè)試之后，性能測(cè)試之前執(zhí)行的，以免安全測(cè)試后修改的一些問(wèn)題會(huì)影響性能。 云智慧 汪曉宇 安全測(cè)試是在IT軟件產(chǎn)品的生命周期中，特別是產(chǎn)品開(kāi)發(fā)基本完成到發(fā)布階段，對(duì)產(chǎn)品進(jìn)行檢驗(yàn)以驗(yàn)證產(chǎn)品符合安全需求定義和產(chǎn)品質(zhì)量標(biāo)準(zhǔn)的過(guò)程。一句話(huà)總結(jié)，安全測(cè)試就是檢查產(chǎn)品是否滿(mǎn)足安全需求的過(guò)程。 眾所...
閱讀 2101·2021-11-24 09:39
閱讀 1052·2021-11-11 16:55
閱讀 1563·2021-10-09 09:43
閱讀 1539·2021-10-08 10:17
閱讀 1797·2021-08-25 09:41
閱讀 500·2019-08-30 13:02
閱讀 701·2019-08-29 15:14
閱讀 1092·2019-08-29 13:53
