CSRF攻擊學(xué)習(xí)筆記
CSRF攻擊簡介
關(guān)鍵處理中引入的安全隱患：
Web應(yīng)用中，用戶登錄后執(zhí)行的操作中有些處理一旦完成就無法撤銷。比如用戶使用信用卡支付、從用戶的銀行賬號轉(zhuǎn)賬、發(fā)送郵件、更改密碼或郵箱地址等都是關(guān)鍵處理的典型案例。
關(guān)鍵處理中如果存在安全隱患，就會產(chǎn)生名為跨站請求偽造（Cross-Site Request Forgeries，簡稱CSRF）的漏洞。
CSRF介紹：
在執(zhí)行關(guān)鍵處理前，需要確認該請求是否確實由用戶自愿發(fā)起。如果忽略了這個步驟，就可能出現(xiàn)很大的問題，比如用戶只是流量惡意網(wǎng)站，瀏覽器就擅自執(zhí)行關(guān)鍵處理等。
引發(fā)上述問題的安全隱患為稱為跨站請求偽造（CSRF）漏洞，而針對CSRF漏洞進行的攻擊就是CSRF攻擊。
Web應(yīng)用存在CSRF漏洞時就可能會遭受如下攻擊：
使用用戶的賬號購物
刪除用戶賬號
使用用戶的賬號發(fā)布帖子
更改用戶密碼或郵箱地址等。
CSRF漏洞造成的影響僅限于應(yīng)用的關(guān)鍵處理被惡意使用，而像用戶的個人信息等就無法通過CSRF攻擊竊取。
因此，為了預(yù)防CSRF漏洞，就需要在執(zhí)行關(guān)鍵處理前確認請求確實是由用戶自愿發(fā)起的。
CSRF漏洞總覽：
產(chǎn)生地點：?以下任一網(wǎng)站上執(zhí)行關(guān)鍵處理的頁面。
僅使用Cookie進行會話管理的網(wǎng)站。
僅依靠HTTP認證、SSL客戶端證書、手機的移動ID來識別用戶的網(wǎng)站。
影響范圍：
存在CSRF漏洞的頁面。
影響類型：
以受害用戶的權(quán)限執(zhí)行關(guān)鍵處理。如購買商品、發(fā)布帖子、更改密碼等。
影響程度：
中~大
用戶參與程度:
需要–>點擊惡意鏈接、瀏覽惡意網(wǎng)站等。
對策概要：
執(zhí)行關(guān)鍵處理前，確認是正規(guī)用戶發(fā)起的請求。
兩種典型的CSRF攻擊模式：
CSRF漏洞實施的兩種典型的攻擊模式。
輸入–執(zhí)行?這種簡單模式的攻擊。
中途包含確認頁面時的攻擊。
輸入–執(zhí)行攻擊模式：
用戶登錄網(wǎng)站。
攻擊者設(shè)下圈套。
受害人瀏覽惡意網(wǎng)站而出發(fā)圈套。
攻擊者使用惡意網(wǎng)站中的JavaScript，使受害人的瀏覽器向攻擊對象網(wǎng)站發(fā)送將密碼為攻擊者指定的密碼的POST請求。
密碼被更改。
存在確認頁面的CSRF攻擊：
Hidden參數(shù)
使用會話變量
根據(jù)同源策略，從iframe的外層（惡意網(wǎng)頁）無法讀取到內(nèi)層（攻擊對象）的內(nèi)容，因此，CSRF攻擊雖然能夠以正規(guī)用戶的權(quán)限惡意使用攻擊對象網(wǎng)站中的關(guān)鍵處理，卻無法獲取網(wǎng)頁中顯示的內(nèi)容。
但是，在使用CSRF攻擊成功更改用戶密碼后，攻擊者就知道了更改后的密碼，從而也就能夠登陸應(yīng)用來竊取被害人的信息了。
修改密碼的三個條件
使用POST方法請求
保持登錄狀態(tài)。
使用POST參數(shù)中的pwd指定新密碼
CSRF攻擊與XSS攻擊對比：
XSS：利用用戶對站點的信任
CSRF：利用站點對已經(jīng)身份認證用戶的信任
CSRF是指惡意使用用戶對服務(wù)器正常請求中的請求處理，惡意使用的內(nèi)容僅限于服務(wù)器端提供的操作。
而XSS，在用戶請求服務(wù)器中包含的腳本被原封不動的以響應(yīng)的形式返回，隨后該惡意腳本在用戶的瀏覽器中被執(zhí)行。由于攻擊者能夠在用戶的瀏覽器上執(zhí)行自己準備的HTML或JavaScript，因此只要是瀏覽器能做到的事情都可以被用作攻擊手段。攻擊者甚至還能夠通過JavaScript惡意使用服務(wù)器端的功能。
CSRF攻擊安全解決方案
對策分析：
防御CSRF的關(guān)鍵為確認關(guān)鍵處理的請求確實是由正規(guī)用戶自愿發(fā)送的。因此，作為CSRF的防范策略，需要執(zhí)行以下兩點：
篩選出需要防范CSRF攻擊的頁面
使代碼有能力辨認是否是正規(guī)用戶的自愿請求。
篩選出需要防范CSRF攻擊的頁面：
并非所有的頁面都需要實施CSRF防御策略，事實上無需防范CSRF的頁面居多。通常情況下，Web應(yīng)用的入口并非只有一處，通過搜索引擎、社交書簽、其他鏈接等方式都能進入Web應(yīng)用中的各種頁面。比如EC（電子商務(wù)）網(wǎng)站一般就非常歡迎通過外部鏈接進入到它的商品展示頁面。而這像這種頁面就不需要實施CSRF對策。
而另一方面，EC網(wǎng)站中的購買商品、更改密碼或確認個人信息等頁面，就不能夠任意由其他網(wǎng)站隨意執(zhí)行。這樣的頁面就應(yīng)當實施CSRF防范策略。
確認是正規(guī)用戶自愿發(fā)送的請求：
判斷請求是否為正規(guī)用戶自愿發(fā)送的實現(xiàn)方法，一般有如下3類：
嵌入機密信息（令牌）
如果訪問需要防范CSRF的頁面（登錄頁面、訂單確認頁面等）時需要提供第三方無法得知的機密信息的話，那么即使出現(xiàn)非正規(guī)用戶自愿發(fā)送的請求，應(yīng)用端也能夠通過判斷得知請求是否合法。用于此目的的機密信息被稱為令牌（Token）。會話ID就是一種既簡單又安全的令牌實現(xiàn)方法。
接收令牌的請求（接受關(guān)鍵處理的請求）必須為POST方法。因為使用GET方法發(fā)送機密信息的話，令牌信息就可能通過Referer泄露出去。
再次輸入密碼
讓用戶在此輸入密碼，也是用來確認請求是否是由用戶自愿發(fā)起的一種方法。除了用來防范CSRF攻擊，在此輸入密碼也可以被用于其他目的。
要求確認密碼的頁面都應(yīng)該是在最后的執(zhí)行頁面。如果僅在途中的某個頁面就行密碼確認，根據(jù)代碼實現(xiàn)方法還是可能會存在CSRF漏洞，所以要求輸入密碼的實際非常重要。
在用戶確認下訂單之前，再次向用戶確認購買意向。
能夠確認此事在電腦前操作的確實是用戶本人。
檢驗Referer
在執(zhí)行關(guān)鍵處理的頁面確認Referer，也是CSRF的一種防范策略。正規(guī)請求中Referer的值應(yīng)該為執(zhí)行頁面的上一個頁面（輸入頁面或者確認頁面等）的URL，這一點一定要得到確認。
CSRF防范策略比較：
CSRF的輔助性對策：
執(zhí)行完關(guān)鍵處理后，建議向用戶注冊的郵箱發(fā)送有關(guān)鍵處理內(nèi)容的通知郵件。
發(fā)送通知郵件雖然不能防范CSRF攻擊，但是在萬一遭受了CSRF攻擊的情況下能在第一時間讓用戶知情，從而將損害降到最低。
另外，除了CSRF攻擊之外，在攻擊者通過XSS攻擊偽裝成用戶操作關(guān)鍵處理時，發(fā)送通知郵件也能使用戶盡早發(fā)現(xiàn)。
但是，由于郵件是未經(jīng)加密的明文傳輸，因此，最好不要在郵件中添加重要信息，而只是通知用戶有人惡意執(zhí)行了關(guān)鍵處理如果用戶想要了解詳情的話，可以登錄Web應(yīng)用查看購買歷史或者發(fā)送歷史等內(nèi)容。
CSRF對策總結(jié)：
CSRF漏洞的根本防范策略如下：
篩選需要防范CSRF的頁面
確認是正規(guī)用戶自愿發(fā)起的請求。
其中，確認是正規(guī)用戶自愿發(fā)起的請求的方法有以下三種。
嵌入機密信息（令牌）
再次輸入密碼
檢驗Referer
另外，作為CSRF漏洞的輔助性對策，可以執(zhí)行以下操作。
執(zhí)行完關(guān)鍵處理后，向用戶注冊的郵箱發(fā)送通知郵件。
自動化掃描程序的檢測方法：
在請求和響應(yīng)過程中檢查是否存在Anti_CSRF token
檢查服務(wù)器是否驗證Anti-CSRF token
檢查token字符串是否可編輯和偽裝
檢查Referer頭字段是否可以偽裝
DVWA的CSRF漏洞
安全級別是Low的情況：
原理：在安全級別為low的情況下，CSRF更改密碼時，可以直接進行提交密碼進行改密。沒有安全控制。
攻擊：可以通過在惡意站點上做超鏈接，引誘用戶點擊，從而直接更改密碼。
安全級別是Medium的情況：
原理：在安全級別為Medium的情況下，主要通過stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false?驗證了Referer字段，從檢查是否來自本網(wǎng)站的更改密碼的請求。
攻擊：可以將惡意站點上惡意鏈接中的html頁面名字改為包含合法站點域名字符串的文件名，從而讓通過Referer字段的檢查。
安全級別為High的情況：
原理：通過服務(wù)器給客戶端生成一個token，在更改密碼時，還需要提交token字段，token可以可以使服務(wù)器發(fā)給客戶端的一個隨機數(shù)。那樣惡意站點就不能知道token從而無法實現(xiàn)繞過用戶直接更改密碼。
攻擊：但是如果合法網(wǎng)站上存在XSS漏洞，那么可以首先利用XSS漏洞，獲取用戶的Token，然后攜帶用戶的Token去更改密碼。從而達到攻擊的效果。
安全級別為Impossible的情況：
原理：在這情況下，除了驗證token，還需要用戶輸入舊密碼，那么第三方惡意站點（非法用戶）肯定無法知道舊密碼，再加上token，基本杜絕了CSRF漏洞的攻擊。
