詳解WEB攻擊之CSRF攻擊與防護(hù)

更新時間：2019年03月08日 14:39:01 作者：yjclsx

這篇文章主要介紹了詳解WEB攻擊之CSRF攻擊與防護(hù)，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧

CSRF 背景與介紹

CSRF定義：跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通?？s寫為 CSRF 或者 XSRF，是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。

簡單地說，是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認(rèn)證過的網(wǎng)站并執(zhí)行一些操作（如發(fā)郵件，發(fā)消息，甚至財產(chǎn)操作如轉(zhuǎn)賬和購買商品）。由于瀏覽器曾經(jīng)認(rèn)證過，所以被訪問的網(wǎng)站會認(rèn)為是真正的用戶操作而去執(zhí)行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發(fā)自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發(fā)出的。

CSRF地位：是一種網(wǎng)絡(luò)攻擊方式，是互聯(lián)網(wǎng)重大安全隱患之一，NYTimes.com（紐約時報）、Metafilter，YouTube、Gmail和百度HI都受到過此類攻擊。

對比XSS：跟跨網(wǎng)站腳本（XSS）相比，XSS 利用的是用戶對指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任。

CSRF 攻擊實例

daguanren（大官人）在銀行有一筆存款，輸入用戶名密碼登錄銀行網(wǎng)銀后發(fā)送請求進(jìn)行個人名下賬戶轉(zhuǎn)賬：

http://www.bank.example/withdraw?account=daguanren1&amount=999&for=daguanren2

將daguanren1中的999塊轉(zhuǎn)到了daguanren2賬號中。通常用戶登錄后，系統(tǒng)會保存用戶登錄的session值（可能是用戶手機(jī)號、賬號等）。但如果這時daguanren不小心新開一個tab頁面進(jìn)入了一個黑客jinlian（金蓮）的網(wǎng)站，而金蓮網(wǎng)站的頁面中嵌有如下html標(biāo)簽：

<!DOCTYPE html>
<html>
  <!--其他頁面元素-->

  <img src=http://www.bank.example/withdraw?account=daguanren1&amount=888&for=jinlian width='0' height='0'>

  <!--其他頁面元素-->
</html>

這個請求就會附帶上daguanren的session值，成功將大官人的888元轉(zhuǎn)至jinlian的賬戶上。但如果daguanren之前沒有登錄網(wǎng)銀，而是直接打開jinlian的網(wǎng)站，則由于沒有session值，不會被攻擊。以上示例雖然是get請求，post請求提交的表單同樣會被攻擊。

<iframe style="display:none" name="csrf-frame"></iframe>
<form method='POST' action='http://www.bank.example/withdraw' target="csrf-frame" id="csrf-form">
 <input type='hidden' name='account' value='daguanren1'>
 <input type='hidden' name='amount' value='888'>
 <input type='hidden' name='for' value='jinlian'>
 <input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>

所以要被CSRF攻擊，必須同時滿足兩個條件：
1.登錄受信任網(wǎng)站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問危險網(wǎng)站B。

CSRF 攻擊的對象

在討論如何抵御 CSRF 之前，先要明確 CSRF 攻擊的對象，也就是要保護(hù)的對象。從以上的例子可知，CSRF 攻擊是黑客借助受害者的 cookie（session）騙取服務(wù)器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的內(nèi)容。另外，對于服務(wù)器返回的結(jié)果，由于瀏覽器同源策略的限制，黑客也無法進(jìn)行解析。因此，黑客無法從返回的結(jié)果中得到任何東西，他所能做的就是給服務(wù)器發(fā)送請求，以執(zhí)行請求中所描述的命令，在服務(wù)器端直接改變數(shù)據(jù)的值，而非竊取服務(wù)器中的數(shù)據(jù)。所以，我們要保護(hù)的對象是那些可以直接產(chǎn)生數(shù)據(jù)改變的服務(wù)，而對于讀取數(shù)據(jù)的服務(wù)，則不需要進(jìn)行 CSRF 的保護(hù)。比如銀行系統(tǒng)中轉(zhuǎn)賬的請求會直接改變賬戶的金額，會遭到 CSRF 攻擊，需要保護(hù)。而查詢余額是對金額的讀取操作，不會改變數(shù)據(jù)，CSRF 攻擊無法解析服務(wù)器返回的結(jié)果，無需保護(hù)。

