CSRF攻擊原理
阿新 • • 發佈：2018-05-01
pos 隱式 因此 AS 服務 理論 隱私權 簡單 驗證機制
CSRF
- CSRF（Cross-site request forgery）跨站請求偽造，CSRF是一種夾持用戶在已經登陸的web應用程序上執行非本意的操作的攻擊方式。相比於XSS，CSRF是利用了系統對頁面瀏覽器的信任，XSS則利用了系統對用戶的信任。
- CSRF攻擊是源於WEB的隱式身份驗證機制，WEB的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批準發送的。
- CSRF攻擊條件：
1、客戶端必須一個網站A並生成cookie憑證存儲在瀏覽器中
2、該cookie沒有清除，客戶端又tab一個頁面B進行訪問別的網站，從而在別的網站中被黑客利用，去執行用戶並不知情的對A的操作 - 攻擊方式
- Get型CSRF：GET型的CSRF利用非常簡單,通常只要發送一段HTTP請求。簡單的說，如果一個網站某個地方的功能，比如(用戶修改自己郵箱)是通過GET進行請求修改的話
- POST型CSRF：舉個例子 比如在一個教育視頻網站平臺。在普通用戶的眼中，點擊網頁->打開試看視頻->購買視頻 是一個很正常的一個流程。可是在攻擊者的眼中可以算正常，但又不正常的，當然不正常的情況下，是在開發者安全意識不足沒有進行處理所造成。攻擊者在購買處抓到購買時候網站處理購買(扣除)用戶余額的地址。
比如：/coures/user/handler/25332/buy.php //通過buy.php處理購買(購買成功)的信息，這裏的25532為視頻ID
那麽攻擊者現在構造一個表單(form.html)，如：
document.forms[0].submit(); //自動提交
構造好form表單後，那麽攻擊者將form.html上傳至一臺服務器上，將該頁面 如:/form.html
發送給受害者，只要受害者正在登陸當前教育網站的時候，打開攻擊者發送的頁面，那麽代碼則自動觸發，自動購買了id為25332的視頻
- csrf攻擊流程
- 發現漏洞可利用處->構造(搭建)搭建代碼->發送給用戶(管理員)->觸發代碼(發送請求)
- 防禦CSRF
- 驗證 HTTP Referer 字段
1）驗證 HTTP Referer 字段
根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，比如需要訪問 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用戶必須先登陸 bank.example，然後通過點擊頁面上的按鈕來觸發轉賬事件。這時，該轉帳請求的 Referer 值就會是轉賬按鈕所在的頁面的 URL，通常是以 bank.example 域名開頭的地址。而如果黑客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站構造請求，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客自己的網站。因此，要防禦 CSRF 攻擊，銀行網站只需要對於每一個轉賬請求驗證其 Referer 值，如果是以 bank.example 開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。
這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心 CSRF 的漏洞，只需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特別是對於當前現有的系統，不需要改變當前系統的任何已有代碼和邏輯，沒有風險，非常便捷。
然而，這種方法並非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對於 Referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 bank.example 網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設為以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。
即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。因為 Referer 值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因為請求沒有 Referer 值而認為是 CSRF 攻擊，拒絕合法用戶的訪問。 - get請求只能用來執行查詢操作，增刪改操作盡量用post
- token 驗證
舉例yii2框架使用這總方式來防禦csrf攻擊：yii在post請求時，要攜帶_csrf字段一起提交，才能請求成功，而這裏的_csrf是後臺生成的token字段傳到前臺放在表單隱藏域中的，同時後臺的token的存放不是通過session，因為為了避免session文件過大，所以後臺將_csrf又以cookie形式通過某種算法加密後返給了客戶端，這時post請求時就會攜帶隱藏域中的_csrf字段和cookie中的_csrf，後臺接受數據後，先將cookie中的_csrf解密，然後和隱藏域中的_csrf對比，如果相同，則請求通過，否則請求失敗 - 加驗證碼
- 驗證 HTTP Referer 字段
CSRF攻擊原理