HTML5 App的代碼注入攻擊

原文連接

摘要

基於HTML5的手機app（譯者注：如下簡稱HTML5 app）愈來愈流行了， 在大多數狀況下它比native應用更容易適配不一樣的移動操做系統。它開發起來很方便，可使用標準的web技術，包括HTML五、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實現程序邏輯。由於HTML五、CSS和JavaScript是跨平臺的，因此這種app從一個平臺移植到另一個平臺也是很容易的，在必定程度上來講甚至是通用的。基於這種優點，基於HTML5的app在迅速普及。Evans Data作的一個針對1200名開發者的調查發現使用HTML5技術進行app開發的佔到了75%[1]。Gartner最近的一項報告稱，在市場佔有率上，HTML5 app將在2016 年和native app勢均力敵。

很是不幸的是，使用HTML五、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代碼

 

<script>alert(’attack’)</script>

<script> alert ( ’ attack ’ ) </script>

圖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代碼。可是，大部分多媒體文件都有被稱爲元數據的額外區域，向這裏注入代碼是很好的選擇。

MP三、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/MP四、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 onerror=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 onerror=$.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優點的基礎上提升其安全性。

10. 致謝

咱們要感謝多位匿名審稿人有價值和使人鼓舞的評論。這個工做得到了NSF 的資助和Google的研究獎勵，可是本文的任何意見、成果、結論和意見並不受NSF和Google的影響。

11. 參考

[1] 75% of developers using html5:survey.

http: //eweek.com/c/a/Application-Development/ 75-of-Developers-Using-HTML5-Survey-508096.

[2] androguard:reverse engineering, malware and goodware analysis of android applications

http://code.google.com/p/androguard.

[3] Appcelerator. http://appcelerator.com.

[4] The facts about fm radio in mobile phones.

http://radioheardhere.com/fm-mobile.htm.

[5] Gartner recommends a hybrid approach forbusiness-to-employee mobile apps. http://gartner.com/newsroom/id/2429815.

[6] Github:build software better, together. https://github.com/.

[7] Gnuradio, usrp and software defined radio links. http://olifantasia.com/cms/en/node/9.

[8] Google url shorener. http://goo.gl/.

[9] Gwt mobile phonegap showcase source code.

https://github.com/dennisjzh/GwtMobile.

[10] Mobile apps under a new type of attack.

http://www.cis.syr.edu/~wedu/attack/index.html.

[11] Owasp. the ten most critical web applicationsecurity risks.

http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf.

[12] Phonegap. http://phonegap.com.

[13] Rhomobile. http://rhomobile.com.

[14] tr.im. http://tr.im/.

[15] Wiki:service set (802.11 network).http://wikipedia.org/wiki/Service_set_(802.11_network).

[16] Hristo Bojinov, Elie Bursztein, and Dan Boneh.

XCS: cross channel scripting and its impact on web applications. In Proceedings of the 16th ACM conference on Computer and communications security, pages 420-431. ACM, 2009.

[17] E. Chin and D. Wagner. Bifocals: Analyzing webview vulnerabilities in android applications.

[18] Martin Georgiev, Suman Jana, and Vitaly Shmatikov. Breaking and fixing origin-based access control in hybrid web/mobile application frameworks. 2014.

[19] O. Hallaraker and G. Vigna. Detecting malicious javascript code in mozilla. In Engineering of Complex Computer Systems. ICECCS 2005.

[20] R. Hansen. Xss cheat sheet. http://ha.ckers.org/xss.html, 2008.

[21] Mario Heiderich, Jo rg Schwenk, Tilman Frosch, Jonas Magazinius, and

Edward Z. Yang. mxss attacks: attacking well-secured web-applications by using innerhtml mutations. 2013.

[22] P. Hooimeijer, B. Livshits, D. Molnar, P. Saxena, and M. Veanes. Fast and precise sanitizer analysis with bek. In Proceedings of the 20th USENIX conference on Security, 2011.

[23] K. Jayaraman, W. Du, B. Rajagopalan, and S. J. Chapin. Escudo: A fine-grained protection model for web browsers. In ICDCS, 2010.

[24] X. Jin, L. Wang, T. Luo, and W. Du. Fine-Grained Access Control for HTML5-Based Mobile Applications in Android. In Proceedings of the 16th Information Security Conference (ISC), 2013.

[25]   N. Jovanovic, C. Kruegel, and E. Kirda. Pixy: A static analysis tool for detecting web application vulnerabilities. In IEEE Symposium on Security and Privacy, 2006.

[26]   T. Luo and W. Du. Contego: Capability-based access control for web browsers. In Trust and Trustworthy Computing. Springer, 2011.

[27]   T. Luo, H. Hao, W. Du, Y. Wang, and H. Yin. Attacks on webview in the android system. In Proceedings of the Annual Computer Security Applications Conference (ACSAC), 2011.

[28]   A. N. Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans.Automatically hardening web applications using precise tainting. Springer, 2005.

[29]   F. Nentwich, N. Jovanovic, E. Kirda, C. Kruegel, and G. Vigna. Cross-site

scripting prevention with dynamic data tainting and static analysis. In Proceeding

of the Network and Distributed System Security Symposium (NDSS), 2007.

[30]   T. Pietraszek and C. V. Berghe. Defending against injection attacks through context-sensitive string evaluation. In Recent Advances in Intrusion Detection, pages 124-145. Springer, 2006.

[31]   Mike Samuel, Prateek Saxena, and Dawn Song. Context-sensitive

auto-sanitization in web templating languages using type qualifiers. In

Proceedings of the 18th ACM conference on Computer and Communications Security, 2011.

[32]   P. Saxena, D. Molnar, and B. Livshits. Scriptgard: automatic

context-sensitive sanitization for large-scale legacy web applications. In

Proceedings of the 18th ACM conference on Computer and communications security, 2011.

[33]   S. Stamm, B. Sterne, and G. Markham. Reining in the web with content

security policy. In Proceedings of the 19th international conference on World wide web, pages 921-930. ACM, 2010.

[34]   R. Wang, L. Xing, X. Wang, and S. Chen. Unauthorized Origin Crossing on Mobile Platforms: Threats and Mitigation. In ACM Conference on Computer and Communications Security (ACM CCS), Berlin, Germany, 2013.

[35]   J. Weinberger, A. Barth, and D. Song. Towards client-side html security policies. In Workshop on Hot Topics on Security (HotSec), 2011.

[36]   Y. Xie and A. Aiken. Static detection of security vulnerabilities in scripting languages. In Proceedings of the 15th conference on USENIX Security Symposium, volume 15, pages 179-192, 2006.

via 做者：Xing Jin, Tongbo Luo, Derek G. Tsui, and Wenliang Du 翻譯：flyh4t（machuanlei@nsfocus.com）