10大最重要的Web安全風險之五：A5-僞造跨站請求

10大最重要的Web安全風險之五：A5-僞造跨站請求（CSRF）

OWASP TOP10

A1-注入   

A2-跨站腳本（XSS）  

A3-錯誤的認證和會話管理 

A4-不正確的直接對象引用  

A5-僞造跨站請求（CSRF）     -- Cross-Site Request Forgery

A7-限制遠程訪問失敗 

A8-未驗證的重定向和傳遞 

A9-不安全的加密存儲   

A10-不足的傳輸層保護

A5-僞造跨站請求（CSRF）

一個跨站請求僞造攻擊會強制一個已登陸的受害者的瀏覽器向服務器（有缺陷站點）發送一個僞造的HTTP請求，這個請求會包括受害者的session cookie以及其餘自動產生的認證信息，這會使得服務器（有缺陷站點）認爲收到的受害者請求是合法請求。

僞造跨站請求問題概述

僞造跨站請求問題的幾個特色

攻擊者：任何可能誘騙用戶向系統提交請求的人。合法用戶訪問的任何站點或HTML頁面均可能有此行爲。

漏洞利用手段：利用難度通常。攻擊者建立一個僞造的HTTP請求而且誘騙受害者經過圖片標記（image tags）、XSS或者其餘技術提交這些請求。若是受害者自己已經在系統中登陸（已認證），則攻擊成功。。

保護和檢測機制：經過入侵檢測或者代碼分析能夠較爲容易的發現CSRF漏洞。

影響： 危害中等。存在這種缺陷的狀況下，攻擊者能夠改變受害者有權限改變的任何數據或調用受害者有權限使用的任何功能。

典型的僞造跨站請求問題

若是一個Web應用容許用戶提交一個未包含任何祕密（不可預測內容）的狀態變動（本例中是轉帳）請求，如：

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

當攻擊者構造一個請求，將受害者的賬號中的金錢進行轉帳，並將這個請求包含在一個其餘站點的圖片請求或iframe請求中，以下：

.<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#「width="0" height="0" />

若是受害者已經登陸轉帳系統，而且訪問了這個包含了惡意請求的連接，則這個僞造請求會包含受害者的session會話信息及其餘認證信息。

系統中是否存在僞造跨站請求

最簡單的檢查是否應用存在CSRF缺陷的辦法是，檢查是否每一個link或form爲每一個用戶包含了不可預測的標記（unpredictable token）。若是沒有這個不可預測標記，攻擊者就能夠構造惡意請求。

注意session cookie、源IP地址或其餘自動產生並被瀏覽器發出的標記並不屬於不可預測標記。由於這些信息在僞造請求中仍然存在（被瀏覽器自動生成發出）。

一個CSRF漏洞測試工具：

使用幫助：

https://www.owasp.org/index.php/CSRFTester

如何避免僞造跨站請求

阻止CSRF的辦法是，在每個請求（body或URL）中包括不可預測的標記。標記至少應該是對每一個用戶的每一個session是不一樣的，也能夠是每一個請求中不一樣。

優先選擇在隱藏字段（hidden field）中傳遞這些標記。這樣這些值就會在請求體（body of the request）中傳遞，避免暴露在URL中。

也能夠在URL中傳遞，但這種方法的風險在於這些值可能由於暴露在URL中而被攻擊者獲取。

OWASP的 CSRF Guardcan能夠用來在Java EE、.NET或者PHP應用中包含這些標記：

https://www.owasp.org/index.php/CSRFGuard

OWASP的ESAPI包括了產生和驗證這些標記的API。

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.html

相關連接：

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/CSRFTester

更詳細的討論

跨站請求僞造，也被稱成爲「one click attack」或者session riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，而且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

CSRF攻擊經過在受權用戶訪問的頁面中包含連接或者腳本的方式工做。例如：一個網站用戶Bob可能正在瀏覽聊天論壇，而同時另外一個用戶Alice也在此論壇中，而且後剛剛發佈了一個具備Bob銀行連接的圖片消息。設想一下，Alice編寫了一個在Bob的銀行站點上進行取款的form提交的連接，並將此連接做爲圖片tag。若是Bob的銀行在cookie中保存他的受權信息，而且此cookie沒有過時，那麼當Bob的瀏覽器嘗試裝載圖片時將提交這個取款form和他的cookie，這樣在沒經Bob贊成的狀況下便受權了此次事務。

