安卓云備份模塊的代碼安全問(wèn)題分析

梁蛟，劉武，韓偉力，王曉陽(yáng)，甘似禹，沈爍

（1. 上海市數(shù)據(jù)科學(xué)重點(diǎn)實(shí)驗(yàn)室（復(fù)旦大學(xué)），上海 201203；2. 上海市信息投資股份有限公司，上海 200120；3. 中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190）

安卓云備份模塊的代碼安全問(wèn)題分析

梁蛟1，劉武1，韓偉力1，王曉陽(yáng)1，甘似禹2，沈爍3

（1. 上海市數(shù)據(jù)科學(xué)重點(diǎn)實(shí)驗(yàn)室（復(fù)旦大學(xué)），上海 201203；2. 上海市信息投資股份有限公司，上海 200120；3. 中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190）

隨著移動(dòng)端云備份服務(wù)的日益普及，為保障用戶隱私數(shù)據(jù)不被泄露，研究第三方應(yīng)用調(diào)用云備份軟件開發(fā)工具包（SDK，software development kit）的安全問(wèn)題變得尤為重要。通過(guò)對(duì)目前國(guó)內(nèi)外安卓應(yīng)用市場(chǎng)中調(diào)用云備份服務(wù)的普遍性進(jìn)行調(diào)研，總結(jié)出4個(gè)當(dāng)前主流的安卓云備份SDK。分析其SDK實(shí)現(xiàn)代碼和官方文檔，對(duì)比使用情況、協(xié)議和接口功能，總結(jié)和發(fā)現(xiàn)了第三方應(yīng)用錯(cuò)誤調(diào)用SDK以及云備份SDK自身存在的代碼安全問(wèn)題，同時(shí)向第三方開發(fā)者提供了相應(yīng)的解決方案。

移動(dòng)云存儲(chǔ)；代碼安全；備份服務(wù)；軟件開發(fā)工具包

1 引言

隨著云計(jì)算技術(shù)和服務(wù)的日益普及，云備份成為目前信息化基礎(chǔ)設(shè)施的一項(xiàng)基本服務(wù)。近年來(lái)，云備份作為一種新型的網(wǎng)絡(luò)服務(wù)為大眾所知，它可以在提供大量存儲(chǔ)空間的同時(shí)減少本地存儲(chǔ)消耗，允許用戶通過(guò)請(qǐng)求遠(yuǎn)程服務(wù)來(lái)上傳、下載以及分享他們的個(gè)人和商業(yè)數(shù)據(jù)。目前研究表明，越來(lái)越多的個(gè)人和企業(yè)已經(jīng)傾向于將其數(shù)據(jù)存儲(chǔ)到云備份服務(wù)器，以保證更低的能源消耗和更高的資源利用率[1]。迄今為止，已經(jīng)出現(xiàn)了大量的云備份服務(wù)提供商，如亞馬遜、Dropbox、谷歌、微軟、百度等，同時(shí)也出現(xiàn)了越來(lái)越多的商業(yè)云備份服務(wù)，如 Dropbox[2]、Google Drive[3]、OneDrive[4]、百度云[5]等。

最近，隨著云備份服務(wù)和安卓智能手機(jī)的普及，一些云備份服務(wù)提供商在目前兩大主流移動(dòng)端操作系統(tǒng)——安卓和 iOS系統(tǒng)上也部署了移動(dòng)備份服務(wù)。移動(dòng)端的用戶可以通過(guò)備份他們的照片、通信錄、聊天記錄，甚至商業(yè)文件到云備份服務(wù)器來(lái)減輕智能手機(jī)的存儲(chǔ)負(fù)擔(dān)，并借此實(shí)現(xiàn)數(shù)據(jù)的跨平臺(tái)同步。同時(shí)，這些云備份服務(wù)平臺(tái)為了擴(kuò)大服務(wù)影響范圍和增強(qiáng)用戶體驗(yàn)，向第三方應(yīng)用提供了接入備份服務(wù)的接口和功能，這些云備份服務(wù)提供商通常將備份服務(wù)集成為一個(gè)軟件開發(fā)工具包，即SDK[6]，以供第三方開發(fā)者使用，幫助簡(jiǎn)化第三方應(yīng)用的開發(fā)。

然而，在調(diào)研中發(fā)現(xiàn)，云備份服務(wù)提供商所開發(fā)的SDK往往都存在代碼安全漏洞。2015年3月，Dropbox所提供的 1.5.4-1.6.1版本的安卓系統(tǒng)SDK被曝出有嚴(yán)重的漏洞（CVE-2014-8889），該漏洞可以讓攻擊者將一個(gè)訪問(wèn)令牌插入到Dropbox SDK的AuthActivity中，實(shí)現(xiàn)本地或遠(yuǎn)程攻擊[6]。此外，第三方應(yīng)用可能會(huì)錯(cuò)誤地調(diào)用這些SDK，當(dāng)這些應(yīng)用在移動(dòng)設(shè)備上運(yùn)行時(shí)，攻擊者可以利用這些漏洞竊取用戶的隱私數(shù)據(jù)。例如，筆者在調(diào)研中發(fā)現(xiàn)有些應(yīng)用將等同于客戶端令牌的App_key和App_secret暴露在應(yīng)用的配置文件（string.xml或AndroidManifest.xml）中，攻擊者通過(guò)反編譯安卓安裝包（APK，Android package）文件輕易獲取這些敏感信息。因此，第三方應(yīng)用在調(diào)用移動(dòng)端云備份 SDK時(shí)也可能面臨潛在的代碼安全問(wèn)題。

本文對(duì)目前四大主流的安卓云備份 SDK（Dropbox、Google Drive、OneDrive和百度云）進(jìn)行了全方位的代碼安全性分析，這是第一個(gè)在代碼安全方面分析各大SDK使用量、協(xié)議和接口功能的研究。同時(shí)也總結(jié)和發(fā)現(xiàn)了一些云備份SDK自身的編碼漏洞，以及第三方應(yīng)用錯(cuò)誤調(diào)用這些SDK可能導(dǎo)致的代碼安全問(wèn)題，并對(duì)此為安卓第三方應(yīng)用開發(fā)者提供了一系列調(diào)用建議。

本文的主要貢獻(xiàn)總結(jié)如下。

1) 對(duì)安卓國(guó)外應(yīng)用市場(chǎng)Google Play和國(guó)內(nèi)應(yīng)用市場(chǎng)酷安網(wǎng)進(jìn)行了有關(guān)移動(dòng)端云備份 SDK調(diào)用量的實(shí)證分析，發(fā)現(xiàn)超過(guò)一半的第三方應(yīng)用沒有遵照官方開發(fā)指南，這可能會(huì)引發(fā)一系列的代碼安全漏洞。

2) 對(duì)四大主流的移動(dòng)端云備份 SDK進(jìn)行了協(xié)議分析和比較。協(xié)議包括 4個(gè)方面：通信協(xié)議、加密協(xié)議、去重協(xié)議和授權(quán)協(xié)議。結(jié)果表明，這四大SDK采用的協(xié)議有些不同，但均沒有采用加密協(xié)議，即在數(shù)據(jù)傳輸前對(duì)用戶的文件數(shù)據(jù)進(jìn)行加密。此外，百度云的SDK采用了基于源的去重協(xié)議，這可能會(huì)導(dǎo)致嚴(yán)重的安全問(wèn)題。

3) 調(diào)研了50個(gè)集成這些云備份SDK的開源應(yīng)用，發(fā)現(xiàn)了存在于第三方應(yīng)用和SDK自身的幾個(gè)代碼安全問(wèn)題，如默認(rèn)下載路徑問(wèn)題，當(dāng)?shù)谌綉?yīng)用的默認(rèn)下載路徑設(shè)置為外部存儲(chǔ)路徑（如SD卡的根目錄）時(shí)，可能會(huì)導(dǎo)致用戶不易檢測(cè)到的數(shù)據(jù)丟失或數(shù)據(jù)被竊取問(wèn)題。基于這些問(wèn)題，本文給開發(fā)人員提供了若干建議來(lái)減輕調(diào)用SDK過(guò)程中可能造成的數(shù)據(jù)泄露等安全隱患。

2 研究背景與動(dòng)機(jī)

