王應(yīng)軍,傅建明,姜百合

(武漢大學(xué) 計算機學(xué)院,武漢 430072)

0 概述

跨站請求偽造(Cross-site Request Forgery,CSRF)攻擊就是攻擊者通過一些技術(shù)手段欺騙用戶的瀏覽器去訪問一個自己曾經(jīng)認(rèn)證過的網(wǎng)站并執(zhí)行一些操作(如發(fā)郵件、發(fā)消息、加好友、甚至是財產(chǎn)操作)。由于瀏覽器曾經(jīng)認(rèn)證過,因此被訪問的網(wǎng)站會認(rèn)為是真正用戶的操作而去執(zhí)行,實際上是執(zhí)行攻擊者構(gòu)造的操作。

隨著互聯(lián)網(wǎng)、云計算、移動計算的高速發(fā)展,網(wǎng)站提供的功能越來越豐富,用戶能夠進(jìn)行的操作也越來越多,從而也存在更多潛在的CSRF攻擊。根據(jù)OWASP[1]發(fā)布的Web應(yīng)用十大安全隱患報告,CSRF排名前八位。2007年,谷歌Gmail遭受了嚴(yán)重的CSRF攻擊[2],攻擊者通過在惡意網(wǎng)站上偽造對受害者Gmail中郵件的轉(zhuǎn)發(fā)請求鏈接,使得成千上萬用戶的郵件遭到泄露。新浪某社區(qū)因存在CSRF漏洞,誘騙用戶點擊可造成蠕蟲[3]。Facebook和Dropbox在聯(lián)合使用過程中,因為auth使用不當(dāng),導(dǎo)致利用CSRF攻擊可以上傳任意文件到Facebook[4]。據(jù)不完全統(tǒng)計,截止2016年5月,在烏云漏洞平臺[5]上提交的CSRF漏洞數(shù)累計有330多個,說明CSRF漏洞廣泛存在。

目前主流防御CSRF的思路包括驗證請求來源與防止請求重放。驗證請求來源如驗證用戶提交請求的referer,但referer是由客戶端發(fā)送可以被偽造從而產(chǎn)生漏報。防止請求重放的常見方法包括在Form表單中增加Token或者在執(zhí)行敏感操作時需要用戶輸入驗證碼,但要求用戶輸入驗證碼時會影響用戶體驗?；赥oken的防御方法也能夠利用postMessage、JSONP的方法,獲取Token進(jìn)而執(zhí)行CSRF攻擊[6]。以上的防御方法存在著用戶體驗差、兼容性差、防御方法易被繞過、Token泄漏導(dǎo)致CSRF攻擊等多種問題,不能在實際應(yīng)用中有效地防御CSRF攻擊。

為此,本文提出一種基于URL地址請求參數(shù)名隨機化的CSRF防御方案。通過對請求參數(shù)名進(jìn)行隨機化,使其不可預(yù)測從而使攻擊者無法進(jìn)行重放。服務(wù)端接受瀏覽器請求后對請求參數(shù)名進(jìn)行驗證來判斷請求是否合法。隨機化的密鑰在每次建立會話時產(chǎn)生,攻擊者無法預(yù)知。被隨機化的參數(shù)也是在服務(wù)器端隨機化之后發(fā)送到瀏覽器,攻擊者無法獲知隨機化的請求參數(shù)名。所以,基于參數(shù)名的隨機化的CSRF防御方案本身不會泄露隨機化參數(shù)的信息,同時隨機化的操作是在服務(wù)器端完成,在保障用戶體驗的同時防御CSRF攻擊。

1 CSRF防御相關(guān)研究

CSRF防御方法根據(jù)CSRF檢測位置的不同可以分為服務(wù)端防御、客戶端防御?？蛻舳朔烙鶄?cè)重于跨域請求的審查;服務(wù)端防御側(cè)重于防止請求重放。

