朱廣蔚 ·CSRF 攻擊和防御原理
CSRF 是跨站點請求偽造 (Cross—Site Request Forgery)，存在巨大的危害性，本節講解 CSRF 攻擊和防御的原理。
1. 什么是 CSRF 攻擊
CSRF 是英文 Cross Site Request Forgery 的縮寫，中文翻譯為 “跨站請求偽造”，它是一種挾制用戶在當前已登錄的 Web 應用程序上執行非本意的操作的攻擊方法。
用戶使用瀏覽器登錄網站，通過身份驗證后，來自該瀏覽器的請求會得到授權：在服務端可以執行新增數據、修改數據、刪除數據等操作。但是，這樣的身份驗證機制存在一個漏洞：只能保證請求發自某個登錄用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。
攻擊者利用身份驗證漏洞可以挾制用戶在當前已登錄的 Web 應用程序上執行非本意的操作。
2. CSRF 攻擊的過程
2.1 案例簡介
本小節通過一個具體的例子，講解 CSRF 工具的步驟。案例的假設如下：
- 存在一個銀行網站，提供在線轉賬功能；
- 用戶登錄銀行后，才可以使用在線轉賬功能；
- 銀行中存在兩個賬戶：受害者賬戶、攻擊者賬戶；
- 存在一個惡意網站，當訪問該惡意網站時，會自動向銀行網站提出轉賬請求。
如果受害者沒有退出銀行網站的情況下訪問惡意網站，因為受害者已經通過了銀行網站的身份驗證，因此發出的轉賬請求會通過銀行網站的授權，即攻擊者完成了攻擊。
2.2 攻擊的步驟
發動 CSRF 攻擊的步驟如下圖所示：
2.2.1 登錄
受害者使用用戶名、密碼登錄銀行網站。
2.2.2 驗證通過
銀行網站根據用戶名、密碼查詢數據庫，如果匹配，則在 Session 中記錄用戶已經通過身份驗證。
銀行網站提供了轉賬的功能，在實現轉賬功能時，首先在 Session 中檢查是用戶是否是登錄用戶，如果是登錄用戶，則允許執行轉賬操作；如果不是登錄用戶，則不允許執行轉賬操作。
2.2.3 被誘導
攻擊者創辦了一個惡意網站，提供一些吸引人的內容（例如：色情、賭博、盜版小說等信息），誘導受害者訪問惡意網站。
2.2.4 惡意 HTML
當受害者訪問惡意網站時，惡意網站傳輸給受害者一段惡意的 HTML 代碼，惡意的 HTML 代碼向銀行發起轉賬請求，代碼可能如下：
<form action='http://www.bank.com/transfer' method='post'>
<input type="text" name="name" value="hacker" placeholder="收款賬戶"/>
<input type="text" name="amount" value="100" placeholder="轉賬數量"/>
<input type="submit" id="submit" value="轉賬">
</form>
<script>
var submit = document.getElementById('submit');
submit.click();
</script>
在第 1 行，定義了一個向銀行網站提出轉賬請求的表單，通過 POST 方法向頁面 http://www.bank.com/transfer’ 提出轉賬請求。
在第 2 行，定義了一個名稱為 ‘name’、值為 ‘hacker’ 的文本字段，表示轉賬的收款賬戶是 ‘hacker’。
在第 3 行，定義了一個名稱為 ‘amount’、值為 ‘100’ 的文本字段，表示轉賬的數量是 100。
在第 8 行和第 9 行，找到提交按鈕，模擬提交按鈕的 click 操作，實現了自動提交表單。即：用戶瀏覽器訪問這段惡意的 HTML 代碼后，會自動向銀行網站發出轉賬 100 元的請求。顯然，這次轉賬不是受害者用戶的本意，是攻擊者偽造的用戶請求。
2.2.5 轉賬
受害者的瀏覽器收到惡意的 HTML 后，執行惡意的 HTML 中的 Javascript 代碼，自動向銀行提出了一個轉賬請求。
銀行網站收到轉賬請求后進行處理，如果受害者沒有退出銀行網站的登錄，此次轉賬請求可以通過身份驗證，可以正常完成轉賬的功能。
通過以上的 5 個步驟，攻擊者成功的挾制了受害者，在當前已登錄的銀行網站上執行非本意的轉賬操作。
3. CSRF 防御的方法
在業界目前防御 CSRF 攻擊有如下策略：
3.1 驗證 HTTP Referer 字段
HTTP Referer 字段簡介
在 HTTP 請求頭里有個 Referer 字段，用于表明請求的來源地址。以向銀行發出轉賬請求為例，說明 Referer 字段。
1. 用戶正常發出轉賬請求
用戶登錄銀行網站成功后，在網站首頁 http://www.bank.com/，存在一個轉賬按鈕；用戶通過點擊頁面上的轉賬按鈕進行轉賬，向銀行發出轉賬請求
| 屬性 | 描述 |
|---|---|
| 請求的地址 | http://www.bank.com/transfer |
| 請求的 Referer | http://www.bank.com/ |
可以看出：請求的地址和請求的 Referer 是屬于相同的域名。
2. 攻擊者通過 CSRF 攻擊發出轉賬請求
如果用戶被誘導進入惡意網站 http://www.malicious.com，在惡意網站的頁面中向銀行發起轉賬請求，請求的屬性如下：
| 屬性 | 描述 |
|---|---|
| 請求的地址 | http://www.bank.com/transfer |
| 請求的 Referer | http://www.malicious.com/ |
可以看出：請求的地址和請求的 Referer 是屬于不同的域名。
3.1.2 驗證 HTTP Referer 字段
正常情況下，Referer 字段和請求的地址是位于同一域名下的。如果是 CSRF 攻擊發起的請求，那么 Referer 字段和請求的地址就不是同一域名了，因此，服務器通過驗證 HTTP Referer 字段就能識別出 CSRF 攻擊。
該方法的優點在于：只需要給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以防御所有的 CSRF 攻擊；特別是對于當前現有的系統，不需要改變當前系統的任何已有代碼和邏輯，沒有風險，非常便捷。
該方法的缺點在于：攻擊者能夠篡改請求頭的 Referer 字段內容，從而欺騙服務器；有可能無法獲取 Referer 的值，因為 Referer 值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。
3.2 在請求中添加 Token 并驗證
目前業界對 CSRF 的防御，流行的做法是使用一個 Token（Anti CSRF Token）。使用 Token 防御 CSRF 攻擊的步驟如下：
- 用戶訪問某個安全相關的頁面，例如銀行的轉賬頁面；
- 服務端生成一個隨機的 Token，放在用戶的 Session 中；
- 在安全相關的頁面附帶上 Token，返回給客戶端；
- 用戶提交請求后，服務端獲取兩個 Token：驗證表單中的 Token、用戶 Session 中的 Token，如果一致則為合法請求，不一致則識別為 CSRF 攻擊。
4. 小結
本節講解了 CSRF 的概念，如何實施 CSRF 攻擊以及如何防御 CSRF 攻擊，使用思維導圖概括如下：
2025 imooc.com All Rights Reserved |