Android 應用有哪些常見，常被利用的安全漏洞？

---

非常經典的webview介面導致遠程代碼執行

http://www.fuckgcd.net/wordpress/archives/275

---

首先，題主詢問「Android 應用」的安全漏洞，說到 Android 應用的安全漏洞，如果拋開系統設計問題，其主要原因是開發過程當中疏漏引起的。但其實也並不能把這些責任都怪在程序猿頭上。所以本答案也將會對 Android 系統設計以及生態環境做一些闡述。（如果想了解 Android 惡意軟體的情況，那就需要另開題目了。）

1. 應用反編譯

漏洞：APK 包非常容易被反編譯成可讀文件，稍加修改就能重新打包成新的 APK。

利用：軟體破解，內購破解，軟體邏輯修改，插入惡意代碼，替換廣告商 ID。

建議：使用 ProGuard 等工具混淆代碼，重要邏輯用 NDK 實現。

例子：反編譯重打包 FlappyBird，把廣告商 ID 換了，遊戲改加插一段惡意代碼等等。

2. 數據的存儲與傳輸

漏洞：外部存儲（SD 卡）上的文件沒有許可權管理，所有應用都可讀可寫。開發者把敏感信息明文存在 SD 卡上，或者動態載入的 payload 放在 SD 卡上。

利用：竊取敏感信息，篡改配置文件，修改 payload 邏輯並重打包。

建議：不要把敏感信息放在外部存儲上面；在動態載入外部資源的時候驗證文件完整性。

漏洞：使用全局可讀寫（MODE_WORLD_READABLE，MODE_WORLD_WRITEABLE）的內部存儲方式，或明文存儲敏感信息（用戶賬號密碼等）。

利用：全局讀寫敏感信息，或 root 後讀取明文信息。

建議：不適用全局可讀寫的內部存儲方式，不明文存儲用戶賬號密碼。

3. 密碼泄露

漏洞：密碼明文存儲，傳輸。

利用：

• root 後可讀寫內部存儲。

• SD 卡全局可讀寫。

• 公共 WiFi 抓包獲取賬號密碼。

建議：實用成熟的加密方案。不要把密碼明文存儲在 SD 卡上。

4. 組件暴露 (Activity, Service, Broadcast Receiver, Content Provider)

漏洞：

• 組件在被調用時未做驗證。

• 在調用其他組件時未做驗證。

利用：

• 調用暴露的組件，達到某種效果，獲取某些信息，構造某些數據。（比如：調用暴露的組件發簡訊、微博等）。
• 監聽暴露組件，讀取數據。

建議：驗證輸入信息、驗證組件調用等。android:exported 設置為 false。使用 android:protectionLevel="signature" 驗證調用來源。

5. WebView

漏洞：

• 惡意 App 可以注入 JavaScript 代碼進入 WebView 中的網頁，網頁未作驗證。

• 惡意網頁可以執行 JavaScript 反過來調用 App 中註冊過的方法，或者使用資源。

利用：

• 惡意程序嵌入 Web App，然後竊取用戶信息。
• 惡意網頁遠程調用 App 代碼。更有甚者，通過 Java Reflection 調用 Runtime 執行任意代碼。

建議：不使用 WebView 中的 setJavaScriptEnabled(true)，或者使用時對輸入進行驗證。

6. 其他漏洞

• ROOT 後的手機可以修改 App 的內購，或者安裝外掛 App 等。
• Logcat 泄露用戶敏感信息。
• 惡意的廣告包。
• 利用 next Intent。

7. 總結

Android 應用的漏洞大部分都是因為開發人員沒有對輸入信息做驗證造成的，另外因為 Intent 這種特殊的機制，需要過濾外部的各種惡意行為。再加上 Android 應用市場混亂，開發人員水平參差不齊。所以現在 Android 應用的漏洞，惡意軟體，釣魚等還在不斷增多。再加上 root 對於 App 沙箱的破壞，Android 升級的限制。國內的 Android 環境一片混亂，慘不忍睹。所以，如果想要保證你的應用沒有安全漏洞，就要記住：永遠不要相信外面的世界。

