李立, 原建偉

(陜西工業(yè)職業(yè)技術(shù)學(xué)院 信息工程學(xué)院， 陜西 咸陽 712000)

0 引言

HTML5J技術(shù)作為Web平臺標(biāo)準(zhǔn)，基于HTML5的Web急劇增加，在豐富了Web應(yīng)用的同時，導(dǎo)致網(wǎng)絡(luò)攻擊量增大，安全性下降[1]。相較于XSS方式，CSRF(Cross-Site Request Forgey,跨站請求偽造)攻擊流程程度低，對應(yīng)的防御資源和措施相對較少，導(dǎo)致CSRF攻擊難以防范，造成很大的危害[2]。目前針對CSRF攻擊的防御進(jìn)行了多角度研究[3]，如利用Rational AppScan工具和檢測技術(shù)實現(xiàn)對CSRF漏洞的檢測，并提出基于CSRF攻擊的防御手段[4]；通過添在地址中加入token[5]，對HTTP頭添加自定義屬性來實現(xiàn)對CSRF攻擊的有效防御。

本文在相關(guān)研究的基礎(chǔ)上，通過建立Web服務(wù)器和HTML5環(huán)境來驗證HTML5受到CSRF攻擊全過程，并提出相應(yīng)的CSRF漏洞檢測和防御方式。

1 HTML5的CSRF攻擊驗證

1.1 HTML5的CSRF 攻擊原理

HTML5是互聯(lián)網(wǎng)應(yīng)用領(lǐng)域的一種應(yīng)用技術(shù)，其中涵蓋了各種API函數(shù)，通過完善的CSS3使得Web前端更加活躍?；贖TML5的應(yīng)用程序能夠在任何瀏覽器上運行，但也帶來了針對該程序的攻擊方式。當(dāng)?shù)卿汬TML5站點時，要求進(jìn)行身份驗證。通常，Web通過Cookie方式記錄用戶認(rèn)證信息，當(dāng)用戶重復(fù)登錄該Web時，瀏覽器將攜帶了該用戶先前的認(rèn)證信息放入HTTP頭部并一同發(fā)送至服務(wù)器，避免了二次認(rèn)證。而用戶認(rèn)證信息一旦被惡意控制，則攻擊者往往利用認(rèn)證執(zhí)行惡意操作，從而受到CSRF攻擊，CSRF攻擊程序圖如圖1所示。

圖1 CSRF攻擊基本原理圖

當(dāng)用戶需認(rèn)證可信任的Web時，用戶通過瀏覽器向Web站點A發(fā)送請求，服務(wù)器接收請求并認(rèn)證用戶合法性，如果是，則將包含用戶認(rèn)證信息的Cookie發(fā)送至瀏覽器，完成身份認(rèn)證。服務(wù)器收到會話請求，添加為可信任站點，當(dāng)瀏覽器向站點A發(fā)送請求，經(jīng)確認(rèn)發(fā)現(xiàn)已通過用戶的認(rèn)證請求，則執(zhí)行動作。攻擊者獲得可信站點信息后，在站點B構(gòu)建頁面，讓用戶在站點B執(zhí)行操作，攻擊者代碼讓用戶執(zhí)行一些惡意操作，瀏覽器接收到Cookie信息協(xié)同惡意攻擊代碼發(fā)送至站點B，即完成了一次CSRF攻擊。

1.2 HTML5的CSRF攻擊驗證

在HTML5的Web完成一次CSRF攻擊時，攻擊者往往偽造特定路徑通過程序?qū)崿F(xiàn)攻擊，其中包括同源策略、跨域資源共享的安全策略、Cookies機制的P3P頭機制等。同源策略作為最基本單圈策略，是采用動態(tài)腳本對相同的協(xié)議、端口的HTTP應(yīng)答；跨域資源共享的安全策略為程序開發(fā)提供跨域請求許可，通過服務(wù)器和瀏覽器相互協(xié)商進(jìn)行判定，同時支持HTTP請求。Cookie安全策略是用戶輸入一次認(rèn)證信息后，服務(wù)器記錄用戶認(rèn)證信息和HTTP狀態(tài)信息，生成Cookie，并保存在瀏覽器中，當(dāng)用戶再次登錄時，只需在HTTP請求頭部帶上Cookie一并發(fā)送服務(wù)器完成用戶認(rèn)證。P3P策略是基于用戶隱私角度指定的相關(guān)標(biāo)準(zhǔn)，標(biāo)識目標(biāo)網(wǎng)站Cookie能否被其他域加載。

