CSRF攻擊技術淺析

楊朝升

(石家莊職業(yè)技術學院 信息工程系,河北 石家莊 050081)

跨站請求偽造(CSRF)最早在2000 年被國外的研究人員提出,國內直到2006年才被提及和研究.2008年,CSRF 攻擊方式開始升級,主要通過蠕蟲腳本的方式在大型社交類應用程序中泛濫,產(chǎn)生了很大的影響.盡管CSRF的危害很大,但是很多開發(fā)者和安全從業(yè)人員對其仍然不夠重視,使得很多Web系統(tǒng)對CSRF防備不足.CSRF是一種危害大且非常隱蔽的攻擊方式,在安全界被稱為“沉睡的巨人”,連續(xù)多年位于OWASP(全球知名的Web安全研究組織)提供的十大Web安全問題前列.本文通過分析CSRF的滲透攻擊過程,提出避免遭受CSRF攻擊的防御手段,以期為維護網(wǎng)絡安全提供借鑒.

1 CSRF簡介

目前,黑客攻擊已成為非常嚴重的網(wǎng)絡安全問題.伴隨著Internet的快速發(fā)展和普及,在電子商務、政務系統(tǒng)、醫(yī)療平臺等領域,Web 應用發(fā)展迅速.Web技術雖然給各行各業(yè)帶來了便利和發(fā)展,但針對Web系統(tǒng)的攻擊也層出不窮.許多黑客甚至可以突破SSL 加密、防火墻及入侵檢測系統(tǒng)攻入Web應用網(wǎng)站的內部,竊取、篡改信息.而利用browser漏洞及黑客攻擊方法,很容易獲取Web應用系統(tǒng)中存儲的用戶資料,如用戶名、密碼及其他保密信息.攻擊手段和過程也趨于工具化、流程化.

OWASP提供的top 10 Web安全問題列表見表1.

表1 OWASP提供的top 10 Web安全問題列表

由表1可知,在OWASP統(tǒng)計的所有安全威脅中,CSRF 攻擊是常見的Web安全攻擊類型之一.Web程序提供了友好的用戶交互界面,正常合法的用戶通過GET 或者POST 表單,將合法請求數(shù)據(jù)傳送給Web程序,但是Web程序與用戶之間的合法會話卻可以被攻擊者通過browser漏洞和惡意script劫持,甚至偽造受害者的請求數(shù)據(jù).

CSRF即是偽造受害者端請求的一種攻擊方式,按照OWASP的定義,CSRF攻擊時會迫使某個登錄的瀏覽器向易受攻擊的Web應用發(fā)送一個請求,然后以受害者的名義,讓入侵者獲得利益.這雖然像跨站腳本攻擊(XSS),但它與XSS 不同.XSS通常攻擊客戶端即browser,而CSRF 則主要攻擊server,CSRF偽造的業(yè)務流程會利用合法用戶的身份達成攻擊.XSS攻擊原理更簡單,流行面更廣;而CSRF比較“小眾”,但它造成的危害卻并不比XSS小,攻擊者只要利用如電子郵件或聊天軟件發(fā)送的鏈接等就能誘導用戶在毫不知情的情況下執(zhí)行隱藏的非本意操作,例如,如果用戶登錄網(wǎng)銀查看賬戶余額,在沒有退出當前網(wǎng)銀系統(tǒng)的情況下去訪問某貼吧網(wǎng)站,而攻擊者恰好在該貼吧中精心構造了一個惡意鏈接,通過感興趣的話題等手段誘使該用戶點擊該惡意鏈接,就會讓該用戶賬戶中的錢在不知情的情況下被轉走.CSRF能夠攻擊成功的原因在于,重要操作的所有參數(shù)都可以被攻擊者猜測到[1].合法請求和CSRF惡意攻擊行為的區(qū)別見圖1.

圖1 正常請求與CSRF惡意請求的區(qū)別

2 CSRF攻擊原理