// TODO: 1. 補充相關文章、材料等; 2. 添加截圖; 3. 列舉實際例子.

---

你說的…不就是root么！沒有比這個更常見常用的了

沒錯目前基本所有的手機端root工具都是用了些奇怪的提權漏洞(SUPER SU的刷包不算

要不然咋可能從低許可權訪問高許可權呢，明顯違反了許可權的繼承與分配規定

最開始大概是CVE-2009-2692這個漏洞吧，到前幾天的臟牛，都是Linux提權漏洞

還有些就是安卓設計的時候有些默認的高許可權程序自己有漏洞…比如棧溢導致的任意執行

再或者就是手機固件的漏洞咯～比如三星系列的cpu漏洞

---

有很多，需檢測的項目就有100多項，包含一些靜態漏洞、一些動態過程中如註冊過程、驗證過程、使用交互過程中產生的漏洞等。

從專業的APP應用安全服務商-海雲安 的檢測結果中，可以看出：

漏洞的存在也是有積極意義的，通過漏洞可以讓開發團隊更好的反查自身，有針對性的查漏補缺，提升自身的安全開發意識，及安全開發能力！

前提是，能及時發現這些安全漏洞。

---

比較常見的App漏洞基本都包括在這個表內，想知道自身app是否有相關漏洞問題，可以在騰訊御安全平台自行檢測查看的。

---

可以用一些方法去檢測APP的安全漏洞，比如：

靜態分析：
利用apktool、dex2jar、jd-gui、smali2dex等靜態分析工具對應用進行反編譯，並對反編譯後的java文件、xml文件等文件靜態掃描分析，通過關鍵詞搜索等靜態方式將具有安全隱患的代碼進行摘錄並存入到檢測平台後台，為後續的安全檢測報告提供數據依據。

動態分析：對應用軟體安裝、運行過程的行為監測和分析。檢測的方式包括沙箱模型和虛擬機方式。虛擬機方式通過建立與Android手機終端軟體運行環境幾乎一樣的虛擬執行環境，手機應用軟體在其中獨立運行，從外界觀察應用程序的執行過程和動態，進而記錄應用程序可能表現出來的惡意行為。

人工檢測：
專業安全人員對待檢測應用，對其進行安裝、運行和試用，通過在試用過程中，逐步掌握應用的特點，並通過專業經驗，來圈定檢測重點。人工專業檢測在涵蓋基礎檢測和深度檢測的全部檢測項的同時，兼顧側重點檢測，給予應用更全面、更專業、更貼合應用的量身打造的檢測服務。

更多：http://www.ineice.com

---

不得不說，安全一直是移動開發領域需要高關注度的問題！

除了其他乎友說的情況外，APICloud回答下基於HTML5開發的跨平台應用，背後可能隱藏的代碼盜取問題。

　　根據 Gartner 的預測，75% 的移動 app 甚至沒有通過基本的安全測試

　　從前幾年蘋果與FBI之間的激烈衝突也再次強調了保護用戶隱私的重要意義，這方面蘋果公司、包括IOS系統做的確實不錯，蘋果公司亦在WWDC大會上宣稱其將在硬體層面確保設備擁有完整的安全防護機制。

　　而目前很多使用的代碼保護解決方案中，對於網頁代碼保護的方式是治標不治本的，無法從根本上去實現真正的代碼加密，從現象說起——

　　1、JS、CSS代碼壓縮

　　通過互聯網上提供的CSS、JS壓縮工具，只起到了減少文件體積、提高載入速度，能夠提升程序的執行性能，但是根本做不到加密，開發者完全可以利用很多方式進行還原。

　　2、混淆HTML、JavaScript、CSS代碼實現保護

　　這是最通常使用的方法，有很多代碼混淆工具，如Packer、Javascript Compressor、JSObfuscator等，幫助開發者保護代碼，然而代碼混淆後會降低程序的執行性能。同時也不乏一些代碼格式化工具的存在，如JSBeauty、VS的Javascript編輯器等，用工具將混淆的代碼重新格式化後，代碼全部恢復為明文，無法做到代碼版權保護。

　　3、僅對HTML文件加密，而對JavaScript和CSS文件不加密

　　僅對App中的HTML文件進行加解密處理是比較容易實現的，HTML文件可以經過加密後保存在App安裝包中，而應用引擎在將HTML文件交給瀏覽器引擎解析之前可以先對加密的HTML文件進行解密，然後再將解密好的HTML文件交給瀏覽器解釋執行，而在整個瀏覽器執行過程中，對JavaScript和CSS文件的解密處理時機還是比較難控制的。但是在一個實際App項目中，大量的功能實現都是放在JavaScript文件中的，所以，這種局部加密的方式還是存在較大的局限性。

　　4、原生應用的代碼加固和加密廠商

　　由於Android應用使用Java語言開發，Java語言存在可以反編譯源碼的問題，所以行業中針對apk出現了加固、加殼產業，很多廠商可以提供加固服務，比如360、梆梆安全等加固產品。然而應用加固通常只能對原生代碼進行加密加固保護，不能對HTML、JavaScript、CSS等網頁代碼進行加密保護。

　　無論應用如何進行加密，都很難保證絕對的安全，而針對這一問題，建議至少應該從三點考慮。

　　第一，代碼安全，因為目前基本上大部分的移動應用都基於H5開發;

　　第二，數據安全，保護應用所有數據的穩定性;

　　第三，功能安全，針對API的調用和控制，包括大企業API調用的限制。

　　而對於移動安全問題，蘋果也通過了禁止JSPatch熱修復框架，其原理是通過JS腳本調用和替換任意OC方案，達到bug修復的目的。也許是為了提升安全和可控性問題，採用JSPatch熱修復框架後，這種安全和可控性正在被挑戰。

　　通過代碼加密功能可以從HTML源頭開始，APICloud則配備了基於RC4加密演算法提出了一套「全包」對稱加密解決方案，可以在雲編譯的時候對安裝包中的HTML、CSS、JS代碼進行加密處理，從HTML5移動應用開發的源頭開始，很大程度的保護源代碼的知識產權。

　　1、一鍵加密，運行時解密：開發者只需要在APICloud上編譯時選擇代碼加密，雲服務器在編譯App安裝包時就會將該App的HTML、JavaScript、CSS代碼自動加密，同時該App在運行過程中實時解密，App退出即焚，不留下解密痕迹;

　　2、零修改，零影響：APICloud的加密方式不改變代碼量大小，不影響運行效率，針對代碼的加密方案不會修改開發者的任何代碼，加密後的代碼不會比加密前多出一個位元組，同時，端底層嵌入了特殊的處理方案，保證代碼加密前後，App的運行效率、使用體驗不受影響;

　　3、自動，智能，方便：開發者在APICloud平台開發App的過程中，無需針對代碼的保護做特殊的處理，按照正常的開發流程進行即可;

　　4、安全盒子：在保護開發者代碼的同時，針對App的各種潛在安全問題，APICloud定義了一個「安全盒子」，僅對盒子內代碼進行加解密保護，盒子外代碼靈活處理;

　　5、重新定義資源標準：APICloud底層在處理被保護代碼時，重新分配了App資源的使用方式，統一資源管理，實現加速資源載入，節省系統開銷，因此，加密代碼後的App在運行過程中甚至能提速運行;

　　加密前

　　加密後

隨著行業技術與應用模塊的不斷發展，應對加密或混淆的解決方案，肯定會在不斷發展中迭代。

---

有一個數字簽名的漏洞，可以對經過簽名的apk包中加入惡意代碼，甚至可以替換系統軟體。以下是鏈接

http://safe.baidu.com/2013-10/android-masterkey-9695860.html

---

推薦閱讀：