<span id="7ztzv"></span>
<sub id="7ztzv"></sub>

<span id="7ztzv"></span><form id="7ztzv"></form>

<span id="7ztzv"></span>

        <address id="7ztzv"></address>

            原文地址:http://drops.wooyun.org/papers/155

            0x00 簡要介紹


            CSRF(Cross-site request forgery)跨站請求偽造,由于目標站無token/referer限制,導致攻擊者可以用戶的身份完成操作達到各種目的。根據HTTP請求方式,CSRF利用方式可分為兩種。

            0x01 GET類型的CSRF


            這種類型的CSRF一般是由于程序員安全意識不強造成的。GET類型的CSRF利用非常簡單,只需要一個HTTP請求,所以,一般會這樣利用:

            <img src=http://wooyun.org/csrf.php?xx=11 /> 
            

            如下圖,在訪問含有這個img的頁面后,成功向http://wooyun.org/csrf.php?xx=11發出了一次HTTP請求。所以,如果將該網址替換為存在GET型CSRF的地址,就能完成攻擊了。

            20130701174309_63157.jpg

            烏云相關案例:

            http://wooyun.org/bugs/wooyun-2010-023783

            http://wooyun.org/bugs/wooyun-2010-027258 (還未公開)

            0x02 POST類型的CSRF


            這種類型的CSRF危害沒有GET型的大,利用起來通常使用的是一個自動提交的表單,如:

            <form action=http://wooyun.org/csrf.php method=POST>
            <input type="text" name="xx" value="11" />
            </form>
            <script> document.forms[0].submit(); </script> 
            

            訪問該頁面后,表單會自動提交,相當于模擬用戶完成了一次POST操作。

            烏云相關案例:

            http://wooyun.org/bugs/wooyun-2010-026622

            http://wooyun.org/bugs/wooyun-2010-022895

            0x03 其他猥瑣流CSRF


            過基礎認證的CSRF(常用于路由器):

            POC:

            <img src=http://admin:[email protected] /> 
            

            加載該圖片后,路由器會給用戶一個合法的SESSION,就可以進行下一步操作了。

            烏云相關案例:

            WooYun: TP-LINK路由器CSRF,可干許多事(影響使用默認密碼或簡單密碼用戶)

            0x04 如何修復


            針對CSRF的防范,有以下幾點要注意:

            關鍵操作只接受POST請求

            驗證碼

            CSRF攻擊的過程,往往是在用戶不知情的情況下構造網絡請求。所以如果使用驗證碼,那么每次操作都需要用戶進行互動,從而簡單有效的防御了CSRF攻擊。

            但是如果你在一個網站作出任何舉動都要輸入驗證碼會嚴重影響用戶體驗,所以驗證碼一般只出現在特殊操作里面,或者在注冊時候使用

            檢測refer

            常見的互聯網頁面與頁面之間是存在聯系的,比如你在www.baidu.com應該是找不到通往www.google.com的鏈接的,再比如你在論壇留言,那么不管你留言后重定向到哪里去了,之前的那個網址一定會包含留言的輸入框,這個之前的網址就會保留在新頁面頭文件的Referer中

            通過檢查Referer的值,我們就可以判斷這個請求是合法的還是非法的,但是問題出在服務器不是任何時候都能接受到Referer的值,所以Refere Check 一般用于監控CSRF攻擊的發生,而不用來抵御攻擊。

            Token

            目前主流的做法是使用Token抵御CSRF攻擊。下面通過分析CSRF 攻擊來理解為什么Token能夠有效

            CSRF攻擊要成功的條件在于攻擊者能夠預測所有的參數從而構造出合法的請求。所以根據不可預測性原則,我們可以對參數進行加密從而防止CSRF攻擊。

            另一個更通用的做法是保持原有參數不變,另外添加一個參數Token,其值是隨機的。這樣攻擊者因為不知道Token而無法構造出合法的請求進行攻擊。

            Token 使用原則

            Token要足夠隨機————只有這樣才算不可預測
            Token是一次性的,即每次請求成功后要更新Token————這樣可以增加攻擊難度,增加預測難度
            Token要注意保密性————敏感操作使用post,防止Token出現在URL中
            

            0x05 測試CSRF中注意的問題


            如果同域下存在xss的話,除了驗證碼,其他的方式都無法防御這個問題。

            有個程序后端可能是用REQUEST方式接受的,而程序默認是POST請求,其實改成GET方式請求也可以發送過去,存在很嚴重的隱患。

            當只采用refer防御時,可以把請求中的修改成如下試試能否繞過:

            原始refer:http://test.com/index.php

            測試幾種方式(以下方式可以通過的話即可能存在問題):

            http://test.com.attack.com/index.php
            http://attack.com/test.com/index.php
            [空]
            

            refer為空構造的方法:

            由于瀏覽器特性,跨協議請求時不帶refer(Geckos內核除外),比如https跳到http,如果https環境不好搭建的話,ftp其實也是可以的:)
            
            <iframe src="data:text/html,<script src=http://www.baidu.com></script>"> //IE不支持
            
            利用 xxx.src='javascript:"HTML代碼的方式"'; 可以去掉refer,IE8要帶。
            <iframe id="aa" src=""></iframe>
            <script>
            document.getElementById("aa").src='javascript:"<html><body>wooyun.org<scr'+'ipt>eval(你想使用的代碼)</scr'+'ipt></body></html>"';
            </script>
            //來自于二哥gainover
            

            <span id="7ztzv"></span>
            <sub id="7ztzv"></sub>

            <span id="7ztzv"></span><form id="7ztzv"></form>

            <span id="7ztzv"></span>

                  <address id="7ztzv"></address>

                      亚洲欧美在线