CSRF是一種依賴web瀏覽器的、被混淆過的代理人攻擊（deputy attack）。在上面銀行示例中的代理人是Bob的web瀏覽器，它被混淆後誤將Bob的受權直接交給了Alice使用。

下面是CSRF的常見特性：

l        依靠用戶標識危害網站

l        利用網站對用戶標識的信任

l        欺騙用戶的瀏覽器發送HTTP請求給目標站點

風險在於那些經過基於受信任的輸入form和對特定行爲無需受權的已認證的用戶來執行某些行爲的web應用。已經經過被保存在用戶瀏覽器中的cookie進行認證的用戶將在徹底無知的狀況下發送HTTP請求到那個信任他的站點，進而進行用戶不肯作的行爲。

使用圖片的CSRF攻擊經常出如今網絡論壇中，由於那裏容許用戶發佈圖片而不能使用JavaScript。

防範措施

對於web站點，將持久化的受權方法（例如cookie或者HTTP受權）切換爲瞬時的受權方法（在每一個form中提供隱藏field），這將幫助網站防止這些攻擊。一種相似的方式是在form中包含祕密信息、用戶指定的代號做爲cookie以外的驗證。

另外一個可選的方法是「雙提交」cookie。此方法只工做於Ajax請求，但它可以做爲無需改變大量form的全局修正方法。若是某個受權的cookie在form. post以前正被JavaScript代碼讀取，那麼限制跨域規則將被應用。若是服務器須要在Post請求體或者URL中包含受權cookie的請求，那麼這個請求必須來自於受信任的域，由於其它域是不能從信任域讀取cookie的。

與一般的信任想法相反，使用Post代替Get方法並不能提供卓有成效的保護。由於JavaScript能使用僞造的POST請求。儘管如此，那些致使對安全產生「反作用」的請求應該總使用Post方式發送。Post方式不會在web服務器和代理服務器日誌中留下數據尾巴，然而Get方式卻會留下數據尾巴。

儘管CSRF是web應用的基本問題，而不是用戶的問題，但用戶可以在缺少安全設計的網站上保護他們的賬戶：經過在瀏覽其它站點前登出站點或者在瀏覽器會話結束後清理瀏覽器的cookie。

影響CSRF的因素

CSRF攻擊依賴下面的假定：

l        攻擊者瞭解受害者所在的站點

l        攻擊者的目標站點具備持久化受權cookie或者受害者具備當前會話cookie

l        目標站點沒有對用戶在網站行爲的第二受權

防範CSRF漏洞——測試篇

CSRF（Cross Site Request Forgey）跨站點僞造請求，是排在OWASP Top10第5位的漏洞，它迫使已被認證的用戶在Web系統上執行其所不欲的操做。這種攻擊依賴於如下：

1） Web瀏覽器對會話相關信息的處理方式（如cookie或Http認證信息）

　　2） 攻擊者對正確的Web系統的URL的瞭解；

　　3） 應用會話管理僅依賴於瀏覽器所瞭解的信息；

　　4） 一些HTML的tag會致使對http(s)資源的直接訪問其中，前3點是確認系統是否存在該漏洞的主要前提，第4點則是用來幫助攻擊者利用該漏洞的。

　　第1點：瀏覽器自動發送用於識別用戶會話的信息，假設site是一個Web應用站點，victim是一個已經在該系統上通過認證的用戶。在server的響應中，site發送一個帶有表明victim身份的cookie給victim，原則上，一旦瀏覽器接收到了服務器發送的cookie，就會在後面對站點的訪問中都帶上這個cookie；

　　第2點：若是應用在URL中沒有使用會話相關的信息，那就意味着應用的URL，它們的參數，相應的值能夠被識別。

　　第3點：是指諸如cookie、或者是基於http的認證信息，存放在瀏覽器中後，就會包含在後面的每次請求中。

　　下面，咱們用Get方法在作個例子，若是用戶已經經過了認證，那麼在他作下一次請求時，請求數據中會自動加上cookie

　　GET請求通常會有多種緣由產生，

　　* 用戶真正在訪問Web系統；

　　* 用戶在訪問地址欄中切實敲入了URL；

