欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

摘要

基于HTML5的手機(jī)app（譯者注：以下簡稱HTML5 app）越來越流行了， 在大多數(shù)情況下它比native應(yīng)用更容易適配不同的移動操作系統(tǒng)。它開發(fā)起來很方便，可以使用標(biāo)準(zhǔn)的web技術(shù)，包括HTML5、JavaScript 和 CSS，也可以借助一些現(xiàn)有的開發(fā)框架（比如PhoneGap）和手機(jī)操作系統(tǒng)進(jìn)行交互。

眾所周知，JavaScript是非常容易遭受代碼注入攻擊的，因此我們計(jì)劃對HTML5 app進(jìn)行一次系統(tǒng)的研究以評估基于web技術(shù)開發(fā)的手機(jī)app安全性是否可靠。成果令人吃驚，我們發(fā)現(xiàn)如果HTML5 app成為主流（至少目從目前的趨勢看是這樣的），我們很多日常行為習(xí)慣都可能引入安全風(fēng)險(xiǎn)，包括二維碼掃瞄、Wi-Fi接入點(diǎn)掃描、播放MP4視頻、配對藍(lán)牙設(shè)備等等。

本文介紹了HTML5 app可能存在的各種漏洞，攻擊者如何利用各種途徑進(jìn)行攻擊以及攻擊成功后可能造成的危害。除了通過樣例程序演示攻擊以外， 我們還研究了PhoneGap 186款用于實(shí)現(xiàn)不同功能的插件，我們發(fā)現(xiàn)其中11款是有漏洞的。我們還對兩款真實(shí)的HTML5手機(jī)進(jìn)行了安全測試，發(fā)現(xiàn)它們也是有漏洞的。

介紹

故事從John Smith開始，他是一個普通人。和大多數(shù)人一樣，他使用了一 款裝滿了各種app的智能手機(jī)，這個智能手機(jī)是他每天生活的一個重要組成部分。早上7點(diǎn)起床，John吃早餐的時(shí)候會打開手機(jī)里面的app聽收本地的廣播節(jié)目。這個app可以顯示當(dāng)前頻段正在播放的音樂的名稱，他可以搜索不同的頻段收聽他喜歡的音樂。8點(diǎn)的時(shí)候，他乘公共汽車上班。他看到一個有趣的產(chǎn)品廣告貼在他前面座位的背后。為了了解更多產(chǎn)品信息，他用手機(jī)上的RFID刷了這個廣告標(biāo)簽。忙完了上午的工作后，John在一家新開的餐館吃午餐。為了節(jié)省手機(jī)流量費(fèi)，他用手機(jī)搜索免費(fèi)的Wi-Fi熱點(diǎn)。他很高興的發(fā)現(xiàn)有好幾個免費(fèi)熱點(diǎn)可以使用。下午5點(diǎn)，John下班回家。在公共汽車上他開始聽他下載的MP3歌曲。他的手機(jī)MP3 app能夠播放MP3文件里面的歌詞，這讓他非常開心。下車以后，他收到了他媳婦的短信讓他買一些好吃的帶回家。

他去了超市，在超市里門口他看到有二維碼貼在那里。他知道二維碼是打折信息就馬上掃了下，他很高興的發(fā)現(xiàn)可以有5美元的優(yōu)惠。

上面這個故事展示了手機(jī)在我們?nèi)粘Ｉ钪惺褂玫钠毡樾裕瓷先]有必 要為這些使用場景擔(dān)心。然而這只是目前的情況，一種迅速發(fā)展的技術(shù)趨勢將很快改變一切。當(dāng)這種技術(shù)被廣泛采用以后，故事里面John的每個行為都可能引入安全風(fēng)險(xiǎn)。廣播節(jié)目、RFID標(biāo)簽、MP3文件、Wi-Fi接入點(diǎn)、SMS信息和二維碼都可能成為攻擊者注入惡意代碼到John的智能手機(jī)的通道，會導(dǎo)致很多危害。惡意代碼不僅僅會駐留在他的手機(jī)，還會像蠕蟲一樣向其他手機(jī)進(jìn)行傳播。這種技術(shù)越流行，這種惡意代碼就傳播的越迅速。

這種技術(shù)就是HTML5技術(shù)，它是HTML5 app的基礎(chǔ)。在這種技術(shù)被用來開發(fā)手機(jī)app之前，絕大多數(shù)的手機(jī)app都是使用各自系統(tǒng)支持的native語言編寫的。比如Android app往往使用Java編寫，iOS app使用Objective-C編寫，跨平臺移植app是比較麻煩的。因?yàn)锳ndroid和iOS使用量都很大，開發(fā)者往往沒有選擇，只能使用不同語言開發(fā)兩個不能版本的app。如果以后其他手機(jī)操作系統(tǒng)用戶多了，開發(fā)者將會更加悲劇。

HTML5 app技術(shù)為這個問題提供了一個解決方案。和native apps不同的是， 這種app是使用HTML5技術(shù)開發(fā)的，這是一種和平臺無關(guān)的技術(shù)，所有手機(jī)操作系統(tǒng)都支持這種web技術(shù)。這種app使用HTML5和CSS繪制用戶界面，使用JavaScript實(shí)現(xiàn)程序邏輯。因?yàn)镠TML5、CSS和JavaScript是跨平臺的，所以這種app從一個平臺移植到另外一個平臺也是很容易的，在一定程度上來說甚至是通用的。基于這種優(yōu)勢，基于HTML5的app在迅速普及。Evans Data做的一個針對1200名開發(fā)者的調(diào)查發(fā)現(xiàn)使用HTML5技術(shù)進(jìn)行app開發(fā)的占到了75%[1]。Gartner最近的一項(xiàng)報(bào)告稱，在市場占有率上，HTML5 app將在2016 年和native app平分秋色。

非常不幸的是，使用HTML5、JavaScript和CSS開發(fā)app將引入natvie語言開發(fā)中不存在的安全風(fēng)險(xiǎn)。目前Web安全中仍然面臨的跨站腳本攻擊（XSS）問題很大程度上是由于數(shù)據(jù)和代碼混雜在一起造成的，攻擊者可以通過注入字符串執(zhí)行代碼。在我們的場景下，所有數(shù)據(jù)都是從不可信的外部通道獲取的。如果這些數(shù)據(jù)中包含代碼并且app開發(fā)者沒有意識到這個風(fēng)險(xiǎn)，外部注入的代碼有可能就會在app內(nèi)部執(zhí)行導(dǎo)致安全破壞。這是一種假想的潛在攻擊方式，是否能夠真正在手機(jī)設(shè)備上完成是未知的。本文對這種攻擊方式進(jìn)行了系統(tǒng)的研究。我們研究的發(fā)現(xiàn)包括如下：

我們確認(rèn)HTML5 app可以被類似XSS的技術(shù)手段攻擊。這種攻擊場景是真是

存在的，我們已經(jīng)在多款常用的app中完成了這種攻擊。主流手機(jī)平臺（包括

Android，iOS，和 Black- berry）的HTML5 app都受這種攻擊技術(shù)的影響。

我們系統(tǒng)的研究了這種攻擊的潛在攻擊通道和場景，大部分攻擊場景我們都做了POC。

我們分析了攻擊者面需要面對的挑戰(zhàn)并展示了如何繞過它們。

文章剩下的內(nèi)容結(jié)構(gòu)是這樣的：第2章介紹WebView和PhoneGap框架。第3章介紹如何進(jìn)行攻擊。第4章介紹攻擊渠道和場景。第5章攻擊者面需要面對的挑戰(zhàn)并展示了如何解決它們。第6章和第7章介紹PhoneGap插件和真實(shí)手機(jī)app的漏洞。章節(jié)8和9討論相關(guān)的工作、解決方案和研究總結(jié)。

背景知識

HTML5 app不能直接在手機(jī)操作系統(tǒng)上運(yùn)行，無論是Android還是iOS都不能直接運(yùn)行HTML5和JavaScript，需要有一個web容器渲染基于HTML5的用戶界面和執(zhí)行JavaScript代碼。大部分手機(jī)操作系統(tǒng)都這樣一個容器：Android 的WebView、iOS的UIWebView以及Windows Phone的WebBrowser。為了簡化過程，本文中使用WebView作為研究對象。WebView最初被設(shè)計(jì)的目的是為了方便native app引入和展示web頁面。它將基礎(chǔ)的web瀏覽器功能封裝到一個類里面，可以被app當(dāng)作瀏覽器組件來使用。通過WebView提供的API函數(shù)，移動應(yīng)用也可以繪制HTML頁面。

