CSRF漏洞

CSRF漏洞原理：

     CSRF是跨站請求僞造，不攻擊網站服務器，而是冒充用戶在站內的正常操做。一般因爲服務端沒有對請求頭作嚴格過濾引發的。CSRF會形成密碼重置，用戶僞造等問題，可能引起嚴重後果。

    咱們知道，絕大多數網站是經過cookie等方式辨識用戶身份，再予以受權的。因此要僞造用戶的正常操做，最好的方法是經過XSS或連接欺騙等途徑，讓用戶在本機（即擁有身份cookie的瀏覽器端）發起用戶所不知道的請求。CSRF攻擊會令用戶在不知情的狀況下攻擊本身已經登陸的系統。

 

 

       CSRF攻擊的目的是濫用基本的Web功能。若是該網站可使服務器上的狀態變化，如改變受害者的電子郵件地址或密碼，或購買的東西，強迫受害人檢索數據等等。CSRF攻擊會修改目標狀態。在這一過程當中，受害者會代替攻擊者執行這些攻擊，攻擊者中不會收到響應，受害者會代替攻擊者執行這些攻擊。

　　在跨站點請求僞造（CSRF）攻擊中，攻擊者經由用戶的瀏覽器注入網絡請求來破壞用戶與網站的會話的完整性。瀏覽器的安全策略容許網站將HTTP請求發送到任何網絡地址。此策略容許控制瀏覽器呈現的內容的攻擊者使用此用戶控制下的其餘資源。

　　須要對頁面參數作修改時，可使用burpsuite生成的csrf poc，從而進行poc測試，測試完成以後必定要驗證，瀏覽器執行了咱們生成的poc測試，令數據產生變化。

　　csrf能夠和XSS聯繫在一塊兒，XSS獲取cookie，CSRF僞造跨站請求完成指令。

 

漏洞利用重點：

　　一、CSRF的攻擊創建在瀏覽器與web服務器的會話中

　　二、欺騙用戶訪問URL

 

攻擊場景：

CSRF攻擊（GET）：

　　這種類型的CSRF通常因爲程序員的安全意識不強形成的。GET類型的CSRF利用很是簡單，只須要一個HTTP請求，因此，通常會這樣利用：<img src=http://test.com/csrf?xx=11 />

　　在訪問含有這個img的頁面後，成功向http://test.com/csrf?xx=11 發出了一次HTTP請求。

　　假如微博存在CSRF漏洞，有一個GET請求讓別人點擊後關注我，這時能夠作一些誘惑性的博客。

　　假如想讓每一個用戶都幫助本身轉發微博，製造一次蠕蟲攻擊，找到轉播文章的頁面與關注個人頁面，寫一個POC，用<iframe>標籤來加載URL，加載兩條URL，這時當用戶點擊會關注而且自動轉發。

 CSRF攻擊（POST）：構造form表單，利用javascript提交。

 

讀取型CSRF：

什麼是讀取型CSRF，以下的漏洞能夠概括進讀取型CSRF，由於這些漏洞的利用手法都跟CSRF是同樣的：

• JSONP劫持
• Flash跨域劫持
• CORS跨域資源讀取

...等等，還有一些Sliverlight跨域這些。

 

瀏覽器Cookie機制：

cookie的兩種表現形式：一種是本地Cookie，又稱持久性Cookie；

　　　　　　　　　　   一種是臨時Cookie，又稱Session Cookie；

 

檢測CSRF漏洞：

　　一、手工檢測如：http://www.test.com/test?id=1 經過此id能夠刪除指定的用戶。能夠編寫一個POC get方式。

　　二、半自動檢測：工具CSRFTester，另外burpsuite scanner模塊也支持檢測CSRF漏洞。

　　三、全自動檢測：主要是插件。

 

預防跨站請求僞造：

　　其實如今有關CSRF漏洞防禦已是比較成熟了，其主要防禦的思路就是須要在進行後臺數據修改操做的過程當中，添加對當前用戶身份的有效驗證措施，而不能僅限於cookie的識別。

　　（1）來源校驗

　　使用http請求頭中的referer來源，對客戶端源身份校驗，此方法早期使用較多，可是仍然容易被繞過，因此這裏並不建議使用。

　　（2）用戶token校驗

　　添加基於當前用戶身份的有效tokens隨機驗證機制，即在向後端提交數據操做請求時，添加基於當前用戶的隨機token校驗值，此種校驗方法當前使用比較多；（xss和csrf漏洞同時存在時token校驗生效）

　　（3）當前用戶密碼驗證

　　在修改關鍵信息時，要當前用戶輸入其自身的密碼，以驗證當前用戶身份的真僞，防止未受權的惡意操做；

　　（4）添加驗證機制

　　在請求數據提交前，需填寫驗證碼信息提交，以增長對用戶來源的有效驗證，防止惡意未受權的操做產生。

 

繞過防護的經驗：

　　相信你們在不少時候抓包一看有token或者刪除referer從新發包報錯了就會以爲這裏不會有csrf漏洞了，可實際狀況可不必定。還有一種常見狀況就是使用驗證碼，目前識別驗證碼的方法都沒法直接利用到繞過CSRF防護上來，因此不考慮用戶體驗的話，驗證碼是防護CSRF攻擊最有效的方法。

狀況A：

　　無token無referer驗證這種狀況如今比較少了，通常出如今一些新上線的業務。通常測試時都是用firefox的live Http Headers插件先抓取一個正常請求的數據包，若是沒token的話，先去掉referer字段再從新提交看返回值。若是沒報錯的話，那就能夠直接寫一個表單（POST型）或者構造個連接（GET型）從新測試了，通常都會成功；但有些經過ajax提交的是行不通的，由於ajax沒法跨域。

狀況B：

　　無token有referer驗證這種狀況比較常見，也許咱們抓包發現無token正慶幸時，刪除referer從新提交一看發現報錯了，難道就這樣放棄了嗎？

　　（1）能夠試試空的referer：即刪除header中的referer的值，若是服務器只是驗證了是否存在referer沒驗證referer值的話，從新提交會發現一個CSRF漏洞又被發現了，由於全部跨域協議傳遞的請求都不會送referer的

　　（2)能夠試試修改referer的值:若是原referer值爲Referer：t.qq.com/xxxx話，咱們能夠試試修改成Referer:t.qq.com.baidu.com/xxx。若是服務器只是驗證了referer是否存在qq.com或者t.qq.com等關鍵詞的話，針對前一種狀況，咱們能夠再騰訊某子站點（http://xx.qq.com)發個帖子將圖片地址修改成咱們構造的csrf連接或者寫好CSRF表單後將地址發佈在微博上等待其它用戶點擊，針對後一種狀況咱們能夠創建個t.qq.com.yourdomain.com的域名存放CSRF表單來繞過REFERER檢測。