HTML5 App的代碼注入攻擊
當前位置：點晴教程→知識管理交流
→『 技術(shù)文檔交流 』
摘要基于HTML5的手機app（譯者注：以下簡稱HTML5 app）越來越流行了， 在大多數(shù)情況下它比native應(yīng)用更容易適配不同的移動操作系統(tǒng)。它開發(fā)起來很方便，可以使用標準的web技術(shù)，包括HTML5、JavaScript 和 CSS，也可以借助一些現(xiàn)有的開發(fā)框架（比如PhoneGap）和手機操作系統(tǒng)進行交互。 眾所周知，JavaScript是非常容易遭受代碼注入攻擊的，因此我們計劃對HTML5 app進行一次系統(tǒng)的研究以評估基于web技術(shù)開發(fā)的手機app安全性是否可靠。成果令人吃驚，我們發(fā)現(xiàn)如果HTML5 app成為主流（至少目從目前的趨勢看是這樣的），我們很多日常行為習慣都可能引入安全風險，包括二維碼掃瞄、Wi-Fi接入點掃描、播放MP4視頻、配對藍牙設(shè)備等等。 本文介紹了HTML5 app可能存在的各種漏洞，攻擊者如何利用各種途徑進行攻擊以及攻擊成功后可能造成的危害。除了通過樣例程序演示攻擊以外， 我們還研究了PhoneGap 186款用于實現(xiàn)不同功能的插件，我們發(fā)現(xiàn)其中11款是有漏洞的。我們還對兩款真實的HTML5手機進行了安全測試，發(fā)現(xiàn)它們也是有漏洞的。 介紹故事從John Smith開始，他是一個普通人。和大多數(shù)人一樣，他使用了一 款裝滿了各種app的智能手機，這個智能手機是他每天生活的一個重要組成部分。早上7點起床，John吃早餐的時候會打開手機里面的app聽收本地的廣播節(jié)目。這個app可以顯示當前頻段正在播放的音樂的名稱，他可以搜索不同的頻段收聽他喜歡的音樂。8點的時候，他乘公共汽車上班。他看到一個有趣的產(chǎn)品廣告貼在他前面座位的背后。為了了解更多產(chǎn)品信息，他用手機上的RFID刷了這個廣告標簽。忙完了上午的工作后，John在一家新開的餐館吃午餐。為了節(jié)省手機流量費，他用手機搜索免費的Wi-Fi熱點。他很高興的發(fā)現(xiàn)有好幾個免費熱點可以使用。下午5點，John下班回家。在公共汽車上他開始聽他下載的MP3歌曲。他的手機MP3 app能夠播放MP3文件里面的歌詞，這讓他非常開心。下車以后，他收到了他媳婦的短信讓他買一些好吃的帶回家。 他去了超市，在超市里門口他看到有二維碼貼在那里。他知道二維碼是打折信息就馬上掃了下，他很高興的發(fā)現(xiàn)可以有5美元的優(yōu)惠。 上面這個故事展示了手機在我們?nèi)粘Ｉ钪惺褂玫钠毡樾?，看上去沒有必 要為這些使用場景擔心。然而這只是目前的情況，一種迅速發(fā)展的技術(shù)趨勢將很快改變一切。當這種技術(shù)被廣泛采用以后，故事里面John的每個行為都可能引入安全風險。廣播節(jié)目、RFID標簽、MP3文件、Wi-Fi接入點、SMS信息和二維碼都可能成為攻擊者注入惡意代碼到John的智能手機的通道，會導致很多危害。惡意代碼不僅僅會駐留在他的手機，還會像蠕蟲一樣向其他手機進行傳播。這種技術(shù)越流行，這種惡意代碼就傳播的越迅速。 這種技術(shù)就是HTML5技術(shù)，它是HTML5 app的基礎(chǔ)。在這種技術(shù)被用來開發(fā)手機app之前，絕大多數(shù)的手機app都是使用各自系統(tǒng)支持的native語言編寫的。比如Android app往往使用Java編寫，iOS app使用Objective-C編寫，跨平臺移植app是比較麻煩的。因為Android和iOS使用量都很大，開發(fā)者往往沒有選擇，只能使用不同語言開發(fā)兩個不能版本的app。如果以后其他手機操作系統(tǒng)用戶多了，開發(fā)者將會更加悲劇。 HTML5 app技術(shù)為這個問題提供了一個解決方案。和native apps不同的是， 這種app是使用HTML5技術(shù)開發(fā)的，這是一種和平臺無關(guān)的技術(shù)，所有手機操作系統(tǒng)都支持這種web技術(shù)。這種app使用HTML5和CSS繪制用戶界面，使用JavaScript實現(xiàn)程序邏輯。因為HTML5、CSS和JavaScript是跨平臺的，所以這種app從一個平臺移植到另外一個平臺也是很容易的，在一定程度上來說甚至是通用的?；谶@種優(yōu)勢，基于HTML5的app在迅速普及。Evans Data做的一個針對1200名開發(fā)者的調(diào)查發(fā)現(xiàn)使用HTML5技術(shù)進行app開發(fā)的占到了75%[1]。Gartner最近的一項報告稱，在市場占有率上，HTML5 app將在2016 年和native app平分秋色。 非常不幸的是，使用HTML5、JavaScript和CSS開發(fā)app將引入natvie語言開發(fā)中不存在的安全風險。目前Web安全中仍然面臨的跨站腳本攻擊（XSS）問題很大程度上是由于數(shù)據(jù)和代碼混雜在一起造成的，攻擊者可以通過注入字符串執(zhí)行代碼。在我們的場景下，所有數(shù)據(jù)都是從不可信的外部通道獲取的。如果這些數(shù)據(jù)中包含代碼并且app開發(fā)者沒有意識到這個風險，外部注入的代碼有可能就會在app內(nèi)部執(zhí)行導致安全破壞。這是一種假想的潛在攻擊方式，是否能夠真正在手機設(shè)備上完成是未知的。本文對這種攻擊方式進行了系統(tǒng)的研究。我們研究的發(fā)現(xiàn)包括如下：
文章剩下的內(nèi)容結(jié)構(gòu)是這樣的：第2章介紹WebView和PhoneGap框架。第3章介紹如何進行攻擊。第4章介紹攻擊渠道和場景。第5章攻擊者面需要面對的挑戰(zhàn)并展示了如何解決它們。第6章和第7章介紹PhoneGap插件和真實手機app的漏洞。章節(jié)8和9討論相關(guān)的工作、解決方案和研究總結(jié)。 背景知識HTML5 app不能直接在手機操作系統(tǒng)上運行，無論是Android還是iOS都不能直接運行HTML5和JavaScript，需要有一個web容器渲染基于HTML5的用戶界面和執(zhí)行JavaScript代碼。大部分手機操作系統(tǒng)都這樣一個容器：Android 的WebView、iOS的UIWebView以及Windows Phone的WebBrowser。為了簡化過程，本文中使用WebView作為研究對象。WebView最初被設(shè)計的目的是為了方便native app引入和展示web頁面。它將基礎(chǔ)的web瀏覽器功能封裝到一個類里面，可以被app當作瀏覽器組件來使用。通過WebView提供的API函數(shù)，移動應(yīng)用也可以繪制HTML頁面。 由于WebView引入的Web內(nèi)容往往是不可信的，WebView像瀏覽器一樣實現(xiàn)了沙盒機制，JavaScript代碼只能運行在一個孤立的環(huán)境中。這樣的沙盒技術(shù)是適用于Web的，但是對于手機app來說過于嚴格了。一個運行在孤立環(huán)境中的手機app是沒有太多用途的，因為它無法訪問系統(tǒng)資源，如文件、觸摸屏、攝像頭等。WebView組件運行應(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īng)有人開發(fā)了很多中間件，包括PhoneGap [12]，RhoMobile [13]， Appcelerator [3]等。在本文中我們將關(guān)注流行的PhoneGap，但是我們的攻擊方式是影響所有中間件的。我們的研究是在Android平臺上，但由于app的跨平臺特性，其他平臺也存在這類安全缺陷，也受這種攻擊的影響。PhoneGap和PhoneGap插件：PhoneGap幫助開發(fā)者使用標準的web技術(shù)創(chuàng)建HTML5 app。開發(fā)者可以使用HTML頁面、JavaScript代碼和CSS文件。 PhoneGap框架默認使用WebView，依賴WebView渲染HTML頁面和執(zhí)行 JavaScript代碼。
PhoneGap由兩部分組成（圖1）：框架部分和插件部分，框架部分是溝通WebView中的代碼和插件模塊的橋梁，插件部分負責系統(tǒng)和外部交互的具體實現(xiàn)。對于每種類型的資源如相機、手機短信、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ā)者如何使用這個插件。當WebView中的JavaScript代碼 需要訪問系統(tǒng)或外部資源時，它可以調(diào)用插件庫提供的API函數(shù)，插件庫中代 碼將調(diào)用PhoneGap API，最后通過PhoneGap框架調(diào)用對應(yīng)的插件中的Java代 碼。當插件完成它的工作后，它通過PhoneGap框架返回處理后的數(shù)據(jù)到頁面。 這是JavaScript代碼通過WebView獲取系統(tǒng)或外部資源的過程，圖1描述了完整 的過程。 代碼注入攻擊Web技術(shù)有一個廣為人知的危險特性：它允許數(shù)據(jù)和代碼混雜到一起，比如當一個字符串包含數(shù)據(jù)和代碼時，代碼會被識別出來并且被JavaScript引擎執(zhí)行。這是一種功能設(shè)計，這樣可以讓JavaScript代碼很方便的嵌入到HTML 頁面中執(zhí)行。不幸的是，這個功能的后果是，如果開發(fā)商只想處理數(shù)據(jù)，但使用了錯誤的API，字符串中的代碼會自動和錯誤的觸發(fā)。如果這樣的數(shù)據(jù)和代碼混合字符串來自不可信的輸入，惡意代碼就可以被注入到應(yīng)用程序中執(zhí) 行，這就是JavaScript代碼注入攻擊。其中一種典型代表就是被我們稱為跨站點腳本（XSS）的，根據(jù)OWASP top10［11］，這是目前Web應(yīng)用程序中的第三常見的安全風險。 3.1 概述 使用Web技術(shù)開發(fā)的手機app將制造一種新的蠕蟲，它可以將針對特定的手機應(yīng)用程序注入惡意代碼。這種攻擊破壞性比Web應(yīng)用程序的XSS攻擊要大很多，不僅僅因為我們給手機上安裝的app授予了很多權(quán)限，更因為在XSS攻擊中惡意代碼的注入大多數(shù)都需要通過Web應(yīng)用服務(wù)器，這是惡意數(shù)據(jù)到達他們攻擊目標的唯一通道，而在手機應(yīng)用場景下有非常多可利用的攻擊通道。這些通道的一個共同的特點是，他們都是連接移動設(shè)備和外界的通道，實質(zhì)上是遭受從另一個設(shè)備（不一定是一個手機設(shè)備）進行攻擊的通道。圖2（a）說明了攻擊的基本思路。
由于智能手機實時地與外面的世界交互，和傳統(tǒng)的網(wǎng)絡(luò)通道相比有更多新的通道可以輸入不可信的數(shù)據(jù)到手機設(shè)備。例如，二維碼、RFID標簽、媒體文件、Bluetooth設(shè)備和Wi-Fi接入點等，惡意代碼可以嵌入在這些通道數(shù)據(jù)里面。 如果數(shù)據(jù)混合的代碼沒有機會被觸發(fā)，就不會有代碼執(zhí)行造成的風險。這就是natvie語言開發(fā)的手機app能夠免疫這種代碼注入攻擊的原因。例如，即使攻擊者可以嵌入Java代碼到二維碼里面，也沒有機會誤觸發(fā)執(zhí)行這些代碼。但由于web技術(shù)的危險特性，這不適用于HTML5 app。特別地，app將數(shù)據(jù)顯示出來是很常見的，例如展示一個二維碼對應(yīng)的信息。有一些Web技術(shù)的API “很帥”：他們可以從代碼中分離數(shù)據(jù)，將數(shù)據(jù)發(fā)送到HTML渲染引擎，將代碼發(fā)送到JavaScript引擎，這里并沒有考慮開發(fā)者本意是否是要執(zhí)行代碼。 當代碼被執(zhí)行時，它可以利用分配給應(yīng)用程序的權(quán)限在移動設(shè)備上進行攻擊，在WebView中使用PhoneGap框架和HTML5的API打開一個“攻擊窗口”。 3.2 觸發(fā)注入的代碼 有兩種常見的方式可以觸發(fā)執(zhí)行數(shù)據(jù)字符串中包含的JavaScript代碼。一種是使用eval()函數(shù)，這個函數(shù)可以把字符作為JavaScript代碼執(zhí)行。這種風險不是很常見，因為程序員知道輸入的字符串是不能包含非法字符的。另外一種觸發(fā)代碼執(zhí)行的方式是通過DOM顯示API和屬性，比如document.write()，appendChild()，innerHTML（屬性）等。一些jQuery API也可以觸發(fā)代碼執(zhí)行，比如html()和append()，它們也是基于顯示API和屬性實現(xiàn)的。JavaScript通過這些API和屬性顯示信息在HTML頁面中（在PhoneGap應(yīng)用程序中，這些頁面就是用戶界面）。在第二種場景中，觸發(fā)執(zhí)行字符串中的代碼在web環(huán)境下可能是因為業(yè)務(wù)需要，但是手機app中這種需求很少見。 不是所有顯示API和屬性都能執(zhí)行字符串中的代碼，這取決于代碼嵌入的方式。在一個HTML頁面中，有兩種典型的代碼和數(shù)據(jù)混雜在一起的場景：腳本或標簽事件屬性。下面給出這兩種場景的示例代碼：
當那兩個字符串被傳遞給DOM/j- Query顯示API和屬性時，代碼alert(‘a(chǎn)ttack’)是否可以被執(zhí)行的總結(jié)如表1所示。我們統(tǒng)計了在代碼中使用每個api和屬性PhoneGap app的所占比例（我們收集的764 app）。 3.3 危害 這種攻擊所能造成的危害如圖2(b)所示，可以分成三類：一種是直接攻擊受害者手機終端造成的（圖中用細的帶箭頭標示），另外兩種是惡意代碼形成的擴散攻擊 (圖中用粗的帶箭頭的線標示)。 首先，注入的惡意代碼可以通過WebView中的代碼打開的“窗口”直接對 手機終端進行攻擊。由于WebView的沙盒機制，正常情況下JavaScript代碼是不能對終端設(shè)備造成太大破壞的。但是為了方便訪問操作系統(tǒng)和硬件設(shè)備，手機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。在手機終端上，不同的app共享數(shù)據(jù)是很常見的。例如，通訊錄是共享的，所以當一個應(yīng)用程序受到外部攻擊時，惡意代碼可以把自己插入到通訊錄中。 當另外一個存在漏洞的PhoneGap app讀取并顯示存有惡意代碼的通訊錄時，代碼就會被觸發(fā)執(zhí)行，這樣就可以在第二個app里面進行攻擊。有很多類似這樣的內(nèi)部數(shù)據(jù)通道可以被利用，比如通訊錄、日歷、圖像和SD卡上的MP3/MP4文件等。 第三，注入的惡意代碼可以將被感染的手機終端設(shè)備變成攻擊跳板終端設(shè)備，它可以使用相同的攻擊技術(shù)去感染其他手機設(shè)備。比如，被感染的app有權(quán)限發(fā)短信，惡意代碼就可以通過發(fā)送帶病毒的短信到通訊錄中所有好友的方式進行傳播。它也可以將代碼加入到MP3文件的元數(shù)據(jù)字段中，然后分享給好友。它也可以偽裝成一個藍牙設(shè)備，名字設(shè)置成惡意代碼，等待其他設(shè)備使用有漏洞的app連接。手機終端上裝的PhoneGap應(yīng)用越多，這種傳輸型的攻擊就越容易成功，惡意代碼就傳播的越快。 代碼注入通道在這個章節(jié)，我們來研究如何識別可以注入代碼到終端設(shè)備中的數(shù)據(jù)通道。為了演示我們是如何利用這些通道進行攻擊的，我們需要找出app中使用了這些通道并且使用不安全的API顯示數(shù)據(jù)的場景?？紤]到我們只收集了幾百個PhoneGap app，它們中的大部分要么沒有使用這些通道要么沒有顯示這些通道獲取的數(shù)據(jù)，所以使用真實的app做這個演示還是比較困難的。因此我們自己動手開發(fā)了用于演示各種攻擊通道的PhoneGap app，為了保證研究的科學性，我們嚴格遵守以下原則： （1）使用已存在的PhoneGap插件； （2）如果一個PhoneGap插件有自己的JavaScript庫，我們就使用它； （3）我們使用的存在漏洞的API是現(xiàn)有的PhoneGap應(yīng)用程序中常用的； （4）PhoneGap應(yīng)用程序?qū)崿F(xiàn)的功能是現(xiàn)有的app中很常見的，不是特意制造的（作為證明，我們隨時可以用非PhoneGap應(yīng)用程序?qū)崿F(xiàn)相同的功能）。 所有的攻擊演示都可以在我們的網(wǎng)站上看到［10］。 4.1 ID通道 在很多情況下，手機在連接到外部實體設(shè)備之前，會獲取外部實體的ID并且展現(xiàn)給用戶看。這就建立了手機和外部實體的通道，甚至是在它們連接之前。我們研究這種通道是如何被用來注入惡意代碼到手機設(shè)備中的。 Wi-Fi接入點：搜索附近的Wi-Fi接入點，很多智能手機用戶都使用Wi-Fi scanner app來掃᧿周圍可用的Wi-Fi熱點。這類app會顯示掃᧿到的Wi-Fi熱點名稱（SSID）和其他信息給用戶。圖3(a)是WIFI Analyzer顯示的結(jié)果，這是一款從Google Play免費下載到的軟件。在Google Play上有超過250款同類的軟件，其中一些是非常流行的下載量超過1000萬。
隨著這類app的流行，不難想像在不久的將來其中的很多app都有可能是基于HTML5開發(fā)的。當這種情況場景變成現(xiàn)實，Wi-Fi熱點的SSID將變成一個潛在的代碼注入通道。為了展示這種攻擊，我們把一個Android手機配置成一個接入點。Android允許將接入點的SSID設(shè)置成任意字符串，我們將SSID設(shè)置為如下的JavaScript代碼 圖3(a)顯示的是我們設(shè)置JavaScript代碼，它在SSID中沒有執(zhí)行因為這個 app是用Java開發(fā)的。如果這個app應(yīng)用程序是用PhoneGap，開發(fā)的，SSID會在 WebView 顯示，這里就容易產(chǎn)生一個高危的錯誤。如果app使用了不安全的API顯示SSID，JavaScript就會被執(zhí)行。 為了證明這個推斷，我們使用PhoneGap框架和它的Wi-Fi插件寫了一個Wi-Fi熱點掃描app。如圖3（b）所示的結(jié)果，這一次沒有正確的顯示SSID， 而是作為代碼執(zhí)行了。在這個app里面，我們沒有做任何特殊的處理。在開發(fā)這個app的時候，我們使用了html()函數(shù)來顯示SSID信息，根據(jù)我們收集的數(shù) 據(jù)來看，有16.36%的PhoneGap app做法是和我們一樣的。即使我們使用 innnerHTML替換顯示API，它比html()更安全并且不會執(zhí)行內(nèi)部的script標簽中的代碼，我們依然有辦法完成代碼注入攻擊。在第五章中我們會給出相關(guān)的細節(jié)。 考慮到使用移動終端設(shè)置一個Wi-Fi接入點是非常容易的，這種攻擊實施起來成本很低。在本章節(jié)，我們沒有展示可以取得的攻擊成果（只彈一個alert() 是沒有危害的）。在第五章節(jié)，我們會介紹如何通過惡意代碼進行真正的攻擊和破壞。 BlueTooth：藍牙具有類似的屬性，在第一次使用BlueTooth連接其他外部設(shè)備的時候，需要進行配對。它會顯示所有所有被探測到的BlueTooth設(shè)備ID，用戶可以選擇其中的一個進行配對。和Wi-Fi一樣，這個ID也打通了從移動終端到其他外部BlueTooth設(shè)備的數(shù)據(jù)通道。只要能收到BlueTooth設(shè)備的信號，ID數(shù)據(jù)就可以直接進入移動終端設(shè)備。 這種攻擊和Wi-Fi上的攻擊非常相似：攻擊者需要打開它手機上的BlueTooth功能，使用惡意的JavaScript作為設(shè)備名稱，然后廣播它的名稱到附近的設(shè)備。附近的任何手機終端只要使用存在缺陷的PhoneGap app去連接配對，就會變成受害者。我們在Google Play上找到一款可攻擊的PhoneGap app。在第七章我們會給出細節(jié)作為一個研究案例。 4.2 不同手機終端之間的數(shù)據(jù)通道 除了從網(wǎng)絡(luò)、Wi-Fi以及藍牙獲取數(shù)據(jù)外，手機終端還有一些與傳統(tǒng)的臺式機和筆記本完全不同的獲取數(shù)據(jù)的通道。比如，大部分智能手機可以掃᧿二維碼（使用相機功能）、接收短信，還有一些智能手機支持讀取RFID卡功能。這些數(shù)據(jù)通道使得用戶從外界獲取信息非常方便，所以被廣泛使用在手機app中。通過研究我們發(fā)現(xiàn)，所有基于HTML5技術(shù)開發(fā)的手機app，都可以通過這些數(shù)據(jù)通道注入惡意代碼。 近場通信 (NFC)：近場通信是一個用于智能設(shè)備之間的近距離無線通信 取外部NFC標簽中的信息，這已經(jīng)成為一種便捷的獲取外部數(shù)據(jù)的方式：用戶只需要點擊他們的設(shè)備上的NFC標簽就可以獲得數(shù)據(jù)。廣告商和商戶利用 NFC標簽進行促銷和廣告宣傳。例如，谷歌已經(jīng)攜手NFC專業(yè)技術(shù)公司Tapit 在澳洲東部的公共交通系統(tǒng)推出了在線音樂服務(wù)。將內(nèi)置NFC標簽的海報放 在公共汽車和火車上的座位后面，感興趣的用戶可以直接使用手機掃描標簽獲取信息。 在Google Play里面有不少讀取NFC標簽的app，比如NFC TagInfo和NFC Reader。這些app通常注冊了操作NFC的Intent對象，當手機設(shè)備檢測到一個 NFC標簽時，它就可以讀取標簽中的數(shù)據(jù)，然后發(fā)送含有數(shù)據(jù)的intent。這時候等待中的app將被觸發(fā)，它會獲取到數(shù)據(jù)并輸出給用戶看。圖4(a) 展示了一 個典型的NFC閱讀程序的用戶界面，需要注意的是我們作為數(shù)據(jù)放在NFC標簽中的JavaScript代碼只是簡單的作為文本內(nèi)容顯示了，因為這個app是用Java 開發(fā)的。
如果這樣一個NFC讀卡程序是用PhoneGap開發(fā)的，而且它使用了不安全的API顯示從NFC標簽讀取的數(shù)據(jù)，對手機終端將會造成巨大的危險。為了展示這個風險，我們用PhoneGap框架和它官方ᨀ供的NFC插件開發(fā)了一個app，我們使用html()展示從NFC標簽讀取的數(shù)據(jù) 從圖4(b)中我們可以看到，從NFC標簽中獲取的JavaScript代碼已經(jīng)被執(zhí)行 了。隨著NFC應(yīng)用日益廣泛，存在缺陷的PhoneGap app在讀取不可信的NFC 標簽時將存在很大的安全隱患。攻擊實現(xiàn)起來很容易：攻擊者替換公共場合的NFC標簽（包含惡意JavaScript代碼），引誘用戶來刷就可以了。這是一種被動的攻擊。攻擊者也可以將惡意的NFC標簽放到攻擊目標周圍實現(xiàn)主動攻擊。在標簽中，攻擊者可以指定應(yīng)用程序接收NFC標簽數(shù)據(jù)。因此，當攻擊者把標簽放到受害者的手機設(shè)備附近時，只要該目標手機設(shè)備沒有鎖屏，該設(shè)備將自動從標簽讀取數(shù)據(jù)，并啟動指定的應(yīng)用程序（通常是一個存在漏洞的PhoneGap app）來處理標簽數(shù)據(jù)。 條形碼：條形碼ᴰ初是使用特殊的光學掃描儀進行掃描的，但隨著智能手機的普及現(xiàn)在大多數(shù)手機設(shè)備都可以使用相機和軟件掃描條形碼。在Android設(shè)備上，谷歌的Goggles軟件和一些三方軟件比如Scan是比較常用的條形碼掃描軟件。通過這些軟件開發(fā)一個讀取條形碼的app是很簡單的：它可以簡單的發(fā)一個intent給系統(tǒng)。這個intent會觸發(fā)已經(jīng)安裝的掃描軟件去掃描條形碼，將條形碼圖片轉(zhuǎn)換成數(shù)據(jù)，返回數(shù)據(jù)到ᴰ初的app。
智能手機使用的一種常見的條形碼是二維碼（或QR碼），它可以存儲超過2k字節(jié)編碼的文本消息。因為存儲信息多和掃描方便，二維碼是在現(xiàn)實生活中有廣泛的應(yīng)用。它們被張貼在商店入口ᨀ供銷售和優(yōu)惠券信息，貼在建筑物門上指引方向，在產(chǎn)品包裝上ᨀ供額外的信息等等。由于二維碼無處不在，掃描它已經(jīng)成為我們生活中的一種常見行為，很少有人意識到掃描二維碼可能帶來的安全風險。 JavaScript代碼可以被嵌入二維碼中，對于一個native應(yīng)用來說這不是問題，代碼會被作為文本來顯示不會被執(zhí)行。圖5(a)是一個native app掃描二維碼的 情景，我們在二維碼中放入代碼，但從圖上可以發(fā)現(xiàn)我們的代碼被作為文本顯示。不幸的是，如果這是一個PhoneGap app，情況將有很大不同。我們開發(fā)了這樣一個app，當我們用它來掃描二維碼的時候，嵌入的JavaScript代碼被執(zhí)行了（參考圖5(b)）。 我們已經(jīng)發(fā)現(xiàn)了一款真實的存在漏洞二維碼掃描軟件，在第七章我們會給出完整的細節(jié)。 文本提?。撼丝梢詮臈l形碼圖片提取數(shù)據(jù)以外，其他類型的圖片也可以提取數(shù)據(jù)。文本提取就是個例子。很多手機應(yīng)用都采用了標準技術(shù)實現(xiàn)了文本提取功能，支持從照相機拍攝的圖片中自動提取信息，提取的文字會顯示給用戶。很多手機app可以從信用卡圖像提取和顯示信息，有一種類似讀取信用卡信息的第三方插件。類似條形碼的場景，如果HTML5 app顯示了從圖片中提取的信息，就會觸發(fā)嵌入在圖像中的惡意代碼。 外圍設(shè)備的數(shù)據(jù)通道：很多手機終端有額外的外置設(shè)備可以讀取一些特 別用途的數(shù)據(jù)。比如，信用卡讀卡器（譯者注：類似國內(nèi)的拉卡拉那種設(shè)備）就是一種特別流行的外設(shè)，Square和PayPal都在使用這種外置設(shè)備。當用戶在這種接在手機上的外設(shè)上刷信用卡時，讀卡器會獲取卡的信息，包括帳戶、卡號和其他附加信息。這些信息會被反饋到app中，然后顯示在屏幕上請用戶 確認。 很多小的商戶使用這種外置設(shè)備接受顧客的支付。但是，如果這種app是用HTML5開發(fā)的，攻擊者只需要用一個偽造的信用卡做一筆簡單的支付就可以想手機設(shè)備中注入惡意代碼。這種app都是和支付服務(wù)相關(guān)的，惡意代碼在app 中運行起來以后會造成巨大的損失。 短信息：另外一種可以從外部獲取內(nèi)容的渠道是短信息。攻擊者可以向短信內(nèi)容注入惡意腳本，然后發(fā)給攻擊目標。當使用了存在缺陷的API函數(shù)的HTML5 app顯示惡意短信的時候，JavaScript會被成功觸發(fā)。 4.3 多媒體的元數(shù)據(jù)通道 播放多媒體的手機app是非常流行的，比如播放歌曲、電影和看圖片。這些多媒體文件都是從互聯(lián)網(wǎng)下載或者朋友分享的，大部分是由音頻、視頻和圖像組成的，看上去很難植入JavaScript代碼。但是，大部分多媒體文件都有被稱為元數(shù)據(jù)的額外區(qū)域，向這里注入代碼是很好的選擇。 MP3、MP4和圖像：MP3 和 MP4 文件是標準的音頻和視頻文件格式。然而，除了視頻和音頻，這類文件還包含很多元數(shù)據(jù)字段，諸如標題、藝術(shù)家、專輯、年代等等。當用戶使用手機app聽mp3音樂或者看mp4視頻時，元數(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顯示出 來?，F(xiàn)在我們想像下，如果app使用PhoneGap開發(fā)的，使用了存在缺陷的API 從輸出元數(shù)據(jù)會是什么情況。為了展示可能造成的影響，我們開發(fā)了一個這 樣的PhoneGap應(yīng)用，結(jié)果如圖6(b)和圖7(b)所示: 嵌入在元數(shù)據(jù)中的JavaScript 代碼被執(zhí)行了。
調(diào)頻收音機：無線電波是另外一種潛在的注入代碼到手機終端的渠道。 近年來，一些新款的智能手機都有了內(nèi)置的調(diào)頻收音機，用戶可以收聽當?shù)仉娕_的廣播節(jié)目。Verizon無線、AT&T和T-Mobileᨀ供的手機都是可以收聽廣播的，無線電行業(yè)協(xié)會正在爭取Apple也加入進來。Nokia在全球范圍內(nèi)已經(jīng)銷售了超過7億部內(nèi)置調(diào)頻收音機的手機，可以看出用戶是認可這種功能 ［4］。用戶也愿意付出$20到$50去購買一個可插拔的調(diào)頻收音機用在手機上。 如今，調(diào)頻廣播不僅包括音頻軌道，它還包括使用RDS（無線電廣播數(shù)據(jù)系統(tǒng)）協(xié)議的數(shù)據(jù)流。RDS是一種傳統(tǒng)的調(diào)頻廣播中用于嵌入數(shù)字信息的通信協(xié)議。RDS標準化了幾種類型的信息傳遞，包括時間、電臺號和節(jié)目信息。無線電中數(shù)字信息包括PI（節(jié)目識別），RT（無線電文本），RT是和節(jié)目同步的64字符的自由文本存儲空間（用于存儲標題和藝術(shù)家等信息）等。有一種流行的調(diào)頻收音app叫FM TwoO，它已經(jīng)被下載了上百萬次，它可以顯示附加的數(shù)字信息給用戶。 使用GNU-Radio軟件和USRP (成本低于$2000)［7］，攻擊者可以很容易的搭建一個調(diào)頻廣播臺，可以播放他們自己制作的通過RDS通道嵌入了惡意代碼的無線電節(jié)目。如果用戶使用了HTML5 app收聽這種節(jié)目，一旦顯示了嵌入的RDS信息，惡意代碼就會在受害者手機上被執(zhí)行。 繞過限制條件在前面的章節(jié)為了簡單起見，我們使用彈框的方式來證明我們可以通過多種通道成功地注入代碼，但是彈框是沒有任何實質(zhì)性危害的。在本章，我們來研究如何編寫惡意代碼實現(xiàn)最大限度的攻擊。如果代碼長度沒有限制，這個問題就不需要探討了，因為攻擊者可以編寫代碼實現(xiàn)他們想做的任何事情。不幸的是在本文描述的攻擊場景下，代碼長度限制是我們需要面對的一個巨大挑戰(zhàn)。例如，在Wi-Fi攻擊中，我們使用SSID字段作為攻擊通道，這個字段只能包含32個字符[15]。問題在于攻擊者能否在這么短的條件下實現(xiàn)有意義的攻擊，用最小的輸入實現(xiàn)最大的破壞。 5.1 數(shù)據(jù)通道的長度限制 為了更好的理解長度限制，我們對已經(jīng)識別的可以注入代碼的數(shù)據(jù)通道進行了系統(tǒng)的研究。研究的結(jié)果如表2所示：
從表中可以看出，長度限制對MP3/MP4、JPEG、二維碼(QR碼)和NFC這 幾個通道影響不大，它們允許輸入超過2000個字符，這對攻擊者來說足夠了。 不幸的是，Wi- Fi的SSID字段、圖片文件的Model和Maker字段、藍牙和短信息看上去是非常有限的。特別是Wi-Fi，僅有的能利用的數(shù)據(jù)通道長度被限制 在32字符。在后面的章節(jié)，我們將把這個極端情況作為目標。我們將找到辦法利用這32字節(jié)的數(shù)據(jù)通道構(gòu)造可以被注入到手機終端中的JavaScript代碼。 可以造成的破壞程度取決于實際注入的代碼，所以病毒代碼的長度取決于 你想取得的攻擊成果。長度可以相當長，是否會產(chǎn)生問題由長度限制決定。 為了解決這個問題，我們使用如下的方案：我們通過有長度限制的攻擊通道 注入一段短的代碼到受害者手機中，這段代碼的目標是加載一個外部URL。 因為外部代碼是通過常規(guī)數(shù)據(jù)通道（比如網(wǎng)絡(luò)連接）進入受害者手機的，這 時候就沒有長度限制了。因此，攻擊者可以放置任意代碼實現(xiàn)最大化的攻擊。 在下面的子章節(jié)，我們會聚焦上面ᨀ到的短的通用代碼，找出能夠引導攻擊或者說能夠引入外部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比購買域名來的長一些，但是它依然具有某些優(yōu)勢：不僅免費，而且能夠隱藏攻擊者。它們可以輕易的使用別人的web 服務(wù)器部署惡意代碼，而不是使用自己的服務(wù)器。 5.3 壓縮惡意代碼 有很多方法可以引入外部的JavaScript代碼，我們將展示每種場景下最短的引入外部JavaScript文件的方式。 使用Script標簽：使用<script>標簽是一種典型的引入JavaScript代碼的方式。在這種情況下，我們可以省略“http:” 和 “>”。下面的代碼是我們構(gòu)造的ᴰ短的腳本代碼，長度為28字符: <script src=//mu.gl></script> 使用事件屬性：不幸的是，正如我們在第3節(jié)中ᨀ到，如果上面用的內(nèi)容被innerHTML顯示，代碼是不會被顯示或執(zhí)行的。為了像上面一樣擊敗 innerHTML，我們需要用另一種方式嵌入代碼。JavaScript可以放在一些HTML 標簽的事件屬性中，如onclick、onscroll、onerror和onmouseover事件。這些標簽可以是Button標簽、A標簽、IMG標記等等。下面是一個例子： <img src onerror=jscode> 以上代碼中我們使用了img標簽。當含有這樣的HTML標簽的數(shù)據(jù)在WebView中顯示的時候，HTML會解析標簽并嘗試加載指定的圖像。但是我 們故意沒有ᨀ供圖像源地址，所以會發(fā)生錯誤，這時onerror屬性指定的代碼 就會被觸發(fā)。這種技術(shù)在運行著Android 4.4系統(tǒng)的Nexus 5手機上測試通過。 早期版本的Android系統(tǒng)，我們需要為src屬性指定一個不存在的URL，例如， 我們需要設(shè)置“src=x”，這樣多了兩個字符。我們的測試使用了Nexus 5，可以 不考慮這種情況。這種包含代碼的方式將繞過innerHTML中實現(xiàn)的過濾機制。 然后，這些屬性不允許從外部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)就是 怎么樣把這些分片的代碼注入到目標用戶的手機上。對某些數(shù)據(jù)通道來說是 很簡單的，因為這些數(shù)據(jù)通道有多個字段可以使用。例如JPEG元數(shù)據(jù)里就有 多個字段可以用，所以我們成功完成攻擊只需要5個字段。當目標app顯示5個 字段的時候，惡意代碼就會被成功執(zhí)行。即使目標app只顯示一個字段，我們 也可以通過分別注入5份代碼到5個不同圖片的方式進行攻擊。
對Wi-Fi來說，只有一個字段我們可以注入代碼，問題就是我們?nèi)绾螌⑸?面的5份代碼同時注入。這里有兩種方案。第一種方式是使用多個Wi-Fi接入 點。按照上面的例子，我們需要設(shè)置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 代碼將會被 執(zhí)行。 攻擊者也可以使用一個接入點完成攻擊。大部分Wi-Fi掃描app會定期刷新 屏幕更新可以被檢測到的接入點列表。為了完成我們的攻擊，我們不需要我 們構(gòu)造的惡意的SSID在同一時間顯示。它們每一個被顯示的時候，注入在 SSID的代碼就會被執(zhí)行。如果5份代碼都被執(zhí)行了，我們的攻擊就成功了。因 此，我們只需要使用一個接入點、每次將接入點SSID修改其中一份代碼，每 次一個，第5份代碼作為最后一個。在圖8(b)，我們從non-PhoneGap app中在 五個不同的時間做的5次屏幕截圖，每次都是一個不同的SSID。實際上，這5個SSID都來自同一個設(shè)備。我們已經(jīng)在我們開發(fā)的PhoneGap app上做了驗證，這些驗證SSID被顯示的時候，jQuery代碼就會被執(zhí)行。 PHONEGAP插件PhoneGap應(yīng)用程序需要使用插件來與Webview之外的對象實體進行交互。 在本章節(jié)中，我們要找到那些存在安全缺陷的插件。如果一個插件使用了不 安全的api顯示從可以攻擊的通道獲取的數(shù)據(jù)，它就是存在安全缺陷的。在本 次研究中，我們從從GitHub [ 6 ]下載了186個第三方插件作為測試對象。 6.1 可被利用的插件 如果一個插件可以被成功攻擊，它需要返回數(shù)據(jù)到WebView中的頁面，并 且數(shù)據(jù)必須是能夠從外部控制的，不是所有的插件都符合這個條件。我們開發(fā)了一個工具對這186個插件進行了分析，我們發(fā)現(xiàn)其中58個插件是完全不輸出數(shù)據(jù)的。另外51個插件輸出的數(shù)據(jù)攻擊者無法控制，比如返回邏輯結(jié)果、 常量字符串或者狀態(tài)數(shù)據(jù)等等。換句話說，這些數(shù)據(jù)要么是系統(tǒng)控制的，要 么是開發(fā)者控制的，所以很難從外部注入代碼。剩下的77個插件是符合我們 要求的，它們可以進一步按照數(shù)據(jù)來源分成三類，如下表 (Table 3).
在這77個插件中，24個插件從Web中獲取數(shù)據(jù)（例如，PhoneGap插件可以獲取Facebook 和 Twitter上的數(shù)據(jù)）。這些數(shù)據(jù)也可能包含惡意代碼，但是這些風險（比如XSS）已經(jīng)廣為人知了，我們不再對這類插件進行討論。另外38個插件從手機設(shè)備資源獲取數(shù)據(jù)（例如日歷和通訊錄），換而言之，數(shù)據(jù)通道是內(nèi)部的。這些數(shù)據(jù)可能包含代碼，攻擊者必須先安裝一個惡意的app 能夠?qū)阂饽_本注入這些資源，然后一個有缺陷的PhoneGap app顯示來自這些資源的數(shù)據(jù)時，惡意腳本才能以目標app的權(quán)限執(zhí)行。這個通道也可以用來在同一個手機上進行跨PhoneGap app攻擊。 我們的主要興趣在“外部數(shù)據(jù)”這一類，其中包含15個插件。它們從外部資源獲取數(shù)據(jù)，并返回數(shù)據(jù)到的WebView的頁面中。我們對它們進行了更深入的研究。 6.2 存在安全缺陷的插件 在我們研究的15個插件中，有四個是語音識別和信用卡掃描相關(guān)的。鑒于讀出JavaScript并讓app識別和獲取信用卡掃描硬件都比較困難，我們沒有對這四個插件進行研究。因此，我們的研究范圍縮小為這11個插件。在這11個插 件中，有5個自帶JavaScript代碼，包括3個藍牙插件、1個Wi-Fi插件和一個短 信插件。研究過以后，我們發(fā)現(xiàn)ᨀ供這些JavaScript代碼有兩個目的：一個目 的是為開發(fā)者ᨀ供示例代碼，告訴他們?nèi)绾问褂眠@個插件；另外一個目的是 提供JavaScript庫，使得插件使用起來更容易。這兩種情況下，如果插件自帶 的JavaScript代碼是有缺陷的，將導致非常顯著的破壞，因為大部分app開發(fā)者 要么直接使用ᨀ供的庫要么參考示例代碼的寫法。從插件包含的JavaScript代 另外的六個插件，它們沒有ᨀ供有缺陷的JavaScript代碼，但是仍然有潛在 的安全缺陷的，因為它們沒有過濾來自可被利用通道的代碼。如果PhoneGap app使用這些插件并且碰巧也使用了存在缺陷的數(shù)據(jù)輸出api，將會造成安全漏 洞?？紤]到這些有缺陷的API在PhoneGap app中是被廣泛使用的 (參考Table 1)，我們相信開發(fā)者將這幾個插件和這些API一起使用進而造成安全漏洞的概率會比較高。在第四章中我們開發(fā)的存在漏洞的app，我們就使用了這些插件 （包括二維碼、 NFC和短信插件）。這表明這些插件和錯誤的api使用方法組 合起來將會導致存在漏洞的app。 案例研究通過我們自己開發(fā)的程序研究過這些潛在的攻擊以后，我們非常想知道現(xiàn) 實中真實存在的app是否也受這種攻擊的影響。出于這個目的，我們進行了有 步驟的搜索。我們從Google Play上下載了25類共計12，068個免費的app，包 括旅游、交通以及社交等等。我們識別出了190個PhoneGap app。從PhoneGap 官方網(wǎng)站[12]我們收集了另外574免費的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é)合以上兩點，我們發(fā)現(xiàn)32個app符合前兩個條件。我們沒有去寫復雜的數(shù)據(jù)流分析工具去檢查是否符合第三個條件，而是手工對這32個app進行了分析。ᴰ終，我們發(fā)現(xiàn)有兩個app符合第三個條件。這意味著，他們非常有可能存在漏洞。我們用真實的攻擊方法對他們進行了測試，結(jié)果證明他們確實存在漏洞。我們會在本章后面部分給出試驗細節(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是可以進行代碼注入攻擊的。 為了對這個存在漏洞的app進行攻擊，我們把攻擊設(shè)備調(diào)成藍牙模式，把惡意的JavaScript代碼嵌入名稱字段（長度限制為248，足夠使用）。為了比較，我們同時還用了一個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返回手機通訊錄中的所有姓名。如果 PhoneGap.exec()請求失敗，第八行的函數(shù)會被執(zhí)行（這里是空函數(shù)）。如果請求成功，第2-7行定義的函數(shù)會被調(diào)用，這里就是要實現(xiàn)的攻擊效果。 當這個回調(diào)函數(shù)被調(diào)用后，PhoneGap插件返回的數(shù)據(jù)會存儲到變量a中，它是一個存儲了從通訊錄中讀取到的姓名的數(shù)組。從第3行到第4行，我們看 到代碼利用通訊錄的數(shù)據(jù)構(gòu)造了一個叫m的字符串。在第5行，出于演示的目的，我們將這個字符串顯示出來了（參考圖9(b)）。在第6行的真實攻擊中， 看上去我們只是構(gòu)造了一個img標簽，但是它的真實目的是調(diào)用一次HTTP GET 方法請求遠程服務(wù)器（攻擊者控制的），通過這個請求將竊取的通訊錄數(shù)據(jù)發(fā)送給攻擊者。 作為一個PhoneGap演示app，存在漏洞的GWT移動PhoneGap示范程序?qū)φ鎸嵉腶pp有很大的影響，因為開發(fā)者通常是通過這樣的演示程序?qū)W習怎么開發(fā)PhoneGap app（這個app的源代碼可以從GitHub [9]上獲取到）。在公開本文之前，我們已經(jīng)聯(lián)系這個app的開發(fā)團隊修復了漏洞。
研究案例 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顯示條形碼里面的數(shù)據(jù)。我們制作一個包含如下腳本的二維碼：
這段代碼使用Geolocation.watchPosition()來竊取用戶的物理位置。這個API 是HTML5中引進的，它注冊了一個當終端的物理位置變化時就會被自動調(diào)用 的處理函數(shù)。從代碼中我們可以看到處理函數(shù)被調(diào)用時，位置信息會被存儲 到變量loc中并且在第六行顯示（見圖10(b)）。在第7行和第8行，loc的內(nèi)容被發(fā)送到外部電腦。由于處理函數(shù)時被循環(huán)調(diào)用的，一旦受害者掃描了二維碼， 這個app也可以在其他平臺上使用，包括iOS和Blackberry。不幸的是，我們在iOS上無法使用它掃᧿二維碼。它依賴于另外一個二維碼掃描app來讀取二維碼，但是這個app不能在iOS上工作。這個RewardingYourself app可以用在Blackberry，我們使用同樣的二維碼進行攻擊測試獲得了成功。這證明了我們的攻擊方法是和平臺無關(guān)的假設(shè)。
解決方案和其他相關(guān)工作找到這種威脅的解決方案已經(jīng)超出了本文范疇，這將是我們下一階段研究 的焦點。在本文中，我們參考XSS攻擊的解決方案簡單的給出一些解決問題的思路。理論上來看這些方法是可行的，但是在實戰(zhàn)中運用還有很多工作要做。 基于數(shù)據(jù)凈化的解決方案：數(shù)據(jù)凈化是一種常見的技術(shù)，它通過過濾數(shù)據(jù)中混雜的代碼來阻止代碼注入攻擊。凈化后的數(shù)據(jù)變成一個純文本無法觸發(fā)代碼執(zhí)行?；趦艋慕鉀Q方案已經(jīng)在web安全領(lǐng)域被廣泛研究，面臨的主要挑戰(zhàn)是如何識別出混雜在數(shù)據(jù)中的代碼。人們提出了很多方法來解決這個問題，包括Bek [22]、CSAS [31]、ScriptGard [32]等。不幸的是，不斷有新的繞過現(xiàn)有凈化方案的攻擊方式被ᨀ出[20，21]。 我們可以采用一些凈化方法移除字符串種的腳本來阻止攻擊；但是挑戰(zhàn)在于我們在什么地方進行數(shù)據(jù)凈化。對XSS攻擊而言很簡單，它只有一種數(shù)據(jù)通道（web服務(wù)器）。但是對于我們ᨀ出的攻擊，有很多通道可以用來注入代碼。有很多地方可以進行凈化操作：其中一個地方是PhoneGap框架，這是所有外部數(shù)據(jù)進入WebView的唯一通道。然而這種方案僅限于PhoneGap。如果我們能在WebView種進行凈化會更合理，這是一個更通用的方案，但是目前還不清楚這種處理是否會影響WebView原有的功能。 基于污點分析的解決方案：另外一種方案是采用污點分析來確定是否存在代碼注入漏洞。污點分析框架可以被應(yīng)用在服務(wù)端[25，28，30，36] 或者客戶端[19，29]。污點分析的思路是標記不可信輸入，跟蹤他們在程序中的擴散。任何直接或者間接執(zhí)行污染數(shù)據(jù)的嘗試都會被記錄和阻止。 使用污點分析方案，我們必須標記進入終端的外部數(shù)據(jù)。挑戰(zhàn)在于需要跟蹤數(shù)據(jù)通過終端設(shè)備、Dalvik虛擬機、JavaScript引擎和不同組件之間的處理過程。如果我們能做到這些，我們就可以阻止代碼被觸發(fā)，甚至可以阻止惡意代碼進入終端設(shè)備。 緩解破壞：與阻止代碼注入攻擊的思路不同，很多研究者致力于緩解腳本注入造成的破壞。這個想法是限制不可信代碼的力量。開發(fā)者需要配置一些 策略，基于內(nèi)容的可信程度對每個DOM元素賦予不同的權(quán)限。例如，Escudo [23] 和Contego [26] 在某些特定的DOM元素中限制腳本的權(quán)限。內(nèi)容安全策 略[33，35] 為JavaScriptᨀ供了一個嚴格的制約，不允許inline方式執(zhí)行JavaScript 和eval()。CSP可以解決本文ᨀ出的問題，但是強制使用缺省的CSP策略需要app開發(fā)者付出巨大的努力去修改現(xiàn)有的app，因為將不支持inline-JavaScript。CSP對HTML5 app保護的有效性值得進一步研究。這個框架是為瀏覽器設(shè)計的，但是我們可以參考上面的思路來做緩解攻擊的工作，換句話說，我們可以開發(fā)一個安全的 WebView為HTML5手機appᨀ供可信計算的基礎(chǔ)。 其他相關(guān)工作：WebView和PhoneGap是HTML5手機app的重要組成部分。很多研究已經(jīng)揭示了他們的安全性 [17，18，24，27，34]。NoFrak [18]和[24] 關(guān)注如何阻止不可信的外部web代碼訪問手機本地資源。他們的解決方案不能用于防御我們的攻擊，因為我們的攻擊方式中代碼來自的外部通道不屬于web。 總結(jié)和未來的工作在本文中，我們發(fā)現(xiàn)了一種新的針對HTML5手機app的代碼注入攻擊。我們在手機終端上使用poc app和真實的app系統(tǒng)的研究了這種攻擊的可行性。 10. 致謝 我們要感謝多位匿名審稿人有價值和令人鼓舞的評論。這個工作獲得了NSF 的資助和Google的研究獎勵，但是本文的任何意見、成果、結(jié)論和意見并不受NSF和Google的影響。 11. 參考 [1] 75% of developers using html5:survey. http: //eweek.com/c/a/Application-Development/ [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. [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 [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 [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 [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 via 作者：Xing Jin, Tongbo Luo, Derek G. Tsui, and Wenliang Du 翻譯：flyh4t（machuanlei@nsfocus.com） 該文章在 2014/11/25 1:25:34 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