由于WebView引入的Web內(nèi)容往往是不可信的，WebView像瀏覽器一樣實(shí)現(xiàn)了沙盒機(jī)制，JavaScript代碼只能運(yùn)行在一個孤立的環(huán)境中。這樣的沙盒技術(shù)是適用于Web的，但是對于手機(jī)app來說過于嚴(yán)格了。一個運(yùn)行在孤立環(huán)境中的手機(jī)app是沒有太多用途的，因?yàn)樗鼰o法訪問系統(tǒng)資源，如文件、觸摸屏、攝像頭等。WebView組件運(yùn)行應(yīng)用程序打通一個內(nèi)部JavaScript代碼和native代碼（例如，Java）的調(diào)用通道。這個通道使得JavaScript代碼可以調(diào)用native代碼，而 native代碼是可以不受WebView的沙盒限制訪問app授權(quán)的系統(tǒng)資源的。開發(fā)者可以在WebView中使用自己編寫的native，但是會降低應(yīng)用程序的可移植性。 常見的做法是使用第三方的中間件作為native代碼的一部分，將跨平臺的問 題留給中間件的開發(fā)商來解決。成熟的中間件是支持多種手機(jī)平臺的。目前已經(jīng)有人開發(fā)了很多中間件，包括PhoneGap [12]，RhoMobile [13]， Appcelerator [3]等。在本文中我們將關(guān)注流行的PhoneGap，但是我們的攻擊方式是影響所有中間件的。我們的研究是在Android平臺上，但由于app的跨平臺特性，其他平臺也存在這類安全缺陷，也受這種攻擊的影響。PhoneGap和PhoneGap插件：PhoneGap幫助開發(fā)者使用標(biāo)準(zhǔn)的web技術(shù)創(chuàng)建HTML5 app。開發(fā)者可以使用HTML頁面、JavaScript代碼和CSS文件。 PhoneGap框架默認(rèn)使用WebView，依賴WebView渲染HTML頁面和執(zhí)行 JavaScript代碼。

PhoneGap由兩部分組成（圖1）：框架部分和插件部分，框架部分是溝通WebView中的代碼和插件模塊的橋梁，插件部分負(fù)責(zé)系統(tǒng)和外部交互的具體實(shí)現(xiàn)。對于每種類型的資源如相機(jī)、手機(jī)短信、WiFi和NFC都有一個或多個插件可以使用。目前PhoneGap框架包括16個可以直接在應(yīng)用程序中使用的內(nèi)置插件。如果一個應(yīng)用程序的需求不能通過內(nèi)置插件滿足，開發(fā)者可以編寫自己的插件或使用第三方插件。目前已經(jīng)有183個第三方插件可以使用，而且數(shù)量還在不斷增加。

插件是使用其宿主移動操作系統(tǒng)的native語言開發(fā)的，但是為了方便JavaScript調(diào)用，很多插件都提供配套的JavaScript庫，有的甚至提供演示的 JavaScript代碼告訴開發(fā)者如何使用這個插件。當(dāng)WebView中的JavaScript代碼 需要訪問系統(tǒng)或外部資源時(shí)，它可以調(diào)用插件庫提供的API函數(shù)，插件庫中代 碼將調(diào)用PhoneGap API，最后通過PhoneGap框架調(diào)用對應(yīng)的插件中的Java代 碼。當(dāng)插件完成它的工作后，它通過PhoneGap框架返回處理后的數(shù)據(jù)到頁面。 這是JavaScript代碼通過WebView獲取系統(tǒng)或外部資源的過程，圖1描述了完整 的過程。

代碼注入攻擊

Web技術(shù)有一個廣為人知的危險(xiǎn)特性：它允許數(shù)據(jù)和代碼混雜到一起，比如當(dāng)一個字符串包含數(shù)據(jù)和代碼時(shí)，代碼會被識別出來并且被JavaScript引擎執(zhí)行。這是一種功能設(shè)計(jì)，這樣可以讓JavaScript代碼很方便的嵌入到HTML 頁面中執(zhí)行。不幸的是，這個功能的后果是，如果開發(fā)商只想處理數(shù)據(jù)，但使用了錯誤的API，字符串中的代碼會自動和錯誤的觸發(fā)。如果這樣的數(shù)據(jù)和代碼混合字符串來自不可信的輸入，惡意代碼就可以被注入到應(yīng)用程序中執(zhí) 行，這就是JavaScript代碼注入攻擊。其中一種典型代表就是被我們稱為跨站點(diǎn)腳本（XSS）的，根據(jù)OWASP top10［11］，這是目前Web應(yīng)用程序中的第三常見的安全風(fēng)險(xiǎn)。

3.1 概述

使用Web技術(shù)開發(fā)的手機(jī)app將制造一種新的蠕蟲，它可以將針對特定的手機(jī)應(yīng)用程序注入惡意代碼。這種攻擊破壞性比Web應(yīng)用程序的XSS攻擊要大很多，不僅僅因?yàn)槲覀兘o手機(jī)上安裝的app授予了很多權(quán)限，更因?yàn)樵赬SS攻擊中惡意代碼的注入大多數(shù)都需要通過Web應(yīng)用服務(wù)器，這是惡意數(shù)據(jù)到達(dá)他們攻擊目標(biāo)的唯一通道，而在手機(jī)應(yīng)用場景下有非常多可利用的攻擊通道。這些通道的一個共同的特點(diǎn)是，他們都是連接移動設(shè)備和外界的通道，實(shí)質(zhì)上是遭受從另一個設(shè)備（不一定是一個手機(jī)設(shè)備）進(jìn)行攻擊的通道。圖2（a）說明了攻擊的基本思路。

由于智能手機(jī)實(shí)時(shí)地與外面的世界交互，和傳統(tǒng)的網(wǎng)絡(luò)通道相比有更多新的通道可以輸入不可信的數(shù)據(jù)到手機(jī)設(shè)備。例如，二維碼、RFID標(biāo)簽、媒體文件、Bluetooth設(shè)備和Wi-Fi接入點(diǎn)等，惡意代碼可以嵌入在這些通道數(shù)據(jù)里面。

如果數(shù)據(jù)混合的代碼沒有機(jī)會被觸發(fā)，就不會有代碼執(zhí)行造成的風(fēng)險(xiǎn)。這就是natvie語言開發(fā)的手機(jī)app能夠免疫這種代碼注入攻擊的原因。例如，即使攻擊者可以嵌入Java代碼到二維碼里面，也沒有機(jī)會誤觸發(fā)執(zhí)行這些代碼。但由于web技術(shù)的危險(xiǎn)特性，這不適用于HTML5 app。特別地，app將數(shù)據(jù)顯示出來是很常見的，例如展示一個二維碼對應(yīng)的信息。有一些Web技術(shù)的API “很帥”：他們可以從代碼中分離數(shù)據(jù)，將數(shù)據(jù)發(fā)送到HTML渲染引擎，將代碼發(fā)送到JavaScript引擎，這里并沒有考慮開發(fā)者本意是否是要執(zhí)行代碼。 當(dāng)代碼被執(zhí)行時(shí)，它可以利用分配給應(yīng)用程序的權(quán)限在移動設(shè)備上進(jìn)行攻擊，在WebView中使用PhoneGap框架和HTML5的API打開一個“攻擊窗口”。

3.2 觸發(fā)注入的代碼

有兩種常見的方式可以觸發(fā)執(zhí)行數(shù)據(jù)字符串中包含的JavaScript代碼。一種是使用eval()函數(shù)，這個函數(shù)可以把字符作為JavaScript代碼執(zhí)行。這種風(fēng)險(xiǎn)不是很常見，因?yàn)槌绦騿T知道輸入的字符串是不能包含非法字符的。另外一種觸發(fā)代碼執(zhí)行的方式是通過DOM顯示API和屬性，比如document.write()，appendChild()，innerHTML（屬性）等。一些jQuery API也可以觸發(fā)代碼執(zhí)行，比如html()和append()，它們也是基于顯示API和屬性實(shí)現(xiàn)的。JavaScript通過這些API和屬性顯示信息在HTML頁面中（在PhoneGap應(yīng)用程序中，這些頁面就是用戶界面）。在第二種場景中，觸發(fā)執(zhí)行字符串中的代碼在web環(huán)境下可能是因?yàn)闃I(yè)務(wù)需要，但是手機(jī)app中這種需求很少見。

