關于防CSRF你需要了解的另一種方法

willin 發布于2019-06-21 16:47 / 562人閱讀

摘要：本文給大家介紹另一種防的方法。第三方請求開始前我們先了解一下第三方請求，什么樣的請求被稱為第三方請求簡單來說就是在一個網頁上發起一個不同源的請求，那么我們可以稱為第三方請求。這一切都不需要做生命周期的管理，也不用擔心會丟失或被中途被篡改。

前言

網站通常會使用 cookie 來記錄用戶的登錄狀態，但并非安全，因為 cookie 被允許在第三方網站（也不僅限于第三方）發起的請求中攜帶，因此利用這一點可以達到 CSRF 攻擊。本文不再對 CSRF 的原理作過多闡述，點擊這里了解CSRF 。
如果別人問起防 CSRF 的方法有哪些，大家通常會說出：Token + Referer，該方案在業界已經非常成熟。當一個問題有了解決辦法后，就很人有人會去了解別的方案，我想聽聽不同的聲音。

有位社會人曾經說過：有趣的靈魂萬里挑一。

本文給大家介紹另一種防 CSRF 的方法。

第三方請求

開始前我們先了解一下第三方請求，什么樣的請求被稱為第三方請求？簡單來說就是在一個網頁上發起一個不同源的請求，那么我們可以稱為第三方請求。

在一個頁面上發起一個第三方請求可以分為有異步請求和同步請求：
1、異步請求 指的是在當前頁面上通過 script、 link、img、fetch、XHR 等方法發起的請求，這些都不會讓頁面發生變化，也不會打開新的頁面。
2、同步請求 指的是在當前頁面點擊標簽，或

提交、 JS 調起的 location.href、window.open() 等方式發起的請求，這些方式可能會使當前頁面刷新或者打開新的頁面。

第三方cookie

通過 a.com 的頁面發起 a.com 的請求，會帶上第一方 cookie (first-party cookie)。
通過 a.com 的頁面發起 b.com 或 c.com 的請求，會自動帶上第三方 cookie (third-party cookie)
CSRF 就是利用第三方請求會帶上第三方 cookie 的弱點來達到在一個不信任的域下也可以達到的危險操作。

關于SameSite

正如文章開頭所說的防 CSRF 可以直接上方案 Token + Referer，但是人家 Google 就是要改變世界，怎么說？ Google 提了一份草案，給 cookie 新增 SameSite 屬性，通過這個屬性可以標記哪個 cookie 只作為同站 cookie （即第一方 cookie，不能作為第三方 cookie），既然不能作為第三方 cookie ，那么別的網站發起第三方請求時，第三方網站是收不到這個被標記關鍵 cookie，后面的鑒權處理就好辦了。這一切都不需要做 token 生命周期的管理，也不用擔心 Referer 會丟失或被中途被篡改。

SameSite 的應用

SameStie 有兩個值：Strict 和 Lax:

SameSite=Strict

嚴格模式，使用 SameSite=Strict 去標記的 cookie 在任何情況下（包括異步請求和同步請求）都不能作為第三方 cookie。

SameSite=Lax

寬松模式，使用 SameSite=Lax 去標記的 cookie 在異步請求和 form 提交跳轉的情況下都不能作為第三方 cookie。

現在給 b.com 的 cookie bbb1 設置一波看看效果。

document.cookie="bbb1=1; SameSite=Strict";
document.cookie="bbb2=2; SameSite=Lax";
document.cookie="bbb3=3;";

注：為了代碼簡潔，這里就不再設置 domain，path，expires 什么的了。

設置完畢后，馬上打開 Chrome 調試面板看看 cookie：

我們可以看到這里 cookie bbb1 的 SameSite 一列被設置了 Strict，bbb2 被設置了 Lax ，說明設置成功了。
在 a.com 頁面中試著異步請求 b.com

// a.html

打開宇宙最強抓包工具 whistle 抓包看看 bbb1 和 bbb2 有沒有被帶到 b.com

我們可以看到 bbb1 和 bbb2 沒有被帶到 b.com ，只看到了 bbb3，很完美。

再看看同步請求：
這里在 a.com 頁面上寫了一個標簽。

// a.html
 open b.com

通過抓包結果我們可以看到 bbb2 被設置了 SameSite=Lax 后，在同步請求的方式下，是可以把 cookie bbb2 帶到 b.com 的，而 bbb1 依然沒有被帶上。

Strict or Lax ?

那么問題來了，兩種模式我們應該分別在什么場景下使用呢？

登錄態關鍵的 cookie 都可以設置為 Strict。

后臺根據用戶的登錄態動態新建一個可以用于校驗登錄態的 cookie ，設置為 Lax ，這樣的話對外推廣比如微博什么的，你希望用戶在微博上打開你的鏈接還能保持登錄態。

如果你的頁面有可能被第三方網站去 iframe 或有接口需要做 jsonp ，那么都不能設置 Strict 或 Lax。

GPU云服務器云服務器說說你所了解的人工智能外呼系統阿里云服務器你了解了嗎人工智能一種現代方法人工智能一種現代的方法

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/11399.html

電商安全無小事，如何有效地抵御 CSRF 攻擊？

摘要：與攻擊相比，攻擊往往很少見，因此對其進行防范的資源也相當稀少。不過，這種受信任的攻擊模式更加難以防范，所以被認為比更具危險性。通過實時升級系統快速同步最新漏洞，避免零日攻擊。現在，我們絕大多數人都會在網上購物買東西。但是很多人都不清楚的是，很多電商網站會存在安全漏洞。比如烏云就通報過，國內很多家公司的網站都存在 CSRF 漏洞。如果某個網站存在這種安全漏洞的話，那么我們在購物的過程中...

趙連江 2019-06-21 16:26 評論0 收藏0
提高NodeJS網站的安全性：Web服務器防黑客攻擊技巧

摘要：盡管這樣，我們還沒有形成很多的安全準則。在這篇文章中，我會分享一些關于提高安全性方面的技巧。注跨站腳本攻擊發生這種情況時，攻擊者注入可執行代碼的響應。這樣可能會被跨站點腳本攻擊。毫無疑問，Node.js現在是越來越成熟。盡管這樣，我們還沒有形成很多的安全準則。在這篇文章中，我會分享一些關于提高Node.js安全性方面的技巧。不用eval，贏得朋友你不僅僅要避免使用eval ...

waterc 2019-06-21 16:25 評論0 收藏0
總結 XSS 與 CSRF 兩種跨站攻擊

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

jcc 2019-08-19 17:53 評論0 收藏0
干貨分享｜安全測試起航之旅

摘要：眾所周知軟件測試分為四大類型，分別是功能測試自動化測試安全測試和性能測試，而安全測試是在功能測試和自動化測試之后，性能測試之前執行的，以免安全測試后修改的一些問題會影響性能。云智慧汪曉宇安全測試是在IT軟件產品的生命周期中，特別是產品開發基本完成到發布階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程。一句話總結，安全測試就是檢查產品是否滿足安全需求的過程。眾所...

Riddler 2019-05-29 16:58 評論0 收藏0