服務(wù)端常用的防御方法就是采用基于驗證碼的防御方法、基于referer的驗證防御方法與Token的防御方法。

基于驗證碼的防御方案是在關(guān)鍵位置要求用戶輸入驗證碼。但是由于輸入驗證碼的用戶體驗較差,目前這種方案沒有廣泛使用?；趓eferer的防御思路是服務(wù)器端驗證請求的referer。但是由于用戶的隱私設(shè)置或者是網(wǎng)絡(luò)傳輸?shù)膯栴},服務(wù)器最終不一定能得到referer,因此基于referer的防御方法存在漏報、誤報的問題,也沒有被廣泛采用。

基于Token的防御方法[7]的思路是在需要進(jìn)行敏感、重要操作時,在對應(yīng)的Form表單的地方添加Token,Token一般是一個隨機數(shù)。當(dāng)用戶通過表單提交請求時,這個Token也會一并提交上去。在正常訪問時,客戶端瀏覽器能夠正確得到這個Token。但是在CSRF攻擊中,攻擊者無法事先知道這個Token,從而能夠防御CSRF攻擊。目前這種防御方法,如Django、Ruby on Rails、ThinkPHP被廣泛地采用。但是這種防御方法也存在缺陷:1)如果對Cookie處理不當(dāng),則導(dǎo)致CSRF的防御方法可以被繞過[8];2)Web應(yīng)用與第三方進(jìn)行跨域交互時可能會泄露Token,如利用JSONP、postMessage可以獲取到Token[9]。

客戶端的防御方法一般都是在瀏覽器端識別出CSRF攻擊,阻斷CSRF的請求或者剝離所有的認(rèn)證信息。鑒于服務(wù)器的防護方法需要修改服務(wù)器端的代碼,很多的學(xué)者都是研究基于客戶端的防御方法。CsFire[10]是一款基于Firefox的插件,CSFire對跨域的2個網(wǎng)站的相關(guān)性進(jìn)行判斷以此界定是否為CSRF攻擊。CsFire如果發(fā)現(xiàn)跨域的2個網(wǎng)站之前存在交互,則認(rèn)為此請求合法,否則認(rèn)為是CSRF攻擊。但是此工具在面對Flicker、Yahoo等第三方登錄的情形時會存在很大的誤報。BEAP[11]則是通過判斷當(dāng)前用戶發(fā)起的請求是否是基于用戶意圖以此來防御CSRF攻擊的一款瀏覽器插件。BEAP通過監(jiān)控用戶網(wǎng)頁行為以此判斷當(dāng)前點擊是否是基于用戶的意圖點擊。例如如果用戶在地址欄輸入URL地址,則認(rèn)為是基于用戶的本意訪問;如果用戶點擊郵件中的鏈接,則認(rèn)為是CSRF攻擊,從而阻止該請求。BEAP這種方式存在很大的誤報,目前很多網(wǎng)站注冊都需要用戶點擊郵件中的注冊鏈接進(jìn)行確認(rèn),BEAP對這類行為都會產(chǎn)生誤報。文獻(xiàn)[12]提出的同源信用應(yīng)用協(xié)議以Web站點的信用度為指標(biāo),計算訪問請求地址的信用來決定該地址是否可達(dá),防止從跨域名網(wǎng)站引入惡意資源。但是該方法還是通過插件的方式加以實現(xiàn)的,導(dǎo)致協(xié)議還是可以被攻擊者破解從而繞過。

從研究者們的研究成果以及實際應(yīng)用可以看出,基于客戶端的防御存在兼容性、用戶體驗差、漏報、誤報以及易被繞過等不同程度的問題。基于服務(wù)器端的防御才能夠有效地防御CSRF攻擊,但是基于referer的防御方法由于referer容易被偽造從而繞過檢測。驗證碼雖然能夠有效地防御CSRF攻擊,但是用戶體驗差。所以,目前最常用的防御方法是基于Token的防御方法,但是Token也存在著Token泄露的問題。