2.1 移動(dòng)云備份存儲(chǔ)

隨著云計(jì)算技術(shù)突飛猛進(jìn)地發(fā)展，在線用戶，尤其是移動(dòng)端用戶，越來(lái)越傾向于利用遠(yuǎn)程存儲(chǔ)服務(wù)對(duì)其個(gè)人或商業(yè)數(shù)據(jù)進(jìn)行備份、恢復(fù)和共享。這些備份服務(wù)提供了比之前更友好的用戶體驗(yàn)，尤其由于目前用戶的手機(jī)存儲(chǔ)通常是有限的，如16 GB，通過(guò)移動(dòng)端云備份服務(wù)可以為用戶節(jié)省大量移動(dòng)設(shè)備的存儲(chǔ)空間。此外，用戶也可以授權(quán)安卓的第三方應(yīng)用，允許這些應(yīng)用將其文件備份到遠(yuǎn)程服務(wù)器或?qū)?shù)據(jù)下載到本地，如圖1所示。Dropbox、Google Drive、OneDrive和百度云是目前最著名的云備份服務(wù)。

1) Dropbox

美國(guó)Dropbox公司于2007年成立，公司提供的Dropbox服務(wù)有文件同步、存儲(chǔ)服務(wù)等功能，并開發(fā)供用戶使用的客戶端軟件[7]。據(jù)相關(guān)調(diào)查顯示，截至2016年3月，Dropbox服務(wù)已經(jīng)擁有來(lái)自200多個(gè)國(guó)家的5億多用戶，平均每天有12億的文件上傳量。此外，已經(jīng)有超過(guò)30萬(wàn)個(gè)第三方應(yīng)用部署在了Dropbox平臺(tái)上。

圖1 安卓第三方應(yīng)用調(diào)用云備份服務(wù)的流程

2) OneDrive

2008年，微軟開發(fā)了 OneDrive（曾用名SkyDrive，Windows Live SkyDrive, Windows Live Folders）作為文件備份服務(wù)，允許用戶備份文件到服務(wù)器，并通過(guò)網(wǎng)頁(yè)瀏覽器、桌面客戶端或移動(dòng)設(shè)備來(lái)訪問(wèn)其存儲(chǔ)在遠(yuǎn)程服務(wù)器的數(shù)據(jù)[8]。截至2016年，OneDrive已經(jīng)有超過(guò)2.5億的用戶使用其云備份服務(wù)。

3) Google Drive

Google公司于2012年開發(fā)了Google Drive作為文件存儲(chǔ)同步服務(wù)[9]。據(jù)統(tǒng)計(jì)數(shù)據(jù)顯示，到2014年10月，Google Drive已經(jīng)擁有超過(guò)2.4億的活躍用戶。

4) 百度云

2012年，百度網(wǎng)盤正式推出了百度云備份服務(wù)。如今，百度云向用戶和第三方開發(fā)者提供云存儲(chǔ)服務(wù)、客戶端軟件、文件管理、資源共享和第三方集成的服務(wù)[10]。統(tǒng)計(jì)數(shù)據(jù)表明，截至2015年，百度云的注冊(cè)用戶已超過(guò)3億。

這4個(gè)云備份服務(wù)提供商均向第三方開發(fā)者提供了移動(dòng)端平臺(tái)的云備份SDK。這些SDK通過(guò)將云備份服務(wù)集成為軟件開發(fā)工具包，極大地簡(jiǎn)化了第三方開發(fā)者的開發(fā)流程，更有利于增大服務(wù)影響力。開發(fā)者可以通過(guò)將下載的SDK導(dǎo)入到應(yīng)用工程中對(duì)云備份服務(wù)進(jìn)行調(diào)用。這些SDK的體系結(jié)構(gòu)將云備份服務(wù)接口的內(nèi)部抽象實(shí)現(xiàn)進(jìn)行封裝，僅對(duì)外提供有限的功能調(diào)用接口，在節(jié)省第三方應(yīng)用開發(fā)者工作量的同時(shí)，也極大地方便了用戶的操作和管理。

2.2 動(dòng)機(jī)

本文的研究動(dòng)機(jī)主要基于以下幾個(gè)方面。

1) 雖然目前安卓系統(tǒng)的云備份模塊已經(jīng)被第三方應(yīng)用廣泛調(diào)用，但至今還沒有一個(gè)對(duì)移動(dòng)端云備份SDK使用量的相關(guān)分析。

2) 為了將云備份服務(wù)集成到第三方應(yīng)用中，所有數(shù)據(jù)需要通過(guò)調(diào)用移動(dòng)端云備份SDK來(lái)與其遠(yuǎn)程云備份服務(wù)進(jìn)行交互。目前各項(xiàng)研究已經(jīng)紕漏了很多云備份服務(wù)中身份與數(shù)據(jù)泄露的漏洞。基于此，這些備份模塊的代碼安全問(wèn)題是保證移動(dòng)設(shè)備數(shù)據(jù)安全的關(guān)鍵，但目前針對(duì)代碼安全的分析還沒有出現(xiàn)。

3) 據(jù)本文調(diào)研顯示，目前移動(dòng)端云備份SDK自身的編碼漏洞問(wèn)題和第三方應(yīng)用誤用這些SDK的問(wèn)題越來(lái)越普遍，通過(guò)研究這些SDK的代碼安全性問(wèn)題來(lái)提醒云備份服務(wù)提供商和第三方開發(fā)者非常有必要。然而，這些安全問(wèn)題和相關(guān)措施還沒有被總結(jié)和提出。

3 部署調(diào)研

為了分析上述云備份SDK的安全性問(wèn)題，本文首先統(tǒng)計(jì)了這些安卓云備份 SDK在第三方應(yīng)用中被調(diào)用的情況。通過(guò)從這些不同的云備份服務(wù)（Dropbox、OneDrive、Google Drive和百度云）的官方網(wǎng)頁(yè)中查閱提供給第三方開發(fā)者的官方指南和程序示例，對(duì)抓取的所有安卓市場(chǎng)的應(yīng)用進(jìn)行反編譯，本文統(tǒng)計(jì)了上述4個(gè)SDK在安卓應(yīng)用中被調(diào)用的比率。

如表1所示，通過(guò)檢測(cè)安卓操作系統(tǒng)官方應(yīng)用市場(chǎng) Google Play[11]的前 430個(gè)熱門應(yīng)用，發(fā)現(xiàn)Google Drive的SDK調(diào)用率最高（3.49%），Dropbox SDK的調(diào)用率緊隨其后（2.79%），OneDrive SDK的調(diào)用率是0.93%。然而，百度云的SDK沒有被本次數(shù)據(jù)集中的應(yīng)用所調(diào)用。此外，本文還選擇了國(guó)內(nèi)最著名的安卓應(yīng)用市場(chǎng)之一——酷安網(wǎng)[12]作為另一個(gè)調(diào)研的市場(chǎng)，共檢測(cè)了前500個(gè)熱門應(yīng)用。統(tǒng)計(jì)數(shù)據(jù)表明，Dropbox SDK的調(diào)用率最高（9.8%），Google Drive的SDK調(diào)用率排第二（6.00%），OneDrive SDK的調(diào)用率是2.2%，百度云 SDK的調(diào)用率最低，為 0.60%?？傮w來(lái)言，Google Play應(yīng)用市場(chǎng)的前430個(gè)熱門應(yīng)用中，有5.11%的應(yīng)用調(diào)用了這4個(gè)主流的云備份SDK；而酷安網(wǎng)應(yīng)用市場(chǎng)的前500個(gè)熱門應(yīng)用中有12.80%的應(yīng)用調(diào)用了這些SDK，可知云備份服務(wù)在國(guó)內(nèi)熱門應(yīng)用中普及率更高。在分析過(guò)這些調(diào)用云備份SDK的應(yīng)用種類后，發(fā)現(xiàn)這些應(yīng)用主要有文件管理器、文檔編輯器、文檔掃描儀、照片編輯器、筆記和日歷表等。

表1 Google Play與酷安網(wǎng)應(yīng)用市場(chǎng)云備份SDK的使用分布情況

4 代碼分析

