成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

關(guān)于防CSRF你需要了解的另一種方法

willin / 567人閱讀

摘要:本文給大家介紹另一種防的方法。第三方請求開始前我們先了解一下第三方請求,什么樣的請求被稱為第三方請求簡單來說就是在一個(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)前頁面上通過 scriptlink、imgfetch、XHR 等方法發(fā)起的請求,這些都不會(huì)讓頁面發(fā)生變化,也不會(huì)打開新的頁面。
2、同步請求 指的是在當(dāng)前頁面點(diǎn)擊 標(biāo)簽,或

提交、 JS 調(diào)起的 location.href、window.open() 等方式發(fā)起的請求,這些方式可能會(huì)使當(dāng)前頁面刷新或者打開新的頁面。

第三方cookie

通過 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)操作。

關(guān)于SameSite

正如文章開頭所說的防 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

相關(guān)文章

  • 電商安全無小事,如何有效地抵御 CSRF 攻擊?

    摘要:與攻擊相比,攻擊往往很少見,因此對(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)站存在這種安全漏洞的話,那么我們在購物的過程中...

    趙連江 評(píng)論0 收藏0
  • 提高NodeJS網(wǎng)站的安全性:Web服務(wù)器黑客攻擊技巧

    摘要:盡管這樣,我們還沒有形成很多的安全準(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 ...

    waterc 評(píng)論0 收藏0
  • 總結(jié) XSS 與 CSRF 兩種跨站攻擊

    摘要:但最近又聽說了另一種跨站攻擊,于是找了些資料了解了一下,并與放在一起做個(gè)比較。腳本中的不速之客全稱跨站腳本,是注入攻擊的一種。 XSS:跨站腳本(Cross-site scripting) CSRF:跨站請求偽造(Cross-site request forgery) 在那個(gè)年代,大家一般用拼接字符串的方式來構(gòu)造動(dòng)態(tài) SQL 語句創(chuàng)建應(yīng)用,于是 SQL 注入成了很流行的攻擊方式。...

    jcc 評(píng)論0 收藏0
  • 干貨分享|安全測試起航之旅

    摘要:眾所周知軟件測試分為四大類型,分別是功能測試自動(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)品是否滿足安全需求的過程。 眾所...

    Riddler 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

閱讀需要支付1元查看
<