不是所有顯示API和屬性都能執(zhí)行字符串中的代碼，這取決于代碼嵌入的方式。在一個HTML頁面中，有兩種典型的代碼和數(shù)據(jù)混雜在一起的場景：腳本或標(biāo)簽事件屬性。下面給出這兩種場景的示例代碼：

當(dāng)那兩個字符串被傳遞給DOM/j- Query顯示API和屬性時(shí)，代碼alert(‘a(chǎn)ttack’)是否可以被執(zhí)行的總結(jié)如表1所示。我們統(tǒng)計(jì)了在代碼中使用每個api和屬性PhoneGap app的所占比例（我們收集的764 app）。

3.3 危害

這種攻擊所能造成的危害如圖2(b)所示，可以分成三類：一種是直接攻擊受害者手機(jī)終端造成的（圖中用細(xì)的帶箭頭標(biāo)示），另外兩種是惡意代碼形成的擴(kuò)散攻擊 (圖中用粗的帶箭頭的線標(biāo)示)。

首先，注入的惡意代碼可以通過WebView中的代碼打開的“窗口”直接對 手機(jī)終端進(jìn)行攻擊。由于WebView的沙盒機(jī)制，正常情況下JavaScript代碼是不能對終端設(shè)備造成太大破壞的。但是為了方便訪問操作系統(tǒng)和硬件設(shè)備，手機(jī)app創(chuàng)造了很多“窗口”。這些“窗口”包括HTML5 API (比如地理定位API )和app安裝的所有PhoneGap插件。需要指出的是，PhoneGap有16個內(nèi)置的插件，所以即使app沒有使用他們，他們?nèi)匀豢梢员蛔⑷氲絘pp中的惡意代碼利用。這些插件包括通訊錄、文件和外置設(shè)備插件。惡意代碼利用他們可以獲取系統(tǒng)資源的訪問權(quán)限。而且很多PhoneGap app也使用了其他第三方PhoneGap插件。例如大約30%的PhoneGap app使用了FaceBook插件，這些插件也容易被惡意代碼利用。

其次，注入的惡意代碼可以通過內(nèi)部數(shù)據(jù)通道注入到同一個設(shè)備上安裝的其他有漏洞的PhoneGap app。在手機(jī)終端上，不同的app共享數(shù)據(jù)是很常見的。例如，通訊錄是共享的，所以當(dāng)一個應(yīng)用程序受到外部攻擊時(shí)，惡意代碼可以把自己插入到通訊錄中。 當(dāng)另外一個存在漏洞的PhoneGap app讀取并顯示存有惡意代碼的通訊錄時(shí)，代碼就會被觸發(fā)執(zhí)行，這樣就可以在第二個app里面進(jìn)行攻擊。有很多類似這樣的內(nèi)部數(shù)據(jù)通道可以被利用，比如通訊錄、日歷、圖像和SD卡上的MP3/MP4文件等。

第三，注入的惡意代碼可以將被感染的手機(jī)終端設(shè)備變成攻擊跳板終端設(shè)備，它可以使用相同的攻擊技術(shù)去感染其他手機(jī)設(shè)備。比如，被感染的app有權(quán)限發(fā)短信，惡意代碼就可以通過發(fā)送帶病毒的短信到通訊錄中所有好友的方式進(jìn)行傳播。它也可以將代碼加入到MP3文件的元數(shù)據(jù)字段中，然后分享給好友。它也可以偽裝成一個藍(lán)牙設(shè)備，名字設(shè)置成惡意代碼，等待其他設(shè)備使用有漏洞的app連接。手機(jī)終端上裝的PhoneGap應(yīng)用越多，這種傳輸型的攻擊就越容易成功，惡意代碼就傳播的越快。

代碼注入通道

在這個章節(jié)，我們來研究如何識別可以注入代碼到終端設(shè)備中的數(shù)據(jù)通道。為了演示我們是如何利用這些通道進(jìn)行攻擊的，我們需要找出app中使用了這些通道并且使用不安全的API顯示數(shù)據(jù)的場景。考慮到我們只收集了幾百個PhoneGap app，它們中的大部分要么沒有使用這些通道要么沒有顯示這些通道獲取的數(shù)據(jù)，所以使用真實(shí)的app做這個演示還是比較困難的。因此我們自己動手開發(fā)了用于演示各種攻擊通道的PhoneGap app，為了保證研究的科學(xué)性，我們嚴(yán)格遵守以下原則：

（1）使用已存在的PhoneGap插件；

（2）如果一個PhoneGap插件有自己的JavaScript庫，我們就使用它；

（3）我們使用的存在漏洞的API是現(xiàn)有的PhoneGap應(yīng)用程序中常用的；

（4）PhoneGap應(yīng)用程序?qū)崿F(xiàn)的功能是現(xiàn)有的app中很常見的，不是特意制造的（作為證明，我們隨時(shí)可以用非PhoneGap應(yīng)用程序?qū)崿F(xiàn)相同的功能）。

所有的攻擊演示都可以在我們的網(wǎng)站上看到［10］。

4.1 ID通道

在很多情況下，手機(jī)在連接到外部實(shí)體設(shè)備之前，會獲取外部實(shí)體的ID并且展現(xiàn)給用戶看。這就建立了手機(jī)和外部實(shí)體的通道，甚至是在它們連接之前。我們研究這種通道是如何被用來注入惡意代碼到手機(jī)設(shè)備中的。

Wi-Fi接入點(diǎn)：搜索附近的Wi-Fi接入點(diǎn)，很多智能手機(jī)用戶都使用Wi-Fi scanner app來掃᧿周圍可用的Wi-Fi熱點(diǎn)。這類app會顯示掃᧿到的Wi-Fi熱點(diǎn)名稱（SSID）和其他信息給用戶。圖3(a)是WIFI Analyzer顯示的結(jié)果，這是一款從Google Play免費(fèi)下載到的軟件。在Google Play上有超過250款同類的軟件，其中一些是非常流行的下載量超過1000萬。

隨著這類app的流行，不難想像在不久的將來其中的很多app都有可能是基于HTML5開發(fā)的。當(dāng)這種情況場景變成現(xiàn)實(shí)，Wi-Fi熱點(diǎn)的SSID將變成一個潛在的代碼注入通道。為了展示這種攻擊，我們把一個Android手機(jī)配置成一個接入點(diǎn)。Android允許將接入點(diǎn)的SSID設(shè)置成任意字符串，我們將SSID設(shè)置為如下的JavaScript代碼

圖3(a)顯示的是我們設(shè)置JavaScript代碼，它在SSID中沒有執(zhí)行因?yàn)檫@個 app是用Java開發(fā)的。如果這個app應(yīng)用程序是用PhoneGap，開發(fā)的，SSID會在 WebView 顯示，這里就容易產(chǎn)生一個高危的錯誤。如果app使用了不安全的API顯示SSID，JavaScript就會被執(zhí)行。

為了證明這個推斷，我們使用PhoneGap框架和它的Wi-Fi插件寫了一個Wi-Fi熱點(diǎn)掃描app。如圖3（b）所示的結(jié)果，這一次沒有正確的顯示SSID， 而是作為代碼執(zhí)行了。在這個app里面，我們沒有做任何特殊的處理。在開發(fā)這個app的時(shí)候，我們使用了html()函數(shù)來顯示SSID信息，根據(jù)我們收集的數(shù) 據(jù)來看，有16.36%的PhoneGap app做法是和我們一樣的。即使我們使用 innnerHTML替換顯示API，它比html()更安全并且不會執(zhí)行內(nèi)部的script標(biāo)簽中的代碼，我們依然有辦法完成代碼注入攻擊。在第五章中我們會給出相關(guān)的細(xì)節(jié)。

考慮到使用移動終端設(shè)置一個Wi-Fi接入點(diǎn)是非常容易的，這種攻擊實(shí)施起來成本很低。在本章節(jié)，我們沒有展示可以取得的攻擊成果（只彈一個alert() 是沒有危害的）。在第五章節(jié)，我們會介紹如何通過惡意代碼進(jìn)行真正的攻擊和破壞。