本文提出基于隨機化的參數(shù)名跨站請求偽造的防御方法,將攻擊者可偽造的請求參數(shù)名作為隨機化對象,使其具有隨機性和不可預(yù)測性,以此防御CSRF攻擊。隨機化技術(shù)是一種新型的保護系統(tǒng)免受攻擊的通用方法,可以有效地打破同構(gòu)和穩(wěn)定性的環(huán)境,以異構(gòu)和隨機的環(huán)境來應(yīng)對未知的攻擊。

目前也有很多的學(xué)者研究如何將隨機化的技術(shù)應(yīng)用在Web安全防御中。文獻(xiàn)[13-14]均提出通過指令集隨機化的方法防御SQL 注入攻擊,其主要思想就是對SQL語句中的關(guān)鍵字后添加隨機數(shù),之后對組裝的SQL語句進(jìn)行驗證。但是由于實現(xiàn)難度較高,最后采用的是通過代理服務(wù)器的方式實現(xiàn)的。由于代理服務(wù)器需要對HTML解析和分析,因此這種方式的兼容性、開銷都存在問題。文獻(xiàn)[15]提出基于指令隨機化的XSS的檢測方法,通過HTML/JavaScript關(guān)鍵字會在末尾追加隨機生成的字符串,攻擊者無法預(yù)測,由于這種方式實現(xiàn)復(fù)雜同樣采用的是代理的方式,因此也會存在兼容性差、開銷大的問題。文獻(xiàn)[16]提出網(wǎng)頁標(biāo)記隨機化對抗XSS 攻擊,鑒于通過代理的方式實現(xiàn)隨機化的效果較差,該方法主要是在PHP平臺上實現(xiàn)。在服務(wù)器通過修改Smarty的代碼來對HTML的標(biāo)簽進(jìn)行標(biāo)記,在客戶端通過代理的方式對標(biāo)記的標(biāo)簽進(jìn)行驗證,雖然具有很好的效果,但是僅適用于使用了Smarty的PHP代碼。

鑒于目前隨機化的方法在Web安全方面開始逐步應(yīng)用,但是針對CSRF的防御卻并沒有使用隨機化的方法,同時之前研究者們提出的針對CSRF的防御方法均存在不同程度的問題,本文提出了基于參數(shù)名的隨機化防御方法,不同于通過代理的方式進(jìn)行隨機化和去隨機化,本文主要是基于源代碼的分析,提供一種通用的CSRF防御思路并且在PHP開源程序上加以驗證。

2 CSRF隨機化防御方法

本節(jié)首先分析CSRF攻擊的原理,然后提出一種基于請求參數(shù)名隨機化的CSRF防御方法,最后說明基于隨機化防御方法的PHP代碼的實現(xiàn)。

2.1 威脅模型

CSRF利用網(wǎng)站對用戶網(wǎng)頁瀏覽器的信任,欺騙用戶的瀏覽器去執(zhí)行非本意的操作。CSRF攻擊的原理如圖1所示。

圖1 CSRF攻擊原理

當(dāng)網(wǎng)站A收到了用戶瀏覽器發(fā)送的轉(zhuǎn)賬請求R時,由于瀏覽器攜帶了用戶的Cookie,網(wǎng)站A認(rèn)為請求R是由用戶發(fā)送的就會按照用戶的權(quán)限處理步驟5的請求,這樣網(wǎng)站B就達(dá)到了模擬用戶操作的目的,成功地實施CSRF攻擊。CSRF能夠成功實施的一個重要的原因是在于所有的用戶在登錄網(wǎng)站A時看到的網(wǎng)頁結(jié)構(gòu)與參數(shù)名都是一樣的,攻擊者很容易構(gòu)造出一個與普通用戶一樣的操作的請求。