為了進(jìn)一步分析4個(gè)移動(dòng)云備份服務(wù)的功能特性，本文通過(guò)查閱其官方文檔和SDK源代碼分析它們的接口實(shí)現(xiàn)。如表2所示，文件管理作為云備份服務(wù)的基本功能，包括文件的創(chuàng)建、獲取、上傳、刪除等操作，這4個(gè)SDK均支持該功能。此外，還存在一些其他特性以幫助簡(jiǎn)化用戶操作和提高系統(tǒng)性能。配額管理功能允許用戶查詢其可用存儲(chǔ)空間，幫助其合理地規(guī)劃剩余空間或通過(guò)充值來(lái)擴(kuò)大存儲(chǔ)空間，4個(gè)云備份服務(wù)提供商均支持此項(xiàng)功能。另一個(gè)特性是文件的批量處理，允許用戶對(duì)文件進(jìn)行批量上傳、下載、刪除等操作。據(jù)本文的調(diào)研分析發(fā)現(xiàn)，僅百度云在其SDK中支持了此項(xiàng)功能，其他3個(gè)云備份SDK沒有提供批量處理功能，第三方應(yīng)用開發(fā)者需在其代碼邏輯中自行實(shí)現(xiàn)。此外，SDK中還有一些高級(jí)特性來(lái)提升用戶體驗(yàn)，包括獲取文件縮略圖、轉(zhuǎn)碼視頻文件、秒速傳輸大文件、離線下載等，經(jīng)過(guò)調(diào)研分析，這些高級(jí)特性僅百度云有全面支持，而Dropbox、OneDrive和Google Drive的SDK均注重于基本功能的實(shí)現(xiàn)，并未對(duì)高級(jí)特性和批量處理功能提供支持。

為保證整個(gè)傳輸過(guò)程的有效性和安全性，云備份服務(wù)提供商制定和采用了一系列協(xié)議對(duì)第三方應(yīng)用調(diào)用移動(dòng)端的云備份服務(wù)進(jìn)行規(guī)范。本文通過(guò)研究云備份 SDK源代碼和第三方應(yīng)用的反編譯代碼，對(duì)以上云備份服務(wù)所用到的4個(gè)主要協(xié)議（通信協(xié)議、加密協(xié)議、去重協(xié)議和授權(quán)協(xié)議）進(jìn)行了全面的分析比較。

表2 安卓云備份SDK的接口功能統(tǒng)計(jì)

1) 通信協(xié)議定義了一個(gè)通信系統(tǒng)的規(guī)則和通信數(shù)據(jù)格式，以允許2個(gè)或多個(gè)實(shí)體通過(guò)通信信道和設(shè)備實(shí)現(xiàn)資源共享和信息互換[13]。

2) 加密協(xié)議提供了將源數(shù)據(jù)（明文）轉(zhuǎn)換成另一種形式數(shù)據(jù)（密文）的轉(zhuǎn)換方式，以實(shí)現(xiàn)信息隱蔽，使數(shù)據(jù)不能被除被授權(quán)方外其他人輕易解密，一定程度上保證了信息的安全性和可靠性[14]。

3) 去重協(xié)議旨在消除服務(wù)器上重復(fù)的數(shù)據(jù)副本。通過(guò)建立數(shù)據(jù)副本與數(shù)據(jù)的連接，不保存副本數(shù)據(jù)本身來(lái)節(jié)約存儲(chǔ)空間[15]。

4) 授權(quán)協(xié)議通過(guò)用戶對(duì)一個(gè)第三方應(yīng)用進(jìn)行授權(quán)，使該應(yīng)用可以代表資源擁有者或者其自身來(lái)獲取有限HTTP（hypertext transfer protocol）服務(wù)的權(quán)限，保證用戶的數(shù)據(jù)只能被該應(yīng)用訪問(wèn)[16]。

下文討論這 4個(gè)協(xié)議在 Dropbox、Google Drive、OneDrive和百度云SDK的使用情況及其各自的安全問(wèn)題，這4個(gè)云備份服務(wù)的協(xié)議對(duì)比情況如表3所示。

表3 安卓云備份SDK的協(xié)議使用情況統(tǒng)計(jì)

4.1 通信協(xié)議分析

表3中四大云備份SDK均采用了超文本傳輸安全協(xié)議（HTTPS，secure hypertext transferprotocol）作為其網(wǎng)絡(luò)通信協(xié)議，該協(xié)議使用安全套接字層（SSL，secure socket layer）來(lái)保證客戶端與服務(wù)器安全地完成信息交換。與超文本傳輸協(xié)議（HTTP）相比， HTTPS會(huì)導(dǎo)致資源和性能上的消耗[17]，影響緩存機(jī)制，并會(huì)產(chǎn)生一些諸如將HTTPS和HTTP混合使用導(dǎo)致的瀏覽器警告問(wèn)題[18]，但是據(jù)本文調(diào)研得知，這4個(gè)主流云備份SDK在整個(gè)網(wǎng)絡(luò)請(qǐng)求過(guò)程中仍然使用的是安全的通信協(xié)議（HTTPS）。在數(shù)據(jù)通信過(guò)程中，保證數(shù)據(jù)傳輸?shù)陌踩允且豁?xiàng)基本要素，如果在第三方應(yīng)用和云備份服務(wù)的通信中不使用安全的通信協(xié)議將會(huì)導(dǎo)致中間人攻擊，雖然采用HTTPS會(huì)造成一定程度的性能損失，但對(duì)于第三方應(yīng)用來(lái)說(shuō)這是有必要的。然而，HTTPS近幾年頻繁曝出相關(guān)漏洞，如未進(jìn)行正確邊界檢查導(dǎo)致的Heartbleed漏洞[19]、證書過(guò)期或不合法導(dǎo)致的SSL中間人劫持問(wèn)題[20]等。HTTPS目前仍然存在很多亟待解決的安全問(wèn)題[21,22]，如SSL 證書的信用鏈體系不完備、加密范圍也比較有限等問(wèn)題，因此，將HTTPS作為保障用戶數(shù)據(jù)安全的唯一措施是不夠的。

4.2 加密協(xié)議分析

為進(jìn)一步保證數(shù)據(jù)傳輸以及存儲(chǔ)過(guò)程中的安全性，有必要采用加密協(xié)議，以在一定程度上減輕數(shù)據(jù)被攻擊者竊取時(shí)的安全威脅。如表3所示，本文發(fā)現(xiàn)四大云備份 SDK均沒有在客戶端提供加密數(shù)據(jù)的功能。經(jīng)過(guò)分析，可能有2個(gè)原因：一方面，SDK的開發(fā)者認(rèn)為HTTPS提供了端到端的保護(hù)機(jī)制，這已經(jīng)足夠減輕截取網(wǎng)絡(luò)流量產(chǎn)生的安全威脅；另一方面，如果要在客戶端對(duì)用戶數(shù)據(jù)進(jìn)行加密，加密密鑰需要保存在客戶端，一旦密鑰泄露，加密也形同虛設(shè)?；谝陨显?，云備份服務(wù)提供商認(rèn)為在客戶端加密是不必要的。

然而，如4.1節(jié)所說(shuō)，僅使用HTTPS進(jìn)行網(wǎng)絡(luò)請(qǐng)求對(duì)數(shù)據(jù)進(jìn)行傳輸不是絕對(duì)安全的。多數(shù)情況下，用戶不會(huì)主動(dòng)加密自己的數(shù)據(jù)。因此，為保證用戶數(shù)據(jù)的安全，云備份服務(wù)提供商必須考慮將加密工具整合到其SDK中，而用戶加密密鑰可以保存在服務(wù)器端，這樣就可以在保證只產(chǎn)生較低通信成本的基礎(chǔ)上，顯著提高用戶個(gè)人數(shù)據(jù)的安全性。

4.3 去重協(xié)議分析

隨著云備份服務(wù)提供給用戶越來(lái)越多的網(wǎng)絡(luò)存儲(chǔ)空間，大量數(shù)據(jù)被存儲(chǔ)到遠(yuǎn)程備份服務(wù)器中。為了消除相同數(shù)據(jù)的多個(gè)副本以節(jié)約服務(wù)器資源，需要提供一種特有的數(shù)據(jù)壓縮技術(shù)。去重協(xié)議的出現(xiàn)可以消除冗余數(shù)據(jù)，以提高存儲(chǔ)和帶寬利用率[23]?；诖?，出于經(jīng)濟(jì)效益的考慮，幾乎所有的云備份服務(wù)均采用了去重協(xié)議。

