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

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

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

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

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

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

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

1 引言

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

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

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

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

本文的貢獻(xiàn)主要包括以下幾點(diǎn)。

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

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

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

2 相關(guān)工作

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

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

3 背景介紹

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

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

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

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

圖1manifest文件示例

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

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

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

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

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

3.2.1 攻擊條件

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

3.2.2 攻擊流程

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

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

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

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

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

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

3.2.3 攻擊危害

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

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

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

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

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

4.1 攻擊流程

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

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

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

圖5MB文件

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

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

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

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

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

RFTM攻擊如圖6所示。

圖6RFTM攻擊

4.2 攻擊測(cè)試

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

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

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

圖7“一點(diǎn)資訊”manifest文件

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

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

4.3 攻擊對(duì)比分析

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

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

表1各AppCache緩存中毒攻擊對(duì)比

5 防御方案

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

5.1 通用防御策略

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

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

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

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

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

5.2.1 輕量級(jí)簽名防御方案Sec-Cache

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

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

表2簽名方案使用的符號(hào)

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

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

②編寫(xiě)符合W3C標(biāo)準(zhǔn)的manifest文件m。

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

①計(jì)算當(dāng)前時(shí)間戳timestamp；

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

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

3) 客戶端校驗(yàn)階段

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

②若已存儲(chǔ)密鑰pk，判斷當(dāng)前時(shí)間是否超過(guò)本地存儲(chǔ)的過(guò)期時(shí)間expire；

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

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

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

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

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

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

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

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

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

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

5.2.3 方案評(píng)估

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

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

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

圖9Sec-Cache方案損失時(shí)間

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

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

6 結(jié)束語(yǔ)

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

[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]王曉強(qiáng). 基于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]. 中國(guó)科學(xué)院大學(xué)學(xué)報(bào), 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é)博士生，主要研究方向?yàn)榫W(wǎng)絡(luò)與系統(tǒng)安全。

王鶴（1987-），女，河南滑縣人，博士，西安電子科技大學(xué)講師，主要研究方向?yàn)樾畔⑾到y(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

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

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

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