BlueTooth：藍(lán)牙具有類似的屬性，在第一次使用BlueTooth連接其他外部設(shè)備的時(shí)候，需要進(jìn)行配對。它會顯示所有所有被探測到的BlueTooth設(shè)備ID，用戶可以選擇其中的一個進(jìn)行配對。和Wi-Fi一樣，這個ID也打通了從移動終端到其他外部BlueTooth設(shè)備的數(shù)據(jù)通道。只要能收到BlueTooth設(shè)備的信號，ID數(shù)據(jù)就可以直接進(jìn)入移動終端設(shè)備。

這種攻擊和Wi-Fi上的攻擊非常相似：攻擊者需要打開它手機(jī)上的BlueTooth功能，使用惡意的JavaScript作為設(shè)備名稱，然后廣播它的名稱到附近的設(shè)備。附近的任何手機(jī)終端只要使用存在缺陷的PhoneGap app去連接配對，就會變成受害者。我們在Google Play上找到一款可攻擊的PhoneGap app。在第七章我們會給出細(xì)節(jié)作為一個研究案例。

4.2 不同手機(jī)終端之間的數(shù)據(jù)通道

除了從網(wǎng)絡(luò)、Wi-Fi以及藍(lán)牙獲取數(shù)據(jù)外，手機(jī)終端還有一些與傳統(tǒng)的臺式機(jī)和筆記本完全不同的獲取數(shù)據(jù)的通道。比如，大部分智能手機(jī)可以掃᧿二維碼（使用相機(jī)功能）、接收短信，還有一些智能手機(jī)支持讀取RFID卡功能。這些數(shù)據(jù)通道使得用戶從外界獲取信息非常方便，所以被廣泛使用在手機(jī)app中。通過研究我們發(fā)現(xiàn)，所有基于HTML5技術(shù)開發(fā)的手機(jī)app，都可以通過這些數(shù)據(jù)通道注入惡意代碼。

近場通信 (NFC)：近場通信是一個用于智能設(shè)備之間的近距離無線通信
的協(xié)議。NFC技術(shù)已經(jīng)被大量的移動設(shè)備所支持，包括谷歌Nexus系列，三星Galaxy S III和S4，三星Galaxy Note 3等。這些手機(jī)上NFCᴰ流行的用途是讀

取外部NFC標(biāo)簽中的信息，這已經(jīng)成為一種便捷的獲取外部數(shù)據(jù)的方式：用戶只需要點(diǎn)擊他們的設(shè)備上的NFC標(biāo)簽就可以獲得數(shù)據(jù)。廣告商和商戶利用 NFC標(biāo)簽進(jìn)行促銷和廣告宣傳。例如，谷歌已經(jīng)攜手NFC專業(yè)技術(shù)公司Tapit 在澳洲東部的公共交通系統(tǒng)推出了在線音樂服務(wù)。將內(nèi)置NFC標(biāo)簽的海報(bào)放 在公共汽車和火車上的座位后面，感興趣的用戶可以直接使用手機(jī)掃描標(biāo)簽獲取信息。

在Google Play里面有不少讀取NFC標(biāo)簽的app，比如NFC TagInfo和NFC Reader。這些app通常注冊了操作NFC的Intent對象，當(dāng)手機(jī)設(shè)備檢測到一個 NFC標(biāo)簽時(shí)，它就可以讀取標(biāo)簽中的數(shù)據(jù)，然后發(fā)送含有數(shù)據(jù)的intent。這時(shí)候等待中的app將被觸發(fā)，它會獲取到數(shù)據(jù)并輸出給用戶看。圖4(a) 展示了一 個典型的NFC閱讀程序的用戶界面，需要注意的是我們作為數(shù)據(jù)放在NFC標(biāo)簽中的JavaScript代碼只是簡單的作為文本內(nèi)容顯示了，因?yàn)檫@個app是用Java 開發(fā)的。

如果這樣一個NFC讀卡程序是用PhoneGap開發(fā)的，而且它使用了不安全的API顯示從NFC標(biāo)簽讀取的數(shù)據(jù)，對手機(jī)終端將會造成巨大的危險(xiǎn)。為了展示這個風(fēng)險(xiǎn)，我們用PhoneGap框架和它官方ᨀ供的NFC插件開發(fā)了一個app，我們使用html()展示從NFC標(biāo)簽讀取的數(shù)據(jù)

從圖4(b)中我們可以看到，從NFC標(biāo)簽中獲取的JavaScript代碼已經(jīng)被執(zhí)行 了。隨著NFC應(yīng)用日益廣泛，存在缺陷的PhoneGap app在讀取不可信的NFC 標(biāo)簽時(shí)將存在很大的安全隱患。攻擊實(shí)現(xiàn)起來很容易：攻擊者替換公共場合的NFC標(biāo)簽（包含惡意JavaScript代碼），引誘用戶來刷就可以了。這是一種被動的攻擊。攻擊者也可以將惡意的NFC標(biāo)簽放到攻擊目標(biāo)周圍實(shí)現(xiàn)主動攻擊。在標(biāo)簽中，攻擊者可以指定應(yīng)用程序接收NFC標(biāo)簽數(shù)據(jù)。因此，當(dāng)攻擊者把標(biāo)簽放到受害者的手機(jī)設(shè)備附近時(shí)，只要該目標(biāo)手機(jī)設(shè)備沒有鎖屏，該設(shè)備將自動從標(biāo)簽讀取數(shù)據(jù)，并啟動指定的應(yīng)用程序（通常是一個存在漏洞的PhoneGap app）來處理標(biāo)簽數(shù)據(jù)。

條形碼：條形碼ᴰ初是使用特殊的光學(xué)掃描儀進(jìn)行掃描的，但隨著智能手機(jī)的普及現(xiàn)在大多數(shù)手機(jī)設(shè)備都可以使用相機(jī)和軟件掃描條形碼。在Android設(shè)備上，谷歌的Goggles軟件和一些三方軟件比如Scan是比較常用的條形碼掃描軟件。通過這些軟件開發(fā)一個讀取條形碼的app是很簡單的：它可以簡單的發(fā)一個intent給系統(tǒng)。這個intent會觸發(fā)已經(jīng)安裝的掃描軟件去掃描條形碼，將條形碼圖片轉(zhuǎn)換成數(shù)據(jù)，返回?cái)?shù)據(jù)到ᴰ初的app。

智能手機(jī)使用的一種常見的條形碼是二維碼（或QR碼），它可以存儲超過2k字節(jié)編碼的文本消息。因?yàn)榇鎯π畔⒍嗪蛼呙璺奖悖S碼是在現(xiàn)實(shí)生活中有廣泛的應(yīng)用。它們被張貼在商店入口ᨀ供銷售和優(yōu)惠券信息，貼在建筑物門上指引方向，在產(chǎn)品包裝上ᨀ供額外的信息等等。由于二維碼無處不在，掃描它已經(jīng)成為我們生活中的一種常見行為，很少有人意識到掃描二維碼可能帶來的安全風(fēng)險(xiǎn)。

JavaScript代碼可以被嵌入二維碼中，對于一個native應(yīng)用來說這不是問題，代碼會被作為文本來顯示不會被執(zhí)行。圖5(a)是一個native app掃描二維碼的 情景，我們在二維碼中放入代碼，但從圖上可以發(fā)現(xiàn)我們的代碼被作為文本顯示。不幸的是，如果這是一個PhoneGap app，情況將有很大不同。我們開發(fā)了這樣一個app，當(dāng)我們用它來掃描二維碼的時(shí)候，嵌入的JavaScript代碼被執(zhí)行了（參考圖5(b)）。

我們已經(jīng)發(fā)現(xiàn)了一款真實(shí)的存在漏洞二維碼掃描軟件，在第七章我們會給出完整的細(xì)節(jié)。

文本提取：除了可以從條形碼圖片提取數(shù)據(jù)以外，其他類型的圖片也可以提取數(shù)據(jù)。文本提取就是個例子。很多手機(jī)應(yīng)用都采用了標(biāo)準(zhǔn)技術(shù)實(shí)現(xiàn)了文本提取功能，支持從照相機(jī)拍攝的圖片中自動提取信息，提取的文字會顯示給用戶。很多手機(jī)app可以從信用卡圖像提取和顯示信息，有一種類似讀取信用卡信息的第三方插件。類似條形碼的場景，如果HTML5 app顯示了從圖片中提取的信息，就會觸發(fā)嵌入在圖像中的惡意代碼。

