Android應(yīng)用會遇到各種各樣的漏洞，如何從細節(jié)上了解各種安全隱患，積極采取適當?shù)姆烙胧┍阕兊糜葹橹匾?。為了讓大家對Android漏洞有一個非常全面的認識，小編專門邀請資深安全工程師為大家詳細解讀常見的Android漏洞，僅供參考。

第一大類：Android Manifest配置相關(guān)的風險或漏洞

1、程序可被任意調(diào)試

風險詳情：安卓應(yīng)用apk配置文件Android Manifest.xml中android:debuggable=true，調(diào)試開關(guān)被打開。

危害情況：App可以被調(diào)試。

修復(fù)建議：把Android Manifest.xml配置文件中調(diào)試開關(guān)屬性關(guān)掉，即設(shè)置android:Debugable="false"。

2、程序數(shù)據(jù)任意備份

風險詳情：安卓應(yīng)用apk配置文件AndroidManifest.xml中android:allowBackup=true，數(shù)據(jù)備份開關(guān)被打開。

危害情況：App應(yīng)用數(shù)據(jù)可被備份導(dǎo)出。

修復(fù)建議：把AndroidManifest.xml配置文件備份開關(guān)關(guān)掉，即設(shè)置android:allowBackup="false"。

組件暴露：建議使用android:protectionLevel="signature"驗證調(diào)用來源。

3、Activity組件暴露

風險詳情：Activity組件的屬性exported被設(shè)置為true或是未設(shè)置exported值但IntentFilter不為空時，activity被認為是導(dǎo)出的，可通過設(shè)置相應(yīng)的Intent喚起activity。

危害情況：黑客可能構(gòu)造惡意數(shù)據(jù)針對導(dǎo)出activity組件實施越權(quán)攻擊。

修復(fù)建議：如果組件不需要與其他App共享數(shù)據(jù)或交互，請將AndroidManifest.xml 配置文件中設(shè)置該組件為exported = “False”。如果組件需要與其他App共享數(shù)據(jù)或交互， 請對組件進行權(quán)限控制和參數(shù)校驗。

4、Service組件暴露

風險詳情：Service組件的屬性exported被設(shè)置為true或是未設(shè)置exported值但IntentFilter不為空時，Service被認為是導(dǎo)出的，可通過設(shè)置相應(yīng)的Intent喚起Service。

危害情況：黑客可能構(gòu)造惡意數(shù)據(jù)針對導(dǎo)出Service組件實施越權(quán)攻擊。

修復(fù)建議：如果組件不需要與其他App共享數(shù)據(jù)或交互，請將AndroidManifest.xml 配置文件中設(shè)置該組件為exported = “False”。如果組件需要與其他App共享數(shù)據(jù)或交互， 請對組件進行權(quán)限控制和參數(shù)校驗。

5、ContentProvider組件暴露

風險詳情：Content Provider組件的屬性exported被設(shè)置為true或是Android API<=16時，Content Provider被認為是導(dǎo)出的。

危害情況：黑客可能訪問到應(yīng)用本身不想共享的數(shù)據(jù)或文件。

修復(fù)建議：如果組件不需要與其他App共享數(shù)據(jù)或交互，請將AndroidManifest.xml 配置文件中設(shè)置該組件為exported = “False”。如果組件需要與其他App共享數(shù)據(jù)或交互， 請對組件進行權(quán)限控制和參數(shù)校驗。

6、BroadcastReceiver組件暴露

風險詳情：BroadcastReceiver組件的屬性exported被設(shè)置為true或是未設(shè)置exported值但IntentFilter不為空時，BroadcastReceiver被認為是導(dǎo)出的。

危害情況：導(dǎo)出的廣播可以導(dǎo)致數(shù)據(jù)泄漏或者是越權(quán)。

修復(fù)建議：如果組件不需要與其他App共享數(shù)據(jù)或交互，請將AndroidManifest.xml 配置文件中設(shè)置該組件為exported = “False”。如果組件需要與其他App共享數(shù)據(jù)或交互， 請對組件進行權(quán)限控制和參數(shù)校驗。

7、Intent Scheme URLs攻擊

風險詳情：在AndroidManifast.xml設(shè)置Scheme協(xié)議之后，可以通過瀏覽器打開對應(yīng)的Activity。