HTTP協(xié)議是無狀態(tài)協(xié)議,大部分網(wǎng)站通過cookie識別用戶身份,進行session追蹤.雖然cookie機制解決了HTTP協(xié)議的無秩序狀態(tài),允許一個用戶在訪問一個Web系統(tǒng)的多個頁面時只進行一次身份認證,提升了用戶的瀏覽網(wǎng)體驗,但之后訪問網(wǎng)站就會自動帶上這個身份標識cookie.如果這期間瀏覽器被惡意控制并在用戶不知情時請求了網(wǎng)站的URL,可能就會執(zhí)行一些違背用戶意愿的操作,如修改個人資料、添加管理員后臺密碼等.而這并不是用戶真正想發(fā)出的請求,是偽造請求,這些請求可以從第三方網(wǎng)站提交,即跨站[2].CSRF并沒有使攻擊者獲取到受害者的cookie值,只是利用受害者本人去點擊相關鏈接,由受害者本人完成CSRF攻擊.臨時cookie在關閉瀏覽器后失效,而本地cookie會在到達響應頭中expires屬性指定的時間后自動失效[3].主流瀏覽器如火狐、chrome等在進行跨域資源請求時默認允許攜帶第三方cookie,這就為CSRF攻擊創(chuàng)造了條件.CSRF攻擊原理見圖2.

圖2 CSRF的攻擊原理

用戶C利用用戶名、密碼成功地登錄社交網(wǎng)站A,網(wǎng)站A會給C頒發(fā)一個獨一無二的標識C身份的cookie.C和A之間的請求、響應、交互均通過該cookie值來完成身份認證.

攻擊者B想加A為好友,但A不同意.這時,B想通過攻擊手段來實現(xiàn)加好友,于是他研究了一個加好友的HTTP請求操作,即通過本地抓包研究請求,構造出一個鏈接,當點擊這個鏈接時,就相當于向服務器提交了一次請求,內容是請求的賬戶將添加B為好友.當B自己提交這個鏈接請求時,由于請求中帶的cookie與服務器頒發(fā)給C用戶的cookie不一致不能實現(xiàn)加好友,這時B將構造的鏈接通過各種方法誘惑C去點擊它(包括發(fā)送鏈接給C點擊;在B網(wǎng)站構造XSS,使得C在訪問B時,自動觸發(fā)并發(fā)送相關鏈接),如果C沒有退出A網(wǎng)站(這個前提很重要,因為C如果關閉了網(wǎng)站瀏覽器,則意味著cookie需要重新頒發(fā)),卻點擊了這個構造的鏈接,這個請求就包含著C的合法cookie,對于服務器A來說,它會認為C發(fā)起了一次“添加B為好友”的合法請求,因此會接受這次操作,從而B就達到了加好友的目的.

3 CSRF滲透案例與分析

3.1 CSRF滲透案例說明

本案例中,受害者在某個貼吧自己ID 下的所有的虛擬貨幣全部丟失.受害者于一周前在某臺機器上登錄了一次自己的賬號,當時虛擬貨幣還在,一周后再次登錄時發(fā)現(xiàn)自己ID 下所有的虛擬貨幣全部丟失.受害者用自己的賬號登錄貼吧網(wǎng)站后,在未退出當前系統(tǒng)的情況下,又訪問了某論壇中的圖片消息,當他點擊圖片消息時,圖片并沒有顯示完全,見圖3,受害者并沒有在意這張沒有加載成功的圖片,關閉圖片顯示后就離開了.

圖3 惡意圖片截圖

一周后,當受害者再次以自己的賬號登錄某貼吧網(wǎng)站后,發(fā)現(xiàn)虛擬貨幣全部丟失,受害者認為是自己的機器中了病毒,將殺毒軟件升級殺毒后,用不同的瀏覽器登錄該貼吧查看賬戶的虛擬貨幣,結果顯示的仍是無虛擬貨幣.

3.2 CSRF案例分析

仔細分析這個地址,發(fā)現(xiàn)這是一個精心構造的帶有正常網(wǎng)銀系統(tǒng)轉賬業(yè)務流程的請求.此請求是惡意的,因為它通過偽造請求數(shù)據(jù)包并劫持合法用戶身份,偷偷地將受害者ID 下的所有資產(chǎn)轉移給發(fā)貼人.

由于大多數(shù)網(wǎng)站具備cookie使用時間驗證策略.當用戶登錄網(wǎng)站上自己的賬戶時,在一段時間內本地計算機不需要再次驗證就可以對這個用戶進行操作,而當鏈接出現(xiàn)在SRC(圖片的鏈接)上時,瀏覽器就會按照本地的cookie去加載這個URL,而網(wǎng)站的cookie是未過期的,所以網(wǎng)站A驗證了來源請求的cookie是合法的.而服務器驗證用戶的身份是通過cookie識別來完成的,所以攻擊者盜用了用戶的cookie即盜用了用戶的身份,以合法用戶的身份發(fā)起了惡意請求,CSRF攻擊就發(fā)生了.