目前存在2種去重方法：基于目標(biāo)的去重方法（target-based deduplication）和基于源的去重方法（source-based deduplication）[15]。基于目標(biāo)的去重方法需要在服務(wù)器端進(jìn)行去重，即數(shù)據(jù)文件需要先傳輸?shù)椒?wù)器，再由服務(wù)器根據(jù)已存在的數(shù)據(jù)確定是否為冗余數(shù)據(jù)，以決定是否需要保留該數(shù)據(jù)文件。該去重方法會(huì)顯著提高服務(wù)器端的存儲(chǔ)利用率，但不會(huì)節(jié)約網(wǎng)絡(luò)帶寬，對(duì)客戶端和用戶完全透明?；谠吹娜ブ胤椒ㄊ侵笖?shù)據(jù)文件會(huì)在客戶端傳輸前進(jìn)行判斷和去重操作，即源數(shù)據(jù)傳輸前會(huì)先將其散列值傳到服務(wù)器端，由服務(wù)器判斷該數(shù)據(jù)是否已存在，如果已存在，則通知客戶端不必對(duì)該數(shù)據(jù)再次傳輸，實(shí)現(xiàn)了數(shù)據(jù)文件的秒速傳輸，在提高服務(wù)器存儲(chǔ)利用率的同時(shí)，也節(jié)約了客戶端的網(wǎng)絡(luò)帶寬。

為進(jìn)一步確認(rèn)以上四大云備份 SDK的去重協(xié)議，本文在調(diào)研分析中進(jìn)行了如下實(shí)驗(yàn)。

1) 創(chuàng)建一個(gè)網(wǎng)絡(luò)中獨(dú)有的 550 M 的加密文件（通過(guò)加密文件來(lái)保證其在備份服務(wù)器上的唯一性）。

2) 將該文件通過(guò)第三方應(yīng)用調(diào)用相關(guān)云備份SDK，分別傳輸?shù)紻ropbox、Google Drive、OneDrive和百度云服務(wù)器中。

3) 監(jiān)控各自的網(wǎng)絡(luò)流量并記錄上傳時(shí)間。

4) 重命名該加密文件，并再次通過(guò)第三方應(yīng)用將其上傳到這4個(gè)云備份服務(wù)器中，繼續(xù)監(jiān)控網(wǎng)絡(luò)流量和上傳時(shí)間。

5) 針對(duì)4個(gè)云備份服務(wù)分別比較2次實(shí)驗(yàn)的網(wǎng)絡(luò)流量和上傳時(shí)間判斷文件是否秒速上傳。

基于源的去重方式最顯著的特點(diǎn)是當(dāng)用戶上傳一個(gè)云服務(wù)器上已存在的文件時(shí)，會(huì)實(shí)現(xiàn)秒速上傳功能。本文就以上4個(gè)云備份SDK的去重協(xié)議進(jìn)行了調(diào)研，如表3所示，結(jié)果表明，Dropbox、Google Drive和OneDrive的SDK采用的是基于目標(biāo)的去重協(xié)議，而百度云SDK采用的是基于源的去重協(xié)議。

此外，在實(shí)驗(yàn)過(guò)程中，發(fā)現(xiàn)有些云備份SDK是基于某個(gè)特定大小的數(shù)據(jù)塊為單位進(jìn)行去重，而不是完整的文件數(shù)據(jù)塊。通過(guò)監(jiān)控網(wǎng)絡(luò)流量，發(fā)現(xiàn)Dropbox將整個(gè)文件分成8 MB的數(shù)據(jù)塊進(jìn)行分片傳輸和去重，而OneDrive以160 kB作為數(shù)據(jù)塊大小。此外，百度云SDK的數(shù)據(jù)塊大小為4 MB。但是，Google Drive并沒有提供基于數(shù)據(jù)塊去重的方法，而是以整個(gè)文件為單位進(jìn)行傳輸與去重。與基于塊的去重方式相比，這種方法去重粒度更大，除了會(huì)使服務(wù)器的存儲(chǔ)利用率有明顯降低外，還會(huì)使大文件的傳輸失敗率增加，導(dǎo)致用戶不易察覺的數(shù)據(jù)丟失等安全問(wèn)題。

雖然對(duì)客戶端和服務(wù)器而言，云備份服務(wù)采用的去重協(xié)議有很多優(yōu)勢(shì)，但其中仍然有很多潛在的安全威脅，尤其是對(duì)于基于源的去重方法。百度云 SDK所采用的基于源的去重方法是通過(guò)服務(wù)器在文件傳輸前檢查其信息——摘要算法 5（MD5，message-digest algorithm 5）值來(lái)確認(rèn)服務(wù)器端是否已存在該副本，如果已經(jīng)存在，則由服務(wù)器端直接生成一個(gè)文件鏈接，而省去了客戶端與服務(wù)器端網(wǎng)絡(luò)傳輸該文件的操作。

然而，現(xiàn)有研究已經(jīng)證明使用 MD5值來(lái)簽名一個(gè)文件，存在嚴(yán)重的漏洞，攻擊者可以事先構(gòu)建一個(gè)文件B為文件A的MD5值碰撞[24]，并將其上傳至服務(wù)器（需保證文件B的首創(chuàng)性，不會(huì)被服務(wù)器作為冗余數(shù)據(jù)去重）。由于文件A與文件B的MD5值相同，當(dāng)用戶在隨后請(qǐng)求上傳文件A時(shí)，百度云的備份服務(wù)器通過(guò)判斷發(fā)現(xiàn)服務(wù)器上已存在MD5值相同的文件，并直接為文件A生成一個(gè)MD5值相同但文件內(nèi)容不同的文件B的鏈接，導(dǎo)致文件A被判斷為冗余數(shù)據(jù)，并沒有通過(guò)實(shí)際的網(wǎng)絡(luò)傳輸保存在備份服務(wù)器，最終導(dǎo)致用戶的文件A數(shù)據(jù)丟失。此外，基于源的去重可以被攻擊者利用來(lái)確認(rèn)文件是否已存在于服務(wù)器，或者惡意獲取文件的內(nèi)容等，即側(cè)信道攻擊[15,25]。雖然目前很多研究者已經(jīng)提出了相關(guān)方法來(lái)減少基于源的去重方法所引起的安全威脅[26～28]，但是這些云備份服務(wù)提供商仍然沒有將這些方法應(yīng)用到其SDK的開發(fā)中。因此，為盡可能規(guī)避風(fēng)險(xiǎn)，當(dāng)?shù)谌介_發(fā)人員將基于源去重方法的云備份SDK集成到應(yīng)用中時(shí)，需要提醒用戶不要上傳敏感數(shù)據(jù)，或提前通過(guò)對(duì)數(shù)據(jù)進(jìn)行加密來(lái)阻止服務(wù)器對(duì)文件的去重行為。

4.4 授權(quán)協(xié)議分析

開放授權(quán)標(biāo)準(zhǔn)（OAuth，open authorization）是一種開放式授權(quán)協(xié)議，允許用戶授權(quán)第三方網(wǎng)站或應(yīng)用訪問(wèn)用戶存儲(chǔ)在另外服務(wù)提供者上的資源信息，而無(wú)需提供用戶名與密碼給第三方網(wǎng)站與應(yīng)用[16,29]。在云備份 SDK中，采用了 OAuth授權(quán)協(xié)議使第三方應(yīng)用在不獲取用戶云備份用戶名與密碼的前提下，可以訪問(wèn)其存儲(chǔ)在云服務(wù)器上的資源。目前，OAuth協(xié)議已經(jīng)有2個(gè)版本：OAuth1.0和 OAuth2.0。為了簡(jiǎn)化授權(quán)流程，OAuth2.0與1.0版本相比做了很多改善，提供了更多的OAuth協(xié)議流以支持移動(dòng)端應(yīng)用程序的用戶授權(quán)，并且不再需要客戶端應(yīng)用實(shí)現(xiàn)簽名等復(fù)雜的密碼學(xué)算法[30]。由表3可知，有些云備份服務(wù)提供商，如Google Drive、OneDrive和百度云在其安卓SDK開發(fā)中直接廢棄了OAuth1.0授權(quán)方式，而Dropbox仍然支持OAuth1.0授權(quán)，但是將OAuth2.0作為了默認(rèn)的授權(quán)方式。