外圍設(shè)備的數(shù)據(jù)通道：很多手機(jī)終端有額外的外置設(shè)備可以讀取一些特 別用途的數(shù)據(jù)。比如，信用卡讀卡器（譯者注：類似國內(nèi)的拉卡拉那種設(shè)備）就是一種特別流行的外設(shè)，Square和PayPal都在使用這種外置設(shè)備。當(dāng)用戶在這種接在手機(jī)上的外設(shè)上刷信用卡時(shí)，讀卡器會獲取卡的信息，包括帳戶、卡號和其他附加信息。這些信息會被反饋到app中，然后顯示在屏幕上請用戶 確認(rèn)。

很多小的商戶使用這種外置設(shè)備接受顧客的支付。但是，如果這種app是用HTML5開發(fā)的，攻擊者只需要用一個偽造的信用卡做一筆簡單的支付就可以想手機(jī)設(shè)備中注入惡意代碼。這種app都是和支付服務(wù)相關(guān)的，惡意代碼在app 中運(yùn)行起來以后會造成巨大的損失。

短信息：另外一種可以從外部獲取內(nèi)容的渠道是短信息。攻擊者可以向短信內(nèi)容注入惡意腳本，然后發(fā)給攻擊目標(biāo)。當(dāng)使用了存在缺陷的API函數(shù)的HTML5 app顯示惡意短信的時(shí)候，JavaScript會被成功觸發(fā)。

4.3 多媒體的元數(shù)據(jù)通道

播放多媒體的手機(jī)app是非常流行的，比如播放歌曲、電影和看圖片。這些多媒體文件都是從互聯(lián)網(wǎng)下載或者朋友分享的，大部分是由音頻、視頻和圖像組成的，看上去很難植入JavaScript代碼。但是，大部分多媒體文件都有被稱為元數(shù)據(jù)的額外區(qū)域，向這里注入代碼是很好的選擇。

MP3、MP4和圖像：MP3 和 MP4 文件是標(biāo)準(zhǔn)的音頻和視頻文件格式。然而，除了視頻和音頻，這類文件還包含很多元數(shù)據(jù)字段，諸如標(biāo)題、藝術(shù)家、專輯、年代等等。當(dāng)用戶使用手機(jī)app聽mp3音樂或者看mp4視頻時(shí)，元數(shù)據(jù)字段中的信息通常會被顯示出來，這樣用戶就知道歌曲的名稱、所屬的專輯、藝術(shù)家名字等等。

圖 6(a)展示了一類典型的MP3播放app的界面，從圖上我們可以看到JavaScript代碼是可以寫入到元數(shù)據(jù)字段的，但是native語言開發(fā)的app只會顯示JavaScript代碼不會執(zhí)行。可以用來向元數(shù)據(jù)字段寫信息的工具有很多，比如iTune、Google Play Music、N7Player等等。

圖像文件情況大體一樣，我們可以從Google Play可以找到很多用于元數(shù)據(jù) 讀取的apps。它們可以顯示作者名字、版權(quán)和圖像᧿述。如圖7(a)所示， JavaScript代碼可以被插入到很多元數(shù)據(jù)字段中并且能夠被native app顯示出 來。現(xiàn)在我們想像下，如果app使用PhoneGap開發(fā)的，使用了存在缺陷的API 從輸出元數(shù)據(jù)會是什么情況。為了展示可能造成的影響，我們開發(fā)了一個這 樣的PhoneGap應(yīng)用，結(jié)果如圖6(b)和圖7(b)所示: 嵌入在元數(shù)據(jù)中的JavaScript 代碼被執(zhí)行了。

調(diào)頻收音機(jī)：無線電波是另外一種潛在的注入代碼到手機(jī)終端的渠道。 近年來，一些新款的智能手機(jī)都有了內(nèi)置的調(diào)頻收音機(jī)，用戶可以收聽當(dāng)?shù)仉娕_的廣播節(jié)目。Verizon無線、AT&T和T-Mobileᨀ供的手機(jī)都是可以收聽廣播的，無線電行業(yè)協(xié)會正在爭取Apple也加入進(jìn)來。Nokia在全球范圍內(nèi)已經(jīng)銷售了超過7億部內(nèi)置調(diào)頻收音機(jī)的手機(jī)，可以看出用戶是認(rèn)可這種功能 ［4］。用戶也愿意付出$20到$50去購買一個可插拔的調(diào)頻收音機(jī)用在手機(jī)上。

如今，調(diào)頻廣播不僅包括音頻軌道，它還包括使用RDS（無線電廣播數(shù)據(jù)系統(tǒng)）協(xié)議的數(shù)據(jù)流。RDS是一種傳統(tǒng)的調(diào)頻廣播中用于嵌入數(shù)字信息的通信協(xié)議。RDS標(biāo)準(zhǔn)化了幾種類型的信息傳遞，包括時(shí)間、電臺號和節(jié)目信息。無線電中數(shù)字信息包括PI（節(jié)目識別），RT（無線電文本），RT是和節(jié)目同步的64字符的自由文本存儲空間（用于存儲標(biāo)題和藝術(shù)家等信息）等。有一種流行的調(diào)頻收音app叫FM TwoO，它已經(jīng)被下載了上百萬次，它可以顯示附加的數(shù)字信息給用戶。

使用GNU-Radio軟件和USRP (成本低于$2000)［7］，攻擊者可以很容易的搭建一個調(diào)頻廣播臺，可以播放他們自己制作的通過RDS通道嵌入了惡意代碼的無線電節(jié)目。如果用戶使用了HTML5 app收聽這種節(jié)目，一旦顯示了嵌入的RDS信息，惡意代碼就會在受害者手機(jī)上被執(zhí)行。

繞過限制條件

在前面的章節(jié)為了簡單起見，我們使用彈框的方式來證明我們可以通過多種通道成功地注入代碼，但是彈框是沒有任何實(shí)質(zhì)性危害的。在本章，我們來研究如何編寫惡意代碼實(shí)現(xiàn)最大限度的攻擊。如果代碼長度沒有限制，這個問題就不需要探討了，因?yàn)楣粽呖梢跃帉懘a實(shí)現(xiàn)他們想做的任何事情。不幸的是在本文描述的攻擊場景下，代碼長度限制是我們需要面對的一個巨大挑戰(zhàn)。例如，在Wi-Fi攻擊中，我們使用SSID字段作為攻擊通道，這個字段只能包含32個字符[15]。問題在于攻擊者能否在這么短的條件下實(shí)現(xiàn)有意義的攻擊，用最小的輸入實(shí)現(xiàn)最大的破壞。

5.1 數(shù)據(jù)通道的長度限制

為了更好的理解長度限制，我們對已經(jīng)識別的可以注入代碼的數(shù)據(jù)通道進(jìn)行了系統(tǒng)的研究。研究的結(jié)果如表2所示：

從表中可以看出，長度限制對MP3/MP4、JPEG、二維碼(QR碼)和NFC這 幾個通道影響不大，它們允許輸入超過2000個字符，這對攻擊者來說足夠了。 不幸的是，Wi- Fi的SSID字段、圖片文件的Model和Maker字段、藍(lán)牙和短信息看上去是非常有限的。特別是Wi-Fi，僅有的能利用的數(shù)據(jù)通道長度被限制 在32字符。在后面的章節(jié)，我們將把這個極端情況作為目標(biāo)。我們將找到辦法利用這32字節(jié)的數(shù)據(jù)通道構(gòu)造可以被注入到手機(jī)終端中的JavaScript代碼。

可以造成的破壞程度取決于實(shí)際注入的代碼，所以病毒代碼的長度取決于 你想取得的攻擊成果。長度可以相當(dāng)長，是否會產(chǎn)生問題由長度限制決定。 為了解決這個問題，我們使用如下的方案：我們通過有長度限制的攻擊通道 注入一段短的代碼到受害者手機(jī)中，這段代碼的目標(biāo)是加載一個外部URL。 因?yàn)橥獠看a是通過常規(guī)數(shù)據(jù)通道（比如網(wǎng)絡(luò)連接）進(jìn)入受害者手機(jī)的，這 時(shí)候就沒有長度限制了。因此，攻擊者可以放置任意代碼實(shí)現(xiàn)最大化的攻擊。

