HTML5應(yīng)用程序緩存中毒攻擊研究

賈巖，王鶴，呂少卿，張玉清,2

（1. 西安電子科技大學(xué)綜合業(yè)務(wù)網(wǎng)理論及關(guān)鍵技術(shù)國家重點實驗室，陜西 西安710071；2. 中國科學(xué)院大學(xué)國家計算機網(wǎng)絡(luò)入侵防范中心，北京 101408）

HTML5應(yīng)用程序緩存中毒攻擊研究

賈巖1，王鶴1，呂少卿1，張玉清1,2

（1. 西安電子科技大學(xué)綜合業(yè)務(wù)網(wǎng)理論及關(guān)鍵技術(shù)國家重點實驗室，陜西 西安710071；2. 中國科學(xué)院大學(xué)國家計算機網(wǎng)絡(luò)入侵防范中心，北京 101408）

HTML5應(yīng)用程序緩存使瀏覽器可以離線地訪問Web應(yīng)用，同時也產(chǎn)生了新的緩存中毒攻擊手段。首先，對應(yīng)用程序緩存中毒攻擊的原理及危害進行了分析，然后針對使用應(yīng)用程序緩存的站點，首次提出了 2次替換manifest文件的新式緩存中毒攻擊方法RFTM。在RFTM攻擊中，服務(wù)器端不會收到客戶端發(fā)送的異常HTTP請求，故對服務(wù)器進行配置無法防范，攻擊更具隱蔽性。最后設(shè)計了一套能有效防止此類攻擊的應(yīng)用層輕量級簽名防御方案Sec-Cache。實驗表明Sec-Cache防御方案能夠有效地防御RFTM攻擊，并有良好的性能與兼容性。

Web安全；HTML5；應(yīng)用程序緩存；緩存中毒攻擊；簽名方案

1 引言

隨著互聯(lián)網(wǎng)的飛速發(fā)展，Web已經(jīng)不單是用來瀏覽簡單的文檔，而成為一個越來越豐富的平臺。早期的Web標準HTML4（超文本標記語言第4代，hyper text markup language 4）已經(jīng)無法滿足人們的需求，因此，W3C組織于2014年10月正式發(fā)布HTML5標準。利用HTML5的新特性，開發(fā)者能夠方便地在不同平臺實現(xiàn)離線文檔處理、地理信息查找和定位等功能。目前的主流瀏覽器如IE、Firefox、Chrome和Opera等，都對HTML5提供了良好的支持[1]。

HTML5在提供各種便利的同時，也帶來了新的安全問題。在2010年的信息安全行業(yè)的最高盛會——黑帽大會上，Kuppan提出了多條 HTML5存在的安全風(fēng)險，其中，首次提出了應(yīng)用程序緩存中毒攻擊[2]。之后，針對HTML5新特性的安全問題，國內(nèi)外研究人員都做了大量的研究，包括Geolocation[3]、postMessage API[4]、跨域資源共享（CORS, cross- origin resource sharing）[5]、WebSocket[6]以及移動平臺HTML5 App的跨站腳本攻擊（XSS,cross site scripting）[7]等。

其中，HTML5引入的應(yīng)用程序緩存（AppCache,applications cache）能夠?qū)⒕W(wǎng)站的內(nèi)容緩存在本地，使用戶能夠在離線的情況下繼續(xù)訪問，方便了離線使用并減少了網(wǎng)絡(luò)流量，但同時也帶來了新的緩存中毒安全威脅。Gilger[8]詳細闡述了 Kuppan[2]提出的應(yīng)用程序緩存中毒攻擊，即通過中間人等手段，利用應(yīng)用程序緩存更新機制的缺陷使用戶緩存惡意內(nèi)容，在受害者回到正常網(wǎng)絡(luò)環(huán)境后，訪問合法網(wǎng)站也會持續(xù)使用緩存的惡意內(nèi)容。在這種攻擊中，攻擊者僅需通過中間人或 DNS欺騙等手段在用戶瀏覽器中緩存惡意代碼一次，便可讓用戶之后每次訪問該網(wǎng)站時都使用惡意內(nèi)容，從而達到長期劫持受害者瀏覽器的目的，即使使用 HTTPS也不能完全避免此類攻擊[9]。但是，在這種應(yīng)用程序緩存中毒攻擊中，瀏覽器會向合法服務(wù)器端請求不存在的應(yīng)用程序緩存清單（manifest）文件，并要求返回滿足條件的HTTP響應(yīng)（如返回30X的HTTP狀態(tài)碼），實現(xiàn)難度較大且會在服務(wù)器日志中留下異常記錄。因此，對于這種攻擊方式，在應(yīng)用層通過服務(wù)器合理配置即可防范。

