Android權限機制帶來的一些安全問題介紹

Android引入了權限機制最初的出發點是為了通過權限策略來嚴格控制和處理安全問題，可參見：下面兩篇文章，但關於這個Android權限的機制仍然存在一些很小但不容忽略的問題，另外正所謂道高一尺魔高一丈，仍然存在一些可以繞過權限的方法。本文旨在分析權限機制的一些缺點和不足，並不能以此文章作為非法應用的參考書。
Android Permission權限機制引子

Android Permission權限機制的具體使用

權限機制的缺陷和不足

(1) 應用程序可以自由地命名一個新的權限，無須遵循一定的命名規則和限制，期盼用戶對不同應用程序(包括未曾安裝過的程序)所使用的任意給定的權限名稱保持警覺是不夠明智的。
這句說的比較費勁，其實就是android對一個新的應用程序(Custom Permission App)聲明權限時，並未規定權限的名稱的命名規則和限制，無規則不成方圓，這不規則的名稱多少會引起一些問題的。

(2) 權限一經被授權給應用程序後，在應用程序的生命期間，它將不會被移除，即使聲明此權限的源程序被刪除。
一個聲明權限的應用程序(Custom Permission App)被刪除之後，並沒有一些機制去通知哪些使用該權限的應用(Custom Permission Client)，而是在使用該權限的應用(Custom Permission Client)運行到指定位置時需要使用權限是才報錯。

(3) 一個系統內兩個不同的權限可以聲明相同的名字。

(4)權限不足時，Log會報，比如：

復制代碼 代碼如下:
03-01 15:02:31.488: E/AndroidRuntime(565): java.lang.SecurityException: Permission Denial: starting Intent { cmp=com.example.custompermission/.MainActivity } from ProcessRecord{44ffc5e0 565:com.example.customtest/10043} (pid=565, uid=10043) requires custom.permission.STARTACTIVITY
03-01 15:02:31.488: E/AndroidRuntime(565): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)

所以別有用心的開發者會想通過這個途徑去增加一定的權限(其他App聲明的權限)，然後去call這個聲明權限的App。

樹立權限意識

劈開上面的缺陷不談，我們仍然應該需要重視一款應用的權限，畢竟谷歌在Android權限方面已經做了很大的努力。

(1)用戶初判斷

用戶可以通過下載的軟件來判斷權限是否過分，比如一款輸入法就不應有發送短信的權限，一些記單詞的程序就不應該有發送短信，查看聯系人和短消息的權限。用戶需要在安裝應用程序前，需要有意識的注意每一個app的權限請求，Android會把一些high risk權限明顯列出來而忽略一些比較low risk的權限，所以用戶可以只看這些列出來的權限，並做到能去甄別它。

(2)第三方軟件/ROM

可以通過第三方軟件來限制權限，比如App Shield，這是是一個需要付費的Android應用，其原理是修改應用程序的apk安裝包，刪除其中AndroidManifest.xml文件內，用於聲明權限的對應”Android.Permission.*”條目，然後再用一個公開的證書對安裝包重新簽名(需要允許”未知源”)，這樣一來，應用程序就不會向系統申請原先所需的權限。當應用運行至相應的流程時，系統將直接拒絕，從而達到用戶控制權限的目的。對於已安裝的應用，AppShield也會按照同樣方法制作好apk安裝包，然後讓用戶先卸載原始的應用，再安裝調整過的應用。除了該應用數字簽名外，用戶可以隨時通過執行同樣的流程，將吊銷的權限恢復。當然第三方ROM也可以做到，比如MIUI在軟件用到某一個權限時就會主動攔截並詢問用戶是否授予權限。

越過權限機制

可是–目前仍有幾種方式可以越過權限機制，從而擁有不需申請權限的方式下使用需要申請權限的權限。

(1) root過的設備靜默安裝

如果你的手機已經被root過了，那麼某些App就可以靜默安裝在你的手機裡。
靜默安裝是指App在安裝時不會有安裝界面提示用戶該App的權限等，而是直接將其安裝在你的手機中，這樣用戶就會失去了最起碼的通過權限去鑒別的機會；這其實不算越過權限機制，但是這些被靜默安裝的程序，不會展示權限就相當於沒有任何權限了。

(2) 使用相同sharedUserId的應用程序

首先簡單介紹下：sharedUserId
默認Android會給每個APK都分配一個單獨的用戶空間，即每個應用程序都有個UID，只有帶著此UID，才能存取該UID所涵蓋的有關資料。
所以如果AP-1與AP-2的UID不同，則在預設(Default)情況下，雙方都無法讀取對方的數據。這種分而治之的方式，可以減輕黑客軟件的惡意傷害數據，提升手機的安全性。
但是如果兩個應用程序都被簽上了相同的UID即使用sharedUserId關鍵字。這個例子需要使用兩個程序來配合使用，這兩個程序在AndroidManifest.xml文件中都會聲明一個相同的sharedUserId，比如下面：

再回到AP-1和AP-2上來，假設AP-1是一個看上去比較正規的程序，只有read contacts的權限，由於比較正規的外表，用戶可能信任並安裝了，後來用戶一段時間後安裝了AP-2，這個AP-2只有連接Internet的權限，但卻可以輕松的將AP-1存儲到數據庫裡面的聯系人信息輕松到上傳到Internet上了。

(3) 破解接受廣播接收器(receiver)的程序

這個是用的比較多的一種方式，同樣需要2個或者多個應用程序來配合。比如病毒開發者會分析到目前市面上比較流行的一些短信應用，並通過一定的技術反編譯代碼、JAVA反射等技術，總之能找到一個能讓正常應用發送短信的receiver，然後通過自己的病毒應用去發送廣播，以達到移花接木之目的。