安卓應用程式滲透測試（十一）
移動平臺提供了很多服務，從身份驗證到安全資料儲存再到安全網路通訊。但是，如果平臺的某些功能使用不當，可能會導致資料洩露，允許不信任主機連線等問題。本文我們總結了一些安卓的checklist。
M1–平臺使用不當
移動平臺(iOS，Android，Windows phone)為我們提供了文件結構良好且通俗易懂的特性和功能，而這類風險的特徵就是app沒有使用這種功能或者使用不當。
另請閱讀： ofollow,noindex">完整的移動應用滲透測試指南
導致這種風險的行為有如下幾種：
違反釋出的指南
所有平臺都會開發安全指南。如果某個app不遵守安全指南，違反開發者提供的最佳做法，就會存在該風險。
違反條款或慣例
開發者編寫的指南並不會包含所有的最佳做法，在某些情況下，有些最佳做法是移動app中約定俗成的。
無意的使用不當
一些app想要正確執行某些操作，但實際操作起來卻發生了某些錯誤。這可能只是一個小錯誤，比如在API呼叫上設定錯誤的標誌，或者對保護措施的理解有誤。
這類錯誤包括錯誤使用平臺功能或沒有使用平臺安全控制元件。這可能包括Android intents，平臺許可權，錯誤使用Touch ID或其他的一些安全控制元件，這些都是移動作業系統的一部分。
移動app的隱私和許可權也是平臺的一部分。因此，如果沒有使用平臺的功能，會導致洩露終端使用者隱私的風險。
下表是一些檢查項和對應的描述：
M2–不安全的資料儲存
不安全的資料儲存和意外的資料洩露
不安全的資料儲存漏洞，當開發團隊認為使用者或惡意軟體無法訪問裝置上的檔案系統及其檔案儲存中的敏感資訊時，就會發生該漏洞。檔案系統其實是很容易訪問的，所以開發團隊不能想當然的認為他們無法訪問，而應該假設惡意使用者和惡意軟體是能夠檢視敏感資料的。
對裝置進行root或越獄可以繞過任何的密碼保護。如果資料沒有得到正確的保護，那麼只要一些特殊的工具就可以檢視app的資料。當開發者無意中將敏感資訊儲存在裝置中某個位置，而該位置能夠輕易被其他app訪問時就會導致無意的資料洩露漏洞。
首先，開發者編寫程式碼來處理使用者或終端提供的敏感資訊。在處理過程中，某個小問題(開發者沒有意識到的問題)可能會導致資訊儲存在裝置中某個不安全的位置，而裝置上的app能夠隨意訪問這個位置。
不安全的資料儲存位置包括—日誌檔案，plist檔案，SD卡，XML資料儲存，資料庫，二進位制資料儲存，雲同步，OS快取資料，圖片，按鍵，日誌記錄和緩衝區等。
下表是一些其他檢查項：
M3—不安全的通訊
移動應用程式通常不會保護網路流量。他們可能在身份驗證期間使用SSL/TLS，但在其他地方並不會使用。這會導致資料洩露和會話ID被攔截的風險。
使用傳輸層安全協議並不意味著所有app都正確部署實施了。要檢測基本的漏洞，還是要對手機流量進行仔細觀察。更細微的漏洞需要檢查應用程式的設計和配置。
可能會存在以下威脅
·與你共享網路的攻擊者(入侵或監聽你的WiFi)
·執行商或網路裝置(路由器，手機訊號塔，代理等)
要確定應用程式是否有足夠的傳輸層安全保護，可以通過代理來檢視應用程式的流量。首先要思考下面的幾個問題：
· 所有連線，不僅僅是傳送到你伺服器的連線，是否進行正確加密？
· SSL證書是最新的嗎？
· SSL證書是自簽名的嗎？
· SSL是否使用高強度的密碼？
· 你的應用是否會接受使用者接受的證書作為授權？
這包括了不安全的握手協議，不正確的SSL版本，弱協商和敏感資產的明文傳輸等。
還有下面這些檢查項
M4—不安全的身份驗證
身份驗證不完善或者缺失會導致攻擊者匿名執行移動應用程式或應用程式使用的後端伺服器中的功能。由於移動裝置採用表單輸入，而表單的身份驗證機制比較脆弱，但是卻非常普遍。
表單因素大力支援純4位數字的PIN短密碼。由於可用性的要求，移動應用的身份驗證要求與傳統的web身份驗證方案存在很大的不同之處。在移動應用中，使用者在會話期間不會總是線上，所以移動網際網路連線比傳統的web連線更不可靠，更不可預測。
因此，移動app在正常執行時有一個要求，就是進行離線身份驗證。這種離線身份驗證的要求對開發人員來說，在實施身份驗證過程中，他們要考慮的事情就會變得更多，更復雜。
要檢測這種不完善的身份驗證方案，測試員可以對處於離線模式的移動app執行二進位制攻擊。
通過攻擊，測試員可以迫使app繞過離線身份驗證並且執行需要離線身份驗證才能執行的功能。同樣，測試員可以嘗試是否能夠匿名執行任意後端伺服器功能，通過刪除向移動app功能發出的任何POST/GET請求中的會話token來實現。
在本地進行使用者身份驗證，可能會導致客戶端繞過漏洞。如果應用程式在本地儲存資料，那麼攻擊者可以在越獄裝置上，通過在執行時操作和修改二進位制來繞過身份驗證。
如果可能的話，確保所有的身份驗證請求都是在伺服器端完成的。只有身份驗證成功後，應用程式資料才會載入到移動裝置上。這就保證了應用程式資料只有在認證成功後才可用。
如果需要在客戶端儲存資料，那就需要使用加密金鑰對資料進行加密，而這個加密金鑰是根據使用者輸入的登陸憑證生成的。這也確保了只有在輸入了正確的憑證之後才能訪問儲存在應用程式中的資料。
還有一些其他的風險，比如通過二進位制攻擊來破解加密的資料。
移動app中的持久身份驗證功能(即記住我功能)千萬不要在裝置上儲存使用者的密碼。
理想情況下，應用程式應該使用裝置特定的身份驗證令牌，使用者可以在app中撤銷該令牌。這樣在裝置被盜或丟失的情況下，通過app撤銷令牌，可以降低未授權訪問的風險。
切勿使用任何容易被篡改的值來驗證使用者身份。包括裝置識別符號或地理位置。還有移動app中的持久身份驗證應該作為一個選項來讓使用者選擇，不能預設啟用。
不正確的會話處理通常跟不完善的身份驗證所導致的結果一樣。一旦認證成功並且得到了一個session，這個session就允許你訪問移動app。移動app程式碼必須非常妥善的保護使用者的會話，就像身份驗證機制一樣。
以下是身份驗證不當的例子
·後端沒有及時終止會話
· 缺乏足夠的超時保護
· 沒有正確重置cookies
· 不安全的token生成
這類漏洞針對的是終端使用者身份驗證和錯誤會話管理。這包括：
· 在需用進行使用者識別時根本無法識別使用者
· 在需要維持使用者身份時無法維持
· 會話管理存在漏洞
其他潛在的風險如下表：
M5—不安全的加密技術
在大多數利用加密技術的移動app中，使用不安全的加密技術是非常普遍的。在移動app中，破解密碼有兩種基本方式。第一種是利用加密/解密技術中的一個程序，該程序存在嚴重漏洞，攻擊者可以利用這個漏洞來解密敏感資料。第二種，移動app可能使用的是脆弱的加密/解密演算法，所以攻擊者可以直接利用這種演算法的漏洞進行破解。下面的內容將更加深入的探討這兩種方法。
1.依賴內建程式碼加密過程
使用像ClutchMod或者GBD這樣的免費工具，攻擊者可以將這個加密app下載到他們越獄的裝置中，並且在IOS載入程式將它載入到記憶體並解密後(在載入程式開始執行之前)，對解密的app拍攝快照。
一旦攻擊者拍攝了快照並存儲在磁碟中，攻擊者就可以使用IDA pro或Hopper工具對app進行靜態/動態分析，然後執行進一步的二進位制攻擊。
2.糟糕的金鑰管理流程
很多人確實使用了正確的演算法，但還是犯了錯誤，使用他們自己的協議來部署。其中的一些問題包括：
· 將金鑰放在與加密內容相同的資料夾中，而且攻擊者可讀
· 生成的金鑰攻擊者通過某種方式可以獲得
· 在二進位制中使用硬編碼金鑰
可以通過二進位制攻擊攔截金鑰。關於如何防禦二進位制攻擊的更多資訊，請檢視M10。
3.建立和使用自定義加密協議
始終使用安全社群認可的現代加密演算法並儘可能在你的移動平臺中使用最先進的加密API。
二進位制攻擊讓攻擊者能夠識別你使用的公共庫以及二進位制檔案中的任何硬編碼金鑰。如果對加密的安全性要求非常高，強烈建議你使用白盒加密技術。
4.使用不安全或過時的演算法
很多加密演算法和協議都應該停止使用，因為已經證明它們存在嚴重的漏洞，而且已經無法滿足現代安全的要求。這些演算法包括 RC2，MD4，MD5，SHA1。
下表是一些檢查項和對應的描述：
