1、Android安全問題產生的根源
【51CTO專稿】研究人員已發現Android上的流行軟件廣泛存在安全陷阱與安全漏洞，漏洞頻發的緣由可能有不少，主要有以下幾種：
- 與一切都是集中管理的IOS相比，Android提供了一種開放的環境，在得到了靈活性、能夠知足各類定製需求的同時，也損失了部分安全性。
- 開發團隊一般將精力集中在產品設計、功能實現、用戶體驗和系統等方面，而不多考慮安全問題
- Android提供的安全機制比較複雜，開發者須要理解它們，並對相應的***思路和***方法有所瞭解，纔能有效地保護軟件。
- 一方面，目前不多出現對特定移動軟件安全漏洞的大規模針對性***，在真實的***出現以前，許多人對此並不重視，另外一方面，利用這些漏洞展開***並不太難，許多***方法和工具都已經成熟，一旦出現這種***，用戶的我的隱私數據可能發生泄漏，帳戶信息可能被收集，若是與釣魚等***結合，甚至可能產生經濟損失。產品開始團隊則可能由此面臨信任危機和法律風險。
下面簡單的例舉幾個不注重安全的現象，這些也是咱們Android開發團隊容易忽略的地方。
2、數據存儲安全問題
Android軟件可使用的存儲區域分外部（SD卡）和內部（NAND閃存）二種，除了大小和位置不一樣以外，二者在安全權限上也有很大的區別。外部存儲的文件沒有讀寫權限的管理，全部應用軟件均可以隨意建立、讀取、修改、刪除位於外部存儲中的任何文件，而Android的應用則只須要申明READ_EXTERNAL_STORAGE和WRITE_EXTERNAL_STORAGE權限。
內部存儲則爲每一個軟件分配了私有區域，並有基本Linux的文件權限控制，其中每一個文件的全部者ID均爲該軟件設立的一個用戶ID，其餘軟件無權讀寫這些文件。
關於數據存儲可能出現的問題包括以下幾點：
將隱私數據明文保存在外部存儲
例如，聊天軟件或社交軟件將聊天記錄、好友信息、社交信息等存儲在SD卡上；備份軟件將通訊錄、短信等備份到SD卡上等，若是這些數據是直接明文保存（包括文本格式、XML格式、SQLite數據庫格式等）的，那麼***者寫的軟件能夠將其讀取出來，並加傳到指定的服務器，形成隱私信息泄露。較好的作法是對這些數據進行加密，密碼保存在內部存儲，由系統託管或者由用戶使用時輸入。
將系統數據明文保存在外部存儲
例如，備份軟件和系統輔助將用戶數據備份到安裝的其餘的SD卡，以便刷機或升級後進行恢復等；或者將一些系統數據緩存在SD卡上供後續使用，一樣的，這些數據是明文保存的，惡意軟件能夠讀取它們，有可能用於展開進一步的***。
將軟件運行時依賴的數據保存在外部存儲
若是軟件將配置文件存儲在SD卡上，而後在運行期間讀取這些配置文件，並其中的數據決定如何工做，也可能產生問題。***者編寫的軟件能夠修改這些配置文件，從而控制這些軟件的運行。例如將登陸使用的服務器列表存儲在SD卡中，修改後，登陸鏈接就會被髮往***者指定的服務器，可能致使帳戶泄露或會話劫持(中間人***)。
對這種配置文件，較安全的方法是保存到內部存儲；若是必須存儲到SD卡，則應該在每次使用前檢驗它是否被篡改，與預先保存在內部的文件哈希值進行比較。
將軟件安裝包或者二進制代碼保存在外部存儲
如今不少軟件都推薦用戶下載並安裝其餘軟件；用戶點擊後，會聯網下載另外一個軟件的APK文件，保存到SD卡而後安裝。
也有一些軟件爲了實現功能擴展，選擇動態加載並執行二進制代碼。例如，下載包含了擴展功能的DEX文件或JRA文件，保存到SD卡，而後在軟件運行時，使用dalvik.system.DexClassLoader類或者java.lang.ClassLoader類加載這些文件，再經過Java反射，執行其中的代碼。
若是安裝或者加載前，軟件沒有對SD卡 的文件進行完整性驗證，判斷其是否可能被篡改和僞造，就可能出現安全問題。
在這裏，***者可使用稱爲「重打包」（re-packaging）的方法，目前大量Android惡意代碼已經採用這一技術，重打包的基本原理是，將APK文件反彙編，獲得 Dalivik指令的smali語法表示 ；而後在其中添加、修改、刪除等一些指令序列，並適當改動Manifest文件；最後，將這些指令從新彙編並打包成新的APK文件，再次簽名，就能夠給其餘手機安裝了，經過重打包，***者能夠加入惡意代碼、改變數據或指令，而軟件原有功能和界面基本不會受到影響，用戶難以察覺。
若是***者對軟件要安裝的APK文件或要加載DEX、JAR文件重打包，植入惡意代碼，或修改其代碼；而後在SD卡上，用其替換原來的文件，或者拷貝到要執行或加載 的路徑，當軟件沒有驗證這些文件的有效性時，就會運行***者的代碼***。結果有不少可能，例如直接發送扣費短信，或者將用戶輸入的帳戶密碼發送給指定的服務器，或者彈出釣魚界面等。
所以，軟件應該在安裝或加載位於SD卡的任何文件以前，對其完整性作驗證，判斷其與實現保存在內部存儲中的（或從服務器下載來的）哈希值是否一致。
全局可讀寫的內部文件
若是開發者使用openFileOutPut(String name,int mode)方法建立內部文件時，將第二個參數設置爲Context.MODE_WORLD_READABLE或者Context.MODE_WORLD_WRITEABLE，就會讓這個文件變爲全局可讀或全局可寫的。
開發者這樣作是爲了實現不一樣軟件之間的數據共享，但這種問題在於沒法控制哪一個軟件能夠讀寫，因此***者的惡意軟件也擁有這一權限。
若是要跨應用有種較好的方法是實現一個Content Provider 組件，提供數據的讀寫接口併爲讀寫操做分別設置一個自定義的權限。
內部敏感文件被root權限軟件讀寫
若是***者的軟件已得到root權限，天然能夠隨意讀寫其餘軟件的內部文件，這種狀況 並很多見。
1)大量的第三方定製ROM提供了root 權限管理工具，若是***者構造的軟件僞形成一些功能強大的工具。能夠欺騙用戶授予它root權限。
2)即使手機預裝的官方系統，國內用戶也大多樂於解鎖，即recovery並刷入toot管理工具。
3)在Android2.2和2.3中，存在一些可用於獲取root權限的漏洞，而且對這種漏洞的利用不須要用戶的確認。
4)所以，咱們並不能假設其餘軟件沒法獲取root權限。即便是存在內部數據，依然有被讀取或修改的可能。
5)前面提到，重要、敏感、隱私的數據應使用內部存儲，如今又遇到root後這些數據依然可能被讀取的問題。我對這個問題的觀點是，若是***者鋌而走險獲取root權限（被用戶或者被安全軟件發現的風險），那理論上他已經擁有了系統的完整控制權，能夠直接得到聯繫人信息、短信記錄等，甚至帳戶密碼、會話憑證、帳戶數據等。例如，早期Google錢包將用戶的信用卡數據明文存儲，***者獲取這些數據後，能夠假裝成持卡人進行進一步***以得到帳戶使用權。這種數據就是「其餘軟件管理的重要數據」。
6)這個問題並無通用的解決方法，開發者可能須要根據實際狀況尋找方案，並在可用性與安全性以前作出恰當的選擇。