目前主要的HTTP請求方法是GET和POST。從數(shù)據(jù)表現(xiàn)形式上來看,GET請求方法的請求數(shù)據(jù)顯式地嵌入在URL中;而POST請求方法的請求數(shù)據(jù)隱式地嵌入在HTML表單中,提交表單時用戶無法看到提交的內(nèi)容。但是無論是通過什么方式提交數(shù)據(jù),提交的字段名對于所有的用戶都是不變的。對于用戶來說,假設(shè)轉(zhuǎn)賬請求的字段名為fromaccount、toaccount、money。攻擊者看到轉(zhuǎn)賬請求的字段名同樣是fromaccount、toaccount、money。這種靜態(tài)的可預(yù)測的參數(shù)名,使得所有的用戶發(fā)送請求時的參數(shù)名都一樣,因而攻擊者能夠偽造出“合法”的惡意請求實施CSRF攻擊。這種CSRF攻擊方法本質(zhì)上就是一種重放攻擊。

2.2 請求參數(shù)名隨機化

根據(jù)2.1節(jié)中對CSRF攻擊原理的分析發(fā)現(xiàn),阻止請求重放就能夠有效地防御CSRF攻擊。通過Token的方式來防御CSRF的防御方法利用的就是阻止攻擊者重放的思想。本文提出的基于請求參數(shù)名隨機化的防御方法,將傳統(tǒng)的靜態(tài)可預(yù)測的請求參數(shù)名作為隨機化為不可預(yù)測的字符串以防御CSRF攻擊,本質(zhì)上也是一種阻止攻擊者請求重放的方法,但是比Token方法能夠更有效地防御CSRF攻擊。

在隨機化算法的選擇方面,考慮到需要對參數(shù)進(jìn)行加密和解密,還要保證在用戶訪問的時候參數(shù)名稱不同,綜合考慮采用的是對稱性加密算法,將加密密鑰保存在SESSION中。為了保證用戶在每次與網(wǎng)站建立會話時的加密密鑰都是不同的,密鑰的生成及用戶與服務(wù)建立會話的時間相關(guān),同時采用摘要算法生成密鑰。這樣就保證了同一用戶在不同時刻以及不同用戶在同一時刻訪問網(wǎng)站所得到的網(wǎng)站的參數(shù)名都是不同的,攻擊者無法猜測到用戶的隨機化的參數(shù)名,也無法獲知密鑰,保證了CSRF攻擊難以實施。整個隨機化防御原理如圖2所示。

當(dāng)用戶向服務(wù)器發(fā)送請求之后,服務(wù)端如果判斷用戶不是第一次訪問,則直接返回已經(jīng)隨機化后的頁面。如果用戶是第一次訪問,則創(chuàng)建隨機化密鑰,同時對訪問頁面中的參數(shù)進(jìn)行隨機化處理,返回隨機化之后的頁面給用戶。用戶在頁面中填寫完畢發(fā)送至服務(wù)器之后,服務(wù)器對隨機化的參數(shù)進(jìn)行還原。如果服務(wù)器能夠還原成為原來的參數(shù),則正常響應(yīng)用戶的請求;否則,服務(wù)器判定為CSRF攻擊,拒絕響應(yīng)。

2.3 隨機化方案實現(xiàn)

為了方便開發(fā)者部署本文的方案,本文實現(xiàn)一個PHP的第三方庫CSRFP[17],用于實現(xiàn)生成隨機化密鑰、參數(shù)名隨機化以及對已經(jīng)隨機化的參數(shù)名還原。通過對國內(nèi)外常見的PHP開源程序(wordpress、joomla、drupal、discuz、phpcms、dedecms、74cms)的分析,發(fā)現(xiàn)這些程序都會引入公共文件,如config.php、common.php、functions.php等。這些文件一般都是集合了程序常使用的功能,如格式化字符串、頁面輸出,同時也用于對GET、POST參數(shù)過濾,以防止XSS、SQL注入攻擊。在這些公共文件中引入CSFRP庫就可以在整個程序中對參數(shù)進(jìn)行隨機化和對隨機化的參數(shù)名還原。開發(fā)者可以自行選擇需要進(jìn)行隨機化防御的位置。開發(fā)者通過引入CSRFP庫,不需要修改原來程序的邏輯和代碼就能夠很容易實現(xiàn)對網(wǎng)站的加固。