在下面的子章節(jié)，我們會聚焦上面ᨀ到的短的通用代碼，找出能夠引導(dǎo)攻擊或者說能夠引入外部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一年。還有一些長一點(diǎn)的（比如4ac.us）也能夠賣到，價(jià)值$3.99 一年。巧合的是參與本課題的一個學(xué)生擁有一個域名mu.gl（他每年為此支付$49），因此我們在本文中使用http://mu.gl。

盡管URL縮寫方案使用的URL比購買域名來的長一些，但是它依然具有某些優(yōu)勢：不僅免費(fèi)，而且能夠隱藏攻擊者。它們可以輕易的使用別人的web 服務(wù)器部署惡意代碼，而不是使用自己的服務(wù)器。

5.3 壓縮惡意代碼

有很多方法可以引入外部的JavaScript代碼，我們將展示每種場景下最短的引入外部JavaScript文件的方式。

使用Script標(biāo)簽：使用<script>標(biāo)簽是一種典型的引入JavaScript代碼的方式。在這種情況下，我們可以省略“http:” 和 “>”。下面的代碼是我們構(gòu)造的ᴰ短的腳本代碼，長度為28字符:

<script src=//mu.gl></script>

使用事件屬性：不幸的是，正如我們在第3節(jié)中ᨀ到，如果上面用的內(nèi)容被innerHTML顯示，代碼是不會被顯示或執(zhí)行的。為了像上面一樣擊敗 innerHTML，我們需要用另一種方式嵌入代碼。JavaScript可以放在一些HTML 標(biāo)簽的事件屬性中，如onclick、onscroll、onerror和onmouseover事件。這些標(biāo)簽可以是Button標(biāo)簽、A標(biāo)簽、IMG標(biāo)記等等。下面是一個例子：

<img src onerror=jscode>

以上代碼中我們使用了img標(biāo)簽。當(dāng)含有這樣的HTML標(biāo)簽的數(shù)據(jù)在WebView中顯示的時(shí)候，HTML會解析標(biāo)簽并嘗試加載指定的圖像。但是我 們故意沒有ᨀ供圖像源地址，所以會發(fā)生錯誤，這時(shí)onerror屬性指定的代碼 就會被觸發(fā)。這種技術(shù)在運(yùn)行著Android 4.4系統(tǒng)的Nexus 5手機(jī)上測試通過。 早期版本的Android系統(tǒng)，我們需要為src屬性指定一個不存在的URL，例如， 我們需要設(shè)置“src=x”，這樣多了兩個字符。我們的測試使用了Nexus 5，可以 不考慮這種情況。這種包含代碼的方式將繞過innerHTML中實(shí)現(xiàn)的過濾機(jī)制。

然后，這些屬性不允許從外部URL加載JavaScript代碼，所有的代碼都必須寫在屬性里面，這使得我們很難造成較大的破壞。為了解決這個問題，我們使用插入的代碼動態(tài)的生成一段腳本，通過這段腳本引入外部URL。下面是一個例子，一共99個字符：

很多PhoneGap應(yīng)用使用JavaScript庫來簡化自身，jQuery就是一個廣泛應(yīng)用的庫。如果一個app真的使用了jQuery，我們可以將上面的代碼簡化到45個字符。這里要用到j(luò)Query的getScript函數(shù)。這里是一個例子（我們不能省略“http:”，否則getScript無法識別HTTP方法）：

<img src onerror=$.getScript(’http://mu.gl’)>

5.4 繞過長度限制

目前為止，我們借助jQuery能夠構(gòu)造的ᴰ短惡意腳本是45個字符。這個腳 本已經(jīng)能夠適用于我們識別出來的大部分代碼注入通道，但是仍然超過Wi-Fi 的SSID字段32個字符的限制，我們需要想辦法解決這個問題。我們的思路是將這段JavaScript分割成幾份，然后使用eval()把它們拼接在一起。例如，我們可以將上面的$.getScript分割成5份，類似以下代碼：

在上面的代碼中，每一份的長度都不超過32個字符。這種方法是通用的， 換句話說，初始的代碼越長，我們需要分割的份數(shù)就越多。下一個挑戰(zhàn)就是 怎么樣把這些分片的代碼注入到目標(biāo)用戶的手機(jī)上。對某些數(shù)據(jù)通道來說是 很簡單的，因?yàn)檫@些數(shù)據(jù)通道有多個字段可以使用。例如JPEG元數(shù)據(jù)里就有 多個字段可以用，所以我們成功完成攻擊只需要5個字段。當(dāng)目標(biāo)app顯示5個 字段的時(shí)候，惡意代碼就會被成功執(zhí)行。即使目標(biāo)app只顯示一個字段，我們 也可以通過分別注入5份代碼到5個不同圖片的方式進(jìn)行攻擊。

對Wi-Fi來說，只有一個字段我們可以注入代碼，問題就是我們?nèi)绾螌⑸?面的5份代碼同時(shí)注入。這里有兩種方案。第一種方式是使用多個Wi-Fi接入 點(diǎn)。按照上面的例子，我們需要設(shè)置5個接入點(diǎn)，每個分別使用一段代碼作為 其 SSID。當(dāng)目標(biāo)用戶使用有漏洞的app掃描附近的Wi-Fi時(shí)，5份代碼會全部 被注入。我們需要確保最后一份代碼包含eval(a+b+c+d)那一份，必須在目標(biāo) 用戶手機(jī)上最后顯示，因?yàn)檫@一段代碼需要先定義a，b，c 和d。為了達(dá)到這 個效果，我們只需要確保第5個接入點(diǎn)ᴰ后廣播它的SSID就可以了。圖 8(a) 展示了一款叫做WIFI Analyze的non- PhoneGap app5顯示個不同的惡意代碼接 入點(diǎn)的場景。而當(dāng)這5個接入點(diǎn)在PhoneGap app種顯示時(shí)，jQuery 代碼將會被 執(zhí)行。

攻擊者也可以使用一個接入點(diǎn)完成攻擊。大部分Wi-Fi掃描app會定期刷新 屏幕更新可以被檢測到的接入點(diǎn)列表。為了完成我們的攻擊，我們不需要我 們構(gòu)造的惡意的SSID在同一時(shí)間顯示。它們每一個被顯示的時(shí)候，注入在 SSID的代碼就會被執(zhí)行。如果5份代碼都被執(zhí)行了，我們的攻擊就成功了。因 此，我們只需要使用一個接入點(diǎn)、每次將接入點(diǎn)SSID修改其中一份代碼，每 次一個，第5份代碼作為最后一個。在圖8(b)，我們從non-PhoneGap app中在 五個不同的時(shí)間做的5次屏幕截圖，每次都是一個不同的SSID。實(shí)際上，這5個SSID都來自同一個設(shè)備。我們已經(jīng)在我們開發(fā)的PhoneGap app上做了驗(yàn)證，這些驗(yàn)證SSID被顯示的時(shí)候，jQuery代碼就會被執(zhí)行。

PHONEGAP插件

PhoneGap應(yīng)用程序需要使用插件來與Webview之外的對象實(shí)體進(jìn)行交互。 在本章節(jié)中，我們要找到那些存在安全缺陷的插件。如果一個插件使用了不 安全的api顯示從可以攻擊的通道獲取的數(shù)據(jù)，它就是存在安全缺陷的。在本 次研究中，我們從從GitHub [ 6 ]下載了186個第三方插件作為測試對象。

6.1 可被利用的插件

如果一個插件可以被成功攻擊，它需要返回?cái)?shù)據(jù)到WebView中的頁面，并 且數(shù)據(jù)必須是能夠從外部控制的，不是所有的插件都符合這個條件。我們開發(fā)了一個工具對這186個插件進(jìn)行了分析，我們發(fā)現(xiàn)其中58個插件是完全不輸出數(shù)據(jù)的。另外51個插件輸出的數(shù)據(jù)攻擊者無法控制，比如返回邏輯結(jié)果、 常量字符串或者狀態(tài)數(shù)據(jù)等等。換句話說，這些數(shù)據(jù)要么是系統(tǒng)控制的，要 么是開發(fā)者控制的，所以很難從外部注入代碼。剩下的77個插件是符合我們 要求的，它們可以進(jìn)一步按照數(shù)據(jù)來源分成三類，如下表 (Table 3).