危害情況：攻擊者通過訪問瀏覽器構(gòu)造Intent語法喚起App相應(yīng)組件，輕則引起拒絕服務(wù)，重則可能演變對App進行越權(quán)調(diào)用甚至升級為提權(quán)漏洞。

修復(fù)建議：App對外部調(diào)用過程和傳輸數(shù)據(jù)進行安全檢查或檢驗，配置category filter, 添加android.intent.category.BROWSABLE方式規(guī)避風險

第二大類：WebView組件及與服務(wù)器通信相關(guān)的風險或漏洞

1、Webview存在本地Java接口

風險詳情：android的webView組件有一個非常特殊的接口函數(shù)addJavascriptInterface，能實現(xiàn)本地java與js之間交互。

危害情況：在targetSdkVersion小于17時，攻擊者利用addJavascriptInterface這個接口添加的函數(shù)，可以遠程執(zhí)行任意代碼。

修復(fù)建議：建議開發(fā)者不要使用addJavascriptInterface，使用注入javascript和第三方協(xié)議的替代方案。

2、Webview組件遠程代碼執(zhí)行（調(diào)用getClassLoader）

風險詳情：使用低于17的targetSDKVersion，并且在Context子類中使用addJavascriptInterface綁定this對象。

危害情況：通過調(diào)用getClassLoader可以繞過google底層對getClass方法的限制。

修復(fù)建議：targetSDKVersion使用大于17的版本。

3、WebView忽略SSL證書錯誤

風險詳情：WebView調(diào)用onReceivedSslError方法時，直接執(zhí)行handler.proceed()來忽略該證書錯誤。

危害情況：忽略SSL證書錯誤可能引起中間人攻擊。

修復(fù)建議：不要重寫onReceivedSslError方法， 或者對于SSL證書錯誤問題按照業(yè)務(wù)場景判斷，避免造成數(shù)據(jù)明文傳輸情況。

4、webview啟用訪問文件數(shù)據(jù)

風險詳情：Webview中使用setAllowFileAccess(true)，App可通過webview訪問私有目錄下的文件數(shù)據(jù)。

危害情況：在Android中，mWebView.setAllowFileAccess(true)為默認設(shè)置。當setAllowFileAccess(true)時，在File域下，可執(zhí)行任意的JavaScript代碼，如果繞過同源策略能夠?qū)λ接心夸浳募M行訪問，導(dǎo)致用戶隱私泄漏。

修復(fù)建議：使用WebView.getSettings().setAllowFileAccess(false)來禁止訪問私有文件數(shù)據(jù)。

5、SSL通信服務(wù)端檢測信任任意證書

風險詳情：自定義SSL x509 TrustManager，重寫checkServerTrusted方法，方法內(nèi)不做任何服務(wù)端的證書校驗。

危害情況：黑客可以使用中間人攻擊獲取加密內(nèi)容。

修復(fù)建議：嚴格判斷服務(wù)端和客戶端證書校驗，對于異常事件禁止return 空或者null。

6、HTTPS關(guān)閉主機名驗證

風險詳情：構(gòu)造HttpClient時，設(shè)置HostnameVerifier時參數(shù)使用ALLOW_ALL_HOSTNAME_VERIFIER或空的HostnameVerifier。

危害情況：關(guān)閉主機名校驗可以導(dǎo)致黑客使用中間人攻擊獲取加密內(nèi)容。

修復(fù)建議：APP在使用SSL時沒有對證書的主機名進行校驗，信任任意主機名下的合法的證書，導(dǎo)致加密通信可被還原成明文通信，加密傳輸遭到破壞。

7、SSL通信客戶端檢測信任任意證書

風險詳情：自定義SSL x509 TrustManager，重寫checkClientTrusted方法，方法內(nèi)不做任何服務(wù)端的證書校驗。

危害情況：黑客可以使用中間人攻擊獲取加密內(nèi)容。

修復(fù)建議：嚴格判斷服務(wù)端和客戶端證書校驗，對于異常事件禁止return 空或者null。

8、開放socket端口

風險詳情：App綁定端口進行監(jiān)聽，建立連接后可接收外部發(fā)送的數(shù)據(jù)。

危害情況：攻擊者可構(gòu)造惡意數(shù)據(jù)對端口進行測試，對于綁定了IP 0.0.0.0的App可發(fā)起遠程攻擊。