本文在現(xiàn)有HTML5應(yīng)用程序緩存中毒攻擊的研究基礎(chǔ)之上，提出了一種2次替換manifest文件的新攻擊方式，稱為2次文件替換法（RFTM，replace file twice method）應(yīng)用程序緩存中毒攻擊。與Kuppan所提出的攻擊相比，RFTM攻擊使客戶端原manifest文件保持不變，合法服務(wù)器端將不會收到任何異常請求，從而繞過Web應(yīng)用防火墻等檢測工具，攻擊更加隱蔽。針對HTML5應(yīng)用程序緩存攻擊以及RFTM攻擊，本文從傳輸層和應(yīng)用層這2個角度探討了相應(yīng)的防御方案，設(shè)計并實現(xiàn)了一套不需要數(shù)字證書認證（CA，certificate authority）中心的輕量級簽名方案Sec-Cache來防止manifest文件被攻擊者替換。

本文的貢獻主要包括以下幾點。

1) 提出了一種新的 2次替換 manifest文件法HTML5應(yīng)用程序緩存中毒攻擊方式。與傳統(tǒng)的應(yīng)用程序緩存中毒攻擊相比，RFTM攻擊更加隱蔽。

2) 針對 RFTM 攻擊，設(shè)計了一套防御方案Sec-Cache。Sec-Cache通過不需要數(shù)字證書認證中心的輕量級簽名來防止 manifest文件被攻擊者替換，進而防止客戶端的應(yīng)用程序緩存被惡意污染。

3) 基于PHP腳本語言和IE瀏覽器插件實現(xiàn)了所提出的Sec-Cache防御方案，并進行了相應(yīng)測試。實驗表明本文提出的防御方案能夠有效地防御RFTM攻擊，并有良好的性能與兼容性。

2 相關(guān)工作

目前，HTML5引入的許多安全問題得到了廣泛關(guān)注，如文獻[4,10,11]研究了postMessage API實現(xiàn)與使用方面的安全問題，文獻[12,13]發(fā)現(xiàn)了多媒體類新特性產(chǎn)生的隱私泄露和XSS攻擊等。

在眾多新特性中，HTML5應(yīng)用程序緩存帶來的安全問題也吸引了許多研究者的目光。Johns等[14]發(fā)現(xiàn)使用AppCache緩存惡意腳本致DNS-IP映射信息過期，可以繞過反DNS Rebinding機制，從而破壞瀏覽器的同源策略。Lee等[15]提出了利用應(yīng)用程序緩存的事件機制來判斷跨源資源狀態(tài)的方法，從而推斷出用戶的訪問習(xí)慣與認證狀態(tài)。這些工作關(guān)注DNS Rebinding和用戶狀態(tài)信息泄露，而沒有充分研究AppCache緩存中毒機制。Homakov[16]結(jié)合HTTP緩存和AppCache特性，為攻陷的站點建立長期后門，但該方法易受客戶端刷新或清除緩存影響；而RFTM攻擊完全符合AppCache的W3C標準，緩存中毒不易清除。Kuppan[2]和Gilger[8]所述攻擊方式利用客戶端處理 manifest文件的邏輯對任意網(wǎng)站進行緩存中毒攻擊，但是服務(wù)端易覺察出流量異常，從而能夠進行相應(yīng)配置來防范該攻擊；而RFTM攻擊中沒有異常流量，更加隱蔽。

3 背景介紹

3.1 HTML5應(yīng)用程序緩存

HTML5引入了應(yīng)用程序離線緩存[17]，瀏覽器每次只需從服務(wù)器下載更改過的資源，使Web應(yīng)用可以在沒有互聯(lián)網(wǎng)連接時進行離線瀏覽，并且能夠加快網(wǎng)站訪問速度，同時減少服務(wù)器負載。

使用 HTML5應(yīng)用程序緩存，需在文檔的＜html＞標簽中包含manifest屬性，例如＜html manifest= “demo.appcache”＞，其中，demo.appcache就是應(yīng)用程序緩存清單文件，稱為 manifest文件。manifest文件是一個簡單的文本文件，它告知瀏覽器需要被緩存的內(nèi)容以及不要被緩存的內(nèi)容，當前頁面不在文件中指明也會被默認緩存。并且，manifest文件需要在服務(wù)器上配置為正確的多用途互聯(lián)網(wǎng)郵件擴展類型（MIME, multipurpose Internet mail extensions），即 “text/cache-manifest”，其推薦的擴展名是appcache。

如圖1所示，一個完整的manifest文件需要以CACHE MANIFEST開頭，接下來以#開頭的行表示注釋。在這個例子中，要緩存的文件是logo.gif和main.js；需要每次連接請求的是 login.asp；而如果無法建立互聯(lián)網(wǎng)連接，html5文件夾下的文件會被404.html替代。

圖1manifest文件示例

如圖2所示，對于使用了 HTML5應(yīng)用程序緩存的頁面，瀏覽器在第一次訪問時，會下載網(wǎng)頁的內(nèi)容及html標簽中指明的manifest文件，并根據(jù)文件中的內(nèi)容緩存指定的文件。接下來再次對該URL訪問時，瀏覽器會根據(jù)緩存內(nèi)容首先請求下載manifest文件，若檢驗該文件沒有更改，則直接使用緩存的內(nèi)容，不再下載指定緩存的文件。即使服務(wù)器端更改了 main.js的內(nèi)容，若manifest文件沒有更改，瀏覽器仍然會使用緩存的main.js文件。