從上述分析可以看出，同源策略限制了來自不同域的訪問請求，但并未限制不同域的用戶通過GET或POST方向Web站點提交信息。在HTML5中，一些標(biāo)簽均帶有“src”屬性標(biāo)簽，僅能發(fā)送GET請求，而對于多數(shù)Web應(yīng)用程序來講，多數(shù)開發(fā)者并未嚴(yán)格區(qū)分POST請求和GET請求，在數(shù)據(jù)提交過程中也并未按照POST方式提交。因此，攻擊者可用GET請求表單提交地址進(jìn)行CSRF攻擊。

以一個模擬隱患網(wǎng)站Back為例，采用MySQL 5.5搭建PHP服務(wù)器，建立轉(zhuǎn)賬功能頁面www.Back.com/transfer.html。假設(shè)采用GET方式提交轉(zhuǎn)賬信息，通過URL：http://www.Bank.com/Transfer.php?AccountId=11&number=1000將轉(zhuǎn)賬請求提交給服務(wù)器。當(dāng)攻擊者掌握相關(guān)參數(shù)時通過偽造相同的URL并放入攻擊網(wǎng)站的頁面Attck_GET.html中等待用戶執(zhí)行。攻擊者利用社交手段將攻擊頁面Attck_GET.html的URL發(fā)送給攻擊者，執(zhí)行攻擊頁面。攻擊者構(gòu)造的頁面Attck_GET.html代碼，如圖2所示。

圖2 頁面 Attck_GET.html 的代碼

圖3 GET 完成的 CSRF 攻擊

在HTML5中，CORS機制下的XML HttpRequst請求通過跨域XHR-2API完成，HTTP向服務(wù)器發(fā)送的請求源信息被包含在生成的Origin頭部中，因而不需要對現(xiàn)有的瀏覽器保護(hù)程序修改。由瀏覽器發(fā)起對XMLHttpRquest請求檢驗是否符合COSR安全規(guī)范用來保護(hù)合法性。然而當(dāng)重新定義XHR-2對象時，將對象的setRequestHeander設(shè)置為“ Content-type ”，設(shè)置屬性“WithCredentials”值為“ture”，瀏覽器的預(yù)檢機制處于待機狀態(tài)，此時Cookie重播，發(fā)生CSRF攻擊。

如在一個論壇站點 www.discuss.com，注冊用戶可通過 www.discuss.com/post.php發(fā)帖，具體內(nèi)容保存在后臺數(shù)據(jù)庫，當(dāng)Bob用戶登錄時，服務(wù)器將攜帶的登錄信息發(fā)送至瀏覽器，允許發(fā)帖。Bob發(fā)帖后，將內(nèi)容存儲在后臺名為CSRF數(shù)據(jù)庫的Postmessage數(shù)據(jù)表，并設(shè)計一個check.php頁面來查看數(shù)據(jù)庫增加的內(nèi)容。用戶登錄后，利用頁面show.php查看發(fā)帖內(nèi)容，并可刪除帖子。

當(dāng)攻擊者掌握頁面相關(guān)參數(shù)后，在www.csrf.com構(gòu)造 attack_del.html頁面，利用一個XHR-2對象將域www.discuss.com 上用戶Bob帖子刪除。即通過XHR-2對象http跨域向頁面show.php發(fā)出請求。當(dāng)attack_del.html頁面發(fā)出跨域請求時，瀏覽器將Cookie信息加載到HTTP請求頭部并向服務(wù)器發(fā)送請求，服務(wù)器鑒別合法用戶發(fā)送的請求，執(zhí)行刪貼操作。attack_del.html頁面代碼，如圖4所示。

圖4 頁面 attck_del.html 的代碼

2 HTML5 的 CSRF 攻擊的檢測與防御

2.1 HTML5的CSRF攻擊檢測

由于CSRF攻擊流程程度較低，因而Web程序員容易忽視CSRF的安全問題。本節(jié)從CSRF漏洞檢測入手，采用自動和手動方式進(jìn)行CSRF攻擊的檢測。