修復(fù)建議：如無必要，只綁定本地ip127.0.0.1，并且對接收的數(shù)據(jù)進行過濾、驗證。

第三大類：數(shù)據(jù)安全風險

1、數(shù)據(jù)存儲

SD卡數(shù)據(jù)被第三方程序訪問

漏洞描述：發(fā)現(xiàn)調(diào)用getExternalStorageDirectory，存儲內(nèi)容到SD卡可以被任意程序訪問，存在安全隱患。

安全建議：建議存儲敏感信息到程序私有目錄，并對敏感數(shù)據(jù)加密

全局File可讀寫漏洞-openFileOutput

風險詳情：openFileOutput(String name,int mode)方法創(chuàng)建內(nèi)部文件時，將文件設(shè)置了全局的可讀權(quán)限MODE_WORLD_READABLE。

危害情況：攻擊者惡意讀取文件內(nèi)容，獲取敏感信息。

修復(fù)建議：請開發(fā)者確認該文件是否存儲敏感數(shù)據(jù)，如存在相關(guān)數(shù)據(jù)，請去掉文件全局可讀屬性。

全局文件可寫

風險詳情：openFileOutput(String name,int mode)方法創(chuàng)建內(nèi)部文件時，將文件設(shè)置了全局的可寫權(quán)限MODE_WORLD_WRITEABLE。

危害情況：攻擊者惡意寫文件內(nèi)容破壞APP的完整性。

修復(fù)建議：請開發(fā)者確認該文件是否存儲敏感數(shù)據(jù)，如存在相關(guān)數(shù)據(jù)，請去掉文件全局可寫屬性。

全局文件可讀可寫

風險詳情：openFileOutput(String name,int mode)方法創(chuàng)建內(nèi)部文件時，將文件設(shè)置了全局的可讀寫權(quán)限。

危害情況：攻擊者惡意寫文件內(nèi)容或者，破壞APP的完整性，或者是攻擊者惡意讀取文件內(nèi)容，獲取敏感信息。

修復(fù)建議：請開發(fā)者確認該文件是否存儲敏感數(shù)據(jù)，如存在相關(guān)數(shù)據(jù)，請去掉文件全局可寫、寫屬性。

2、私有文件泄露風險-getSharedPreferences

配置文件可讀

風險詳情：使用getSharedPreferences打開文件時第二個參數(shù)設(shè)置為MODE_WORLD_READABLE。

危害情況：文件可以被其他應(yīng)用讀取導(dǎo)致信息泄漏。

修復(fù)建議：如果必須設(shè)置為全局可讀模式供其他程序使用，請保證存儲的數(shù)據(jù)非隱私數(shù)據(jù)或是加密后存儲。

配置文件可寫

風險詳情：使用getSharedPreferences打開文件時第二個參數(shù)設(shè)置為MODE_WORLD_WRITEABLE。

危害情況：文件可以被其他應(yīng)用寫入導(dǎo)致文件內(nèi)容被篡改，可能導(dǎo)致影響應(yīng)用程序的正常運行或更嚴重的問題。

修復(fù)建議：使用getSharedPreferences時第二個參數(shù)設(shè)置為MODE_PRIVATE即可。

配置文件可讀可寫

風險詳情：使用getSharedPreferences打開文件時，如將第二個參數(shù)設(shè)置為MODE_WORLD_READABLE 或MODE_WORLD_WRITEABLE。

危害情況：當前文件可以被其他應(yīng)用讀取和寫入，導(dǎo)致信息泄漏、文件內(nèi)容被篡改，影響應(yīng)用程序的正常運行或更嚴重的問題。

修復(fù)建議：使用getSharedPreferences時第二個參數(shù)設(shè)置為MODE_PRIVATE。禁止使用MODE_WORLD_READABLE | MODE_WORLD_WRITEABLE模式。

3、數(shù)據(jù)加密

明文數(shù)字證書漏洞：

Apk使用的數(shù)字證書可被用來校驗服務(wù)器的合法身份，以及在與服務(wù)器進行通信的過程中對傳輸數(shù)據(jù)進行加密、解密運算，保證傳輸數(shù)據(jù)的保密性、完整性。

