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

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攻擊的危害這麼大，為什麼不能在前端禁止這種請求呢？各大浏覽器廠商似乎也注意到了這個問題，谷歌提出了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，如下：

請求類型	示例	Lax情況
連結	<a href="..."></a>	發送 Cookie
預加載	<link rel="prerender" href="..."/>
GET 表單	<form method="GET" action="...">
POST 表單	<form method="POST" action="...">	不發送
iframe	frameLabelStart--frameLabelEnd
AJAX	$.get("...")
Image	<img src="...">

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

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

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

總結

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