　　* 用戶點擊了一個鏈接指向了這個URL；

　　這些調用對於系統來講是沒法區別的，特別的，第三種方式相對來講是極爲危險的，有不少種方法能夠用來仿造鏈接的真實屬性，鏈接能夠被嵌入到一封郵件中，或者在某個惡意網站上，看上去這個鏈接好像是在訪問另外一個網站，而事實上倒是被引到了Web系統的訪問上。若是用戶點擊了鏈接，因爲它已經被系統認證經過了，瀏覽器就會對系統提交一個待用認證信息的GET請求。這就在系統上完成了一個操做（儘管這個操做不是用戶自己所指望作的）。

攻擊者還能夠經過Web的一些標記，注入img來達到這個目的。舉個例子，假設攻擊者發給用戶一封郵件，引誘用戶訪問了一個URL，而這個URL的頁面含有下面的HTML：

<html><body> ... <img src=」https://www.company.example/action」 width=」0」 height=」0」> ... </body></html>

　　那麼用戶在點擊這個URL時，瀏覽器將會作什麼呢，它將會嘗試顯示一個寬度爲0的圖片，而事實上這是訪問了www.company.example/action，顯然若是瀏覽器並無阻斷下載img的圖片，那麼該動做就會執行了。

　　該問題的存在是基於如下一些事實：

　　* 有一些HTML的tags可能會執行一些腳本（如img）

　　* 瀏覽器自己並不能識別img這個tag裏的值是不是真實合法的圖片

　　* 無論圖片是不是在網站本地或是其餘網站，圖片都會被下載

　　舉個例子：

　　假設用戶要登陸到某個防火牆web管理系統，登陸時，用戶必須對系統進行身份驗證，因此用戶的會話信息會保存在cookie中。假設咱們的防火牆管理系統容許認證過的用戶根據防火牆規則的排號來刪除規則（甚至容許用戶輸入「*」來刪除全部的規則），那麼下一步顯示的就是刪除頁面，假定表單下面就會提交一個GET請求，是以以下的格式：

　　https://[target]/fwmgt/delete?rule=1

　　或https://[target]/fwmgt/delete?rule=*

　　咱們舉的例子很簡單，僅僅是爲了說明CSRF的存在。

　　那麼，若是用戶輸入了「*」，而後按取了Delete鍵，那麼就提交了以下的GET請求，

　　https://www.company.example/fwmgt/delete?rule=*

　　同時就刪除了全部的防火牆規則。

顯然，若是用戶直接在地址欄中輸入https://[target]/fwmgt/delete?rule=*，或者經過某個連接轉接到這個url，或者如上面所說，把連接隱藏在img這個tag後面，諸如此種方法，若是用戶在點擊這個鏈接的時候，已經登陸進了防火牆管理系統，顯然這個訪問就能成功奏效，從而達到了刪除全部規則的目的。

　　讓咱們想象一下，若是這樣的攻擊用於一些敏感系統，競拍系統，或者是銀行轉帳等等，所形成的後果將會多大。

　　應對方法：

　　對於用戶來講，因爲CSRF漏洞極爲廣泛，因此在咱們的平常使用中要注意如下幾點：

　　* 保證系統使用完就註銷登陸的習慣；

　　* 不要使用瀏覽器的保存用戶名/密碼的功能，不要使用網站的「記住我」功能

　　* 不要使用同一個瀏覽器瀏覽普通網頁和你的關鍵性Web系統

　　對於開發人員來講，如上所述，因爲將會話相關的信息放入了URL才形成了上述的問題，那麼若是咱們在URL層面增長會話特定的信息，那麼對攻擊者來講就增長了瞭解URL結構的難度。另外，咱們還能夠儘量的使用POST，而不是GET；儘量多的增長一些諸如「你肯定要這樣作嗎？」的頁面等……

　　說到這，想必你們都已明白CSRF是什麼了，下面咱們來看下針對這個漏洞，做爲測試人員該如何去測試。

　　通常的測試用例應該以下構建：

　　1. 假設u是須要被測試的URL，例如u =http://www.example.com/action；

　　2. 構建一個包含了訪問上述URL信息的html頁面；

　　3. 確保合法用戶已經登陸了系統；

　　4. 誘使該用戶在本身不知情的狀況下訪問上述URL；

　　5. 確認是否執行了該操做。