考慮到目前CSRF攻擊主要是POST型的攻擊。所以,在實驗過程中只對表單中的參數(shù)名進(jìn)行隨機化。

對參數(shù)名進(jìn)行隨機化的示例代碼如下:

name="">

通過在公共文件類似common.php中引入CSRFP庫,就能夠完成對隨機化的參數(shù)名進(jìn)行還原,代碼如下:

foreach ($_POST as $random_name=> $value) {

$name=CSRFP::decrypt($random_name);

$_POST[$name]=$_POST[$random_name];}

通過解密還原的代碼可以看出,主要就是對$_POST中的已經(jīng)隨機化的random_name進(jìn)行解密還原為name。如果隨機化的random_name是被攻擊者篡改或者是由攻擊者創(chuàng)建的,那么在進(jìn)行解密為name時無法正確還原,之后的處理流程就會失敗,從而丟棄這次請求,保護網(wǎng)站不會受到CSRF攻擊。CSRF隨機化防御流程如圖3所示。

圖3 隨機化防御流程

對比2.1節(jié)CSRF的攻擊原理,當(dāng)使用了隨機化參數(shù)名的CSRF防御方法之后,參數(shù)名稱完全是隨機的字符串(步驟2)。當(dāng)攻擊者發(fā)起CSRF攻擊時,攻擊者無法知道新的參數(shù)名而是按照之前的參數(shù)名發(fā)起攻擊(步驟4)。當(dāng)服務(wù)器端收到這些參數(shù)名進(jìn)行校驗時,檢驗失敗,從而判定為不是正常請求,拒絕響應(yīng)(步驟5和步驟6)。通過這種方法可以有效地防御CSRF攻擊。

3 實驗與結(jié)果分析

本節(jié)對基于隨機化參數(shù)名CSRF防御方法的有效性和性能進(jìn)行測試以及安全性分析,同時與目前主流的基于Token的CSRF防御方法進(jìn)行對比分析。實驗分析方法是通過在本地搭建Apache、MySQL、PHP的網(wǎng)站運行環(huán)境,應(yīng)用隨機化的防御方案加固存在CSRF漏洞的PHP開源程序,檢測有效性;通過記錄應(yīng)用隨機化的防御方案之后的訪問時間來分析性能。

3.1 有效性測試

在有效性方面,實驗選取了國內(nèi)外存在CSRF漏洞的開源PHP程序進(jìn)行部署和實驗分析。根據(jù)Czeskis[18]所進(jìn)行的實驗方法,選取國外的PHP開源程序是Selectapix、UseBB、PHPDug、PoMMo。國內(nèi)的PHP開源程序選擇的是PHPCMS、EmpireCMS、FineCMS和蟬知CMS。所選取的PHP開源程序都存在CSRF漏洞。同時還與目前主流的CSRF防御方法——基于Token的防御方法進(jìn)行了對比實驗。實驗結(jié)果如表1所示,其中,√為可以被防御,—為無法防御。

表1 隨機化防御實驗結(jié)果

從實驗結(jié)果可以發(fā)現(xiàn),采用基于隨機化的防御方法比基于Token的防御方法更有效。例如PHPCMS的CSRF攻擊使用Token無法防御,但是使用基于隨機化的方法可以被防御。PHPCMS的CSRF漏洞出現(xiàn)添加友情鏈接的地方,默認(rèn)情況下會在添加鏈接后面加上Token,第三方鏈接就能夠得到Token,造成了Token的泄露。當(dāng)管理員審核此鏈接時,就會執(zhí)行CSRF攻擊。

如果采用隨機化的防御方法,不會在任何地方添加Token,那么就不存在泄露的問題,所以,能夠防御CSRF攻擊。而FineCMS的CSRF攻擊,2種防御方法均無法防御,原因在于FineCMS是通過XSS的方法得到了Token,從而執(zhí)行CSRF攻擊。無論是采用Token還是隨機化的防御方法,都可以通過XSS的方法得到相關(guān)參數(shù)名和參數(shù)值,所以無法防御。

綜合實驗結(jié)果可以看出,基于參數(shù)名的隨機化方案比基于Token的防御方法能夠更加有效地防御CSRF攻擊。

3.2 性能測試

在隨機化的方法中,需要生成隨機化密鑰并對參數(shù)進(jìn)行加密。所以,性能測試包括不同的對稱性加密算法與不同摘要算法的性能差異、基于Token的防御方法的性能差異、隨機化的input數(shù)量對性能的影響。

實驗方法是用PHP編寫一個常見的用戶注冊頁面,此頁面中包含了一個注冊的Form表單,通過增加Form表單中的input數(shù)量來測試input數(shù)量對防御方法的性能的影響。性能測試的方法采用的是文獻(xiàn)[19]的分析方法,性能測試的數(shù)據(jù)是基于頁面所加載的時間,頁面加載的時間是以Chrome Dev Tools Load的時間作為訪問時間,連續(xù)訪問10次獲取平均值作為最終的訪問時間。圖4是性能測試的實驗結(jié)果。

圖4 隨機化防御性能測試結(jié)果

圖4橫坐標(biāo)標(biāo)識的是Form表單中的input數(shù)量,縱坐標(biāo)標(biāo)識頁面加載的時間,每一條曲線表示不同的摘要算法和對稱性加密算法組合一起的隨機化算法。曲線Token表示的是在Form表單中增加一個隱藏的Token,頁面曲線表示只有Form表單(以下均稱為頁面曲線)。

從圖4可以看出,不同的摘要算法和對稱性算法組合在一起的隨機化算法之前沒有很大的差別,但是隨著Form表單中的input數(shù)量變多,算法的耗時增加?；赥oken的防御方法的耗時保持不變。雖然如此,但是基于隨機化參數(shù)名防御方法的耗時與基于Token的防御方法耗時相差不大,最大差距為15 ms,與頁面曲線的差距為25 ms,最大差距為40 ms,不影響用戶的體驗。在空間消耗方面,基于Token的防御方法和基于隨機化參數(shù)名的方法的空間消耗是一樣的,對于每一個用戶,只需要保存32位的字符串即可。對于Token來說,保存的是Form表單中的Token域的值,對于基于隨機化參數(shù)名的方法來說,保存的是隨機化的密鑰,兩者的長度都是32位。所以,2種方法在空間損耗上面沒有差異性。

在性能損耗方面,可以發(fā)現(xiàn)當(dāng)只有2個input標(biāo)簽時,基于隨機化算法的耗時與基于Token的防御方法耗時相當(dāng)。所以,當(dāng)Form中的input數(shù)量較多時,開發(fā)者可以有選擇性地只對其中的幾個input標(biāo)簽進(jìn)行隨機化,在保證隨機化方法的有效性的同時還可以確保性能開銷較小。

3.3 安全性分析

安全性分析主要包括2個方面,即防御方法本身的安全性以及程序使用了防御方法之后的安全性。

對于防御方法本身的安全性分析的前提在于,攻擊者只能發(fā)起CSRF攻擊而無法通過其他的攻擊方法使隨機化的防御方法失效,比如通過SQL注入、文件讀取的方式獲得網(wǎng)站的源代碼從而繞過CSRF的驗證。如果攻擊者需要繞過防御方法就必須要知道隨機化密鑰和隨機化的加密算法。密鑰的生成在每一次用戶與網(wǎng)站建立會話時都不一樣,與當(dāng)前服務(wù)器端的時間相關(guān),所以攻擊者無法猜解出密鑰的,同時密鑰是保存在SESSION中的,攻擊者無法通過任何的攻擊手段得到SESSION中的值,從而保證了隨機化密鑰的安全性。至于隨機化加密算法的安全性,由于加密算法是保存在服務(wù)器端,除非攻擊者能夠得到網(wǎng)站的源代碼,在一般情況下攻擊者是無法得到源代碼的,因此加密算法也是比較安全的。