目前，OAuth2.0已經(jīng)通過(guò)各種方法和途徑被證明協(xié)議本身是安全的[31～33]。為了避免包括竊取網(wǎng)絡(luò)流量中的敏感信息、XSS攻擊和跨站點(diǎn)請(qǐng)求偽造等潛在的攻擊[34]，OAuth工作團(tuán)隊(duì)給開發(fā)者提供了正式的官方指南，即OAuth攻擊模型[35]。但，在實(shí)際中，開發(fā)者很容易因?yàn)閰f(xié)議中沒有明確的解釋和定義而造成對(duì)協(xié)議的誤用和錯(cuò)用[36,37]，尤其是由于移動(dòng)端與Web端系統(tǒng)實(shí)現(xiàn)機(jī)制的不同所導(dǎo)致的一系列安全問(wèn)題[38,39]。例如，使用不安全的方式來(lái)傳輸或保存密碼和訪問(wèn)令牌等敏感信息?；诖耍疚倪M(jìn)行了實(shí)驗(yàn)，通過(guò)監(jiān)控網(wǎng)絡(luò)請(qǐng)求來(lái)檢測(cè)一些敏感信息是否泄露。在實(shí)驗(yàn)中發(fā)現(xiàn)，一些應(yīng)用將訪問(wèn)令牌（可作為用戶登錄和確認(rèn)用戶身份的安全證書）作為一個(gè)鍵值屬性以明文方式加入到HTTP請(qǐng)求中，攻擊者可以通過(guò)攔截HTTP請(qǐng)求輕易獲取用戶的訪問(wèn)令牌，進(jìn)而竊取用戶存儲(chǔ)在遠(yuǎn)程備份服務(wù)器中的資源數(shù)據(jù)。為了避免不必要的數(shù)據(jù)丟失和泄露，第三方應(yīng)用和云備份SDK開發(fā)者應(yīng)嚴(yán)格遵守OAuth協(xié)議官方指南。

5 安全問(wèn)題與應(yīng)對(duì)策略

隨著目前越來(lái)越多的安卓開發(fā)者將云備份SDK集成到其應(yīng)用中，移動(dòng)備份模塊的安全性問(wèn)題必需引起廣泛的重視。然而，由于云備份SDK自身的編碼漏洞和第三方開發(fā)者不正確的調(diào)用，導(dǎo)致目前仍然存在很多安全問(wèn)題。通過(guò)進(jìn)行廣泛的調(diào)研分析工作，本文討論云備份SDK的以下幾個(gè)代碼安全問(wèn)題。為盡可能減輕安全威脅，本文為第三方開發(fā)人員提供了相應(yīng)的對(duì)策。

5.1 移動(dòng)端云備份SDK自身的編碼漏洞

為簡(jiǎn)化應(yīng)用的開發(fā)流程，云備份服務(wù)向第三方應(yīng)用提供了SDK。SDK是一個(gè)函數(shù)庫(kù)，為第三方應(yīng)用訪問(wèn)云備份服務(wù)提供了簡(jiǎn)便的調(diào)用方式。雖然使用這些 SDK可以顯著降低第三方應(yīng)用的開發(fā)周期，并有利于提升用戶體驗(yàn)，但目前這些SDK自身仍然存在很多缺陷，調(diào)用這些SDK第三方應(yīng)用的安全性也會(huì)因此受到嚴(yán)重影響。

2015年 3月，Dropbox所提供的安卓平臺(tái)SDK的1.5.4-1.6.1版本被曝出認(rèn)證機(jī)制存在嚴(yán)重的安全漏洞[6]（CVE-2014-8889），該漏洞允許攻擊者通過(guò)將訪問(wèn)令牌插入到Dropbox SDK用于身份認(rèn)證的AuthActivity中，繞過(guò)其隨機(jī)數(shù)防護(hù)來(lái)竊取用戶信息。AuthActivity是一個(gè)安卓應(yīng)用的活動(dòng)（activity，安卓系統(tǒng)組件之一），可以接受幾種不同的意圖（Intent，安卓系統(tǒng)用于提供應(yīng)用間或組件間交互與通信的機(jī)制）的附加參數(shù)（extra parameter）。由于AuthActivity將屬性exported和browasable設(shè)置為 true，使其可以被攜帶有任意Intent附加參數(shù)的惡意應(yīng)用和網(wǎng)站啟動(dòng)。研究發(fā)現(xiàn)，AuthActivity中有一個(gè) Intent附加參數(shù)INTERNAL_WEB_HOST可以被攻擊者控制，最終繞過(guò)Dropbox的隨機(jī)數(shù)防護(hù)機(jī)制進(jìn)行攻擊?；诖耍粽呖梢岳么寺┒醋⑷胱约旱脑L問(wèn)令牌，將用戶手機(jī)設(shè)備的第三方應(yīng)用連接至自己的Dropbox云備份賬戶，導(dǎo)致用戶將敏感數(shù)據(jù)備份至攻擊者賬戶，并可能會(huì)從攻擊者賬戶下載到惡意數(shù)據(jù)。

2015年11月，烏云網(wǎng)[40]曝出了百度Moplus SDK漏洞[41]，漏洞被命名為蟲洞（wormhole）,引起業(yè)界廣泛關(guān)注。由于Moplus SDK在實(shí)現(xiàn)中保留了后門功能，因此也使攻擊者可以借此進(jìn)行惡意行為，如遠(yuǎn)程靜默安裝應(yīng)用、遠(yuǎn)程打開任意網(wǎng)頁(yè)、遠(yuǎn)程讀取寫入文件等。百度云應(yīng)用使用了該Moplus SDK，由于第三方應(yīng)用調(diào)用百度云SDK實(shí)現(xiàn)云備份服務(wù)的前提是手機(jī)設(shè)備中已安裝了百度云應(yīng)用，因此，所有調(diào)用百度云SDK來(lái)備份用戶數(shù)據(jù)的第三方應(yīng)用都會(huì)受到Moplus SDK漏洞的影響。

一旦SDK的漏洞被紕漏，云備份服務(wù)提供商通常會(huì)第一時(shí)間修復(fù)該漏洞，并發(fā)行一個(gè)新的SDK版本。雖然第三方開發(fā)者無(wú)法避免此類SDK自身的編碼漏洞，但在調(diào)研中發(fā)現(xiàn)有些第三方應(yīng)用不會(huì)經(jīng)常檢測(cè)其所調(diào)用的SDK版本，導(dǎo)致這些第三方應(yīng)用仍然可能會(huì)受到已有漏洞的攻擊。因此，第三方開發(fā)人員需要及時(shí)更新云備份SDK的版本或設(shè)置自動(dòng)檢查 SDK的版本更新來(lái)盡可能保證用戶數(shù)據(jù)的安全性。

5.2 安卓第三方開發(fā)者錯(cuò)誤調(diào)用云備份 SDK的問(wèn)題

除了云備份 SDK自身的編碼漏洞所導(dǎo)致的用戶存儲(chǔ)在遠(yuǎn)程服務(wù)器上的數(shù)據(jù)泄露外，第三方開發(fā)者對(duì)云備份 SDK的不正確調(diào)用仍然是一個(gè)潛在的威脅。為了幫助第三方開發(fā)者簡(jiǎn)化其集成云備份服務(wù)的過(guò)程，每個(gè)云備份服務(wù)提供商均提供了SDK及其調(diào)用指南，但出于開發(fā)過(guò)程中的簡(jiǎn)便性和性能考慮，很多第三方開發(fā)者并不會(huì)遵守這些使用說(shuō)明。此外，還有對(duì)官方調(diào)用指南理解不當(dāng)導(dǎo)致的誤用問(wèn)題。根據(jù)本文調(diào)研分析，這可能會(huì)導(dǎo)致嚴(yán)重的安全問(wèn)題。此外，為了進(jìn)一步保證第三方應(yīng)用調(diào)用云備份服務(wù)的安全性，本文為第三方開發(fā)人員提供了相應(yīng)的對(duì)策。

1) App_key和App_secret參數(shù)的硬編碼問(wèn)題

