HTML5的CSRF攻擊與防御技術研究

李立, 原建偉

(陜西工業職業技術學院 信息工程學院， 陜西 咸陽 712000)

0 引言

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

本文在相關研究的基礎上，通過建立Web服務器和HTML5環境來驗證HTML5受到CSRF攻擊全過程，并提出相應的CSRF漏洞檢測和防御方式。

1 HTML5的CSRF攻擊驗證

1.1 HTML5的CSRF 攻擊原理

HTML5是互聯網應用領域的一種應用技術，其中涵蓋了各種API函數，通過完善的CSS3使得Web前端更加活躍。基于HTML5的應用程序能夠在任何瀏覽器上運行，但也帶來了針對該程序的攻擊方式。當登錄HTML5站點時，要求進行身份驗證。通常，Web通過Cookie方式記錄用戶認證信息，當用戶重復登錄該Web時，瀏覽器將攜帶了該用戶先前的認證信息放入HTTP頭部并一同發送至服務器，避免了二次認證。而用戶認證信息一旦被惡意控制，則攻擊者往往利用認證執行惡意操作，從而受到CSRF攻擊，CSRF攻擊程序圖如圖1所示。

圖1 CSRF攻擊基本原理圖

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

1.2 HTML5的CSRF攻擊驗證

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

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

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

圖2 頁面 Attck_GET.html 的代碼

圖3 GET 完成的 CSRF 攻擊

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

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

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

圖4 頁面 attck_del.html 的代碼

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

2.1 HTML5的CSRF攻擊檢測

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

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

圖5 Rational AppScan工作示意圖

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

2.2 基于 HTML5 的 CSRF 的防御

2.2.1 驗證碼驗證

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

圖6 驗證碼預防CSRF攻擊

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

2.2.2 驗證HTTP Referer字段

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

圖7 驗證HTTP Referer字段攻擊

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

2.2.3 請求中添加token

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

圖8 頁面嵌入token代碼

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