3.3 CSRF攻擊可能造成的傷害

如果攻擊取得成功,CSRF 攻擊可能造成如下傷害:修改受攻擊者在網(wǎng)站的設置(比如員工在公司網(wǎng)站中的ID 內容);修改公司的硬件防火墻設置;使用受攻擊者的登錄信息在網(wǎng)站中發(fā)表評論或留言;通過受攻擊者的IP 地址發(fā)表匿名留言;將資金轉移到另一個用戶賬號中;竊取有價值的資料;運行惡意軟件,留下很少或不留下能查明真實攻擊者的痕跡;進行股票交易;訂閱在線服務等[4].

4 CSRF防御策略

(1)通過驗證碼防御CSRF

目前,對于CSRF 攻擊的防御最基礎的方法是強制驗證碼機制,這也是最簡潔有效的.CSRF攻擊的原因在于用戶在不知情的情況下被動地進行網(wǎng)絡請求,利用驗證碼強制用戶與服務器建立有效的交互機制,就能夠很好地遏制CSRF攻擊,但是在很多場景下需要考慮用戶體驗的效果,驗證碼不能隨時應用,故驗證碼機制只能作為輔助手段.

(2)通過referer防御CSRF

常見的Web業(yè)務間往往是有關聯(lián)的,比如銀行轉賬業(yè)務必須在登錄成功后才能進行,因此可以通過驗證referer即驗證當前網(wǎng)頁是從哪個頁面鏈接的來防御CSRF攻擊,但不是所有的服務器都能保證取得referer,很多服務器出于安全考慮往往限制referer的使用.

(3)通過token防御CSRF

CSRF攻擊之所以能夠成功,是因為攻擊者可以完全偽造用戶的請求,該請求中用戶驗證信息均存在于cookie中,因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶的cookie來通過安全驗證[5].一般的合法請求需要登錄A頁面進行表單內容信息的填寫,在客戶請求A頁面等待服務器的響應,服務器返回A頁面的內容時,可以在返回的表單中插入一個用戶不可見的token隱藏字段,這個字段對應的值是根據(jù)一定的算法生成的.用戶在填寫好表單后提交頁面請求B,請求B中就會攜帶該token值.而當請求再次發(fā)生時,就會對請求中的數(shù)據(jù)進行檢查,查看是否有該token值并且是否和之前發(fā)送給用戶的token值一致,正常的合法請求是一致的,但是CSRF攻擊則不然,由于其沒有登錄A頁面,因此直接對B頁面的請求中肯定沒有token,這樣Web系統(tǒng)就可以判斷為CSRF攻擊.

如果惡意攻擊者通過客戶端抓包獲取到了token,或者通過其他方式從受害者處獲取到了token,也不能繞過服務器的檢測.首先這個token是根據(jù)一定的算法生成的,影響它的因素有源IP、時間等,所以即使獲取了受害者的token并加入到請求參數(shù)中,由于源IP、時間等不一致,Web系統(tǒng)同樣能夠識別是否為CSRF 攻擊.但這種保存token的方法是建立在cookie不會被攻擊者截獲的前提下的.如果Web系統(tǒng)同時存在XSS漏洞,那么攻擊者可以通過XSS來獲取cookie,CSRF防護也會失效.

Token實現(xiàn)的CSRF防護原理圖見圖4.

圖4 Token防護原理圖

5 CSRF防御開發(fā)建議

(1)對Web應用中的身份標識信息cookie,要盡可能地縮短驗證時間,減少cookie暴露的風險.

(2)CSRF之所以能夠成功,究其原因是重要業(yè)務過程中的參數(shù)可以被攻擊者猜測到,所以建議開發(fā)人員重點梳理重要業(yè)務中的參數(shù),并對其進行加密或者隨機化處理,從而讓攻擊者無法猜測到真實的參數(shù)值.簡而言之,通過“不可預測性原則”保護Web系統(tǒng).

(3)相對于GET 提交表單方式,雖然POST 也存在安全威脅,但POST 提交方式更隱蔽,更安全,建議提交表單業(yè)務采用POST 方式.

(4)在使用過程中,要注意token的保密性,防止token被XSS漏洞泄露,盡量把token寫入表單中而不是放在URL中,避免通過referer的方式被竊取.