瀏覽器處理應(yīng)用程序緩存的邏輯如圖3所示。如果瀏覽器已經(jīng)緩存了合法站點的內(nèi)容，用戶再次訪問該站點時，會根據(jù)之前記錄的 URL首先請求manifest文件，判斷服務(wù)器返回的HTTP狀態(tài)碼。若服務(wù)器返回404或410，應(yīng)用程序緩存會被刪除，瀏覽器重新請求資源；若返回其他錯誤代碼或重定向，則應(yīng)用程序緩存不會被刪除；若服務(wù)器返回的是200狀態(tài)碼，瀏覽器接下來會判斷MIME類型，若是要求的text/cache-manifest MIME類型，則進入對比manifest文件階段，否則繼續(xù)使用原來的緩存。在對比階段，若發(fā)現(xiàn)manifest文件發(fā)生了更改，則更新manifest文件以及緩存的內(nèi)容。

圖2正常使用應(yīng)用程序緩存的情況

3.2 應(yīng)用程序緩存中毒攻擊

應(yīng)用程序緩存中毒攻擊是指通過應(yīng)用程序緩存讓受害者在訪問合法網(wǎng)站時使用攻擊者提供的惡意內(nèi)容，而且攻擊者加入的代碼可以長期存在于受害者的瀏覽器中。HTTP緩存和HTML5應(yīng)用程序緩存都可以達到劫持用戶瀏覽的目的[18]，但相比于HTTP緩存，HTML5應(yīng)用程序緩存提供了新的緩存毒化手段，且惡意緩存至少會使用一次，不會輕易受到刷新網(wǎng)頁的影響，毒化的持續(xù)時間更長。

3.2.1 攻擊條件

攻擊者只要達到以下2個條件之一即可發(fā)動應(yīng)用程序緩存中毒攻擊。1) 攻擊者能夠控制受害者瀏覽器與合法域名的通信，如通過局域網(wǎng)ARP欺騙、釣魚AP[19]來進行中間人流量劫持，或使用DNS欺騙等手段。2) 攻擊者攻陷合法站點，從而可以在站點中加入應(yīng)用程序緩存以及惡意內(nèi)容，使訪問該站點的所有用戶緩存惡意內(nèi)容。只需滿足以上任何一個條件，攻擊者即可為合法域名加入自己編寫的manifest文件和惡意腳本等內(nèi)容。

3.2.2 攻擊流程

要實現(xiàn)應(yīng)用程序緩存攻擊，攻擊者需要讓受害者瀏覽器在訪問合法網(wǎng)站時使用加入的惡意內(nèi)容。Kuppan所提攻擊就是根據(jù)圖3中的①、②這2條路徑使受害者長期使用緩存的惡意內(nèi)容，直到用戶手動刪除應(yīng)用程序緩存。其攻擊主要包含以下幾個步驟（如圖4所示）。

1) 前期準備，如調(diào)查用戶訪問習(xí)慣、模仿站點、編寫惡意JavaScript等。

2) 通過釣魚Wi-Fi、中間人、DNS欺騙等方式對目標URL網(wǎng)頁注入manifest屬性，使用戶瀏覽器下載配置正確MIME類型的manifest文件，從而緩存惡意內(nèi)容。

3) 確保manifest文件的URL在合法網(wǎng)站不會返回 404或者 410狀態(tài)碼，或者返回含有非text/cache-manifest類型的200狀態(tài)碼。

4) 用戶返回正常的網(wǎng)絡(luò)環(huán)境訪問網(wǎng)站，卻使用了攻擊者緩存的惡意內(nèi)容，此時，攻擊結(jié)束。

圖3瀏覽器處理應(yīng)用程序緩存邏輯

3.2.3 攻擊危害

結(jié)合 HTML5豐富的功能，攻擊者可以利用應(yīng)用程序緩存中毒攻擊進行許多復(fù)雜的攻擊。如 shell of the future[20]（一種反向Web shell控制器）即可以作為攻擊手段來長期劫持用戶的會話。除會話劫持外，攻擊者利用 WebSocket可以對受害者所在的局域網(wǎng)進行掃描[21]，找到內(nèi)部服務(wù)器的IP地址，并利用CORS反饋給攻擊者，泄露內(nèi)部網(wǎng)絡(luò)信息。利用應(yīng)用程序緩存還可以方便攻擊者判斷受害者內(nèi)部網(wǎng)絡(luò)的 URL，甚至其登錄狀態(tài)[15]。若移動端 HTML5 App緩存了惡意內(nèi)容，攻擊者利用Geolocation API還能夠獲知受害者的地理位置信息。

圖4應(yīng)用程序緩存中毒攻擊示意

