CSRF的原理與防禦 | 你想不想來一次CSRF攻擊？

• 2019 年 12 月 10 日
• 筆記

CSRF是Cross Site Request Forgery的縮寫，中文翻譯過來是跨站請求偽造。這個漏洞往往能給用戶帶來巨大的損失，CSRF在等保安全檢測中，也是一個非常重要的檢測項。但是在我們的網站中，大部分都沒有做CSRF的防禦，小夥伴們想不想來一次CSRF攻擊，體驗一下做黑客感覺？如果想要做黑客，可要仔細的往下看喲~

CSRF攻擊的原理

要想理解CSRF攻擊的原理，我們從一個經典的案例出發，看看它是如何進行攻擊的。假設你的銀行網站的域名是www.a-bank.com，這個銀行網站提供了一個轉賬的功能，在這個功能頁面中，有一個表單，表單中有兩個輸入框，一個是轉賬金額，另一個是對方帳號，還有一個提交按鈕。當你登錄了你的銀行網站，輸入轉賬金額，對方帳號，點擊提交按鈕，就會進行轉賬。

當然，現在的銀行網站不會有這麼簡單的轉賬操作了，我們在這裡只是舉一個簡單的例子，讓大家明白CSRF的原理。咱們可以發散思維，聯想到其他類似的操作。

這個轉賬的表單項，如下所示：

<form method="post" action="/transfer">      <input type="text" name="amount"/>      <input type="text" name="account"/>      <input type="submit" value="Transfer"/>  </form>

當我們輸入金額和帳號，點擊提交按鈕，表單就會提交，給後端的銀行網站服務發送請求。請求的內容如下：

POST /transfer HTTP/1.1  Host: www.a-bank.com  Cookie: JSESSIONID=randomid  Content-Type: application/x-www-form-urlencoded    amount=100.00&account=9876

請求成功後，你輸入的轉賬金額100元，將轉賬到9876這個賬戶當中。假如你完成轉賬操作後，並沒有退出登錄，而是訪問了一個惡意網站，這時，你的銀行網站www.a-bank.com還是處於登錄狀態，而這個惡意網站中，出現了一個帶有」贏錢「字樣的按鈕，這個」贏錢「字樣的按鈕後面是一個form表單，表單如下：

<form method="post" action="https://www.a-bank.com/transfer">      <input type="hidden" name="amount" value="100.00"/>      <input type="hidden" name="account" value="黑客的銀行賬戶"/>      <input type="submit" value="贏錢!"/>  </form>

我們可以看到這個表單中，金額和賬戶都是隱藏的，在網頁上只看到了一個贏錢按鈕。這時，你忍不住衝動，點了一個」贏錢「按鈕，這時，將會發生什麼操作呢？我們仔細看一下上面表單中的action寫的是什麼？action寫的是你的銀行網站的轉賬請求介面。你點了一下贏錢按鈕，在這個不正規的網站中，將會發送https://www.a-bank.com/transfer這個請求，在發送這個請求的時候，會自動帶上www.a-bank.com的cookie，不要問我為什麼是這樣，這是瀏覽器的標準，標準就是這樣規定的。銀行後台接到這個請求後，首先要判斷用戶是否登錄，由於攜帶了cookie，是登錄的，會繼續執行後面的轉賬流程，最後轉賬成功。你點了一下」贏錢「按鈕，自己沒有賺到錢，而是給黑客轉賬了100元。

這就是CSRF攻擊的原理，在其他的網站向你的網站發送請求，如果你的網站中的用戶沒有退出登錄，而發送的請求又是一些敏感的操作請求，比如：轉賬，那麼將會給你的網站的用戶帶來巨大的損失。

CSRF的防禦

我們知道了CSRF攻擊的原理，就可以做針對性的防禦了。CSRF的防禦可以從兩個方面考慮，一個是後台介面層做防禦；另一個則是在前端做防禦，這種不同源的請求，不可以帶cookie。

後端防禦CSRF