故：增刪改需要防范CSRF攻擊，而讀無需防范。

當(dāng)前防御 CSRF 的幾種策略

在業(yè)界目前防御 CSRF 攻擊主要有四種策略：
- 驗證 HTTP Referer 字段；
- 在請求地址中添加 token 并驗證；
- 在 HTTP 頭中自定義屬性并驗證；
- Chrome瀏覽器端啟用SameSite cookie

1、驗證 HTTP Referer 字段

什么是HTTP Referer？下面GIF圖是由百度跳轉(zhuǎn)到QQ郵箱頁面的Referer查看示意：

可以看出Referer為

Referer：https://www.baidu.com/

根據(jù) HTTP 協(xié)議，在 HTTP 頭（request 的 header）中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。如果黑客要對銀行網(wǎng)站實施 CSRF 攻擊，當(dāng)用戶通過黑客的網(wǎng)站發(fā)送請求到銀行時，該請求的 Referer 值是指向黑客的網(wǎng)站而不是用戶的網(wǎng)站。因此，要防御 CSRF 攻擊，銀行網(wǎng)站只需要對于每一個轉(zhuǎn)賬請求驗證其 Referer 值，如果是以 www.bank.example開頭的域名，則說明該請求是來自銀行網(wǎng)站自己的請求，是合法的。如果 Referer 是其他網(wǎng)站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。

這種方法的顯而易見的好處就是簡單易行，網(wǎng)站的普通開發(fā)人員不需要操心 CSRF 的漏洞，只需要在最后給所有安全敏感的請求統(tǒng)一增加一個攔截器來檢查 Referer 的值就可以。特別是對于當(dāng)前現(xiàn)有的系統(tǒng)，不需要改變當(dāng)前系統(tǒng)的任何已有代碼和邏輯。

然而，這種方法并非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協(xié)議上有明確的要求，但是每個瀏覽器對于 Referer 的具體實現(xiàn)可能有差別，并不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴于第三方（即瀏覽器）來保障，從理論上來講，這樣并不安全。事實上，對于某些瀏覽器，比如 IE6 或 FF2，目前已經(jīng)有一些方法可以篡改 Referer 值。如果 www.bank.example網(wǎng)站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設(shè)為以 www.bank.example域名開頭的地址，這樣就可以通過驗證，從而進(jìn)行 CSRF 攻擊。

即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。因為 Referer 值會記錄下用戶的訪問來源，有些用戶認(rèn)為這樣會侵犯到他們自己的隱私權(quán)，特別是有些組織擔(dān)心 Referer 值會把組織內(nèi)網(wǎng)中的某些信息泄露到外網(wǎng)中。因此，用戶自己可以設(shè)置瀏覽器使其在發(fā)送請求時不再提供 Referer。當(dāng)他們正常訪問銀行網(wǎng)站時，網(wǎng)站會因為請求沒有 Referer 值而認(rèn)為是 CSRF 攻擊，拒絕合法用戶的訪問。

另外，如果Referer的判斷邏輯寫的不嚴(yán)密的話，也容易被攻破，例如

const referer = request.headers.referer;
if (referer.indexOf('www.bank.example') > -1) {
 // pass
}

如果黑客的網(wǎng)站是www.bank.example.hack.com，則referer檢查無效。

2、在請求地址中添加 token 并驗證

CSRF 攻擊之所以能夠成功，是因為黑客可以完全偽造用戶的請求，該請求中所有的用戶驗證信息都是存在于 cookie 中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶的 cookie 來通過安全驗證。要抵御 CSRF，關(guān)鍵在于在請求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。可以在 HTTP 請求中以參數(shù)的形式加入一個隨機(jī)產(chǎn)生的 token，并在服務(wù)器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內(nèi)容不正確，則認(rèn)為可能是 CSRF 攻擊而拒絕該請求。

這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸后產(chǎn)生并放于 session 之中，然后在每次請求時把 token 從 session 中拿出，與請求中的 token 進(jìn)行比對，但這種方法的難點在于如何把 token 以參數(shù)的形式加入請求。對于 GET 請求，token 將附在請求地址之后，這樣 URL 就變成

http://url?csrftoken=tokenvalue

