首先對(duì)遇到的安全問題進(jìn)行歸類：
服務(wù)交互安全測(cè)試
- 進(jìn)程間交互安全
由于Android App之間不能共享內(nèi)存秧廉，為了實(shí)現(xiàn)不同進(jìn)程之間的通信昵仅，對(duì)應(yīng)到Android系統(tǒng)中的四種組件即為：Activity劫扒，Content provider诫睬，Broadcast以及Service巫延。使用沒有安全性的進(jìn)程通信機(jī)制可能會(huì)導(dǎo)致App的敏感數(shù)據(jù)泄露
解決辦法：
在AndroidManifest. xml中檢查Activity的exported屬性是否位true励两，如果為true黎茎，則可以被第三方App啟動(dòng)，繞過(guò)登錄等其他頁(yè)面当悔，暴露用戶敏感數(shù)據(jù)傅瞻。
在AndroidManifest. xml中檢查Content provider的exported屬性是否位true，如果為true盲憎，則可以被第三方App調(diào)用實(shí)現(xiàn)增刪改查嗅骄。
在AndroidManifest. xml中檢查Broadcast的exported屬性是否位true，如果為true饼疙，則可以接受第三方App發(fā)送的廣播消息溺森。
在AndroidManifest. xml中檢查Service的exported屬性是否位true，如果為true宏多，則可以被第三方App啟動(dòng)儿惫。
- WebView交互安全
如果使用了webview，則搜索關(guān)鍵字accessibility伸但、accessibilityTraversal和searchBoxJavaBridge_ 在使用webview之前需要調(diào)用removeJavascriptInterface("accessibility")肾请，removeJavascriptInterface("accessibilityTraversal")，removeJavascriptInterface("searchBoxJavaBridge_ ")三個(gè)函數(shù)更胖，如果任意一個(gè)函數(shù)沒有調(diào)用铛铁，則存在問題隔显。
如果使用了webview，則搜索關(guān)鍵字setSavePassword饵逐。在使用webview之前需要調(diào)用setSavePassword(false)函數(shù)括眠，如果沒有調(diào)用，則存在問題倍权。
如果使用了webview掷豺，那就在源碼中搜索OnReceivedSslError關(guān)鍵字。當(dāng)存在onReceivedSslError函數(shù)時(shí)薄声，檢查其中的處理方法当船，如果調(diào)用的是handle.proceed()則存在錯(cuò)誤，直接忽略了ssl的錯(cuò)誤默辨。如果調(diào)用的是handle.cancle()則沒有問題德频。檢測(cè)WebView加載的頁(yè)面在未明確要求下，是否使用了Javascript
搜索關(guān)鍵字setAllowFileAccess缩幸。在使用webview之前需要調(diào)用setAllowFileAccess(false)函數(shù)壹置，如果沒有調(diào)用或者設(shè)置為true，則可能存在同源策略漏洞表谊，需要進(jìn)一步判斷钞护。
如果設(shè)置了setAllowFileAccess(true)，則需要設(shè)置setAllowFileAccessFromFileURLs(false)和setAllowUniversalAccessFromFileURLs(false)爆办，同時(shí)需要訪談開發(fā)setAllowFileAccess(true)的目的以及是否存在風(fēng)險(xiǎn)患亿。此函數(shù)的目的是為了可以通過(guò)webview加載html文件，如果html文件是寫死可控的押逼，則也可以認(rèn)為是安全的，如果html文件是變化的惦界，或者是存儲(chǔ)在不安全的區(qū)域如SD卡挑格，或者是由服務(wù)端返回的，則存在風(fēng)險(xiǎn)沾歪，需要進(jìn)一步判斷漂彤。（備注：加載html里面的js代碼需要setJavaScriptEnable(true），如果為false灾搏，則風(fēng)險(xiǎn)也不大挫望，因?yàn)閮H僅加載靜態(tài)頁(yè)面風(fēng)險(xiǎn)較小）狂窑。
如果設(shè)置setAllowFileAccess(true)媳板，則在webview加載url（loadUrl、loadData泉哈、loadDataWithBaseURL）時(shí)必須全部采用https協(xié)議蛉幸，避免出現(xiàn)中間人攻擊破讨。且建議通過(guò)白名單的機(jī)制校驗(yàn)url的合法性，避免加載惡意鏈接導(dǎo)致釣魚攻擊奕纫。搜索關(guān)鍵字setJavaScriptEnabled提陶。如果此函數(shù)的參數(shù)是false，則用例pass匹层，如果是true隙笆，則繼續(xù)分析（大部分都是true）（還有可能就是一個(gè)應(yīng)用內(nèi)有多個(gè)使用webview的地方，每個(gè)webview配置的也不同升筏，這就需要每個(gè)都分析一遍） 全工程搜索JavascriptInterface關(guān)鍵字撑柔，查看通過(guò)注解標(biāo)注的函數(shù)，這些函數(shù)是暴露給js交互的接口仰冠，存在風(fēng)險(xiǎn)乏冀。如果這些函數(shù)執(zhí)行了一些敏感操作或者傳遞了一些敏感數(shù)據(jù)，則需要繼續(xù)分析（這個(gè)漏洞被外部提過(guò)不少問題洋只，要重視） 對(duì)于暴露的接口辆沦，在webview加載url（loadUrl、loadData识虚、loadDataWithBaseURL）時(shí)需要有下面三條措施：
1）采用https協(xié)議加載url肢扯，避免出現(xiàn)中間人攻擊。
2）建議通過(guò)白名單機(jī)制校驗(yàn)url的合法性担锤，避免加載惡意鏈接導(dǎo)致釣魚攻擊
3）對(duì)于不同場(chǎng)景的webview分別配置蔚晨，避免暴露所有接口（比如這個(gè)頁(yè)面的webview需要暴露很多接口，另外一個(gè)頁(yè)面的不需要暴露這些接口肛循，那第二個(gè)頁(yè)面需要單獨(dú)配置webview铭腕，不與第一個(gè)頁(yè)面使用相同的webview配置）全工程搜索shouldOverrideUrlLoading|shouldInterceptRequest關(guān)鍵字 查看是否對(duì)參數(shù)url進(jìn)行校驗(yàn)。url校驗(yàn)不能僅僅使用getHost多糠、contains累舷、startsWith、endsWith中的一個(gè)方法校驗(yàn)夹孔，很容易繞過(guò)被盈。要多個(gè)結(jié)合使用。具體需要訪談開發(fā)加載哪些域名的url搭伤，然后判斷校驗(yàn)方法是否存在繞過(guò)的風(fēng)險(xiǎn)只怎。
檢測(cè)WebView加載資源的完整性，是否加載被篡改后的惡意資源文件
檢測(cè)WebView中使用的協(xié)議是否是安全通信協(xié)議怜俐，是否包含具有潛在風(fēng)險(xiǎn)的程序功能
解決辦法：
WebView加載的HTML頁(yè)面在未明確要求下身堡，禁用Javascript
對(duì)WebView加載的外部文件進(jìn)行校驗(yàn)
采用HTTPS安全通信協(xié)議
本地?cái)?shù)據(jù)安全測(cè)試
- （1）數(shù)據(jù)創(chuàng)建要求進(jìn)行用戶協(xié)議檢測(cè)、數(shù)據(jù)采集檢測(cè)佑菩、數(shù)據(jù)輸入檢測(cè)盾沫、數(shù)據(jù)生成檢測(cè)裁赠；
（2）數(shù)據(jù)存儲(chǔ)要求進(jìn)行訪問控制檢測(cè)、數(shù)據(jù)加密檢測(cè)赴精；
（3）數(shù)據(jù)處理要求進(jìn)行用戶協(xié)議檢測(cè)佩捞、敏感數(shù)據(jù)使用不當(dāng)檢測(cè)；
（4）數(shù)據(jù)共享要求進(jìn)行第三方SDK用戶協(xié)議檢測(cè)蕾哟、與第三方SDK數(shù)據(jù)共享檢測(cè)一忱；
（5）數(shù)據(jù)備份要求進(jìn)行敏感數(shù)據(jù)備份檢測(cè)、備份數(shù)據(jù)加密強(qiáng)度檢測(cè)谭确；
（6）數(shù)據(jù)銷毀要求進(jìn)行后臺(tái)運(yùn)行檢測(cè)帘营、敏感數(shù)據(jù)清除檢測(cè)。
1.1 數(shù)據(jù)創(chuàng)建
在數(shù)據(jù)創(chuàng)建階段逐哈，開發(fā)者會(huì)通過(guò)多種方式獲取App中的用戶信息芬迄，例如用戶終端ME號(hào)碼、M號(hào)碼昂秃、位置禀梳、手機(jī)號(hào)、生物識(shí)別等肠骆，部分App還會(huì)嵌入第三方SDK算途，還可能在用戶未知情的情況下，私自上傳用戶終端或個(gè)人信息到第三方SDK的服務(wù)器端蚀腿。本節(jié)主要從用戶協(xié)議嘴瓤、數(shù)據(jù)采集、數(shù)據(jù)輸入莉钙、數(shù)據(jù)生成4個(gè)維度提出安全要求
1.1.1 用戶協(xié)議
App安裝或者更新后廓脆，在用戶啟動(dòng)App并開始使用前，一般會(huì)有一個(gè)用戶使用協(xié)議磁玉，對(duì)App的主要功能狞贱、信息保密條款、法律聲明蜀涨、信息收集等進(jìn)行說(shuō)明。用戶協(xié)議安全要求主要是Ap要存在用戶協(xié)議蝎毡，在協(xié)議中聲明用戶信息的用途以及保護(hù)措施厚柳。
1.1.2 數(shù)據(jù)采集
數(shù)據(jù)采集是指開發(fā)者因功能需求需要收集用戶手機(jī)IMEI、IMSI沐兵、版本等信息别垮，但如果過(guò)度收集用戶個(gè)人信息，且對(duì)用戶個(gè)人隱私保護(hù)不當(dāng)扎谎，容易造成用戶個(gè)人信息泄露甚至被任意售賣和傳播碳想。數(shù)據(jù)采集安全要求App申請(qǐng)權(quán)限采用最小權(quán)限機(jī)制烧董，避免過(guò)度申請(qǐng)如發(fā)送短信、讀取短信胧奔、讀取聯(lián)系人等敏感權(quán)限逊移，在使用敏感權(quán)限時(shí)要告知用戶，讓用戶自己選擇龙填，收集的數(shù)據(jù)需加密后傳輸胳泉。
1.1.3 數(shù)據(jù)輸入
數(shù)據(jù)輸入是指App客戶端與服務(wù)器端進(jìn)行通信信息交互時(shí)，App采用登錄界面岩遗、支付界面等方式獲取用戶輸入的賬戶扇商、密碼、手機(jī)號(hào)宿礁、身份證號(hào)等信息案铺。在用戶輸入期間，如果App對(duì)上述信息保護(hù)不當(dāng)梆靖，就容易造成用戶個(gè)人信息泄露控汉。數(shù)據(jù)輸入安全要求主要有以下5個(gè)方面口客戶端采用自定義的軟鍵盤，避免采用系統(tǒng)自帶的軟鍵盤涤姊，避免黑客利用 Android系統(tǒng)鍵盤 Event事件記錄機(jī)制暇番，造成用戶輸入信息泄露；
1.2 數(shù)據(jù)存儲(chǔ)
App在終端存儲(chǔ)的數(shù)據(jù)包括賬號(hào)思喊、密碼壁酬、訂單等用戶敏感信息，如果存儲(chǔ)不當(dāng)恨课，就很容易造成信息泄露舆乔，所以終端存儲(chǔ)文件的訪問控制和敏感數(shù)據(jù)加密處理直接影響著終端數(shù)據(jù)存儲(chǔ)的安全。針對(duì)數(shù)據(jù)存儲(chǔ)剂公，我們主要從訪問控制和數(shù)據(jù)加密兩個(gè)維度提出安全要求希俩。
1.2.1訪問控制
訪問控制是指App客戶端在本地生成的文件是否具有適當(dāng)?shù)脑L問權(quán)限限制。部分開發(fā)者在開發(fā)過(guò)程中未對(duì)本地生成的數(shù)據(jù)文件纲辽，xml文件等設(shè)置適當(dāng)?shù)臋?quán)限限制颜武，把只限于當(dāng)前程序訪問的文件權(quán)限設(shè)置為了允許其他App訪問，就會(huì)造成用戶數(shù)據(jù)泄露拖吼。訪問控制的安全要求是App本地存儲(chǔ)的file鳞上、xml、 cache吊档、db等文件篙议，均不允許外部程序訪問。
1.2.2 數(shù)據(jù)加密
華為欽定的安全算法
對(duì)稱加密算法可以使用：AES256及以上強(qiáng)度，禁止DES鬼贱，3DES
密鑰交換算法建議使用：DH1024移怯，ECDHE NIST-P256
數(shù)字簽名算法：DSA2048 ECDSA NIST-P256
非對(duì)稱算法建議使用：RSA2048、ECC192及以上強(qiáng)度这难；禁止使用RSA1024及以下強(qiáng)度
摘要算法建議使用：SHA256及以上強(qiáng)度舟误，非安全相關(guān)場(chǎng)景可以使用SHA1，MD5
身份認(rèn)證算法建議使用:HMAC-SHA256及以上強(qiáng)度;
數(shù)字信封建議使用：PKCS#7
目前App客戶端常用的加密算法有AES雁佳、DES脐帝、RSA、SHA糖权、MD5堵腹、Base64等。整體可以分為對(duì)稱加密算法星澳、非對(duì)稱加密算法和數(shù)字摘要算法疚顷，其中Base64不算加密算法，只是對(duì)數(shù)據(jù)進(jìn)行編碼禁偎。各個(gè)加密算法的優(yōu)缺點(diǎn)如下腿堤。
（1）對(duì)稱加密算法
高級(jí)加密標(biāo)準(zhǔn)和數(shù)據(jù)加密標(biāo)準(zhǔn)是常用的對(duì)稱加密算法，使用密鑰加密的塊算法如暖。優(yōu)點(diǎn)是加密速度快笆檀、效率高，缺點(diǎn)是加密解密是同一個(gè)密鑰盒至，密鑰泄露的話就不能再保證其安全性募谎。
（2）非對(duì)稱加密算法
RSA加密是一種非對(duì)稱加密算法心墅，采用公鑰耳鸯、私鑰進(jìn)行加解密竞川，優(yōu)點(diǎn)是不可逆，缺點(diǎn)是加密內(nèi)容有長(zhǎng)度限制酒唉。
（3）數(shù)字摘要算法
MD5加密即消息摘要算法（ message-digest algorithm）矩桂，優(yōu)點(diǎn)是不可逆、可壓縮痪伦、不容易修改侄榴、容易計(jì)算，缺點(diǎn)是存在碰撞破解的風(fēng)險(xiǎn)
SHA加密即安全哈希算法（ secure hash algorithm）网沾，優(yōu)點(diǎn)是破解難度高牲蜀、不可逆，缺點(diǎn) 修改绅这，容易計(jì)算，缺點(diǎn)是存在碰撞破解的風(fēng)險(xiǎn)在辆。
用戶數(shù)據(jù)的保護(hù)能力直接關(guān)系到用戶信息的安全证薇，根據(jù)測(cè)評(píng)過(guò)程中發(fā)現(xiàn)的目前App常用的 是可以通過(guò)窮舉進(jìn)行破解度苔。數(shù)據(jù)存儲(chǔ)加密保護(hù)方式，對(duì)數(shù)據(jù)加密安全的測(cè)評(píng)主要涉及以下5個(gè)方面：
口App在本地生成的文件（包含xml浑度、file寇窑、db、 cache）要求加密后存儲(chǔ)箩张；
口如果使用對(duì)稱加密算法對(duì)數(shù)據(jù)進(jìn)行加密存儲(chǔ)甩骏，加密密鑰不可明文存儲(chǔ)或僅進(jìn)行簡(jiǎn)單的加密存儲(chǔ)，否則會(huì)存在泄露加密密鑰先慷、用戶數(shù)據(jù)被破解的風(fēng)險(xiǎn)饮笛；
口如果對(duì)數(shù)據(jù)進(jìn)行加密存儲(chǔ)的加密算法需要用到隨機(jī)數(shù)，隨機(jī)數(shù)強(qiáng)度要高论熙，不要使用 Random類來(lái)獲取隨機(jī)數(shù)福青；需使用SecureRandom.getInstanceStrong()獲取隨機(jī)數(shù)，同時(shí)不要給 SecureRandom設(shè)置種子脓诡，以保證生產(chǎn)隨機(jī)數(shù)的安全性无午；
口對(duì)數(shù)據(jù)進(jìn)行加密存儲(chǔ)的算法不要過(guò)于單一，如果多個(gè)過(guò)程均采用同一種加密算法祝谚，一旦被破解宪迟，則會(huì)泄露所有數(shù)據(jù)；需要使用多種加密算法組合交惯，并且對(duì)不同的數(shù)據(jù)采用不同的加密算法次泽，以保證用戶數(shù)據(jù)存儲(chǔ)的安全性；
口對(duì)數(shù)據(jù)進(jìn)行加密存儲(chǔ)的算法要使用恰當(dāng)商玫，配置正確箕憾，避免使用不安全的加密算法，如
AES28拳昌、RSA2048袭异、SHA-256等加密算法被相關(guān)部門通報(bào)已不再安全。
另 ： 記錄下一些獨(dú)特的問題以及原理
- AVMP問題：
Android組件暴露攻擊原理
我們?cè)谑褂肐DE編寫代碼的時(shí)候炬藤，Intelligent Tip會(huì)給我們的編碼問題作出提示御铃，如下圖所示，
[圖片上傳失敗...(image-6e0d52-1604922281116)]
是一個(gè)使用了未初始化變量的提示沈矿。
在Eclipse這樣的IDE中上真，這是一個(gè)錯(cuò)誤提示，如果不消除這個(gè)錯(cuò)誤羹膳，連編譯都無(wú)法完成睡互，也就在一定程度上避免了程序員犯“使用未初始化變量”的錯(cuò)誤。
但如果僅僅依賴IDE來(lái)防止程序員的錯(cuò)誤，肯定是遠(yuǎn)遠(yuǎn)不夠的就珠。
對(duì)應(yīng)Android組件暴露攻擊所發(fā)現(xiàn)的漏洞寇壳，很多人喜歡把其歸類到“未對(duì)輸入進(jìn)行有效校驗(yàn)”一類，而實(shí)際上妻怎，我們也可以認(rèn)為是“使用了未正確初始化的數(shù)據(jù)造成的程序異晨茄祝”。
眾所周知逼侦，所謂組件暴露匿辩，實(shí)際上是對(duì)外暴露了應(yīng)用的接口，也就相當(dāng)于暴露了應(yīng)用程序的攻擊面榛丢。
惡意的用戶可以通過(guò)這個(gè)攻擊面來(lái)注入數(shù)據(jù)铲球，由于“未對(duì)輸入進(jìn)行有效校驗(yàn)”，也就導(dǎo)致“數(shù)據(jù)沒有正確地初始化”涕滋，一旦使用了這樣的數(shù)據(jù)睬辐，就會(huì)產(chǎn)生風(fēng)險(xiǎn)。
以Null Intent為例宾肺，一個(gè)典型的空Intent的數(shù)據(jù)格式如下溯饵，對(duì)象中大多數(shù)成員的數(shù)據(jù)為null：
[圖片上傳失敗...(image-4aaea2-1604922281116)]
一旦我們有使用類似如下的代碼，就會(huì)觸發(fā)異常：
String data = intent.getStringExtra("data"); // data=null
Log.d(TAG, "Data length:" + data.length()); //data.length會(huì)觸發(fā)NullPointerException
這就是一個(gè)典型數(shù)據(jù)未正確初始化的問題锨用。
解決方法通常是在使用外部傳入的數(shù)據(jù)前丰刊，要進(jìn)行必要的校驗(yàn)，對(duì)數(shù)據(jù)進(jìn)行正確的初始化增拥。
以上僅是Null Intent攻擊會(huì)產(chǎn)生NullPointerException問題的一個(gè)例子啄巧。實(shí)際上，這列攻擊能夠觸發(fā)超過(guò)50種不同的異常類型 如下圖[圖片上傳失敗...(image-952f83-1604922281116)]