我們先聊聊後端的防禦，後端防禦主要是區分哪些請求是惡意請求，哪些請求是自己網站的請求。區分惡意請求的方式有很多，在這裡給大家介紹兩種吧。

第一種，CSRF Token的方式。這種方式是在表單頁面生成一個隨機數，這個隨機數一定要後端生成，並且對這個隨機數進行存儲。在前端頁面中，對這個Token表單項進行隱藏。程式碼如下：

<form method="post" action="/transfer">      <input type="hidden" name="_csrf" value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>      <input type="text" name="amount"/>      <input type="hidden" name="account"/>      <input type="submit" value="Transfer"/>  </form>

_csrf就是CSRF Token。我們看到他的value是一個UUID，這個UUID是後台生成的。當用戶點擊轉賬按鈕時，會給銀行的後台發送請求，請求中包含_csrf參數，如下：

POST /transfer HTTP/1.1  Host: www.a-bank.com  Cookie: JSESSIONID=randomid  Content-Type: application/x-www-form-urlencoded    amount=100.00&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

銀行後台接收到這個請求後，判斷_csrf的值是否存在，如果存在則是自己網站的請求，進行後續的流程；如果不存在，則是惡意網站的請求，直接忽略。

第二種，通過請求頭中的referer欄位判斷請求的來源。每一個發送給後端的請求，在請求頭中都會包含一個referer欄位，這個欄位標識著請求的來源。如果請求是從銀行網站發出的，這個欄位會是銀行網站轉賬頁的鏈接，比如：https://www.a-bank.com/transfer-view；如果是從惡意網站發出的，那麼referer欄位一定不會是銀行網站。我們在做後端防禦時，可以先取出每個請求的請求頭中的referer欄位，判斷是不是以自己網站的域名開頭，在咱們的示例中，如果referer欄位是以https://www.a-bank.com/開頭的，則繼續執行轉賬操作；如果不是，則直接忽略掉這個請求。

以上就是後端防禦CSRF攻擊的兩種方式，都需要在後端做特殊的處理。當然也可以在前端做處理，怎麼做呢？我們接著往下看。

前端防禦CSRF

既然CSRF攻擊的危害這麼大，為什麼不能在前端禁止這種請求呢？各大瀏覽器廠商似乎也注意到了這個問題，Google提出了same-site cookies概念，same-site cookies 是基於 Chrome 和 Mozilla 開發者花了三年多時間制定的 IETF 標準。它是在原有的Cookie中，新添加了一個SameSite屬性，它標識著在非同源的請求中，是否可以帶上Cookie，它可以設置為3個值，分別為：

• Strict
• Lax
• None

Cookie中的內容為：

POST /transfer HTTP/1.1  Host: www.a-bank.com  Cookie: JSESSIONID=randomid;SameSite=Strict;

Strict是最嚴格的，它完全禁止在跨站情況下，發送Cookie。只有在自己的網站內部發送請求，才會帶上Cookie。不過這個規則過於嚴格，會影響用戶的體驗。比如在一個網站中有一個鏈接，這個鏈接連接到了GitHub上，由於SameSite設置為Strict，跳轉到GitHub後，GitHub總是未登錄狀態。

Lax的規則稍稍放寬了些，大部分跨站的請求也不會帶上Cookie，但是一些導航的Get請求會帶上Cookie，如下：

上面的表格就是SameSite設置為Lax的時候，Cookie的發送情況。

None就是關閉SameSite屬性，所有的情況下都發送Cookie。不過SameSite設置None，還要同時設置Cookie的Secure屬性，否則是不生效的。

以上就是在前端通過Cookie的SameSite屬性防禦CSRF攻擊，不過大家在使用SameSite屬性時，要注意瀏覽器是否支援SameSite屬性。

總結

到這裡CSRF的攻和防都已經介紹完了，大部分網站都是沒有做CSRF防禦的，小夥伴們有沒有想當黑客的癮，找幾個網站搞一下試試吧~~