在之前的文章中我們介紹過XSS攻擊 和 SQL 注入。沒看過的小伙伴可以在專欄中以往的文章中查看。這兩種攻擊分別篡改了原始的 HTML 和 SQL 邏輯，從而使得黑客能夠執行自定義的功能。那么除了對代碼邏輯進行篡改，黑客還能通過什么方式發起 Web 攻擊呢？

我們還是先來看一個例子。在平常使用瀏覽器訪問各種網頁的時候，是否遇到過，自己的銀行應用突然發起了一筆轉賬，又或者，你的微博突然發送了一條內容？

學習 XSS 之后，你可能會聯想到，這是銀行或者微博中出現了某個 XSS 漏洞。但問題是，你今天并沒有訪問過銀行或者微博的頁面，所以并沒有“被 XSS”的機會。這時，你想到，會不會是你今天訪問的其他網頁里存在一些惡意的攻擊，實現了你不知道的轉賬和發博行為呢？

CSRF 攻擊是如何產生的？

我們幾乎每天都要用到瀏覽器，我們的信息也會被瀏覽器“保存”。那我們首先來看一下，瀏覽器是如何保存你的身份信息的。

當我們在訪問一個 Web 頁面的時候，并不是我們自己去獲取頁面信息，而是瀏覽器去獲取了這些信息，并將它們進行了展示。這就說明，你允許瀏覽器代表你去和 Web 的服務端進行交互。為了能夠準確地代表你的身份，瀏覽器通常會在 Cookie 中存儲一些必要的身份信息。所以，在我們使用一個網頁的時候，只需要在首次訪問的時候登錄就可以了。

從用戶體驗上來說，這當然是非常方便的。但是，黑客正是利用這一點，來編寫帶有惡意 JavaScript 腳本的網頁，通過“釣魚”的方式誘導你訪問。然后，黑客會通過這些 JavaScript 腳本竊取你保存在網頁中的身份信息，通過仿冒你，讓你的瀏覽器發起偽造的請求，最終執行黑客定義的操作。而這一切對于你自己而言都是無感知的。這就是 CSRF（Cross-Site Request Forgery，跨站請求偽造）攻擊。

接下來，我們就以銀行轉賬為例子，來詳細講解一下這個攻擊過程。

當你在銀行頁面發起一筆轉賬時，這個過程其實是通過一個轉賬接口來完成的。這個接口的內容可能包括下面這些內容：

• 接口地址：http://bank.com/transfer ；
• HTTP 方法：POST；
• 接口參數：to（目標賬戶）、amount（金額）。

在轉賬之前，你肯定進行了一次登錄。這樣一來，這個轉賬接口就可以通過你之前存儲在 Cookie 中的相關字段來完成認證了。所以，這個接口參數中不需要包含任何身份認證相關的信息。也正是因為如此，這個接口滿足了 CSRF 攻擊的基本條件：

• 使用 Cookie 進行認證；
• 參數中不包含任何隱私信息。

于是，黑客可以構造一個如下的空白網頁。我們假設這個網頁的地址為 http://hacker.com。

<

在 HTML 中，<script>標簽內的 JavaScript 腳本會在打開網頁的時候自動執行。因此，一旦用戶訪問了這個 hacker.com 的頁面，它就會自動提交 form 表單，向http://bank.com/transfer這個接口（假設為轉賬接口）發起一個 POST 請求。

其中，to 和 amount 這兩個參數，代表著用戶向黑客的賬號轉賬 10000 元。只要這個用戶之前登錄過 http://bank.com，并且賬戶余額大于 10000 元，那么黑客就能夠成功地收到這 10000 元的轉賬了。在這個網頁中，<input>的標簽帶有“hidden”屬性，所以這整個過程對于用戶來說都是不可見的。

為了方便你理解，我把這個流程，我畫成了一張圖，如下所示：

---

通過 CSRF 攻擊，黑客能做什么？

和 XSS 一樣，CSRF 也可以仿冒用戶去進行一些功能操作的請求，比如修改密碼、轉賬等等，相當于繞過身份認證，進行未授權的操作。

值得一提的是，盡管黑客通過 CSRF 能進行的操作沒有 XSS 豐富，但 CSRF 在傳播和攻擊成本上都低于 XSS。這也就是說，即使你的網頁中沒有任何注入漏洞，但只要接口配置不當，就能夠被 CSRF 利用。而黑客也只需要在自己的域名中，搭建一個誘導性的網頁，就可以讓任何訪問網頁的用戶都遭受到 CSRF 攻擊。而且，用戶每天需要訪問大量的網頁，根本沒有辦法確認每一個網頁的合法性。而從嚴格意義上來說，用戶根本沒有辦法防止 CSRF 攻擊。因此，我們只能從應用本身入手去加強防護。

如何進行 CSRF 防護？

那究竟該怎么進行 CSRF 防護呢？我們有兩種方法。行業內標準的 CSRF 防護方法是 CSRFToken。 我們先來看這個方法。

通過前面的學習，我們知道，CSRF 是通過自動提交表單的形式來發起攻擊的。所以，在前面轉賬的例子中，黑客可以通過抓包分析出 http://bank.com/transfer 這個接口所需要的參數，從而構造對應的 form 表單。因此，我們只需要在這個接口中，加入一個黑客無法猜到的參數，就可以有效防止 CSRF 了。這就是 CSRF Token 的工作原理。

它的工作流程，我也總結了一下，如下圖所示：

除了 CSRF Token 之外，我們也可以通過二次驗證來加強防護。

回想一下，當你進行各類支付操作的時候，銀行網頁通常會要求你輸入支付密碼。你可能會覺得奇怪，明明自己已經登錄了，為什么還需要輸入一個獨立的支付密碼呢？這其實和 CSRF Token 的原理一樣：這個獨立的支付密碼是需要用戶輸入的，只存在于用戶的記憶中，因此，也是黑客無法獲取到的參數。

怎么理解呢？假如說，黑客通過 CSRF 攻擊，替你發起了一筆轉賬。在支付的時候，銀行會發起一個全新的頁面，讓你驗證支付密碼。這個時候你發現，這個支付請求不是你本人發起的，那你肯定不會輸入支付密碼來完成驗證。所以，在用戶進行支付這樣的敏感操作時，應用通常會要求用戶提供一些私密的信息，就是為了對 CSRF 攻擊進行防護。

講到這里，你現在對 CSRF 的攻擊和防護，應該有了一個大概的了解。簡單來說，CSRF 其實就是黑客利用瀏覽器存儲用戶 Cookie 這一特性，來模擬用戶發起一次帶有認證信息的請求，比如轉賬、修改密碼等。防護 CSRF 的原理也很簡單，在這些請求中，加入一些黑客無法得到的參數信息即可，比如 CSRF Token 或者獨立的支付密碼等。掌握了這些內容，其實 CSRF 的知識基本上就差不多了。

總結

以上是生活随笔為你收集整理的csrf攻击原理与解决方法_信息安全之CSRF攻击的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。