明文存儲的數(shù)字證書如果被篡改，客戶端可能連接到假冒的服務(wù)端上，導(dǎo)致用戶名、密碼等信息被竊取；如果明文證書被盜取，可能造成傳輸數(shù)據(jù)被截獲解密，用戶信息泄露，或者偽造客戶端向服務(wù)器發(fā)送請求，篡改服務(wù)器中的用戶數(shù)據(jù)或造成服務(wù)器響應(yīng)異常。

AES弱加密

風險詳情：在AES加密時，使用“AES/ECB/NoPadding”或“AES/ECB/PKCS5padding”的模式。

危害情況：ECB是將文件分塊后對文件塊做同一加密，破解加密只需要針對一個文件塊進行解密，降低了破解難度和文件安全性。

修復(fù)建議：禁止使用AES加密的ECB模式，顯式指定加密算法為：CBC或CFB模式，可帶上PKCS5Padding填充。AES密鑰長度最少是128位，推薦使用256位。

隨機數(shù)不安全使用

風險詳情：調(diào)用SecureRandom類中的setSeed方法。

危害情況：生成的隨機數(shù)具有確定性，存在被破解的可能性。

修復(fù)建議：用/dev/urandom或/dev/random來初始化偽隨機數(shù)生成器。

AES/DES硬編碼密鑰

風險詳情：使用AES或DES加解密時，密鑰采用硬編碼在程序中。

危害情況：通過反編譯獲取密鑰可以輕易解密APP通信數(shù)據(jù)。

修復(fù)建議：密鑰加密存儲或變形后進行加解密運算，不要硬編碼到代碼中。

數(shù)據(jù)傳輸：與上面的重復(fù)了，也可以把webview系列的漏洞歸入這一小類。

第四大類：文件目錄遍歷類漏洞

1、Provider文件目錄遍歷

風險詳情：當Provider被導(dǎo)出且覆寫了openFile方法時，沒有對Content Query Uri進行有效判斷或過濾。

危害情況：攻擊者可以利用openFile()接口進行文件目錄遍歷以達到訪問任意可讀文件的目的。

修復(fù)建議：一般情況下無需覆寫openFile方法，如果必要，對提交的參數(shù)進行“../”目錄跳轉(zhuǎn)符或其他安全校驗。

2、unzip解壓縮漏洞

風險詳情：解壓zip文件，使用getName()獲取壓縮文件名后未對名稱進行校驗。

危害情況：攻擊者可構(gòu)造惡意zip文件，被解壓的文件將會進行目錄跳轉(zhuǎn)被解壓到其他目錄，覆蓋相應(yīng)文件導(dǎo)致任意代碼執(zhí)行。

修復(fù)建議：解壓文件時，判斷文件名是否有../特殊字符。

第五大類：文件格式解析類漏洞

1、FFmpeg文件讀取

風險詳情：使用了低版本的FFmpeg庫進行視頻解碼。

危害情況：在FFmpeg的某些版本中可能存在本地文件讀取漏洞，可以通過構(gòu)造惡意文件獲取本地文件內(nèi)容。

修復(fù)建議：升級FFmpeg庫到最新版。

2、安卓“Janus”漏洞

漏洞詳情：向原始的App APK的前部添加一個攻擊的classes.dex文件(A文件)，安卓系統(tǒng)在校驗時計算了A文件的hash值，并以”classes.dex”字符串做為key保存， 然后安卓計算原始的classes.dex文件（B），并再次以”classes.dex”字符串做為key保存，這次保存會覆蓋掉A文件的hash值，導(dǎo)致Android系統(tǒng)認為APK沒有被修改，完成安裝，APK程序運行時，系統(tǒng)優(yōu)先以先找到的A文件執(zhí)行，忽略了B，導(dǎo)致漏洞的產(chǎn)生。

危害情況：該漏洞可以讓攻擊者繞過安卓系統(tǒng)的signature scheme V1簽名機制，進而直接對App進行篡改。而且由于安卓系統(tǒng)的其他安全機制也是建立在簽名和校驗基礎(chǔ)之上，該漏洞相當于繞過了安卓系統(tǒng)的整個安全機制。

修復(fù)建議：禁止安裝有多個同名ZipEntry的APK文件。

第六大類：內(nèi)存堆棧類漏洞

1、未使用編譯器堆棧保護技術(shù)