通過瀏覽器，HTML5給予了攻擊者強大的操作能力，甚至可以攀比傳統(tǒng)PC端的本地木馬，而Web的跨平臺特性使攻擊可以容易地擴展到移動端。應(yīng)用程序緩存中毒攻擊就是讓受害者感染這種“木馬”的手段。

4 RFTM應(yīng)用程序緩存中毒攻擊

Kuppan所描述的攻擊方式采用圖3中的第①、②條標號路徑來達到讓用戶緩存惡意內(nèi)容的效果，由于緩存中毒的客戶端會嘗試下載不存在的manifest文件，所以服務(wù)器會收到異常的GET請求，從而會觸發(fā)服務(wù)端的防御措施，留下攻擊痕跡。因此，本文提出了2次替換manifest文件的攻擊方法RFTM，通過圖 3中的路徑③來完成攻擊。RFTM攻擊中客戶端不會向服務(wù)器發(fā)出異常請求留下痕跡，使緩存中毒攻擊更加隱蔽。

4.1 攻擊流程

對于使用了應(yīng)用程序緩存的站點，正常用戶請求 manifest文件常常是通過圖 3中標號為③的流程，RFTM即是要達到通過該流程緩存惡意內(nèi)容的效果。需要注意，該種應(yīng)用程序緩存攻擊需要具備3.2.1節(jié)所述攻擊方法的前提條件，并且要求目標合法網(wǎng)站已經(jīng)使用了應(yīng)用程序緩存功能下面假設(shè)合法網(wǎng)站的域名為 www.domain.com，以圖 1中的manifest文件為合法文件（簡稱為文件MA），攻擊的主要步驟如下。

1) 攻擊者從 www.domain.com下載合法網(wǎng)站的MA文件。由于manifest文件是要交給瀏覽器在客戶端處理的，所以很容易得到原manifest文件。

2) 復(fù)制MA，并更改其內(nèi)容確保會引發(fā)客戶端更新，例如，將其中的v1.0.0更改為v2.0.0。保持文件名不變，更改后的文件稱為MB，如圖5所示。

圖5MB文件

3) 攻擊者模仿 www.domain.com 搭建惡意的Web服務(wù)器，包括相同外觀的主頁、URL相同的manifest文件，以及需要緩存的logo.gif、main.js等文件，使受害者不易發(fā)現(xiàn)網(wǎng)頁被替換。同時所有文件URL也要與原網(wǎng)站相同。

4) 在緩存文件中加入攻擊代碼，如竊取信息的JavaScript，利用瀏覽器漏洞的 Shellcode等。這些代碼將可以長期保持在受害者的瀏覽器中。

5) 通過DNS欺騙、中間人等手段，在受害者訪問的網(wǎng)頁中加入透明的iframe標簽，使受害者不知情地訪問 www.domain.com，并收到攻擊者創(chuàng)建的惡意網(wǎng)站內(nèi)容。由于MB文件與原MA文件不同，所以瀏覽器會更新 www.domain.com的緩存文件（不妨假設(shè)瀏覽器已經(jīng)按照MA文件緩存）。

6) 接下來攻擊者修改MB文件與MA文件相同，稱為MA'文件，本例中即將v2.0.0改回v1.0.0。再通過步驟 5)中的方式，使受害者瀏覽器再次更新應(yīng)用程序緩存，注意排除HTTP緩存對manifest文件的影響。這關(guān)鍵的一步使用戶再次訪問合法www.domain.com 時不會更新應(yīng)用程序緩存文件，直到 www.domain.com本身對應(yīng)用程序緩存文件進行了更新。

7) 攻擊結(jié)束后，用戶回到正常的網(wǎng)絡(luò)環(huán)境中，再次訪問www.domain.com。由于MA'與MA在內(nèi)容、路徑、文件名上完全一致，而瀏覽器發(fā)出的GET請求也與原來的正常請求一樣，故不會觸發(fā)更新緩存，從而使用帶有攻擊代碼的緩存頁，直到www.domain.com對manifest文件進行了更新，或者用戶手動刪除應(yīng)用程序緩存。

RFTM攻擊如圖6所示。

圖6RFTM攻擊

4.2 攻擊測試

本次攻擊測試以小米公司的“一點資訊”注1注1：http://news.browser.miui.com/。站點為例。這是一個新聞資訊類站點，小米手機定制系統(tǒng) MIUI捆綁瀏覽器默認頁面即有該站點的導(dǎo)航，以方便用戶查看新聞資訊。該站點使用HTML5應(yīng)用程序緩存，使手機用戶在離線時也可以查看資訊摘要，減少了移動端流量，提供了良好的離線體驗，其中的cache.appcache文件如圖7(a)所示。下面將針對該站點進行RFTM攻擊測試。