在第三方應(yīng)用集成一個(gè)移動(dòng)端云備份 SDK之前，需要首先在相應(yīng)的云備份服務(wù)中注冊(cè)該應(yīng)用，之后會(huì)得到一個(gè)云備份服務(wù)提供商授權(quán)的App_key和App_secret。當(dāng)?shù)谌綉?yīng)用調(diào)用SDK的身份認(rèn)證接口時(shí)，需要提供 App_key和App_secret讓云備份服務(wù)提供商確認(rèn)應(yīng)用的身份信息。然而，一旦這2個(gè)參數(shù)被泄露，攻擊者就可以用它們來(lái)偽造第三方應(yīng)用實(shí)施惡意行為。雖然這些云備份服務(wù)可以在發(fā)現(xiàn)異常行為后限制該應(yīng)用的權(quán)限，但這仍然會(huì)影響到應(yīng)用對(duì)接口的正常調(diào)用。因此，為了使應(yīng)用正常運(yùn)行，保證App_key和App_secret的安全是必需的。

然而，在檢測(cè)了Google Play應(yīng)用市場(chǎng)的22個(gè)調(diào)用云備份SDK的應(yīng)用和酷安網(wǎng)應(yīng)用市場(chǎng)的64個(gè)應(yīng)用后，本文發(fā)現(xiàn)很多開發(fā)者仍然沒有遵守云備份 SDK的官方調(diào)用指南。結(jié)果表明，Google Play應(yīng)用市場(chǎng)選取的22個(gè)應(yīng)用中，有2個(gè)應(yīng)用（9.09%）將其App_key和App_secret暴露在string.xml和AndroidManifest.xml等配置文件中，而在酷安網(wǎng)應(yīng)用市場(chǎng)選取的64個(gè)被測(cè)應(yīng)用中，有5個(gè)應(yīng)用（7.80%）也出現(xiàn)了上述問(wèn)題。這意味著攻擊者通過(guò)反編譯應(yīng)用的APK文件就可以輕易獲取這些敏感信息。為了盡可能避免此類漏洞，第三方應(yīng)用需要將 App_key和App_secret寫入 Java代碼中，并對(duì)代碼進(jìn)行混淆。當(dāng)然，更安全的方法是將 App_key和App_secret保存在應(yīng)用的服務(wù)器端。

2) 訪問(wèn)令牌的存儲(chǔ)問(wèn)題

訪問(wèn)令牌包含登錄會(huì)話所需的安全證書和用戶的身份認(rèn)證信息。用戶在對(duì)第三方應(yīng)用進(jìn)行授權(quán)后，云備份服務(wù)器會(huì)頒發(fā)訪問(wèn)令牌給該應(yīng)用，以允許其訪問(wèn)用戶存在云備份服務(wù)器上受保護(hù)的資源。為了避免重復(fù)進(jìn)行認(rèn)證請(qǐng)求導(dǎo)致的應(yīng)用性能和網(wǎng)絡(luò)耗費(fèi)問(wèn)題，第三方應(yīng)用通常需要將訪問(wèn)令牌存在本地以方便保存會(huì)話狀態(tài)。然而，訪問(wèn)令牌存儲(chǔ)的位置是否足夠安全，需要進(jìn)一步討論。為分析此類問(wèn)題，本文選擇了50個(gè)調(diào)用這些云備份SDK的開源安卓應(yīng)用，并分析了相關(guān)源代碼。結(jié)果表明，所有應(yīng)用均調(diào)用一個(gè)名為SharedPreferences的Java類來(lái)存儲(chǔ)訪問(wèn)令牌，該類可以在應(yīng)用的data文件夾下創(chuàng)建一個(gè)可擴(kuò)展標(biāo)記語(yǔ)言（XML，extensible markup language）文件，文件路徑為/data/data/your_packet_name/shared_prefs/ your_prefs_name.xml。由于安卓系統(tǒng)的沙箱保護(hù)機(jī)制，一個(gè)外部應(yīng)用很難訪問(wèn)到其他應(yīng)用沙箱內(nèi)的數(shù)據(jù)。多數(shù)情況下，將訪問(wèn)令牌通過(guò)調(diào)用SharedPreference類來(lái)存儲(chǔ)是安全的。然而，如果用戶的移動(dòng)設(shè)備已經(jīng)擁有了root權(quán)限，且存儲(chǔ)在SharedPreference中的訪問(wèn)令牌并未加密，則仍然會(huì)導(dǎo)致嚴(yán)重的用戶數(shù)據(jù)泄露問(wèn)題。

3) 默認(rèn)保存路徑的問(wèn)題

當(dāng)用戶通過(guò)第三方應(yīng)用從云備份服務(wù)器中下載一個(gè)文件到本地時(shí)，為簡(jiǎn)化用戶操作，第三方應(yīng)用通常會(huì)設(shè)置一個(gè)默認(rèn)保存路徑。如圖2所示，通過(guò)分析50個(gè)開源安卓應(yīng)用的源代碼，發(fā)現(xiàn)默認(rèn)下載路徑通常是一個(gè)外部存儲(chǔ)路徑，如SD卡的根路徑。這會(huì)導(dǎo)致攻擊者也有權(quán)限訪問(wèn)和修改這些文件，由于用戶通常不會(huì)在下載前檢查文件內(nèi)容，因此攻擊者可以在用戶察覺不到的情況下私自竊取和篡改用戶的敏感文件，如收入、身體情況、身份證信息等數(shù)據(jù)。

為了避免此類數(shù)據(jù)泄露問(wèn)題，本文提出第三方開發(fā)者需要將文件的默認(rèn)保存路徑設(shè)置為應(yīng)用內(nèi)部路徑，如應(yīng)用的沙箱路徑。此外，如果用戶選擇將外部存儲(chǔ)路徑作為下載路徑，則需要提醒用戶確保文件中不包含任何敏感信息。

6 相關(guān)工作

云備份服務(wù)的安全問(wèn)題一直以來(lái)都被工業(yè)界和學(xué)術(shù)界廣泛討論與研究[42]。目前，很多研究主要集中在分析云備份服務(wù)提供商是否完整地保存有用戶文件的問(wèn)題，即提供給用戶確認(rèn)文件未被云備份服務(wù)器泄露或修改的方法。Subashini等[43]總結(jié)了由于云計(jì)算的服務(wù)傳遞模型導(dǎo)致的安全問(wèn)題，并提出了幾個(gè)當(dāng)前云計(jì)算技術(shù)所面臨挑戰(zhàn)的解決方案。Chow等[44]對(duì)采用云備份服務(wù)會(huì)引起的安全問(wèn)題和嚴(yán)重性進(jìn)行了分類，并提出第三方應(yīng)用對(duì)數(shù)據(jù)的控制問(wèn)題是一個(gè)安全隱患。此外，數(shù)據(jù)持有性驗(yàn)證模型[45]的出現(xiàn)向用戶提供了在不對(duì)文件進(jìn)行逐個(gè)檢索的前提下，判斷云備份服務(wù)器上是否存有該數(shù)據(jù)的驗(yàn)證方法。另外，很多研究提供了更多改進(jìn)的存儲(chǔ)協(xié)議[46～49]。

圖2 外部下載路徑導(dǎo)致的攻擊

為了節(jié)約云服務(wù)器上的存儲(chǔ)空間和客戶端與服務(wù)器間的網(wǎng)絡(luò)傳輸帶寬，目前很多云備份服務(wù)均采用了去重協(xié)議[50]，即確保遠(yuǎn)程服務(wù)器上僅有一份真實(shí)存在的文件或文件數(shù)據(jù)塊，去除重復(fù)的冗余數(shù)據(jù)。此外，為了在此基礎(chǔ)上保證數(shù)據(jù)的機(jī)密性，Douceur等[51]提出了收斂加密（CE，convergent encryption），保證相同的文件加密后仍然相同。之后很多研究主要集中在改進(jìn)去重和CE相結(jié)合的云備份系統(tǒng)，以同時(shí)保證存儲(chǔ)空間利用率和安全性[26,27,52]。此外，Harnik等[15]對(duì)基于源的去重方式總結(jié)了其側(cè)信道攻擊的漏洞[25]。文中建議用戶通過(guò)在上傳文件前對(duì)其數(shù)據(jù)進(jìn)行加密來(lái)阻止服務(wù)器的去重操作，并提出了將去重隨機(jī)化的解決方案來(lái)應(yīng)對(duì)去重所導(dǎo)致的攻擊。Mulazzani等[53]提出通過(guò)客戶端的數(shù)據(jù)所有權(quán)證明來(lái)避免散列值篡改攻擊，他們發(fā)現(xiàn)了Dropbox的相關(guān)漏洞來(lái)說(shuō)明此類問(wèn)題的嚴(yán)重性。

近幾年，由于云備份服務(wù)和移動(dòng)設(shè)備的快速崛起，很多研究者將其注意力轉(zhuǎn)移到移動(dòng)端云備份的安全問(wèn)題上。基于此，為簡(jiǎn)化安卓第三方應(yīng)用的開發(fā)，云備份服務(wù)提供商通常會(huì)開發(fā)SDK供第三方開發(fā)者調(diào)用。云備份SDK的安全問(wèn)題直接影響所有調(diào)用這些 SDK的第三方應(yīng)用的用戶數(shù)據(jù)安全。Hay等[6]發(fā)現(xiàn)了安卓系統(tǒng)中Dropbox SDK的嚴(yán)重缺陷，這個(gè)缺陷會(huì)導(dǎo)致本地和遠(yuǎn)程攻擊。此外，目前很多安全社區(qū)正在致力于檢測(cè)云備份SDK的漏洞。例如，國(guó)內(nèi)的烏云網(wǎng)平臺(tái)發(fā)現(xiàn)了百度Moplus SDK的Wormhole漏洞，百度云SDK也在此波及范圍內(nèi)，使攻擊者可以在用戶檢測(cè)不到的情況下通過(guò)一個(gè)開放的 HTTP服務(wù)器訪問(wèn)存儲(chǔ)在受影響應(yīng)用中的數(shù)據(jù)內(nèi)容[54]，該漏洞導(dǎo)致1億臺(tái)安卓設(shè)備受到攻擊。

然而，以上的研究工作均沒有對(duì)安卓云備份SDK的代碼安全問(wèn)題做一個(gè)全面分析，即這些工作都將注意力集中到發(fā)現(xiàn)一個(gè)特定 SDK的某個(gè)缺陷上或提出一個(gè)更加安全的系統(tǒng)協(xié)議上。本文的研究工作與其他工作不同的是，本文致力于對(duì)安卓系統(tǒng)的移動(dòng)云備份模塊進(jìn)行全面的代碼安全分析。本文提供了 4種不同的安卓云備份 SDK（Dropbox、Google Drive、OneDrive和百度云）的安全性分析。在總結(jié)了其調(diào)用情況、協(xié)議和接口功能后，本文總結(jié)和發(fā)現(xiàn)了幾個(gè)由于SDK自身的編碼漏洞和第三方開發(fā)者錯(cuò)誤調(diào)用云備份SDK所引發(fā)的安全問(wèn)題。最后，本文向第三方開發(fā)人員提出了相應(yīng)對(duì)策來(lái)盡可能規(guī)避這些安全風(fēng)險(xiǎn)。

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

本文首次對(duì)目前四大主流的安卓云備份 SDK（Dropbox、Google Drive、OneDrive和百度云）進(jìn)行了代碼安全方面的分析。在統(tǒng)計(jì)了第三方應(yīng)用在國(guó)內(nèi)外兩大安卓應(yīng)用市場(chǎng) Google Play和酷安網(wǎng)上調(diào)用云備份SDK的比率說(shuō)明其普及性后，本文對(duì)這4個(gè)SDK進(jìn)行了接口功能的分析，并通過(guò)進(jìn)行源代碼分析對(duì)4類協(xié)議（通信協(xié)議、加密協(xié)議、去重協(xié)議和授權(quán)協(xié)議）的使用進(jìn)行了討論，結(jié)果發(fā)現(xiàn)這4個(gè)SDK均沒有在數(shù)據(jù)傳輸前對(duì)用戶文件數(shù)據(jù)進(jìn)行加密，同時(shí)百度云SDK采用的基于源的去重協(xié)議可能會(huì)導(dǎo)致嚴(yán)重的安全漏洞。此外，本文總結(jié)和發(fā)現(xiàn)了云備份SDK自身的代碼安全問(wèn)題和第三方應(yīng)用開發(fā)者錯(cuò)誤調(diào)用SDK所導(dǎo)致的漏洞?；诖?，本文向第三方開發(fā)者提供了相應(yīng)措施以盡可能保證第三方應(yīng)用的用戶數(shù)據(jù)安全。

接下來(lái)，筆者計(jì)劃將注意力轉(zhuǎn)移到發(fā)現(xiàn)更具影響力的安卓平臺(tái)移動(dòng)云備份模塊的安全隱患上。此外，由于本文總結(jié)的代碼安全問(wèn)題仍然基于實(shí)例分析，之后計(jì)劃將這些分析方法集成為一個(gè)自動(dòng)化掃描工具，通過(guò)對(duì)安卓應(yīng)用中云備份SDK調(diào)用的安全問(wèn)題進(jìn)行大規(guī)模掃描，提出更具普適性的解決方案。

[1] BUYYA R, YEO C S, VENUGOPAL S, et al. Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility[J]. Future Generation Computer Systems, 2009, 25(6): 599-616.

[2] [EB/OL]. https://www.dropbox.com/.

[3] [EB/OL]. https://www.google.com/drive/.

[4] [EB/OL]. https://onedrive.live.com/.

[5] [EB/OL]. https://yun.baidu.com/.

[6] HAY R, PELES O. Remote exploitation of the dropbox SDK for Android[EB/OL].https://dl.packetstormsecurity.net/1503-exploits/ exploiting-dropboxsdk-android.pdf.

[7] [EB/OL]. https://en.wikipedia.org/wiki/Dropbox_(service).

[8] [EB/OL]. https://en.wikipedia.org/wiki/OneDrive.

[9] [EB/OL]. https://en.wikipedia.org/wiki/Google_Drive.

[10] [EB/OL]. https://en.wikipedia.org/wiki/Baidu_Cloud.

[11] [EB/OL]. https://play.google.com/store.

[12] [EB/OL]. http://www.coolapk.com/.

[13] [EB/OL]. https://en.wikipedia.org/wiki/Communications_protocol.

[14] VLADIMIROVA T, BANU R, SWEETING M N, et al. On-board security services in small satellites[C]//IETF RFC. 2000.

[15] HARNIK D, PINKAS B, SHULMAN-PELEG A. Side channels in cloud services: deduplication in cloud storage[J]. IEEE Security & Privacy, 2010, 8(6):40-47.

[16] RECORDON D, HARDT D. The OAuth 2.0 authorization framework[J]. Polymer, 2009, 50(24): 5708-5712.

[17] GOLDBERG A, BUFF R, SCHMITT A. A comparison of HTTP and HTTPS performance[J]. Computer Measurement Group, 1998.

[18] SUN S T, HAWKEY K, BEZNOSOV K. Systematically breaking and fixing OpenID security: formal analysis, semi-automated empirical evaluation, and practical countermeasures[J]. Computers & Security, 2012, 31(4):465-483.

[19] DURUMERIC Z, KASTEN J, ADRIAN D, et al. The Matter of Heartbleed[C]// Conference on Internet Measurement. 2014:475-488.

[20] 魏興國(guó). HTTP和 HTTPS協(xié)議安全性分析[J]. 程序員, 2007(7):53-55. WEI X G. Security analysis of HTTP and HTTPS protocol[J]. The Programmer, 2007(7):53-55.

[21] FAHL S, HARBACH M, MUDERS T, et al. Why eve and mallory love Android: an analysis of Android SSL (in)security[C]//ACM Conference on Computer and Communications Security. 2012: 50-61.

[22] FAHL S, HARBACH M, PERL H, et al. Rethinking SSL development in an appified world[C]//ACM Sigsac Conference on Computer & Communications Security. 2013:49-60.

[23] PATIL M A V, KALE M N D. Survey on secure authorized de-duplication in hybrid cloud[J]. International Journal on Recent and Innovation Trends in Computing and Communication, 2014, 2(11): 3574-3577.