AppScan作為目前流行的網(wǎng)絡(luò)安全檢測工具，能從代碼和產(chǎn)品方面進(jìn)行安全檢測。采用Rational AppScan測試時，通過向被檢測地址發(fā)送兩次請求。第一次請求后退出登錄，第二次請求時，若沒有CSRF漏洞或進(jìn)行了CSRF漏洞防范，由于AppScan檢測是在兩個不同的Session中對目標(biāo)資源的操作，因此兩次請求返回結(jié)果不同。Rational AppScan工作示意圖，如圖5所示。

圖5 Rational AppScan工作示意圖

實際上，由于一個Web中存在大量URL，因此，首先采用Rational AppScan進(jìn)行全路徑覆蓋檢測，保證路徑測試能夠覆蓋Web應(yīng)用的每一個路徑。同時利用手動檢測CSRF漏洞，對一些靜態(tài)資源有DELETE/PUT操作下進(jìn)行測試，針對GET請求來刪除數(shù)據(jù)庫記錄情況下，在維持一個服務(wù)器連接下，輸入瀏覽器地址，當(dāng)ID號為“0”時頁面被刪除，CSRF進(jìn)行攻擊，表明URL沒有任何CSRF保護(hù)。

2.2 基于 HTML5 的 CSRF 的防御

2.2.1 驗證碼驗證

當(dāng)用戶與服務(wù)器信息交互時，要求用戶同時填寫隨機字符串驗證碼，并對其檢測[13]。CSRF往往在用戶不知情下強制讓用戶與應(yīng)用執(zhí)行交互操作，因而由攻擊者偽造的請求能被用戶發(fā)現(xiàn)，有效避開了CSRF的攻擊，根據(jù)代碼生成的驗證碼代碼如圖6所示。

圖6 驗證碼預(yù)防CSRF攻擊

驗證碼驗證方法使得用戶和應(yīng)用間頻繁交互，降低了用戶體驗度。同時，由于驗證圖片使用中存在類似的MHTML缺陷，對一些版本IE功能造成影響，因此，驗證碼進(jìn)行預(yù)防CSRF攻擊中更多的是作為一種輔助手段。

2.2.2 驗證HTTP Referer字段

當(dāng)用戶訪問一個受限制地址時，需要登錄該網(wǎng)站才能瀏覽該網(wǎng)址資源，通常一個請求的Referer值為受限制資源的URL，但攻擊者通過CSRF攻擊時，發(fā)起請求的Referer為本身的URL，因此，可通過驗證Referer值抵御CSRF攻擊。瀏覽器域名中采用discuss.com的Referer值開頭作為合法請求，則跟進(jìn)響應(yīng)，否則拒絕請求，防止外部鏈接請求的代碼如圖7所示。

圖7 驗證HTTP Referer字段攻擊

圖中函數(shù)strncnmp()檢測訪問頁面與設(shè)定頁面Referer是否一致，若一致，則該請求為合法頁面發(fā)出的請求，受理POST請求，可執(zhí)行訪問和刪除操作，否則為不合法請求，直接清除該POST請求。

2.2.3 請求中添加token

攻擊者發(fā)送CSRF攻擊時，通過猜測來獲取部分重要操作參數(shù)，要有效地預(yù)防CSRF攻擊，關(guān)鍵是在一個關(guān)鍵點放入不能偽造的隨機數(shù)，即加入token，并在服務(wù)器端建立相應(yīng)的攔截器對token進(jìn)行過認(rèn)證。一旦請求中為發(fā)現(xiàn)該token或token錯誤，則認(rèn)為是非法請求而拒絕。token通過如下代碼引入：$tokenvalue=md5(uniqid(rand(), true))。服務(wù)器登錄建立token，放入會話Session中，當(dāng)每次發(fā)出請求時，則從Session中提取token，并與請求攜帶的token比較，如果相互匹配，則執(zhí)行請求。在頁面中加入token的設(shè)計代碼，如圖8所示。

圖8 頁面嵌入token代碼

實際執(zhí)行中，一個站點往往存在多個地方接受form請求，因此將token以參數(shù)形式加入每一個請求者中并不顯示，通常在每次頁面加載時，用腳本遍歷DOM樹，將token加入到和