攻擊準備：攻擊者首先制作與“一點資訊”功能外觀相同的頁面并加入攻擊代碼（這里用彈窗說明）；在主頁相同目錄準備好 manifest文件cache.appcache，內(nèi)容如圖7(b)所示，作為第一次替換使用。另外，為了防止HTTP緩存對攻擊的影響，在服務(wù)器的配置文件設(shè)置恰當?shù)?expires 、last-modified、cache-control頭域。

攻擊實施：攻擊者與受害者同處一個Wi-Fi局域網(wǎng)。打開本機 Apache服務(wù)器，使用中間人攻擊綜合工具ettercap對受害者進行ARP欺騙，并使用etterfilter在用戶流量中加入不可見的內(nèi)嵌窗口，讓受害者不知情地訪問“一點資訊”站點。

圖7“一點資訊”manifest文件

同時，對受害者進行 DNS欺騙，使“一點資訊”的域名解析到攻擊者的服務(wù)器。在受害者訪問一次攻擊者服務(wù)器后，攻擊者即可修改manifest文件內(nèi)容為圖7(a)中所示，與原manifest文件一致，待受害者再次被迫訪問“一點資訊”時，2次替換完成，RFTM攻擊結(jié)束。

攻擊效果：在更換網(wǎng)絡(luò)環(huán)境后，當受害者再次訪問“一點資訊”站點時，瀏覽器彈出對話框，攻擊成功。攻擊者完全可以加入功能更加強大的惡意代碼，在受害者每次使用“一點資訊”查看新聞時執(zhí)行，直到站點更新manifest文件或用戶手動刪除應(yīng)用程序緩存。

4.3 攻擊對比分析

與 Kuppan[2]和 Homakov[16]提出的應(yīng)用程序緩存中毒攻擊相比，RFTM攻擊的主要特點如表1所示。就攻擊條件而言， RFTM和Kuppan的攻擊都不要求攻陷Web站點，但需要對客戶端進行流量劫持，而且RFTM還要求站點使用應(yīng)用程序緩存，條件較為苛刻。就隱蔽性而言，在 Homakov的攻擊中，HTTP緩存機制會使服務(wù)器原有流量減少，Kuppan的攻擊會請求不存在的 manifest文件留下異常信息，而RFTM攻擊使受害者在緩存惡意內(nèi)容的同時，最終的manifest文件也與合法網(wǎng)站上的一致，當用戶回到安全網(wǎng)絡(luò)環(huán)境再次訪問合法網(wǎng)站時，服務(wù)器端不會收到任何異常請求，通信流量與緩存中毒前完全相同，攻擊更加隱蔽。因此，通過對服務(wù)器的配置無法防范RFTM攻擊，該方法更加適合攻擊者對大范圍用戶進行緩存投毒，而Kuppan的攻擊則能夠通過對服務(wù)器進行合理配置防范。就攻擊成功后客戶端恢復(fù)難易度而言，RFTM和Kuppan的攻擊均需用戶手動清除離線數(shù)據(jù)，步驟較為復(fù)雜，而Homakov的攻擊清除瀏覽器緩存即可恢復(fù)。

目前，Web站點還沒有普遍使用應(yīng)用程序緩存，故RFTM攻擊的影響范圍不如Kuppan的攻擊廣泛。但隨著逐漸增多的離線 Web應(yīng)用，如小米一點資訊、離線 Gmail、在線二元交易平臺 Binary.com、Zoho離線文檔、Remember the Milk、WordPress等，以及日益普及的移動端HTML5 App，RFTM應(yīng)用程序緩存中毒攻擊將會造成巨大的安全隱患。

表1各AppCache緩存中毒攻擊對比

5 防御方案

本節(jié)討論并總結(jié)針對應(yīng)用程序緩存中毒攻擊的防御方案。針對上述攻擊，可以從2個方面出發(fā)來考慮防御措施。1) 阻止攻擊發(fā)生的前提條件，如防止流量劫持；2) 從應(yīng)用程序緩存的應(yīng)用層面，如對服務(wù)器進行設(shè)置，引入防止替換緩存文件的簽名機制。

5.1 通用防御策略

由于應(yīng)用程序緩存中毒攻擊需要首先劫持用戶的HTTP通信，因此為了防止此類攻擊，站點應(yīng)該盡可能多地開啟 HTTPS來防止流量劫持，但是sslstrip[22]的易于使用和用戶自身較低的安全意識，使防護效果不佳。所以，更推薦使用 HTTP strict transport security（HSTS）[23]，只要用戶第一次訪問了合法的站點，瀏覽器在很長時間里都只能用HTTPS訪問該站點，這可以較好地防御流量劫持，從而不受應(yīng)用程序緩存攻擊影響，然而目前只有極少數(shù)站點開啟了HSTS[9]。

需要注意，若攻擊者具備了修改合法站點Web文件的權(quán)限，使用 HTTPS并不能起到任何防御作用。另外，若不使用緩存，可以在 HTTP頭加入no-store來強制取消緩存，但同時這也會造成用戶體驗的負面影響。

5.2 應(yīng)用層面防御方案