在這77個插件中，24個插件從Web中獲取數(shù)據(jù)（例如，PhoneGap插件可以獲取Facebook 和 Twitter上的數(shù)據(jù)）。這些數(shù)據(jù)也可能包含惡意代碼，但是這些風(fēng)險(xiǎn)（比如XSS）已經(jīng)廣為人知了，我們不再對這類插件進(jìn)行討論。另外38個插件從手機(jī)設(shè)備資源獲取數(shù)據(jù)（例如日歷和通訊錄），換而言之，數(shù)據(jù)通道是內(nèi)部的。這些數(shù)據(jù)可能包含代碼，攻擊者必須先安裝一個惡意的app 能夠?qū)阂饽_本注入這些資源，然后一個有缺陷的PhoneGap app顯示來自這些資源的數(shù)據(jù)時(shí)，惡意腳本才能以目標(biāo)app的權(quán)限執(zhí)行。這個通道也可以用來在同一個手機(jī)上進(jìn)行跨PhoneGap app攻擊。

我們的主要興趣在“外部數(shù)據(jù)”這一類，其中包含15個插件。它們從外部資源獲取數(shù)據(jù)，并返回?cái)?shù)據(jù)到的WebView的頁面中。我們對它們進(jìn)行了更深入的研究。

6.2 存在安全缺陷的插件

在我們研究的15個插件中，有四個是語音識別和信用卡掃描相關(guān)的。鑒于讀出JavaScript并讓app識別和獲取信用卡掃描硬件都比較困難，我們沒有對這四個插件進(jìn)行研究。因此，我們的研究范圍縮小為這11個插件。在這11個插 件中，有5個自帶JavaScript代碼，包括3個藍(lán)牙插件、1個Wi-Fi插件和一個短 信插件。研究過以后，我們發(fā)現(xiàn)ᨀ供這些JavaScript代碼有兩個目的：一個目 的是為開發(fā)者ᨀ供示例代碼，告訴他們?nèi)绾问褂眠@個插件；另外一個目的是 提供JavaScript庫，使得插件使用起來更容易。這兩種情況下，如果插件自帶 的JavaScript代碼是有缺陷的，將導(dǎo)致非常顯著的破壞，因?yàn)榇蟛糠謅pp開發(fā)者 要么直接使用ᨀ供的庫要么參考示例代碼的寫法。從插件包含的JavaScript代
碼，我們發(fā)現(xiàn)它們基本上都使用innerHTML或者h(yuǎn)tml() 顯示數(shù)據(jù)。因此，如 果數(shù)據(jù)包含惡意代碼就會被執(zhí)行。我們已經(jīng)通過試驗(yàn)證實(shí)了我們的推斷。

另外的六個插件，它們沒有ᨀ供有缺陷的JavaScript代碼，但是仍然有潛在 的安全缺陷的，因?yàn)樗鼈儧]有過濾來自可被利用通道的代碼。如果PhoneGap app使用這些插件并且碰巧也使用了存在缺陷的數(shù)據(jù)輸出api，將會造成安全漏 洞。考慮到這些有缺陷的API在PhoneGap app中是被廣泛使用的 (參考Table 1)，我們相信開發(fā)者將這幾個插件和這些API一起使用進(jìn)而造成安全漏洞的概率會比較高。在第四章中我們開發(fā)的存在漏洞的app，我們就使用了這些插件 （包括二維碼、 NFC和短信插件）。這表明這些插件和錯誤的api使用方法組 合起來將會導(dǎo)致存在漏洞的app。

案例研究

通過我們自己開發(fā)的程序研究過這些潛在的攻擊以后，我們非常想知道現(xiàn) 實(shí)中真實(shí)存在的app是否也受這種攻擊的影響。出于這個目的，我們進(jìn)行了有 步驟的搜索。我們從Google Play上下載了25類共計(jì)12，068個免費(fèi)的app，包 括旅游、交通以及社交等等。我們識別出了190個PhoneGap app。從PhoneGap 官方網(wǎng)站[12]我們收集了另外574免費(fèi)的PhoneGap app，我們一共收集了764 個PhoneGap app。雖然這個數(shù)字相對Google Play上的海量軟件來說是比較小的，但是我們相信隨著HTML5 app越來越流行，這個數(shù)字會在短期內(nèi)顯著的
增長。

為了確定一個PhoneGap是否受這種攻擊的影響，我們用AndroGuard [2]寫了一個Python工具來掃瞄這764個PhoneGap app，分析如下的信息：

• app是否從我們已經(jīng)識別的通道中讀取外部數(shù)據(jù)

• app是否使用存在缺陷的API或?qū)傩燥@示信息

顯示的信息是否來自以上的通道

我們發(fā)現(xiàn)結(jié)果如下：

(1) 142個app符合第一個條件。

(2) 290個app至少使用了一種有缺陷的API或者屬性顯示信息

結(jié)合以上兩點(diǎn)，我們發(fā)現(xiàn)32個app符合前兩個條件。我們沒有去寫復(fù)雜的數(shù)據(jù)流分析工具去檢查是否符合第三個條件，而是手工對這32個app進(jìn)行了分析。ᴰ終，我們發(fā)現(xiàn)有兩個app符合第三個條件。這意味著，他們非常有可能存在漏洞。我們用真實(shí)的攻擊方法對他們進(jìn)行了測試，結(jié)果證明他們確實(shí)存在漏洞。我們會在本章后面部分給出試驗(yàn)細(xì)節(jié)。

案例研究 1: GWT移動PhoneGap示例應(yīng)用。這是一個PhoneGap示例app，他告訴開發(fā)者如何使用PhoneGap和它的插件。這個app使用全部的三個內(nèi)置插件和三個第三方插件——ChildBrowser插件,Bluetooth插件和Facebook插件。這個app授予了這些插件全部權(quán)限。

這個app的一個功能是使用Bluetooth插件列出所有能檢測到的Bluetooth設(shè)備（通常是為了配對的需要）。不幸的是，它使用了innerHTML 顯示Bluetooth 設(shè)備的名稱。這個API是可以進(jìn)行代碼注入攻擊的。

為了對這個存在漏洞的app進(jìn)行攻擊，我們把攻擊設(shè)備調(diào)成藍(lán)牙模式，把惡意的JavaScript代碼嵌入名稱字段（長度限制為248，足夠使用）。為了比較，我們同時(shí)還用了一個non-PhoneGap app做Bluetooth配對，測試結(jié)果圖9(a)，從中我們可以看出在non-PhoneGap app中代碼作為純文本顯示了。

代碼如下所示（為了方便閱讀，我們加了一些空格）

PhoneGap.exec() 最終會觸發(fā)一個WebView之外的PhoneGap方法（Java代 碼），它需要5個參數(shù)。后面的三個參數(shù)在上面代碼第九行，分別是插件名稱 (Contacts)，需要通過插件調(diào)用的方法 (search)，還有傳遞給方法的參數(shù)。簡單的說，這三個參數(shù)請求PhoneGap返回手機(jī)通訊錄中的所有姓名。如果 PhoneGap.exec()請求失敗，第八行的函數(shù)會被執(zhí)行（這里是空函數(shù)）。如果請求成功，第2-7行定義的函數(shù)會被調(diào)用，這里就是要實(shí)現(xiàn)的攻擊效果。

當(dāng)這個回調(diào)函數(shù)被調(diào)用后，PhoneGap插件返回的數(shù)據(jù)會存儲到變量a中，它是一個存儲了從通訊錄中讀取到的姓名的數(shù)組。從第3行到第4行，我們看 到代碼利用通訊錄的數(shù)據(jù)構(gòu)造了一個叫m的字符串。在第5行，出于演示的目的，我們將這個字符串顯示出來了（參考圖9(b)）。在第6行的真實(shí)攻擊中， 看上去我們只是構(gòu)造了一個img標(biāo)簽，但是它的真實(shí)目的是調(diào)用一次HTTP GET 方法請求遠(yuǎn)程服務(wù)器（攻擊者控制的），通過這個請求將竊取的通訊錄數(shù)據(jù)發(fā)送給攻擊者。

