摘要
基於HTML5的手機app（譯者注：以下簡稱HTML5 app）越來越流行了， 在大多數情況下它比native應用更容易適配不同的移動操作系統。它開發起來很方便，可以使用標準的web技術，包括HTML5、JavaScript 和 CSS，也可以藉助一些現有的開發框架（比如PhoneGap）和手機操作系統進行交互。
衆所周知，JavaScript是非常容易遭受代碼注入攻擊的，因此我們計劃對HTML5 app進行一次系統的研究以評估基於web技術開發的手機app安全性是否可靠。成果令人吃驚，我們發現如果HTML5 app成爲主流（至少目從目前的趨勢看是這樣的），我們很多日常行爲習慣都可能引入安全風險，包括二維碼掃瞄、Wi-Fi接入點掃描、播放MP4視頻、配對藍牙設備等等。
本文介紹了HTML5 app可能存在的各種漏洞，攻擊者如何利用各種途徑進行攻擊以及攻擊成功後可能造成的危害。除了通過樣例程序演示攻擊以外， 我們還研究了PhoneGap 186款用於實現不同功能的插件，我們發現其中11款是有漏洞的。我們還對兩款真實的HTML5手機進行了安全測試，發現它們也是有漏洞的。
介紹
故事從John Smith開始，他是一個普通人。和大多數人一樣，他使用了一 款裝滿了各種app的智能手機，這個智能手機是他每天生活的一個重要組成部分。早上7點起牀，John吃早餐的時候會打開手機裏面的app聽收本地的廣播節目。這個app可以顯示當前頻段正在播放的音樂的名稱，他可以搜索不同的頻段收聽他喜歡的音樂。8點的時候，他乘公共汽車上班。他看到一個有趣的產品廣告貼在他前面座位的背後。爲了瞭解更多產品信息，他用手機上的RFID刷了這個廣告標籤。忙完了上午的工作後，John在一家新開的餐館吃午餐。爲了節省手機流量費，他用手機搜索免費的Wi-Fi熱點。他很高興的發現有好幾個免費熱點可以使用。下午5點，John下班回家。在公共汽車上他開始聽他下載的MP3歌曲。他的手機MP3 app能夠播放MP3文件裏面的歌詞，這讓他非常開心。下車以後，他收到了他媳婦的短信讓他買一些好吃的帶回家。
他去了超市，在超市裏門口他看到有二維碼貼在那裏。他知道二維碼是打折信息就馬上掃了下，他很高興的發現可以有5美元的優惠。
上面這個故事展示了手機在我們日常生活中使用的普遍性，看上去沒有必 要爲這些使用場景擔心。然而這只是目前的情況，一種迅速發展的技術趨勢將很快改變一切。當這種技術被廣泛採用以後，故事裏面John的每個行爲都可能引入安全風險。廣播節目、RFID標籤、MP3文件、Wi-Fi接入點、SMS信息和二維碼都可能成爲攻擊者注入惡意代碼到John的智能手機的通道，會導致很多危害。惡意代碼不僅僅會駐留在他的手機，還會像蠕蟲一樣向其他手機進行傳播。這種技術越流行，這種惡意代碼就傳播的越迅速。
這種技術就是HTML5技術，它是HTML5 app的基礎。在這種技術被用來開發手機app之前，絕大多數的手機app都是使用各自系統支持的native語言編寫的。比如Android app往往使用Java編寫，iOS app使用Objective-C編寫，跨平臺移植app是比較麻煩的。因爲Android和iOS使用量都很大，開發者往往沒有選擇，只能使用不同語言開發兩個不能版本的app。如果以後其他手機操作系統用戶多了，開發者將會更加悲劇。
HTML5 app技術爲這個問題提供了一個解決方案。和native apps不同的是， 這種app是使用HTML5技術開發的，這是一種和平臺無關的技術，所有手機操作系統都支持這種web技術。這種app使用HTML5和CSS繪製用戶界面，使用JavaScript實現程序邏輯。因爲HTML5、CSS和JavaScript是跨平臺的，所以這種app從一個平臺移植到另外一個平臺也是很容易的，在一定程度上來說甚至是通用的。基於這種優勢，基於HTML5的app在迅速普及。Evans Data做的一個針對1200名開發者的調查發現使用HTML5技術進行app開發的佔到了75%[1]。Gartner最近的一項報告稱，在市場佔有率上，HTML5 app將在2016 年和native app平分秋色。
非常不幸的是，使用HTML5、JavaScript和CSS開發app將引入natvie語言開發中不存在的安全風險。目前Web安全中仍然面臨的跨站腳本攻擊（XSS）問題很大程度上是由於數據和代碼混雜在一起造成的，攻擊者可以通過注入字符串執行代碼。在我們的場景下，所有數據都是從不可信的外部通道獲取的。如果這些數據中包含代碼並且app開發者沒有意識到這個風險，外部注入的代碼有可能就會在app內部執行導致安全破壞。這是一種假想的潛在攻擊方式，是否能夠真正在手機設備上完成是未知的。本文對這種攻擊方式進行了系統的研究。我們研究的發現包括如下：
- 我們確認HTML5 app可以被類似XSS的技術手段攻擊。這種攻擊場景是真是
存在的，我們已經在多款常用的app中完成了這種攻擊。主流手機平臺（包括
Android，iOS，和 Black- berry）的HTML5 app都受這種攻擊技術的影響。 - 我們系統的研究了這種攻擊的潛在攻擊通道和場景，大部分攻擊場景我們都做了POC。
- 我們分析了攻擊者面需要面對的挑戰並展示瞭如何繞過它們。
文章剩下的內容結構是這樣的：第2章介紹WebView和PhoneGap框架。第3章介紹如何進行攻擊。第4章介紹攻擊渠道和場景。第5章攻擊者面需要面對的挑戰並展示瞭如何解決它們。第6章和第7章介紹PhoneGap插件和真實手機app的漏洞。章節8和9討論相關的工作、解決方案和研究總結。
背景知識
HTML5 app不能直接在手機操作系統上運行，無論是Android還是iOS都不能直接運行HTML5和JavaScript，需要有一個web容器渲染基於HTML5的用戶界面和執行JavaScript代碼。大部分手機操作系統都這樣一個容器：Android 的WebView、iOS的UIWebView以及Windows Phone的WebBrowser。爲了簡化過程，本文中使用WebView作爲研究對象。WebView最初被設計的目的是爲了方便native app引入和展示web頁面。它將基礎的web瀏覽器功能封裝到一個類裏面，可以被app當作瀏覽器組件來使用。通過WebView提供的API函數，移動應用也可以繪製HTML頁面。
由於WebView引入的Web內容往往是不可信的，WebView像瀏覽器一樣實現了沙盒機制，JavaScript代碼只能運行在一個孤立的環境中。這樣的沙盒技術是適用於Web的，但是對於手機app來說過於嚴格了。一個運行在孤立環境中的手機app是沒有太多用途的，因爲它無法訪問系統資源，如文件、觸摸屏、攝像頭等。WebView組件運行應用程序打通一個內部JavaScript代碼和native代碼（例如，Java）的調用通道。這個通道使得JavaScript代碼可以調用native代碼，而 native代碼是可以不受WebView的沙盒限制訪問app授權的系統資源的。開發者可以在WebView中使用自己編寫的native，但是會降低應用程序的可移植性。 常見的做法是使用第三方的中間件作爲native代碼的一部分，將跨平臺的問 題留給中間件的開發商來解決。成熟的中間件是支持多種手機平臺的。目前已經有人開發了很多中間件，包括PhoneGap [12]，RhoMobile [13]， Appcelerator [3]等。在本文中我們將關注流行的PhoneGap，但是我們的攻擊方式是影響所有中間件的。我們的研究是在Android平臺上，但由於app的跨平臺特性，其他平臺也存在這類安全缺陷，也受這種攻擊的影響。PhoneGap和PhoneGap插件：PhoneGap幫助開發者使用標準的web技術創建HTML5 app。開發者可以使用HTML頁面、JavaScript代碼和CSS文件。 PhoneGap框架默認使用WebView，依賴WebView渲染HTML頁面和執行 JavaScript代碼。
PhoneGap由兩部分組成（圖1）：框架部分和插件部分，框架部分是溝通WebView中的代碼和插件模塊的橋樑，插件部分負責系統和外部交互的具體實現。對於每種類型的資源如相機、手機短信、WiFi和NFC都有一個或多個插件可以使用。目前PhoneGap框架包括16個可以直接在應用程序中使用的內置插件。如果一個應用程序的需求不能通過內置插件滿足，開發者可以編寫自己的插件或使用第三方插件。目前已經有183個第三方插件可以使用，而且數量還在不斷增加。
插件是使用其宿主移動操作系統的native語言開發的，但是爲了方便JavaScript調用，很多插件都提供配套的JavaScript庫，有的甚至提供演示的 JavaScript代碼告訴開發者如何使用這個插件。當WebView中的JavaScript代碼 需要訪問系統或外部資源時，它可以調用插件庫提供的API函數，插件庫中代 碼將調用PhoneGap API，最後通過PhoneGap框架調用對應的插件中的Java代 碼。當插件完成它的工作後，它通過PhoneGap框架返回處理後的數據到頁面。 這是JavaScript代碼通過WebView獲取系統或外部資源的過程，圖1描述了完整 的過程。
代碼注入攻擊
Web技術有一個廣爲人知的危險特性：它允許數據和代碼混雜到一起，比如當一個字符串包含數據和代碼時，代碼會被識別出來並且被JavaScript引擎執行。這是一種功能設計，這樣可以讓JavaScript代碼很方便的嵌入到HTML 頁面中執行。不幸的是，這個功能的後果是，如果開發商只想處理數據，但使用了錯誤的API，字符串中的代碼會自動和錯誤的觸發。如果這樣的數據和代碼混合字符串來自不可信的輸入，惡意代碼就可以被注入到應用程序中執 行，這就是JavaScript代碼注入攻擊。其中一種典型代表就是被我們稱爲跨站點腳本（XSS）的，根據OWASP top10［11］，這是目前Web應用程序中的第三常見的安全風險。
3.1 概述
使用Web技術開發的手機app將製造一種新的蠕蟲，它可以將針對特定的手機應用程序注入惡意代碼。這種攻擊破壞性比Web應用程序的XSS攻擊要大很多，不僅僅因爲我們給手機上安裝的app授予了很多權限，更因爲在XSS攻擊中惡意代碼的注入大多數都需要通過Web應用服務器，這是惡意數據到達他們攻擊目標的唯一通道，而在手機應用場景下有非常多可利用的攻擊通道。這些通道的一個共同的特點是，他們都是連接移動設備和外界的通道，實質上是遭受從另一個設備（不一定是一個手機設備）進行攻擊的通道。圖2（a）說明了攻擊的基本思路。
由於智能手機實時地與外面的世界交互，和傳統的網絡通道相比有更多新的通道可以輸入不可信的數據到手機設備。例如，二維碼、RFID標籤、媒體文件、Bluetooth設備和Wi-Fi接入點等，惡意代碼可以嵌入在這些通道數據裏面。
如果數據混合的代碼沒有機會被觸發，就不會有代碼執行造成的風險。這就是natvie語言開發的手機app能夠免疫這種代碼注入攻擊的原因。例如，即使攻擊者可以嵌入Java代碼到二維碼裏面，也沒有機會誤觸發執行這些代碼。但由於web技術的危險特性，這不適用於HTML5 app。特別地，app將數據顯示出來是很常見的，例如展示一個二維碼對應的信息。有一些Web技術的API “很帥”：他們可以從代碼中分離數據，將數據發送到HTML渲染引擎，將代碼發送到JavaScript引擎，這裏並沒有考慮開發者本意是否是要執行代碼。 當代碼被執行時，它可以利用分配給應用程序的權限在移動設備上進行攻擊，在WebView中使用PhoneGap框架和HTML5的API打開一個“攻擊窗口”。
3.2 觸發注入的代碼
有兩種常見的方式可以觸發執行數據字符串中包含的JavaScript代碼。一種是使用eval()函數，這個函數可以把字符作爲JavaScript代碼執行。這種風險不是很常見，因爲程序員知道輸入的字符串是不能包含非法字符的。另外一種觸發代碼執行的方式是通過DOM顯示API和屬性，比如document.write()，appendChild()，innerHTML（屬性）等。一些jQuery API也可以觸發代碼執行，比如html()和append()，它們也是基於顯示API和屬性實現的。JavaScript通過這些API和屬性顯示信息在HTML頁面中（在PhoneGap應用程序中，這些頁面就是用戶界面）。在第二種場景中，觸發執行字符串中的代碼在web環境下可能是因爲業務需要，但是手機app中這種需求很少見。
不是所有顯示API和屬性都能執行字符串中的代碼，這取決於代碼嵌入的方式。在一個HTML頁面中，有兩種典型的代碼和數據混雜在一起的場景：腳本或標籤事件屬性。下面給出這兩種場景的示例代碼：
當那兩個字符串被傳遞給DOM/j- Query顯示API和屬性時，代碼alert(‘attack’)是否可以被執行的總結如表1所示。我們統計了在代碼中使用每個api和屬性PhoneGap app的所佔比例（我們收集的764 app）。
3.3 危害
這種攻擊所能造成的危害如圖2(b)所示，可以分成三類：一種是直接攻擊受害者手機終端造成的（圖中用細的帶箭頭標示），另外兩種是惡意代碼形成的擴散攻擊 (圖中用粗的帶箭頭的線標示)。
首先，注入的惡意代碼可以通過WebView中的代碼打開的“窗口”直接對 手機終端進行攻擊。由於WebView的沙盒機制，正常情況下JavaScript代碼是不能對終端設備造成太大破壞的。但是爲了方便訪問操作系統和硬件設備，手機app創造了很多“窗口”。這些“窗口”包括HTML5 API (比如地理定位API )和app安裝的所有PhoneGap插件。需要指出的是，PhoneGap有16個內置的插件，所以即使app沒有使用他們，他們仍然可以被注入到app中的惡意代碼利用。這些插件包括通訊錄、文件和外置設備插件。惡意代碼利用他們可以獲取系統資源的訪問權限。而且很多PhoneGap app也使用了其他第三方PhoneGap插件。例如大約30%的PhoneGap app使用了FaceBook插件，這些插件也容易被惡意代碼利用。
其次，注入的惡意代碼可以通過內部數據通道注入到同一個設備上安裝的其他有漏洞的PhoneGap app。在手機終端上，不同的app共享數據是很常見的。例如，通訊錄是共享的，所以當一個應用程序受到外部攻擊時，惡意代碼可以把自己插入到通訊錄中。 當另外一個存在漏洞的PhoneGap app讀取並顯示存有惡意代碼的通訊錄時，代碼就會被觸發執行，這樣就可以在第二個app裏面進行攻擊。有很多類似這樣的內部數據通道可以被利用，比如通訊錄、日曆、圖像和SD卡上的MP3/MP4文件等。
第三，注入的惡意代碼可以將被感染的手機終端設備變成攻擊跳板終端設備，它可以使用相同的攻擊技術去感染其他手機設備。比如，被感染的app有權限發短信，惡意代碼就可以通過發送帶病毒的短信到通訊錄中所有好友的方式進行傳播。它也可以將代碼加入到MP3文件的元數據字段中，然後分享給好友。它也可以僞裝成一個藍牙設備，名字設置成惡意代碼，等待其他設備使用有漏洞的app連接。手機終端上裝的PhoneGap應用越多，這種傳輸型的攻擊就越容易成功，惡意代碼就傳播的越快。
代碼注入通道
在這個章節，我們來研究如何識別可以注入代碼到終端設備中的數據通道。爲了演示我們是如何利用這些通道進行攻擊的，我們需要找出app中使用了這些通道並且使用不安全的API顯示數據的場景。考慮到我們只收集了幾百個PhoneGap app，它們中的大部分要麼沒有使用這些通道要麼沒有顯示這些通道獲取的數據，所以使用真實的app做這個演示還是比較困難的。因此我們自己動手開發了用於演示各種攻擊通道的PhoneGap app，爲了保證研究的科學性，我們嚴格遵守以下原則：
（1）使用已存在的PhoneGap插件；
（2）如果一個PhoneGap插件有自己的JavaScript庫，我們就使用它；
（3）我們使用的存在漏洞的API是現有的PhoneGap應用程序中常用的；
（4）PhoneGap應用程序實現的功能是現有的app中很常見的，不是特意製造的（作爲證明，我們隨時可以用非PhoneGap應用程序實現相同的功能）。
所有的攻擊演示都可以在我們的網站上看到［10］。
4.1 ID通道
在很多情況下，手機在連接到外部實體設備之前，會獲取外部實體的ID並且展現給用戶看。這就建立了手機和外部實體的通道，甚至是在它們連接之前。我們研究這種通道是如何被用來注入惡意代碼到手機設備中的。
Wi-Fi接入點：搜索附近的Wi-Fi接入點，很多智能手機用戶都使用Wi-Fi scanner app來掃᧿周圍可用的Wi-Fi熱點。這類app會顯示掃᧿到的Wi-Fi熱點名稱（SSID）和其他信息給用戶。圖3(a)是WIFI Analyzer顯示的結果，這是一款從Google Play免費下載到的軟件。在Google Play上有超過250款同類的軟件，其中一些是非常流行的下載量超過1000萬。
隨着這類app的流行，不難想像在不久的將來其中的很多app都有可能是基於HTML5開發的。當這種情況場景變成現實，Wi-Fi熱點的SSID將變成一個潛在的代碼注入通道。爲了展示這種攻擊，我們把一個Android手機配置成一個接入點。Android允許將接入點的SSID設置成任意字符串，我們將SSID設置爲如下的JavaScript代碼
圖3(a)顯示的是我們設置JavaScript代碼，它在SSID中沒有執行因爲這個 app是用Java開發的。如果這個app應用程序是用PhoneGap，開發的，SSID會在 WebView 顯示，這裏就容易產生一個高危的錯誤。如果app使用了不安全的API顯示SSID，JavaScript就會被執行。
爲了證明這個推斷，我們使用PhoneGap框架和它的Wi-Fi插件寫了一個Wi-Fi熱點掃描app。如圖3（b）所示的結果，這一次沒有正確的顯示SSID， 而是作爲代碼執行了。在這個app裏面，我們沒有做任何特殊的處理。在開發這個app的時候，我們使用了html()函數來顯示SSID信息，根據我們收集的數 據來看，有16.36%的PhoneGap app做法是和我們一樣的。即使我們使用 innnerHTML替換顯示API，它比html()更安全並且不會執行內部的script標籤中的代碼，我們依然有辦法完成代碼注入攻擊。在第五章中我們會給出相關的細節。
考慮到使用移動終端設置一個Wi-Fi接入點是非常容易的，這種攻擊實施起來成本很低。在本章節，我們沒有展示可以取得的攻擊成果（只彈一個alert() 是沒有危害的）。在第五章節，我們會介紹如何通過惡意代碼進行真正的攻擊和破壞。
BlueTooth：藍牙具有類似的屬性，在第一次使用BlueTooth連接其他外部設備的時候，需要進行配對。它會顯示所有所有被探測到的BlueTooth設備ID，用戶可以選擇其中的一個進行配對。和Wi-Fi一樣，這個ID也打通了從移動終端到其他外部BlueTooth設備的數據通道。只要能收到BlueTooth設備的信號，ID數據就可以直接進入移動終端設備。
這種攻擊和Wi-Fi上的攻擊非常相似：攻擊者需要打開它手機上的BlueTooth功能，使用惡意的JavaScript作爲設備名稱，然後廣播它的名稱到附近的設備。附近的任何手機終端只要使用存在缺陷的PhoneGap app去連接配對，就會變成受害者。我們在Google Play上找到一款可攻擊的PhoneGap app。在第七章我們會給出細節作爲一個研究案例。
4.2 不同手機終端之間的數據通道
除了從網絡、Wi-Fi以及藍牙獲取數據外，手機終端還有一些與傳統的臺式機和筆記本完全不同的獲取數據的通道。比如，大部分智能手機可以掃᧿二維碼（使用相機功能）、接收短信，還有一些智能手機支持讀取RFID卡功能。這些數據通道使得用戶從外界獲取信息非常方便，所以被廣泛使用在手機app中。通過研究我們發現，所有基於HTML5技術開發的手機app，都可以通過這些數據通道注入惡意代碼。
近場通信 (NFC)：近場通信是一個用於智能設備之間的近距離無線通信
的協議。NFC技術已經被大量的移動設備所支持，包括谷歌Nexus系列，三星Galaxy S III和S4，三星Galaxy Note 3等。這些手機上NFCᴰ流行的用途是讀
取外部NFC標籤中的信息，這已經成爲一種便捷的獲取外部數據的方式：用戶只需要點擊他們的設備上的NFC標籤就可以獲得數據。廣告商和商戶利用 NFC標籤進行促銷和廣告宣傳。例如，谷歌已經攜手NFC專業技術公司Tapit 在澳洲東部的公共交通系統推出了在線音樂服務。將內置NFC標籤的海報放 在公共汽車和火車上的座位後面，感興趣的用戶可以直接使用手機掃描標籤獲取信息。
在Google Play裏面有不少讀取NFC標籤的app，比如NFC TagInfo和NFC Reader。這些app通常註冊了操作NFC的Intent對象，當手機設備檢測到一個 NFC標籤時，它就可以讀取標籤中的數據，然後發送含有數據的intent。這時候等待中的app將被觸發，它會獲取到數據並輸出給用戶看。圖4(a) 展示了一 個典型的NFC閱讀程序的用戶界面，需要注意的是我們作爲數據放在NFC標籤中的JavaScript代碼只是簡單的作爲文本內容顯示了，因爲這個app是用Java 開發的。
如果這樣一個NFC讀卡程序是用PhoneGap開發的，而且它使用了不安全的API顯示從NFC標籤讀取的數據，對手機終端將會造成巨大的危險。爲了展示這個風險，我們用PhoneGap框架和它官方ᨀ供的NFC插件開發了一個app，我們使用html()展示從NFC標籤讀取的數據
從圖4(b)中我們可以看到，從NFC標籤中獲取的JavaScript代碼已經被執行 了。隨着NFC應用日益廣泛，存在缺陷的PhoneGap app在讀取不可信的NFC 標籤時將存在很大的安全隱患。攻擊實現起來很容易：攻擊者替換公共場合的NFC標籤（包含惡意JavaScript代碼），引誘用戶來刷就可以了。這是一種被動的攻擊。攻擊者也可以將惡意的NFC標籤放到攻擊目標周圍實現主動攻擊。在標籤中，攻擊者可以指定應用程序接收NFC標籤數據。因此，當攻擊者把標籤放到受害者的手機設備附近時，只要該目標手機設備沒有鎖屏，該設備將自動從標籤讀取數據，並啓動指定的應用程序（通常是一個存在漏洞的PhoneGap app）來處理標籤數據。
條形碼：條形碼ᴰ初是使用特殊的光學掃描儀進行掃描的，但隨着智能手機的普及現在大多數手機設備都可以使用相機和軟件掃描條形碼。在Android設備上，谷歌的Goggles軟件和一些三方軟件比如Scan是比較常用的條形碼掃描軟件。通過這些軟件開發一個讀取條形碼的app是很簡單的：它可以簡單的發一個intent給系統。這個intent會觸發已經安裝的掃描軟件去掃描條形碼，將條形碼圖片轉換成數據，返回數據到ᴰ初的app。
智能手機使用的一種常見的條形碼是二維碼（或QR碼），它可以存儲超過2k字節編碼的文本消息。因爲存儲信息多和掃描方便，二維碼是在現實生活中有廣泛的應用。它們被張貼在商店入口ᨀ供銷售和優惠券信息，貼在建築物門上指引方向，在產品包裝上ᨀ供額外的信息等等。由於二維碼無處不在，掃描它已經成爲我們生活中的一種常見行爲，很少有人意識到掃描二維碼可能帶來的安全風險。
JavaScript代碼可以被嵌入二維碼中，對於一個native應用來說這不是問題，代碼會被作爲文本來顯示不會被執行。圖5(a)是一個native app掃描二維碼的 情景，我們在二維碼中放入代碼，但從圖上可以發現我們的代碼被作爲文本顯示。不幸的是，如果這是一個PhoneGap app，情況將有很大不同。我們開發了這樣一個app，當我們用它來掃描二維碼的時候，嵌入的JavaScript代碼被執行了（參考圖5(b)）。
我們已經發現了一款真實的存在漏洞二維碼掃描軟件，在第七章我們會給出完整的細節。
文本提取：除了可以從條形碼圖片提取數據以外，其他類型的圖片也可以提取數據。文本提取就是個例子。很多手機應用都採用了標準技術實現了文本提取功能，支持從照相機拍攝的圖片中自動提取信息，提取的文字會顯示給用戶。很多手機app可以從信用卡圖像提取和顯示信息，有一種類似讀取信用卡信息的第三方插件。類似條形碼的場景，如果HTML5 app顯示了從圖片中提取的信息，就會觸發嵌入在圖像中的惡意代碼。
外圍設備的數據通道：很多手機終端有額外的外置設備可以讀取一些特 別用途的數據。比如，信用卡讀卡器（譯者注：類似國內的拉卡拉那種設備）就是一種特別流行的外設，Square和PayPal都在使用這種外置設備。當用戶在這種接在手機上的外設上刷信用卡時，讀卡器會獲取卡的信息，包括帳戶、卡號和其他附加信息。這些信息會被反饋到app中，然後顯示在屏幕上請用戶 確認。
很多小的商戶使用這種外置設備接受顧客的支付。但是，如果這種app是用HTML5開發的，攻擊者只需要用一個僞造的信用卡做一筆簡單的支付就可以想手機設備中注入惡意代碼。這種app都是和支付服務相關的，惡意代碼在app 中運行起來以後會造成巨大的損失。
短信息：另外一種可以從外部獲取內容的渠道是短信息。攻擊者可以向短信內容注入惡意腳本，然後發給攻擊目標。當使用了存在缺陷的API函數的HTML5 app顯示惡意短信的時候，JavaScript會被成功觸發。
4.3 多媒體的元數據通道
播放多媒體的手機app是非常流行的，比如播放歌曲、電影和看圖片。這些多媒體文件都是從互聯網下載或者朋友分享的，大部分是由音頻、視頻和圖像組成的，看上去很難植入JavaScript代碼。但是，大部分多媒體文件都有被稱爲元數據的額外區域，向這裏注入代碼是很好的選擇。
MP3、MP4和圖像：MP3 和 MP4 文件是標準的音頻和視頻文件格式。然而，除了視頻和音頻，這類文件還包含很多元數據字段，諸如標題、藝術家、專輯、年代等等。當用戶使用手機app聽mp3音樂或者看mp4視頻時，元數據字段中的信息通常會被顯示出來，這樣用戶就知道歌曲的名稱、所屬的專輯、藝術家名字等等。
圖 6(a)展示了一類典型的MP3播放app的界面，從圖上我們可以看到JavaScript代碼是可以寫入到元數據字段的，但是native語言開發的app只會顯示JavaScript代碼不會執行。可以用來向元數據字段寫信息的工具有很多，比如iTune、Google Play Music、N7Player等等。
圖像文件情況大體一樣，我們可以從Google Play可以找到很多用於元數據 讀取的apps。它們可以顯示作者名字、版權和圖像᧿述。如圖7(a)所示， JavaScript代碼可以被插入到很多元數據字段中並且能夠被native app顯示出 來。現在我們想像下，如果app使用PhoneGap開發的，使用了存在缺陷的API 從輸出元數據會是什麼情況。爲了展示可能造成的影響，我們開發了一個這 樣的PhoneGap應用，結果如圖6(b)和圖7(b)所示: 嵌入在元數據中的JavaScript 代碼被執行了。
調頻收音機：無線電波是另外一種潛在的注入代碼到手機終端的渠道。 近年來，一些新款的智能手機都有了內置的調頻收音機，用戶可以收聽當地電臺的廣播節目。Verizon無線、AT&T和T-Mobileᨀ供的手機都是可以收聽廣播的，無線電行業協會正在爭取Apple也加入進來。Nokia在全球範圍內已經銷售了超過7億部內置調頻收音機的手機，可以看出用戶是認可這種功能 ［4］。用戶也願意付出$20到$50去購買一個可插拔的調頻收音機用在手機上。
如今，調頻廣播不僅包括音頻軌道，它還包括使用RDS（無線電廣播數據系統）協議的數據流。RDS是一種傳統的調頻廣播中用於嵌入數字信息的通信協議。RDS標準化了幾種類型的信息傳遞，包括時間、電臺號和節目信息。無線電中數字信息包括PI（節目識別），RT（無線電文本），RT是和節目同步的64字符的自由文本存儲空間（用於存儲標題和藝術家等信息）等。有一種流行的調頻收音app叫FM TwoO，它已經被下載了上百萬次，它可以顯示附加的數字信息給用戶。
使用GNU-Radio軟件和USRP (成本低於$2000)［7］，攻擊者可以很容易的搭建一個調頻廣播臺，可以播放他們自己製作的通過RDS通道嵌入了惡意代碼的無線電節目。如果用戶使用了HTML5 app收聽這種節目，一旦顯示了嵌入的RDS信息，惡意代碼就會在受害者手機上被執行。
繞過限制條件
在前面的章節爲了簡單起見，我們使用彈框的方式來證明我們可以通過多種通道成功地注入代碼，但是彈框是沒有任何實質性危害的。在本章，我們來研究如何編寫惡意代碼實現最大限度的攻擊。如果代碼長度沒有限制，這個問題就不需要探討了，因爲攻擊者可以編寫代碼實現他們想做的任何事情。不幸的是在本文描述的攻擊場景下，代碼長度限制是我們需要面對的一個巨大挑戰。例如，在Wi-Fi攻擊中，我們使用SSID字段作爲攻擊通道，這個字段只能包含32個字符[15]。問題在於攻擊者能否在這麼短的條件下實現有意義的攻擊，用最小的輸入實現最大的破壞。
5.1 數據通道的長度限制
爲了更好的理解長度限制，我們對已經識別的可以注入代碼的數據通道進行了系統的研究。研究的結果如表2所示：
從表中可以看出，長度限制對MP3/MP4、JPEG、二維碼(QR碼)和NFC這 幾個通道影響不大，它們允許輸入超過2000個字符，這對攻擊者來說足夠了。 不幸的是，Wi- Fi的SSID字段、圖片文件的Model和Maker字段、藍牙和短信息看上去是非常有限的。特別是Wi-Fi，僅有的能利用的數據通道長度被限制 在32字符。在後面的章節，我們將把這個極端情況作爲目標。我們將找到辦法利用這32字節的數據通道構造可以被注入到手機終端中的JavaScript代碼。
可以造成的破壞程度取決於實際注入的代碼，所以病毒代碼的長度取決於 你想取得的攻擊成果。長度可以相當長，是否會產生問題由長度限制決定。 爲了解決這個問題，我們使用如下的方案：我們通過有長度限制的攻擊通道 注入一段短的代碼到受害者手機中，這段代碼的目標是加載一個外部URL。 因爲外部代碼是通過常規數據通道（比如網絡連接）進入受害者手機的，這 時候就沒有長度限制了。因此，攻擊者可以放置任意代碼實現最大化的攻擊。
在下面的子章節，我們會聚焦上面ᨀ到的短的通用代碼，找出能夠引導攻擊或者說能夠引入外部URL的ᴰ短的JavaScript代碼。
5.2 短URL
我們需要使用一個URL指向外部代碼，所以儘量減小URL的長度是很重要的。我們研究了很多方法，其中一個方法是使用在線URL縮寫功能，比如 Google URL縮寫功能[8]和tr.im [14]等等。URL縮寫功能是用來在一些app中顯示超過限制的長URL的。嘗試了幾個在線平臺之後，我們得到了ᴰ短的URL http://tr.im/4ktkq。另外一個方法是購買比較短的域名，我們找到了域名e.gg，需要$1，490一年。還有一些長一點的（比如4ac.us）也能夠賣到，價值$3.99 一年。巧合的是參與本課題的一個學生擁有一個域名mu.gl（他每年爲此支付$49），因此我們在本文中使用http://mu.gl。
儘管URL縮寫方案使用的URL比購買域名來的長一些，但是它依然具有某些優勢：不僅免費，而且能夠隱藏攻擊者。它們可以輕易的使用別人的web 服務器部署惡意代碼，而不是使用自己的服務器。
5.3 壓縮惡意代碼
有很多方法可以引入外部的JavaScript代碼，我們將展示每種場景下最短的引入外部JavaScript文件的方式。
使用Script標籤：使用<script>標籤是一種典型的引入JavaScript代碼的方式。在這種情況下，我們可以省略“http:” 和 “>”。下面的代碼是我們構造的ᴰ短的腳本代碼，長度爲28字符:
<script src=//mu.gl></script>
使用事件屬性：不幸的是，正如我們在第3節中ᨀ到，如果上面用的內容被innerHTML顯示，代碼是不會被顯示或執行的。爲了像上面一樣擊敗 innerHTML，我們需要用另一種方式嵌入代碼。JavaScript可以放在一些HTML 標籤的事件屬性中，如onclick、onscroll、onerror和onmouseover事件。這些標籤可以是Button標籤、A標籤、IMG標記等等。下面是一個例子：
<img src οnerrοr=jscode>
以上代碼中我們使用了img標籤。當含有這樣的HTML標籤的數據在WebView中顯示的時候，HTML會解析標籤並嘗試加載指定的圖像。但是我 們故意沒有ᨀ供圖像源地址，所以會發生錯誤，這時onerror屬性指定的代碼 就會被觸發。這種技術在運行着Android 4.4系統的Nexus 5手機上測試通過。 早期版本的Android系統，我們需要爲src屬性指定一個不存在的URL，例如， 我們需要設置“src=x”，這樣多了兩個字符。我們的測試使用了Nexus 5，可以 不考慮這種情況。這種包含代碼的方式將繞過innerHTML中實現的過濾機制。
然後，這些屬性不允許從外部URL加載JavaScript代碼，所有的代碼都必須寫在屬性裏面，這使得我們很難造成較大的破壞。爲了解決這個問題，我們使用插入的代碼動態的生成一段腳本，通過這段腳本引入外部URL。下面是一個例子，一共99個字符：
很多PhoneGap應用使用JavaScript庫來簡化自身，jQuery就是一個廣泛應用的庫。如果一個app真的使用了jQuery，我們可以將上面的代碼簡化到45個字符。這裏要用到jQuery的getScript函數。這裏是一個例子（我們不能省略“http:”，否則getScript無法識別HTTP方法）：
<img src οnerrοr=$.getScript(’http://mu.gl’)>
5.4 繞過長度限制
目前爲止，我們藉助jQuery能夠構造的ᴰ短惡意腳本是45個字符。這個腳 本已經能夠適用於我們識別出來的大部分代碼注入通道，但是仍然超過Wi-Fi 的SSID字段32個字符的限制，我們需要想辦法解決這個問題。我們的思路是將這段JavaScript分割成幾份，然後使用eval()把它們拼接在一起。例如，我們可以將上面的$.getScript分割成5份，類似以下代碼：
在上面的代碼中，每一份的長度都不超過32個字符。這種方法是通用的， 換句話說，初始的代碼越長，我們需要分割的份數就越多。下一個挑戰就是 怎麼樣把這些分片的代碼注入到目標用戶的手機上。對某些數據通道來說是 很簡單的，因爲這些數據通道有多個字段可以使用。例如JPEG元數據裏就有 多個字段可以用，所以我們成功完成攻擊只需要5個字段。當目標app顯示5個 字段的時候，惡意代碼就會被成功執行。即使目標app只顯示一個字段，我們 也可以通過分別注入5份代碼到5個不同圖片的方式進行攻擊。
對Wi-Fi來說，只有一個字段我們可以注入代碼，問題就是我們如何將上 面的5份代碼同時注入。這裏有兩種方案。第一種方式是使用多個Wi-Fi接入 點。按照上面的例子，我們需要設置5個接入點，每個分別使用一段代碼作爲 其 SSID。當目標用戶使用有漏洞的app掃描附近的Wi-Fi時，5份代碼會全部 被注入。我們需要確保最後一份代碼包含eval(a+b+c+d)那一份，必須在目標 用戶手機上最後顯示，因爲這一段代碼需要先定義a，b，c 和d。爲了達到這 個效果，我們只需要確保第5個接入點ᴰ後廣播它的SSID就可以了。圖 8(a) 展示了一款叫做WIFI Analyze的non- PhoneGap app5顯示個不同的惡意代碼接 入點的場景。而當這5個接入點在PhoneGap app種顯示時，jQuery 代碼將會被 執行。
攻擊者也可以使用一個接入點完成攻擊。大部分Wi-Fi掃描app會定期刷新 屏幕更新可以被檢測到的接入點列表。爲了完成我們的攻擊，我們不需要我 們構造的惡意的SSID在同一時間顯示。它們每一個被顯示的時候，注入在 SSID的代碼就會被執行。如果5份代碼都被執行了，我們的攻擊就成功了。因 此，我們只需要使用一個接入點、每次將接入點SSID修改其中一份代碼，每 次一個，第5份代碼作爲最後一個。在圖8(b)，我們從non-PhoneGap app中在 五個不同的時間做的5次屏幕截圖，每次都是一個不同的SSID。實際上，這5個SSID都來自同一個設備。我們已經在我們開發的PhoneGap app上做了驗證，這些驗證SSID被顯示的時候，jQuery代碼就會被執行。
PHONEGAP插件
PhoneGap應用程序需要使用插件來與Webview之外的對象實體進行交互。 在本章節中，我們要找到那些存在安全缺陷的插件。如果一個插件使用了不 安全的api顯示從可以攻擊的通道獲取的數據，它就是存在安全缺陷的。在本 次研究中，我們從從GitHub [ 6 ]下載了186個第三方插件作爲測試對象。
6.1 可被利用的插件
如果一個插件可以被成功攻擊，它需要返回數據到WebView中的頁面，並 且數據必須是能夠從外部控制的，不是所有的插件都符合這個條件。我們開發了一個工具對這186個插件進行了分析，我們發現其中58個插件是完全不輸出數據的。另外51個插件輸出的數據攻擊者無法控制，比如返回邏輯結果、 常量字符串或者狀態數據等等。換句話說，這些數據要麼是系統控制的，要 麼是開發者控制的，所以很難從外部注入代碼。剩下的77個插件是符合我們 要求的，它們可以進一步按照數據來源分成三類，如下表 (Table 3).
在這77個插件中，24個插件從Web中獲取數據（例如，PhoneGap插件可以獲取Facebook 和 Twitter上的數據）。這些數據也可能包含惡意代碼，但是這些風險（比如XSS）已經廣爲人知了，我們不再對這類插件進行討論。另外38個插件從手機設備資源獲取數據（例如日曆和通訊錄），換而言之，數據通道是內部的。這些數據可能包含代碼，攻擊者必須先安裝一個惡意的app 能夠將惡意腳本注入這些資源，然後一個有缺陷的PhoneGap app顯示來自這些資源的數據時，惡意腳本才能以目標app的權限執行。這個通道也可以用來在同一個手機上進行跨PhoneGap app攻擊。
我們的主要興趣在“外部數據”這一類，其中包含15個插件。它們從外部資源獲取數據，並返回數據到的WebView的頁面中。我們對它們進行了更深入的研究。
6.2 存在安全缺陷的插件
在我們研究的15個插件中，有四個是語音識別和信用卡掃描相關的。鑑於讀出JavaScript並讓app識別和獲取信用卡掃描硬件都比較困難，我們沒有對這四個插件進行研究。因此，我們的研究範圍縮小爲這11個插件。在這11個插 件中，有5個自帶JavaScript代碼，包括3個藍牙插件、1個Wi-Fi插件和一個短 信插件。研究過以後，我們發現ᨀ供這些JavaScript代碼有兩個目的：一個目 的是爲開發者ᨀ供示例代碼，告訴他們如何使用這個插件；另外一個目的是
提供JavaScript庫，使得插件使用起來更容易。這兩種情況下，如果插件自帶 的JavaScript代碼是有缺陷的，將導致非常顯著的破壞，因爲大部分app開發者 要麼直接使用ᨀ供的庫要麼參考示例代碼的寫法。從插件包含的JavaScript代
碼，我們發現它們基本上都使用innerHTML或者html() 顯示數據。因此，如 果數據包含惡意代碼就會被執行。我們已經通過試驗證實了我們的推斷。
另外的六個插件，它們沒有ᨀ供有缺陷的JavaScript代碼，但是仍然有潛在 的安全缺陷的，因爲它們沒有過濾來自可被利用通道的代碼。如果PhoneGap app使用這些插件並且碰巧也使用了存在缺陷的數據輸出api，將會造成安全漏 洞。考慮到這些有缺陷的API在PhoneGap app中是被廣泛使用的 (參考Table 1)，我們相信開發者將這幾個插件和這些API一起使用進而造成安全漏洞的概率會比較高。在第四章中我們開發的存在漏洞的app，我們就使用了這些插件 （包括二維碼、 NFC和短信插件）。這表明這些插件和錯誤的api使用方法組 合起來將會導致存在漏洞的app。
案例研究
通過我們自己開發的程序研究過這些潛在的攻擊以後，我們非常想知道現 實中真實存在的app是否也受這種攻擊的影響。出於這個目的，我們進行了有 步驟的搜索。我們從Google Play上下載了25類共計12，068個免費的app，包 括旅遊、交通以及社交等等。我們識別出了190個PhoneGap app。從PhoneGap 官方網站[12]我們收集了另外574免費的PhoneGap app，我們一共收集了764 個PhoneGap app。雖然這個數字相對Google
Play上的海量軟件來說是比較小的，但是我們相信隨着HTML5 app越來越流行，這個數字會在短期內顯著的
增長。
爲了確定一個PhoneGap是否受這種攻擊的影響，我們用AndroGuard [2]寫了一個Python工具來掃瞄這764個PhoneGap app，分析如下的信息：
• app是否從我們已經識別的通道中讀取外部數據
• app是否使用存在缺陷的API或屬性顯示信息
顯示的信息是否來自以上的通道
我們發現結果如下：
(1) 142個app符合第一個條件。
(2) 290個app至少使用了一種有缺陷的API或者屬性顯示信息
結合以上兩點，我們發現32個app符合前兩個條件。我們沒有去寫複雜的數據流分析工具去檢查是否符合第三個條件，而是手工對這32個app進行了分析。ᴰ終，我們發現有兩個app符合第三個條件。這意味着，他們非常有可能存在漏洞。我們用真實的攻擊方法對他們進行了測試，結果證明他們確實存在漏洞。我們會在本章後面部分給出試驗細節。
案例研究 1: GWT移動PhoneGap示例應用。這是一個PhoneGap示例app，他告訴開發者如何使用PhoneGap和它的插件。這個app使用全部的三個內置插件和三個第三方插件——ChildBrowser插件,Bluetooth插件和Facebook插件。這個app授予了這些插件全部權限。
這個app的一個功能是使用Bluetooth插件列出所有能檢測到的Bluetooth設備（通常是爲了配對的需要）。不幸的是，它使用了innerHTML 顯示Bluetooth 設備的名稱。這個API是可以進行代碼注入攻擊的。
爲了對這個存在漏洞的app進行攻擊，我們把攻擊設備調成藍牙模式，把惡意的JavaScript代碼嵌入名稱字段（長度限制爲248，足夠使用）。爲了比較，我們同時還用了一個non-PhoneGap app做Bluetooth配對，測試結果圖9(a)，從中我們可以看出在non-PhoneGap app中代碼作爲純文本顯示了。
代碼如下所示（爲了方便閱讀，我們加了一些空格）
PhoneGap.exec() 最終會觸發一個WebView之外的PhoneGap方法（Java代 碼），它需要5個參數。後面的三個參數在上面代碼第九行，分別是插件名稱 (Contacts)，需要通過插件調用的方法 (search)，還有傳遞給方法的參數。簡單的說，這三個參數請求PhoneGap返回手機通訊錄中的所有姓名。如果 PhoneGap.exec()請求失敗，第八行的函數會被執行（這裏是空函數）。如果請求成功，第2-7行定義的函數會被調用，這裏就是要實現的攻擊效果。
當這個回調函數被調用後，PhoneGap插件返回的數據會存儲到變量a中，它是一個存儲了從通訊錄中讀取到的姓名的數組。從第3行到第4行，我們看 到代碼利用通訊錄的數據構造了一個叫m的字符串。在第5行，出於演示的目的，我們將這個字符串顯示出來了（參考圖9(b)）。在第6行的真實攻擊中， 看上去我們只是構造了一個img標籤，但是它的真實目的是調用一次HTTP GET 方法請求遠程服務器（攻擊者控制的），通過這個請求將竊取的通訊錄數據發送給攻擊者。
作爲一個PhoneGap演示app，存在漏洞的GWT移動PhoneGap示範程序對真實的app有很大的影響，因爲開發者通常是通過這樣的演示程序學習怎麼開發PhoneGap app（這個app的源代碼可以從GitHub [9]上獲取到）。在公開本文之前，我們已經聯繫這個app的開發團隊修復了漏洞。
研究案例 2: RewardingYourself app。This app manages users’ miles or points in their loyalty program and find out how much they are worth. （譯者注：這句 實在是看不懂，望高手賜教）。這個app使用了所有PhoneGap官方插件和一個第三方的條形碼掃描插件。當這個app掃描一個條形碼時，會使用可以被注入代碼的innerHTML顯示條形碼裏面的數據。我們製作一個包含如下腳本的二維碼：
這段代碼使用Geolocation.watchPosition()來竊取用戶的物理位置。這個API 是HTML5中引進的，它註冊了一個當終端的物理位置變化時就會被自動調用 的處理函數。從代碼中我們可以看到處理函數被調用時，位置信息會被存儲 到變量loc中並且在第六行顯示（見圖10(b)）。在第7行和第8行，loc的內容被髮送到外部電腦。由於處理函數時被循環調用的，一旦受害者掃描了二維碼，
只要這個有漏洞的app在運行，手機就會不斷的發送位置信息給攻擊者 (見Figure 10(c))。
這個app也可以在其他平臺上使用，包括iOS和Blackberry。不幸的是，我們在iOS上無法使用它掃᧿二維碼。它依賴於另外一個二維碼掃描app來讀取二維碼，但是這個app不能在iOS上工作。這個RewardingYourself app可以用在Blackberry，我們使用同樣的二維碼進行攻擊測試獲得了成功。這證明了我們的攻擊方法是和平臺無關的假設。
解決方案和其他相關工作
找到這種威脅的解決方案已經超出了本文範疇，這將是我們下一階段研究 的焦點。在本文中，我們參考XSS攻擊的解決方案簡單的給出一些解決問題的思路。理論上來看這些方法是可行的，但是在實戰中運用還有很多工作要做。
基於數據淨化的解決方案：數據淨化是一種常見的技術，它通過過濾數據中混雜的代碼來阻止代碼注入攻擊。淨化後的數據變成一個純文本無法觸發代碼執行。基於淨化的解決方案已經在web安全領域被廣泛研究，面臨的主要挑戰是如何識別出混雜在數據中的代碼。人們提出了很多方法來解決這個問題，包括Bek [22]、CSAS [31]、ScriptGard [32]等。不幸的是，不斷有新的繞過現有淨化方案的攻擊方式被ᨀ出[20，21]。
我們可以採用一些淨化方法移除字符串種的腳本來阻止攻擊；但是挑戰在於我們在什麼地方進行數據淨化。對XSS攻擊而言很簡單，它只有一種數據通道（web服務器）。但是對於我們ᨀ出的攻擊，有很多通道可以用來注入代碼。有很多地方可以進行淨化操作：其中一個地方是PhoneGap框架，這是所有外部數據進入WebView的唯一通道。然而這種方案僅限於PhoneGap。如果我們能在WebView種進行淨化會更合理，這是一個更通用的方案，但是目前還不清楚這種處理是否會影響WebView原有的功能。
基於污點分析的解決方案：另外一種方案是採用污點分析來確定是否存在代碼注入漏洞。污點分析框架可以被應用在服務端[25，28，30，36] 或者客戶端[19，29]。污點分析的思路是標記不可信輸入，跟蹤他們在程序中的擴散。任何直接或者間接執行污染數據的嘗試都會被記錄和阻止。
使用污點分析方案，我們必須標記進入終端的外部數據。挑戰在於需要跟蹤數據通過終端設備、Dalvik虛擬機、JavaScript引擎和不同組件之間的處理過程。如果我們能做到這些，我們就可以阻止代碼被觸發，甚至可以阻止惡意代碼進入終端設備。
緩解破壞：與阻止代碼注入攻擊的思路不同，很多研究者致力於緩解腳本注入造成的破壞。這個想法是限制不可信代碼的力量。開發者需要配置一些 策略，基於內容的可信程度對每個DOM元素賦予不同的權限。例如，Escudo [23] 和Contego [26] 在某些特定的DOM元素中限制腳本的權限。內容安全策 略[33，35] 爲JavaScriptᨀ供了一個嚴格的制約，不允許inline方式執行JavaScript 和eval()。CSP可以解決本文ᨀ出的問題，但是強制使用缺省的CSP策略需要app開發者付出巨大的努力去修改現有的app，因爲將不支持inline-JavaScript。CSP對HTML5 app保護的有效性值得進一步研究。這個框架是爲瀏覽器設計的，但是我們可以參考上面的思路來做緩解攻擊的工作，換句話說，我們可以開發一個安全的 WebView爲HTML5手機appᨀ供可信計算的基礎。
其他相關工作：WebView和PhoneGap是HTML5手機app的重要組成部分。很多研究已經揭示了他們的安全性 [17，18，24，27，34]。NoFrak [18]和[24] 關注如何阻止不可信的外部web代碼訪問手機本地資源。他們的解決方案不能用於防禦我們的攻擊，因爲我們的攻擊方式中代碼來自的外部通道不屬於web。
XCS [16] 發現了很多有趣的注入代碼到服務器的通道，比如打印機、路由器 和電子相框等。一旦代碼被web接口搜索，就會在桌面瀏覽器上執行。在我們 的工作中，大部分數據通道是完全不同的手機平臺的，研究的問題也是完全不同的攻擊方式。
總結和未來的工作
在本文中，我們發現了一種新的針對HTML5手機app的代碼注入攻擊。我們在手機終端上使用poc app和真實的app系統的研究了這種攻擊的可行性。
HTML5 app以其可移植性優勢已經越來越流行，我們預計這種攻擊將在不久的將來爆發。能夠在爆發前識別這種攻擊是非常重要的，它可以幫助我們在思維中明確各種技術例如PhoneGap所帶來的風險是不斷變化的。在我們下一步的工作中，我們會開發解決這種攻擊的解決方案，和PhoneGap團隊（還有其他類似團隊）一起找到切實可行的解決方案，在保持HTML5手機app優勢的基礎上提高其安全性。