根據(jù)Kuppan的應(yīng)用程序緩存中毒攻擊，客戶端會請求不存在的manifest文件，并期望獲得使用本地應(yīng)用程序緩存的HTTP響應(yīng)碼。針對這樣的攻擊特征，網(wǎng)站管理員可以設(shè)置對異常的manifest文件請求返回404狀態(tài)碼，從而取消客戶端的應(yīng)用程序緩存。同時，出于安全的考慮，瀏覽器在請求manifest文件收到錯誤的MIME類型及異常狀態(tài)碼時，也應(yīng)取消應(yīng)用程序緩存的使用。

而采用RFTM攻擊方法，客戶端則不會發(fā)出異常請求，服務(wù)端無從察覺，采用上述措施無法防御。故本文在應(yīng)用層面提出一種輕量級簽名防御方案Sec-Cache，來防止攻擊者替換manifest文件。

5.2.1 輕量級簽名防御方案Sec-Cache

攻擊者替換manifest文件使用戶緩存有害的內(nèi)容，根源是瀏覽器沒有對manifest文件驗證來源。雖然可以采用目前常用的證書機制來對緩存機制簽名，但由于會引入CA等，造成較大的安全開銷。因此，本文提出一個通過服務(wù)器和客戶端協(xié)作的輕量級簽名方案，來防止攻擊者對manifest文件的偽造。描述方案使用的符號定義如表2所示。

下面從服務(wù)器端和客戶瀏覽器端這2方面來對簽名方案加以說明。服務(wù)器端只在必要的時候執(zhí)行初始化階段，如生成密鑰、更新manifest文件。服務(wù)器在每次收到客戶端請求manifest文件時，執(zhí)行簽名階段步驟。注意，服務(wù)器需要在密鑰過期之前一段時間產(chǎn)生新的公私鑰對，并在簽名保護下發(fā)布新的公鑰。

表2簽名方案使用的符號

1) 服務(wù)端初始化階段

①生成RSA算法的公私鑰對(pk, sk)并妥善保存；

②編寫符合W3C標準的manifest文件m。

2) 服務(wù)器簽名階段

①計算當前時間戳timestamp；

②計算check=Sig(sk, H(m||timestamp||pk||expire))；

③收到客戶端請求后發(fā)送m||pk||timestamp|| expire||check。

3) 客戶端校驗階段

①判斷是否存儲當前URL的pk，若無，則存儲服務(wù)器發(fā)布的(pk, expire)；

②若已存儲密鑰pk，判斷當前時間是否超過本地存儲的過期時間expire；

③根據(jù)timestamp判斷消息是否為重放，若是，則拒絕該manifest文件；

④計算 h’=H(m||timestamp||pk||expire)；

⑤判斷h’是否等于Ver(pk, check)，若等于，則接受該manifest文件。

簽名方案執(zhí)行流程如圖8所示。

圖8簽名方案執(zhí)行流程

為防止攻擊者為不使用應(yīng)用程序緩存的合法網(wǎng)站加入應(yīng)用程序緩存，當客戶端請求manifest文件收到HTTP 404狀態(tài)碼時，不應(yīng)使用應(yīng)用程序緩存；但在過期時間內(nèi)客戶端應(yīng)不刪除已有緩存及公鑰，以防止攻擊者刪除原有緩存內(nèi)容。

5.2.2 Sec-Cache方案實現(xiàn)

為了驗證方案的可行性并進行性能評估，實驗在apache服務(wù)器上用openssl產(chǎn)生公私鑰對，并采用PHP動態(tài)生成manifest文件的方法實現(xiàn)了服務(wù)器端簽名；在客戶端，以 IE插件形式模擬了客戶端的校驗過程。

在Sec-Cache方案中，check與timestamp是隨著服務(wù)器簽名時間變化的內(nèi)容，故將這2個字段以新增HTTP頭域或者cookie的形式發(fā)送給客戶端以保持兼容性，其余內(nèi)容以注釋按“#關(guān)鍵字：”開頭的形式加入 manifest文件中。Sec-Cache方案定義的關(guān)鍵字如表3所示，要求開發(fā)者加入的注釋內(nèi)容不能與關(guān)鍵字沖突。#SEC_CACHEv1.0表示方案的版本，方便未來改進升級；#DELETE關(guān)鍵字為服務(wù)器提供了刪除客戶端應(yīng)用程序緩存的支持，當客戶端收到該關(guān)鍵字時刪除當前應(yīng)用程序緩存。

表3Sec-Cache方案定義的關(guān)鍵字

5.2.3 方案評估

Sec-Cache方案采用了簽名機制，在攻擊者無法獲得私鑰的情況下，對manifest文件進行任何更改，客戶端都會在驗證簽名階段發(fā)現(xiàn)，故可以有效地防止攻擊者偽造合法網(wǎng)站的manifest文件，從而防御RFTM攻擊。同時，簽名機制能夠阻止攻擊者在任意 URL偽造 manifest文件，故也可以防范Kuppan的攻擊。另外，即使攻擊者攻陷了合法站點，若沒有獲得私鑰，也不能對manifest文件進行偽造。