而對于 POST 請求來說，要在 form 的最后加上

 <input type="hidden" name="csrftoken" value="tokenvalue"/>

該方法有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支持用戶自己發(fā)表內(nèi)容的網(wǎng)站，黑客可以在上面發(fā)布自己個人網(wǎng)站的地址。由于系統(tǒng)也會在這個地址后面加上 token，黑客可以在自己的網(wǎng)站上得到這個 token，并馬上就可以發(fā)動 CSRF 攻擊。為了避免這一點，系統(tǒng)可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在后面添加 token，如果是通向外網(wǎng)則不加。不過，即使這個 csrftoken 不以參數(shù)的形式附加在請求之中，黑客的網(wǎng)站也同樣可以通過 Referer 來得到這個 token 值以發(fā)動 CSRF 攻擊。這也是一些用戶喜歡手動關(guān)閉瀏覽器 Referer 功能的原因。

3、在 HTTP 頭中自定義屬性并驗證

這種方法也是使用 token 并進(jìn)行驗證，和上一種方法不同的是，這里并不是把 token 以參數(shù)的形式置于 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔(dān)心 token 會透過 Referer 泄露到其他網(wǎng)站中去。

然而這種方法的局限性非常大。XMLHttpRequest 請求通常用于 Ajax 方法中對于頁面局部的異步刷新，并非所有的請求都適合用這個類來發(fā)起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進(jìn)行前進(jìn)，后退，刷新，收藏等操作，給用戶帶來不便。另外，對于沒有進(jìn)行 CSRF 防護(hù)的遺留系統(tǒng)來說，要采用這種方法來進(jìn)行防護(hù)，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網(wǎng)站，這代價無疑是不能接受的。

4、Chrome瀏覽器端啟用SameSite cookie

下面介紹如何啟用SameSite cookie的設(shè)置，很簡單。

原本的 Cookie 的 header 設(shè)置是長這樣：

Set-Cookie: session_id=esadfas325

需要在尾部增加 SameSite 就好：

Set-Cookie: session_id=esdfas32e5; SameSite

SameSite 有兩種模式，Lax跟Strict模式，默認(rèn)啟用Strict模式，可以自己指定模式：

Set-Cookie: session_id=esdfas32e5; SameSite=StrictSet-Cookie: foo=bar; SameSite=Lax

Strict模式規(guī)定 cookie 只允許相同的site使用，不應(yīng)該在任何的 cross site request 被加上去。即a標(biāo)簽、form表單和XMLHttpRequest提交的內(nèi)容，只要是提交到不同的site去，就不會帶上cookie。

但也存在不便，例如朋友發(fā)送過來我已經(jīng)登陸過的一個頁面鏈接，我點開后，該頁面仍然需要重新登錄。

有兩種處理辦法，第一種是與Amazon一樣，準(zhǔn)備兩組不同的cookie，第一組用于維持登錄狀態(tài)不設(shè)定SameSite，第二組針對的是一些敏感操作會用到（例如購買、支付、設(shè)定賬戶等）嚴(yán)格設(shè)定SameSite。

基于這個思路，就產(chǎn)生了 SameSite 的另一一種模式：Lax模式。

Lax 模式打開了一些限制，例如

<a>
<link rel="prerender">
<form method="GET">

這些都會帶上cookie。但是 POST 方法的 form，或是只要是 POST, PUT, DELETE 這些方法，就不會帶cookie。
但一定注意將重要的請求方式改成POST，否則GET仍然會被攻擊。
PS：該方式目前僅Chrome支持。

后記

方式1通過驗證HTTP Referer頭信息來防止跨站請求偽造csrf，在java中可以通過filter來實現(xiàn)。方式2和方式3都是通過在請求中添加token來進(jìn)行安全校驗的，spring security 提供的csrf防護(hù)就是采用這樣的方式，而且從spring security 4.0開始csrf防護(hù)是默認(rèn)開啟的。對于一個新項目，可以幾種方式都用上，這樣更加安全。如果是一個已經(jīng)完備的web程序，還是使用方式1修改起來方便，不然每個請求都加上csrfToken改動很大。關(guān)于spring security csrf可參考我的博文：http://dhdzp.com/article/157547.htm

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家

您可能感興趣的文章: