教你輕鬆解決CSRF跨站請求偽造攻擊
摘要：CSRF（Cross-site request forgery）跨站請求偽造，通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比XSS更具危險性。
本文分享自華為雲社區《CSRF跨站請求偽造攻擊及防禦》，作者： HZDX。
什麼是CSRF跨站請求偽造
CSRF的定義
CSRF（Cross-site request forgery）跨站請求偽造，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比XSS更具危險性。
可以這樣來理解：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發送郵件、發消息，盜取你的賬號，添加系統管理員，甚至於購買商品、虛擬貨幣轉賬等。
CSRF的分類
- HTML CSRF攻擊
- JSON HiJacking攻擊
- Flash CSRF攻擊
CSRF的攻擊過程
- 假設用戶A登錄銀行的網站進行操作，同時也訪問了攻擊者預先設置好的網站。
- 用戶A點擊了攻擊者網站的某一個鏈接，這個鏈接是//www.bank.com/xxx指向銀行，銀行服務器根據這個鏈接攜帶的參數會進行轉賬操作。
- 銀行服務器在執行轉賬操作之前會進行Session驗證，但是由於用戶A已經登錄了銀行網站，攻擊者的鏈接也是//www.bank.com，所以攻擊的鏈接就會攜帶session到服務器。
- 由於session id是正確的，所以銀行會判斷操作是由本人發起的，執行轉賬操作。
CSRF的攻擊條件
- 登錄受信任網站A，生成可信的Session
- 在不登出A的情況下，訪問危險網站B，網站B偽造網站A的請求
CSRF跨站請求偽造的預防方法
驗證 HTTP Referer 字段
HTTP header中包含一個Referer字段，這個字段用於指明http請求的來源地址。當用戶進行正常請求時，此Referer字段應該與請求的地址位於同一個域名下（//bank.com）。如果是通過CSRF攻擊偽造的請求則此Referer應當包含惡意網址的地址（//evil.com）。所以通過對Referer來源地址的校驗可以識別出偽造的惡意請求。
這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其局限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但並無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。並且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。
在請求地址中添加token並驗證
由於CSRF攻擊的本質在於攻擊者欺騙用戶去訪問自己設置的請求，所以如果在請求敏感數據時，要求用戶瀏覽器提供不是保存在cookie中並且攻擊者無法偽造的數據作為校驗條件，那麼攻擊者就無法偽造未校驗的請求進行CSRF攻擊。
服務器將其生成並附加在窗體中，其內容是一個偽隨機數。當客戶端通過表單提交請求時，這個偽隨機數也一併提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到並傳回這個偽隨機數，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從獲取頁面信息得知這個偽隨機數的值，服務端就會因為校驗token的值為空或者錯誤，拒絕這個可疑請求。
在HTTP頭中自定義屬性並驗證
這種方法也是使用 token 並進行驗證，和上一種方法不同的是，這裡並不是把 token 以參數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。
通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。
智能雲網
智能雲網社區是華為專為開發者打造的「學習、開發、驗證、交流」一站式支持與服務平台，該平台涵蓋多領域知識。目前承載了雲園區網絡，雲廣域網絡，數通網絡開放可編程，超融合數據中心網絡，數通網絡設備開放社區共五個場景。為了響應廣大開發者需求，還提供了開發者交流、API 體驗中心、多媒體課件、SDK工具包、開發者工具以及遠程實驗室共六大工具，讓開發者輕鬆開發。歡迎各位前來體驗。