[24] WANG X, YU H. How to break MD5 and other hash functions[C]// International Conference on Theory and Applications of Cryptographic Techniques. 2005:561-561.

[25] PULLS T. (More) Side channels in cloud storage[M]//Privacy and Identity Management for Life. Berlin Heidelberg: Springer, 2011: 102-115.

[26] BELLARE M, KEELVEEDHI S, RISTENPART T. DupLESS: server-aided encryption for deduplicated storage[C]// Usenix Conference on Security. 2013:179-194.

[27] LIU J, ASOKAN N, PINKAS B. Secure deduplication of encrypted data without additional independent servers[C]//The 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015: 874-885.

[28] XU J, CHANG E C, ZHOU J. Weak leakage-resilient client-side deduplication of encrypted data in cloud storage[C]// The 8th ACM SIGSAC Symposium on Information, Computer and Communications Security. 2013: 195-206.

[29] 張?zhí)扃? OAuth 協(xié)議安全性研究[J]. 信息網(wǎng)絡(luò)安全, 2013(3):68-70. ZHANG T Q. Study on OAuth protocol security[J]. Netinfo Security, 2013(3):68-70.

[30] HAMMER-LAHAV E. Introducing oauth 2.0[J]. Hueniverse, 2010.

[31] PAI S, SHARMA Y, KUMAR S, et al. Formal verification of OAuth 2.0 using alloy framework[C]//The International Conference on Communication Systems and Network Technologies. 2011: 655-659.

[32] CHARI S, JUTLA C S, ROY A. Universally composable security analysis of OAuth v2.0.[J]. Iacr Cryptology Eprint Archive, 2011.

[33] SLACK Q, FROSTIG R. OAuth 2.0 implicit grant flow analysis using Murphi[J].

[34] ALESSANDRI A, BESCHI S, CASCIARO R, et al. The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[C]//ACM Conference on Computer and Communications Security. 2012:378-390.

[35] MCGLOIN M, HUNT P. OAuth 2.0 Threat model and security considerations[J]. Internet Engineering Task Force (IETF) RFC, 2013.

[36] KIANI K. How to secure your oauth implementation[EB/OL].https://www.mendeley.com/research/four-attacks-oauth-secure-oaut h-implementation/.

[37] WANG R, ZHOU Y, CHEN S, et al. Explicating SDKS: uncovering assumptions underlying secure authentication and authorization[C]//Presented as Part of the 22nd USENIX Security Symposium. 2013: 399-314.

[38] CHEN E Y, PEI Y, CHEN S, et al. Oauth demystified for mobile application developers[C]//The 2014 ACM SIGSAC Conference on Computer and Communications Security. ACM, 2014: 892-903.

[39] WANG H, ZHANG Y, LI J, et al. Vulnerability assessment of oauth implementations in android applications[C]//The 31st Annual Computer Security Applications Conference. ACM, 2015: 61-70.

[40] [EB/OL]. http://www.wooyun.org/.

[41] [EB/OL]. http://www.androidheadlines.com/2014/11/50-users-rootphones- order-removebuilt-apps-one.html.

[42] FERNANDES D A B, SOARES L F B, GOMES J V, et al. Security issues in cloud environments: a survey[J]. International Journal of Information Security, 2013, 13(2):113-170.

[43] SUBASHINI S, KAVITHA V. A survey on security issues in service delivery models of cloud computing[J]. Journal of Network & Computer Applications, 2011, 35(1):1-11.

[44] CHOW R, GOLLE P, JAKOBSSON M, et al. Controlling data in the cloud: outsourcing computation without outsourcing control[J]. ACM Workshop on Cloud Computing Security, 2009:85-90.

[45] ATENIESE G, BURNS R, CURTMOLA R, et al. Provable data possession at untrusted stores[C]//ACM Conference on Computer and Communications Security. ACM, 2007:598-609.

[46] JUELS A, KALISKI B S. Pors: proofs of retrievability for large files[C]//ACM Conference on Computer and Communications Security. ACM, 2007:584-597.

[47] BOWERS K D, JUELS A, OPREA A. Proofs of retrievability: theory and implementation[C]//ACM Cloud Computing Security Workshop 2009:43-54.

[48] ATENIESE G, PIETRO R D, MANCINI L V, et al. Scalable and efficient provable data possession.[C]//The 4th International Conference on Security and Privacy in Communication Networks. 2008:1-10.

[49] ERWAY C C, PAPAMANTHOU C, TAMASSIA R. Dynamic provable data possession[J]. ACM Transactions on Information & System Security, 2009, 17(4):213-222.

[50] QUINLAN S, DORWARD S. Venti: a new approach to archival storage[C]// The Conference on File and Storage Technologies. USENIX Association. 2002:89-101.

[51] DOUCEUR J R, ADYA A, BOLOSKY W J, et al. Reclaiming space from duplicate files in a serverless distributed file system[C]//The International Conference on Distributed Computing Systems. 2002: 617-624.

[52] BELLARE M, KEELVEEDHI S. Interactive message-locked encryption and secure deduplication[M]//Public-Key Cryptography-PKC 2015. Berlin Heidelberg: Springer, 2015:516-538.

[53] MULAZZANI M, SCHRITTWIESER S, LEITHNER M, et al. Dark clouds on the horizon: using cloud storage as attack vector and online slack space[C]//USENIX Security. 2011:5.

[54] [EB/OL].http://blog.trendmicro.com/trendlabs-security-intelligence/ setting-the-record-straight-on-moplus-sdk-and-the-wormholevulnerability/.

Code security of mobile backup modules on the Android platform

LIANG Jiao1, LIU Wu1, HAN Wei-li1, WANG Xiao-yang1, GAN Si-yu2, SHEN Shuo3

(1. Shanghai Key Laboratory of Data Science, Fudan University, Shanghai 201203, China;
2. Shanghai Information Investment Inc, Shanghai 200120, China;
3. Computer Network Information Center, Chinese Academy of Sciences, Beijing 100190, China)

Since more and more third-party Android applications integrate backup services, the security issues of mobile backup modules are critical. By studying how widely these backup services were being used in the Android applications, the differences of code security about four mainstream Android backup SDK were investigated. After analyzing and comparing the usages, protocols and API functions of these SDK. Based on the above findings and three reported security issues of mobile backup services, the countermeasures for third-party application developers were suggested to securely call the SDK of mobile backup services.

mobile cloud storage, code security, backup services, SDK

TP309

A

10.11959/j.issn.2096-109x.2017.00132

梁蛟（1993-），女，山西忻州人，復(fù)旦大學(xué)碩士生，主要研究方向?yàn)樵苽浞菹到y(tǒng)安全、訪問(wèn)控制。

劉武（1992-），男，湖南湘潭人，復(fù)旦大學(xué)碩士生，主要研究方向?yàn)樵苽浞菹到y(tǒng)安全、訪問(wèn)控制。

韓偉力（1975-），男，浙江紹興人，博士，復(fù)旦大學(xué)副教授，主要研究方向?yàn)樵L問(wèn)控制、數(shù)字身份安全、網(wǎng)絡(luò)與系統(tǒng)安全。

王曉陽(yáng)（1960-），男，上海人，博士，復(fù)旦大學(xué)特聘教授、博士生導(dǎo)師，主要研究方向?yàn)閿?shù)據(jù)庫(kù)、并行式數(shù)據(jù)分析和信息安全。

甘似禹（1966-），男，江西撫州人，上海市信息投資股份有限公司大數(shù)據(jù)研究院高級(jí)工程師，主要研究方向?yàn)殡娮訑?shù)據(jù)交換、數(shù)據(jù)質(zhì)量和系統(tǒng)安全。

沈爍（1977-），男，遼寧阜新人，博士，中國(guó)科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心物聯(lián)網(wǎng)中心副主任、副研究員，主要研究方向?yàn)槲锫?lián)網(wǎng)標(biāo)準(zhǔn)體系、信息安全。

2016-09-23；

2016-11-15。通信作者：韓偉力, wlhan@fudan.edu.cn

上海市科技創(chuàng)新行動(dòng)計(jì)劃基金資助項(xiàng)目（No.16DZ1100200, No.15511101500）

Foundation Item: The Shanghai Innovation Action Project (No.16DZ1100200, No.15511101500)