作為一個PhoneGap演示app，存在漏洞的GWT移動PhoneGap示范程序?qū)φ鎸?shí)的app有很大的影響，因?yàn)殚_發(fā)者通常是通過這樣的演示程序?qū)W習(xí)怎么開發(fā)PhoneGap app（這個app的源代碼可以從GitHub [9]上獲取到）。在公開本文之前，我們已經(jīng)聯(lián)系這個app的開發(fā)團(tuán)隊(duì)修復(fù)了漏洞。

研究案例 2: RewardingYourself app。This app manages users’ miles or points in their loyalty program and find out how much they are worth. （譯者注：這句 實(shí)在是看不懂，望高手賜教）。這個app使用了所有PhoneGap官方插件和一個第三方的條形碼掃描插件。當(dāng)這個app掃描一個條形碼時(shí)，會使用可以被注入代碼的innerHTML顯示條形碼里面的數(shù)據(jù)。我們制作一個包含如下腳本的二維碼：

這段代碼使用Geolocation.watchPosition()來竊取用戶的物理位置。這個API 是HTML5中引進(jìn)的，它注冊了一個當(dāng)終端的物理位置變化時(shí)就會被自動調(diào)用 的處理函數(shù)。從代碼中我們可以看到處理函數(shù)被調(diào)用時(shí)，位置信息會被存儲 到變量loc中并且在第六行顯示（見圖10(b)）。在第7行和第8行，loc的內(nèi)容被發(fā)送到外部電腦。由于處理函數(shù)時(shí)被循環(huán)調(diào)用的，一旦受害者掃描了二維碼，
只要這個有漏洞的app在運(yùn)行，手機(jī)就會不斷的發(fā)送位置信息給攻擊者 (見Figure 10(c))。

這個app也可以在其他平臺上使用，包括iOS和Blackberry。不幸的是，我們在iOS上無法使用它掃᧿二維碼。它依賴于另外一個二維碼掃描app來讀取二維碼，但是這個app不能在iOS上工作。這個RewardingYourself app可以用在Blackberry，我們使用同樣的二維碼進(jìn)行攻擊測試獲得了成功。這證明了我們的攻擊方法是和平臺無關(guān)的假設(shè)。

解決方案和其他相關(guān)工作

找到這種威脅的解決方案已經(jīng)超出了本文范疇，這將是我們下一階段研究 的焦點(diǎn)。在本文中，我們參考XSS攻擊的解決方案簡單的給出一些解決問題的思路。理論上來看這些方法是可行的，但是在實(shí)戰(zhàn)中運(yùn)用還有很多工作要做。

基于數(shù)據(jù)凈化的解決方案：數(shù)據(jù)凈化是一種常見的技術(shù)，它通過過濾數(shù)據(jù)中混雜的代碼來阻止代碼注入攻擊。凈化后的數(shù)據(jù)變成一個純文本無法觸發(fā)代碼執(zhí)行。基于凈化的解決方案已經(jīng)在web安全領(lǐng)域被廣泛研究，面臨的主要挑戰(zhàn)是如何識別出混雜在數(shù)據(jù)中的代碼。人們提出了很多方法來解決這個問題，包括Bek [22]、CSAS [31]、ScriptGard [32]等。不幸的是，不斷有新的繞過現(xiàn)有凈化方案的攻擊方式被ᨀ出[20，21]。

我們可以采用一些凈化方法移除字符串種的腳本來阻止攻擊；但是挑戰(zhàn)在于我們在什么地方進(jìn)行數(shù)據(jù)凈化。對XSS攻擊而言很簡單，它只有一種數(shù)據(jù)通道（web服務(wù)器）。但是對于我們ᨀ出的攻擊，有很多通道可以用來注入代碼。有很多地方可以進(jìn)行凈化操作：其中一個地方是PhoneGap框架，這是所有外部數(shù)據(jù)進(jìn)入WebView的唯一通道。然而這種方案僅限于PhoneGap。如果我們能在WebView種進(jìn)行凈化會更合理，這是一個更通用的方案，但是目前還不清楚這種處理是否會影響WebView原有的功能。

基于污點(diǎn)分析的解決方案：另外一種方案是采用污點(diǎn)分析來確定是否存在代碼注入漏洞。污點(diǎn)分析框架可以被應(yīng)用在服務(wù)端[25，28，30，36] 或者客戶端[19，29]。污點(diǎn)分析的思路是標(biāo)記不可信輸入，跟蹤他們在程序中的擴(kuò)散。任何直接或者間接執(zhí)行污染數(shù)據(jù)的嘗試都會被記錄和阻止。

使用污點(diǎn)分析方案，我們必須標(biāo)記進(jìn)入終端的外部數(shù)據(jù)。挑戰(zhàn)在于需要跟蹤數(shù)據(jù)通過終端設(shè)備、Dalvik虛擬機(jī)、JavaScript引擎和不同組件之間的處理過程。如果我們能做到這些，我們就可以阻止代碼被觸發(fā)，甚至可以阻止惡意代碼進(jìn)入終端設(shè)備。

緩解破壞：與阻止代碼注入攻擊的思路不同，很多研究者致力于緩解腳本注入造成的破壞。這個想法是限制不可信代碼的力量。開發(fā)者需要配置一些 策略，基于內(nèi)容的可信程度對每個DOM元素賦予不同的權(quán)限。例如，Escudo [23] 和Contego [26] 在某些特定的DOM元素中限制腳本的權(quán)限。內(nèi)容安全策 略[33，35] 為JavaScriptᨀ供了一個嚴(yán)格的制約，不允許inline方式執(zhí)行JavaScript 和eval()。CSP可以解決本文ᨀ出的問題，但是強(qiáng)制使用缺省的CSP策略需要app開發(fā)者付出巨大的努力去修改現(xiàn)有的app，因?yàn)閷⒉恢С謎nline-JavaScript。CSP對HTML5 app保護(hù)的有效性值得進(jìn)一步研究。這個框架是為瀏覽器設(shè)計(jì)的，但是我們可以參考上面的思路來做緩解攻擊的工作，換句話說，我們可以開發(fā)一個安全的 WebView為HTML5手機(jī)appᨀ供可信計(jì)算的基礎(chǔ)。

其他相關(guān)工作：WebView和PhoneGap是HTML5手機(jī)app的重要組成部分。很多研究已經(jīng)揭示了他們的安全性 [17，18，24，27，34]。NoFrak [18]和[24] 關(guān)注如何阻止不可信的外部web代碼訪問手機(jī)本地資源。他們的解決方案不能用于防御我們的攻擊，因?yàn)槲覀兊墓舴绞街写a來自的外部通道不屬于web。
XCS [16] 發(fā)現(xiàn)了很多有趣的注入代碼到服務(wù)器的通道，比如打印機(jī)、路由器 和電子相框等。一旦代碼被web接口搜索，就會在桌面瀏覽器上執(zhí)行。在我們 的工作中，大部分?jǐn)?shù)據(jù)通道是完全不同的手機(jī)平臺的，研究的問題也是完全不同的攻擊方式。

總結(jié)和未來的工作

在本文中，我們發(fā)現(xiàn)了一種新的針對HTML5手機(jī)app的代碼注入攻擊。我們在手機(jī)終端上使用poc app和真實(shí)的app系統(tǒng)的研究了這種攻擊的可行性。
HTML5 app以其可移植性優(yōu)勢已經(jīng)越來越流行，我們預(yù)計(jì)這種攻擊將在不久的將來爆發(fā)。能夠在爆發(fā)前識別這種攻擊是非常重要的，它可以幫助我們在思維中明確各種技術(shù)例如PhoneGap所帶來的風(fēng)險(xiǎn)是不斷變化的。在我們下一步的工作中，我們會開發(fā)解決這種攻擊的解決方案，和PhoneGap團(tuán)隊(duì)（還有其他類似團(tuán)隊(duì)）一起找到切實(shí)可行的解決方案，在保持HTML5手機(jī)app優(yōu)勢的基礎(chǔ)上提高其安全性。

10. 致謝

我們要感謝多位匿名審稿人有價(jià)值和令人鼓舞的評論。這個工作獲得了NSF 的資助和Google的研究獎勵，但是本文的任何意見、成果、結(jié)論和意見并不受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）