該方案還具有良好的兼容性?；谠械膽?yīng)用程序緩存工作流程，沒有增加客戶端與服務(wù)端的通信步驟；新增不變關(guān)鍵字段以注釋形式加入manifest文件，不影響現(xiàn)有的瀏覽器處理應(yīng)用程序緩存。

在效率上，該方案增加了少量傳輸時的流量，以及服務(wù)端和客戶端的校驗計算過程。通過查看HTTP頭部的Content-Length信息，可知添加的關(guān)鍵字固定增加通信流量約為384 byte，主要由發(fā)布的公鑰與check字段組成，不隨原manifest文件大小的增加而增加。為了測試該方案時間效率影響的大小，實驗采用Intel i74712MQ處理器、6 GB內(nèi)存的筆記本電腦作為客戶端，2 GB內(nèi)存、雙處理器的橋接模式Linux虛擬機作為服務(wù)器測試。通過使用瀏覽器開發(fā)人員工具的計時功能，可以觀測出服務(wù)器簽名的耗時；通過在客戶端代碼中加入計時器的方法，計算客戶端校驗階段耗時，這2部分耗時之和即為方案的損失時間。通過增加manifest文件的長度，多次實驗計算均值，得到如圖9所示的損失時間。

圖9Sec-Cache方案損失時間

由實驗結(jié)果可知，服務(wù)器端簽名階段耗時基本穩(wěn)定在1～2 ms，表明方案對服務(wù)器的影響較小，損失時間主要在客戶端。通常，一個manifest文件的大小不超過1000 byte，而完成一個大中型網(wǎng)頁的加載少則需要幾百毫秒的時間，相比于 Sec-Cache方案所帶來的優(yōu)點，增加的開銷微不足道。

由于服務(wù)器不能主動通知客戶端，該方案在更新密鑰時存在缺陷。若客戶端在第一次保存了公鑰后，在密鑰過期時間到達之前沒有及時更新密鑰，則會刪除原密鑰脫離保護。即該方案只能保護第一次登錄的是合法網(wǎng)站并且及時更新公鑰的用戶，這點與HSTS相似。在更高安全需求的場景，可以考慮結(jié)合CA證書機制。

6 結(jié)束語

HTML5標準化后，越來越多的Web應(yīng)用開始使用這項新標準。本文首先詳細分析了HTML5應(yīng)用程序緩存以及應(yīng)用程序緩存中毒攻擊，并討論了攻擊所產(chǎn)生的危害。針對使用應(yīng)用程序緩存的站點，本文提出了更加隱蔽的RFTM攻擊方式。通過2次替換manifest文件，攻擊者緩存惡意內(nèi)容的同時，最終的manifest文件也與合法網(wǎng)站上的一致。因此，合法服務(wù)器端不會收到任何異常的請求，使緩存中毒更加隱蔽，并且通過對服務(wù)器的配置無法防范。接下來，從傳輸層與應(yīng)用層這2個方面，對應(yīng)用程序緩存中毒攻擊的防御方案進行了討論，并設(shè)計了一種輕量級簽名防御方案Sec-Cache來防止RFTM應(yīng)用程序緩存中毒攻擊。實驗表明該方案具有良好的效率與兼容性。

[1]LEENHEER N. How well does your browser support HTML5[EB/OL].http://html5test.com.

[2]KUPPAN L. Attacking with HTML5[EB/OL]. http://www.andlabs.org.

[3]ZALEWSKI M. Geolocation spoofing and other UI woes[EB/OL].http://seclists.org/bugtraq/2010/Aug/201.

[4]SON S, SHMATIKOV V. The postman always rings twice: attacking and defending postMessage in HTML5 Websites[C]//NDSS. 2013.

[5]王曉強. 基于HTML5的CSRF攻擊與防御技術(shù)研究[D]. 成都: 電子科技大學(xué), 2013.WANG X Q. Research of CSRF attack and defense techniques based on HTML5 [D]. Chengdu: University of Electronic Science and Technology of China, 2013.

[6]KULSHRESTHA A. An empirical study of HTML5 websockets and their cross browser behavior for mixed content and untrusted certificates[J]. International Journal of Computer Applications, 2013, 82(6):13-18.

[7]JIN X, HU X, YING K, et al. Code injection attacks on HTML5-based mobile apps: characterization, detection and mitigation[C]// ACM SIGSAC Conference on Computer amp; Communications Security. 2014:66-77.

[8]GILGER J. Persistent AppCache injections [EB/OL]. https://heipei.github.io/2015/08/20/Persistent-AppCache-Injections/.

[9]JIA Y, CHEN Y, DONG X. Man-in-the-browser-cache: persisting https attacks via browser cache poisoning[J]. Computers amp; Security, 2015: 62-80.

