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