本文對比使用了防御方案前后的請求流程,隨機化防御分析如圖5所示。

圖5 隨機化防御分析對比

在圖5中,虛線標(biāo)識的是使用隨機化防御之后在整個流程中發(fā)生變化的地方,包括頁面的隨機化和后臺的驗證操作。其中在客戶端的改變是頁面中的參數(shù)的變化,由原來的具有含義的參數(shù)變?yōu)榱藷o意義的字符串。從前臺頁面中分析,對攻擊者來說,頁面中的參數(shù)名發(fā)生改變,并沒有增加新的輸入和輸出以及功能方面的問題,因此雖然參數(shù)名發(fā)生了變化,但是并沒有增加新的攻擊點。后臺服務(wù)器端程序的改變在于隨機化密鑰的生成和保存、隨機化參數(shù)名以及參數(shù)驗證。密鑰的生成是由算法完成,密鑰的保存是保存在程序中的SESSION,SESSION是保存在服務(wù)器端的鍵值對,密鑰的生成和存儲對程序的整個功能不會有影響。其次是對Form表單中的參數(shù)進(jìn)行隨機化,通過對參數(shù)名進(jìn)行隨機化的加密操作,不會加入新的輸入輸出和新功能,只會改變頁面中的參數(shù)名,因此不會引入新的問題。最后是對參數(shù)名的驗證,通過圖5的流程發(fā)現(xiàn),對參數(shù)名的檢驗是在服務(wù)器處理之前,這種處理方式在目前的Web開發(fā)中十分常見,類似Java中的Filter、PHP中的include common.php。如果驗證通過,再由后面后臺服務(wù)器的程序進(jìn)行處理。所以,對參數(shù)名的檢驗并不會影響整個程序的功能,只是多增加了對參數(shù)名的檢驗和過濾。

因此通過綜合分析,當(dāng)程序應(yīng)用了隨機化的防御方案之后,除了在SESSION中保存隨機化的密鑰,并沒有在程序中引用新的變量、新的輸入和輸出,隨機化的參數(shù)檢驗不會對程序的整個流程造成影響,這種防御部署方式也是目前Web開發(fā)中常用的防御部署方式。

4 結(jié)束語

針對目前流行的CSRF攻擊,本文提出一種參數(shù)名隨機化CSRF防御方法。該隨機化方法部署在Web服務(wù)端,開發(fā)者應(yīng)用本文開發(fā)的PHP開源庫,自行選擇需要隨機化的參數(shù)名,利用請求和響應(yīng)中隨機化參數(shù)名的一致性識別偽造請求,從而檢測CSRF攻擊。與已有基于客戶端的防御方法相比,隨機化方法的漏報和誤報較低。與已有服務(wù)端的Token策略相比,不存在因為JSONP和postMessage的方法使得Token泄露而導(dǎo)致CSRF攻擊的情況。實驗結(jié)果表明,CSRF隨機化防御方案比基于Token的方法能夠更加有效地防御CSRF攻擊,同時不影響用戶體驗。隨著其不斷應(yīng)用,該方案會得到不斷的完善。

為了能夠更加方便地應(yīng)用基于參數(shù)名隨機化CSRF的防御方法,下一步在Web服務(wù)器如apache、nginx上以插件的形式進(jìn)行參數(shù)名隨機化,以在不修改程序代碼的情況下完成參數(shù)名隨機化的防護工作,同時解決性能開銷的問題。