[10]HANNA S, CHUL E, SHIN R, et al. The Emperor's new APIs: on the(in) secure usage of new client-side primitives[J]. W2sp Web Securityamp; Privacy, 2010.

[11]李瀟宇, 張玉清, 劉奇旭,等. 一種基于HTML5的安全跨文檔消息傳遞方案[J]. 中國科學(xué)院大學(xué)學(xué)報, 2013, 30(1):124-130.LI X Y, ZHANG Y Q, LIU Q X, et al. Secure cross document messaging scheme based on HTML5 [J]. Journal of Graduate University of Chinese Academy of Sciences, 2013, 30(1):124-130.

[12]TIAN Y, LIU Y C, BHOSALE A, et al. All your screens are belong to us: attacks exploiting the HTMl5 screen sharing API[C]// Proceedings of the 2014 IEEE Symposium on Security and Privacy, IEEE Computer Society. 2014:34-48.

[13]HEIDERICH M, FROSCH T, JENSEN M, et al. Crouching tiger -hidden payload: security risks of scalable vectors graphics[C]// Proceedings of the 18th ACM Conference on Computer and Communications Security. 2011: 239-250.

[14]JOHNS M, LEKIES S, STOCK B. Eradicating DNS rebinding with the extended same-origin policy[C]//Usenix Conference on Security.2013:621-636.

[15]LEE S, KIM H, KIM J. Identifying cross-origin resource status using application cache [C]//Proc NDSS ’15. 2015.

[16]HOMAKOV E. Using AppCache and service worker for evil [EB/OL].http://sakurity.com/blog/2015/08/13/middlekit.html.

[17]W3C. Offline Web applications–HTML5[EB/OL]. https://www.w3.org/TR/html5/browsers.html#offline.

[18]VALLENTIN M, BEN-DAVID Y. Persistent browser cache poisoning[R/OL].http://eecs.berkeley.edu/～yahel/papers/Browser-Cache-Poisoni ng.Song.Spring10.attack-project.pdf.

[19]WALIULLAH M, GAN D. Wireless LAN security threats amp; vulnerabilities: a literature review[J]. International Journal of Advanced Computer Science amp; Application, 2014, 5(1): 176-181.

[20]LAVA. Shell of the future: reverse web shell handler for XSS exploitation[EB/OL]. http://www.andlabs.org/tools/sotf/sotf.html

[21]LAVA. HTML5 based JavaScript network reconnaissance tool [EB/OL].http://www.andlabs.org/tools/jsrecon.html.

[22]MARLINSPIKE M. A tool for exploiting moxie marlinspike's SSLquot;strippingquot;Attack[EB/OL]. https://github.com/ moxie0/sslstrip.

[23]Internet Engineering Task Force. HTTP strict transport security (HSTS)[S/OL]. https://tools.ietf.org/html/ rfc6797.

賈巖（1992-），男，河北石家莊人，西安電子科技大學(xué)博士生，主要研究方向為網(wǎng)絡(luò)與系統(tǒng)安全。

王鶴（1987-），女，河南滑縣人，博士，西安電子科技大學(xué)講師，主要研究方向為信息系統(tǒng)安全與量子密碼。

Research on HTML5 application cache poison attack

JIA Yan1, WANG He1, LYU Shao-qing1, ZHANG Yu-qing1,2
(1. Information Security Research Center of State Key Laboratory of Integrated Services Networks, Xidian University, Xi'an 710071, China;2. National Computer Network Intrusion Protection Center, University of Chinese Academy of Sciences, Beijing 101408, China)

HTML5 application cache (AppCache) allowed Web browser to access Web offline. But it also brought a new method of cache poisoning attack that was more persisting. As for websites which used the AppCache, a novel poisoning method RFTM (replace file twice method), in which the attacker replaced the manifest file twice to poison the client’s AppCache, was proposed. Compared with the original attack, the legal server would not receive abnormal HTTP requests from the client in the attack. Therefore, changing the server configuration could not prevent the client from the RFTM AppCache poisoning. To avoid the attack mentioned above, a lightweight signature defense scheme Sec-Cache in application layer was designed. Furthermore, experiments show that it has good performance and compatibility.

Web security, HTML5, application cache, cache poisoning attack, signature scheme

s:The National Natural Science Foundation of China (No.61272481, No.61572460), Research Fund of Ministry of Education?China Mobile (No.MCM20130431)

TP393.08

A

10.11959/j.issn.1000-436x.2016206

2016-03-11；

2016-07-25

國家自然科學(xué)基金資助項目（No.61272481, No.61572460）；教育部—中國移動科研基金資助項目（No.MCM20130431）

呂少卿（1987-），男，山西五寨人，西安電子科技大學(xué)博士生，主要研究方向為在線社交網(wǎng)絡(luò)安全。

張玉清（1966-），男，陜西寶雞人，博士，中國科學(xué)院大學(xué)教授、博士生導(dǎo)師，主要研究方向為網(wǎng)絡(luò)與信息系統(tǒng)安全。