風險詳情：為了檢測棧中的溢出，引入了Stack Canaries漏洞緩解技術(shù)。在所有函數(shù)調(diào)用發(fā)生時，向棧幀內(nèi)壓入一個額外的被稱作canary的隨機數(shù)，當棧中發(fā)生溢出時，canary將被首先覆蓋，之后才是EBP和返回地址。在函數(shù)返回之前，系統(tǒng)將執(zhí)行一個額外的安全驗證操作，將棧幀中原先存放的canary和.data中副本的值進行比較，如果兩者不吻合，說明發(fā)生了棧溢出。

危害情況：不使用Stack Canaries棧保護技術(shù)，發(fā)生棧溢出時系統(tǒng)并不會對程序進行保護。

修復(fù)建議：使用NDK編譯so時，在Android.mk文件中添加：LOCAL_CFLAGS := -Wall -O2 -U_FORTIFY_SOURCE -fstack-protector-all

2、未使用地址空間隨機化技術(shù)

風險詳情：PIE全稱Position Independent Executables，是一種地址空間隨機化技術(shù)。當so被加載時，在內(nèi)存里的地址是隨機分配的。

危害情況：不使用PIE，將會使得shellcode的執(zhí)行難度降低，攻擊成功率增加。

修復(fù)建議：NDK編譯so時，加入LOCAL_CFLAGS := -fpie -pie開啟對PIE的支持。

3、libupnp棧溢出漏洞

風險詳情：使用了低于1.6.18版本的libupnp庫文件。

危害情況：構(gòu)造惡意數(shù)據(jù)包可造成緩沖區(qū)溢出，造成代碼執(zhí)行。

修復(fù)建議：升級libupnp庫到1.6.18版本或以上。

第七大類：動態(tài)類漏洞

1、DEX文件動態(tài)加載

風險詳情：使用DexClassLoader加載外部的apk、jar 或dex文件，當外部文件的來源無法控制時或是被篡改，此時無法保證加載的文件是否安全。

危害情況：加載惡意的dex文件將會導(dǎo)致任意命令的執(zhí)行。

修復(fù)建議：加載外部文件前，必須使用校驗簽名或MD5等方式確認外部文件的安全性。

2、動態(tài)注冊廣播

風險詳情：使用registerReceiver動態(tài)注冊的廣播在組件的生命周期里是默認導(dǎo)出的。

危害情況：導(dǎo)出的廣播可以導(dǎo)致拒絕服務(wù)、數(shù)據(jù)泄漏或是越權(quán)調(diào)用。

修復(fù)建議：使用帶權(quán)限檢驗的registerReceiver API進行動態(tài)廣播的注冊。

第八大類：校驗或限定不嚴導(dǎo)致的風險或漏洞

1、Fragment注入

風險詳情：通過導(dǎo)出的PreferenceActivity的子類，沒有正確處理Intent的extra值。

危害情況：攻擊者可繞過限制訪問未授權(quán)的界面。

修復(fù)建議：當targetSdk大于等于19時，強制實現(xiàn)了isValidFragment方法；小于19時，在PreferenceActivity的子類中都要加入isValidFragment ，兩種情況下在isValidFragment方法中進行fragment名的合法性校驗。

2、隱式意圖調(diào)用

風險詳情：封裝Intent時采用隱式設(shè)置，只設(shè)定action，未限定具體的接收對象，導(dǎo)致Intent可被其他應(yīng)用獲取并讀取其中數(shù)據(jù)。

危害情況：Intent隱式調(diào)用發(fā)送的意圖可被第三方劫持，導(dǎo)致內(nèi)部隱私數(shù)據(jù)泄露。

修復(fù)建議：可將隱式調(diào)用改為顯式調(diào)用。

第九大類：命令行調(diào)用類相關(guān)的風險或漏洞

1、動態(tài)鏈接庫中包含執(zhí)行命令函數(shù)：

風險詳情：在native程序中，有時需要執(zhí)行系統(tǒng)命令，在接收外部傳入的參數(shù)執(zhí)行命令時沒有做過濾或檢驗。

危害情況：攻擊者傳入任意命令，導(dǎo)致惡意命令的執(zhí)行。

修復(fù)建議：對傳入的參數(shù)進行嚴格的過濾。

最新評論