跨站請求偽造攻擊的基本原理與防範
摘要：文章介紹了跨站請求偽造攻擊的基本情況，並以兩種常見的場景作為講解的範例，分析了該類攻擊的主要原理與產生條件。針對跨站請求偽造攻擊的主要 目標和所利用的漏洞，重點介紹了5種不同的防範方法，並簡單的說明5種方法各自的優劣之處。為Web應用系統的安全防範和設計提供參考。
1 跨站請求偽造簡介
跨站請求偽造（Cross Site Request Forgery，簡稱CSRF），也被稱為“one click attack”或“session riding”。跨站請求偽造與目前非常流行的安全漏洞“跨站腳本攻擊（Cross Site Scripting）”名字上有點相似，但它與XSS的攻擊方法完全不一樣。XSS利用漏洞影響站點內的用戶，攻擊目標是同一站點內的用戶者，而CSRF 通過偽裝成受害用戶發送惡意請求來影響Web系統中受害用戶的利益。
CSRF的形成是因為攻擊者較容易猜測某些Web應用一個特定敏感操作的所有細節（若是開源項目，則更直接找到關鍵操作的漏洞細節）。利用瀏 覽器能保存會話cookie等憑證，並會自動發送的特點，攻擊者可以創建一個惡意web頁面生成偽造請求，再利用社會工程學的手段蠱惑受害者進行操作，從 而在被攻擊Web應用上偽裝成受害者進行的特定敏感操作，如修改密碼、通信方式甚至轉賬等。
CSRF不像XSS那麽廣為人知，但在OWASP 2013公布的10大Web應用安全威脅中，跨站請求偽造依然位居第8位，依然是一個不可忽略的嚴重安全漏洞。又因為CSRF比XSS更難以防範，且更具危險性，所以CSRF也被稱為“沈睡的巨人”。
2 跨站請求偽造的場景
跨站請求偽造攻擊可以在以受害者名義偽造請求並發送給受攻擊的站點，這樣就能以受害者的身份和權限執行一些特殊敏感的操作，但這一切受害者是毫不知情的。例如：
Tom登錄了一個銀行網站affectedBank.com，並沒有退出。
黑客Jerry知道affectedBank.com的轉賬功能有CSRF漏洞。於是Jerry在大型社交網站sns.com中發表一張帖子，在帖子中Jerry插入一行類似的html代碼
Tom在瀏覽器的另外一個標簽頁中查看Jerry的這條消息
Tom的瀏覽器將Jerry偽造的轉賬請求發送給affectedBank，從而轉出1000元到Jerry的賬戶。
流程如圖1所示。
上述例子當中的轉賬操作是通過GET請求方式執行，在實際中可能會更多使用POST的方式。受攻擊站點只接納使用POST方式請求，表面上已 經不能直接將偽造請求包裝在其他網站中，但黑客仍然可以使用重定向的方式將社交網站中GET的請求指向一個封裝POST的頁面，從而實現POST請求組合 與提交。
在上述例子中進行一些擴展：
A. Jerry在自己控制的站點evil.com中構造一個頁面Redirector.php。將使得外部通過GET請求Redirector.php而來的 參數在頁面中重新組合出表單的內容，再通過頁面內的JavaScript提交到www. affectedBank.com/Transfer.php中。
B. 在sns.com的帖子中包裝一個不可見的GET請求，申請訪問Redirector.php。類似於
C. Tom在訪問帖子時，實際將執行兩次請求，第一次是GET請求跳轉到Redirector頁面，第二次是POST請求將數據提交到affectedBank.com/Transfer.php。
流程如圖2所示：
圖2 重定向實現POST請求的CSRF
直接利用GET請求Redirector.php頁面容易暴露黑客的攻擊意圖，Jerry可以在Evil.com的Web服務器中設置一個 Rewrite功能，將請求而來的face.png重寫為http：//www.evil.com/Redirector.php？csrf= http：//www.affectedBank.com/Transfer.php？toAccount=Jerry&money=1000， 這樣在sns.com發帖時的引用部分就可以直接寫成“http：//www.evil.com/face.png”，使得攻擊更加隱蔽。
3 跨站請求偽造的基本原理
從上述的跨站請求偽造攻擊的場景中，有三個引發攻擊形成的必要條件。
1） 瀏覽器會自動發送用戶標識的會話信息，並且用戶毫不知情也無法幹預。換而言之，用戶不知道瀏覽器發送的內容中，已經包含身份標識信息。身份標識信息（例如 cookie）主要是站點用於識別受認證用戶的一個標誌。如果站點收到帶有受害者認證信息的請求，那麽這個請求就會被看作是已登錄的受害者發送而來的正確 操作請求。
2） 攻擊者清楚在被攻擊網站的特殊敏感操作的URL結構，並能分析其中所支持的參數和允許值。一般而言，通過訪問被攻擊Web應用程序，查看潛入在HTML或 JavaScript中的URL、分析提交的表單結構就可以了解到相應的信息。如果是一個開源項目，攻擊者直接就可以從源代碼中進行分析提取可以攻擊的特 殊敏感操作。
3） 被攻擊網站完全依賴於會話信息識別用戶。因為會話信息其實對瀏覽器而言是透明的，瀏覽器只負責存放和在發送請求時附加相關的會話信息，通過瀏覽器並不能解 析出會話信息的內容。為了提高Web應用的便利性，降低開發的成本，部分Web應用就會完全依賴這類信息來標識一個用戶會話。從而導致Web應用程序不會 判斷一個請求是否真是由合法用戶發送的。
一般來說，要發生跨站請求偽造攻擊，需要有以下幾個特點：
1） 在受攻擊站點已經登錄，且沒有正常退出。
2） 受攻擊站點的會話失效時間比較長。而且失效時間越長受攻擊機率越高。
3） 受攻擊站點的特殊敏感操作沒有嚴謹的用戶身份標識驗證。
4） 受害者主動訪問含有偽造請求的頁面。電子郵件、論壇、博客等常見的互聯網應用都是攻擊者可利用的社會工程學的範圍。
4 跨站請求偽造防範的主要方法
要做好攻擊的防範，首先需要明確攻擊的目標。跨站請求偽造攻擊的對象，就是要保護的對象。從上文的分析可知，跨站請求偽造攻擊是黑客利用受害 者瀏覽器中包含的用戶身份認證信息騙取服務器的信任，但是黑客其實並不能拿到身份認證的具體憑證，也看不到身份認證的內容。另外，由於瀏覽器同源策略的限 制，黑客也無法進行解析查看從受攻擊服務器響應回來的內容。因此，黑客無法從服務器響應中得到任何東西。他所能做的僅僅是給服務器發送請求，以執行請求中 所包含的特殊敏感操作，從而達到在服務器端直接更改數據，並非竊取服務器的敏感信息或受害者的個人資料。
因此，針對跨站請求偽造攻擊要保護的對象是那些可以直接影響數據改變的操作或服務，其他僅僅讀取信息的操作或服務，則不需要進行跨站請求偽造 攻擊的防範。例如上文中的銀行系統，查詢余額是僅僅返回讀取到的金額數，跨站請求偽造攻擊無法攔截服務器返回的結果，不需要防範。而轉賬的操作會涉及改變 賬戶的金額，有遭受跨站請求偽造攻擊的威脅，需要保護。
一般的攻擊防範，都可以從服務端和客戶端兩方面入手，因為跨站請求偽造主要是針對服務端的欺騙，所以這裏攻擊的防範主要在服務端進行。防範的核心思想則是在服務器端不唯一依靠瀏覽器所直接提交的身份認證信息，而需要添加額外的校驗信息。主要的實現方式有以下幾種。
1） 驗證 HTTP Referer。在 HTTP 協議的請求頭部含有一個字段叫 Referer，它記錄了本次請求的來源地址。只需校驗Referer是否以本域作為來源，則可以判斷這個請求的真偽。
這種方式的優點在於簡單易用，開發人員只需用在敏感操作前增加一個攔截器檢查Referer的值即可。對於已有的系統，不需要改動內部的邏 輯，比較方便。但這種方法並不是百分百有效。每個瀏覽器對HTTP協議的實現有一些差別，目前已經發現，IE6的瀏覽器Referer的值是可以被篡改。 對於新版瀏覽器，雖然無法纂改Referer值，但部分用戶基於隱式權的需要，可以設置瀏覽器發送的請求不包含Referer信息。這些用戶在訪問時會被 誤認為偽造的請求，從而拒絕了合法用戶的訪問。
2） 加密cookie信息。在敏感操作的提交內容中，添加一個對cookie進行Hash後的值，服務器端對Hash值進行校驗，若通過則是合法的用戶請求。 因為在直接的跨站請求偽造攻擊中，黑客其實是無法獲取cookie的具體內容，因此也無法構造一個Hash後的cookie值，從而基本杜絕了跨站請求攻 擊的實施。但是這種方法還有一種可能的泄露情況。如果黑客先通過XSS攻擊盜取了用戶的cookie，然後再利用盜取的cookie生成Hash值而制作 偽造請求。這種情況的攻擊實現比較繁瑣復雜，涉及到XSS和CSRF兩種攻擊的結合使用。
4） 使用令牌。添加一個隱藏表單域記錄隨機的令牌，在求的參數中包含該令牌。服務器端執行操作前驗證這個令牌，如果請求中沒有令牌或者內容不正確，則認為可能 是偽造請求攻擊而拒絕該請求。這種方法也可以完全解決請求偽造的問題。但在一個網站中，需要防範的地方非常多，要求每一個請求都加上令牌會增加了開發人員 的工作量，而且還很容易遺漏。
5） 在 HTTP 頭中自定義屬性。為了解決上一個方法設置Token比較麻煩的問題，可以將令牌放到 HTTP 頭中自定義的屬性裏。利用XMLHttpRequest這個對象，一次性為所有敏感操作在請求頭增加一個新的屬性，該屬性的值則是一個令牌。這種添加令牌 的方式比上一種方法簡單。而且，通過 XMLHttpRequest請求的地址不會被記錄到瀏覽器的訪問歷史，不用擔心令牌會透過Referer被竊取。這種其實是使用Ajax方法在頁面局部 的異步刷新的操作，令牌在前進，後退，收藏等行為中將失效，而且如果是遺留系統，添加Ajax請求的方法等同重新設計整個系統，代價過高。
此外，還有一些措施加固防範。如：在每次敏感操作都彈出對話框需要用戶進行二次確認。服務器端將用戶會話的失效時間設置得較短一些。用戶自己養成習慣，在一個站點操作完成後，馬上退出登錄以撤銷認證會話。
5 總結
跨站偽造請求攻擊的威脅雖然比較大，但是其原理與機制相對集中。只要把握其無法偽造的一些信息，就可以有效的防範該類攻擊。在防範偽造請求攻 擊的方法選用時，註意選擇最有效而且代價最少的方案，不能盲目追求技術的先進或復雜，而且在先滿足系統的安全需要的前提下，盡量做到用戶的易用性和系統的 安全性的平衡。Web應用的安全威脅層出不窮，在系統設計的時候需要註意做好安全漏洞的測試，以防止用戶和企業不必要的損失。 本文章來源於：http://www.qklw1.com/article-3847.html 轉載請註明來路，謝謝合作！
跨站請求偽造攻擊的基本原理與防範