App安全測試
在App項目中都會碰到三座App安全大山。App客戶端安全、數據傳輸安全、App服務端安全。下面以分析檢測的思路進行對App安全威脅的這三座大山進行一些剖析梳理總結。
工具介紹
靜態分析工具 : Apktool、dex2jar、jadx-gui、JEB、Androidkiller、GDA。
動態分析工具 : DDMS、gdb、IDA、Drozer。
抓包分析工具 : Fiddler、Wireshark、charles。
掛鉤框架 : frida、xposed。
其他工具 : JDK、AndroidSDK、AndroidResEdit、uiautomatorviewer、010 editor、jarsigner。
App客戶端安全測試
運行環境檢測
1.反編譯App代碼，查看App中是否存在檢測root的關鍵代碼。
2.運行App程序，觀察確認是否能夠正常運行并有對應提示用戶信息。
通過上圖靜態分析App的java實現代碼，可以很清晰的看到代碼中有實現對root檢測，通過檢測可以改root的關鍵App包和檢測root后的特有關鍵路徑方式進行判斷環境信息。
反編譯檢測
1.可以利用apktool、de2jar、jadx-gui工具，進行反編譯查看分析代碼。
2.直接利用可視化工具AndroidKiller、GDA、JEB工具進行反編譯分析代碼。
下面以apktool反編譯方式進行對反編譯dex分析。
（對于App中so文件，可以直接用IDA工具進行靜態反編譯分析arm匯編代碼）
App實際上是一個zip壓縮包格式，可以直接將后綴修改成zip后綴，進行解壓就可以獲取到App的包數據。
通過利用dex2jar命令行將dex文件轉換為jar（java代碼）文件。
命令格式:dex2jar.bat 要轉換的dex文件路徑
通過jadx-gui工具，進行查看分析jar文件的java代碼。
經過這個App反編譯dex流程分析:上圖的App雖然可以通過反編譯工具進行反編譯，但是該App采用了360加固保護，dex文件里面的數據都是360加固的數據，真正的dex數據都被隱藏和抽取了。所以該App的反編譯這項是相對安全的。
客戶端完整性檢測
在App中的每個文件都會做一次算法記錄，并保存在MANIFEST.MF文件中，我們就可以通過基于MANIFEST.MF文件的安全機制對App包進行完整性校驗檢測。完整性校驗可以在啟動App時候觸發，如果App被二次打包修改了，那么MANIFEST.MF文件中的校驗信息是不一樣的。
1.通過利用AndroidKiller工具對App進行反編譯，修改，二次打包并簽名。
2.通過apktool進行反編譯、修改、打包，再通過SignApk工具進行對App重新簽名。
下面以androidkiller工具進行App替換圖片的完整性檢測分析。
將App直接拖入androidkiller工具里面，在工具的工程管理界面下res是App所有資源圖片所存放的位置。只要右擊res文件夾進行打開文件路徑，就可以跳轉到App反編譯后的資源文件夾。
可以通過提取其他App的資源圖片進行替換，替換完圖片后將App重新編譯并簽名。
通過分析:如果App沒有完整性校驗的功能，那么App就可以通過反編譯修改，二次打包簽名并能正常運行。如果App有完整性校驗功能，那么App二次打包后，是不能正常運行的。
安全App的做法是：在每次啟動App的時候，進行對自身App完整性校驗，并且在驗證App邏輯中，不要單純的只使用MANIFEST.MF文件中的數據為驗證條件，最好同時驗證是否有不屬于App的文件，這個過程可以和服務端進行結合完成。
組件安全檢測
Android四大組件簡介
Activity：呈現可供用戶交互的界面，是最常見的組件；
Service：長時間執行后臺作業，常見于監控類應用；
Content Provider：在多個APP間共享數據，比如通訊錄；
Broadcast Receiver：注冊特定事件，并在其發生時被激活。
Android的四大基本組件，都需要注冊才能使用。每個Activity、service、Content Provider都需要在AndroidManifest文件中進行配置。AndroidManifest文件中未進行聲明的activity、service以及Content Provider將不為系統所見，因此這些組件就不可用。而broadcast receiver廣播接收者的注冊分靜態注冊（在AndroidManifest文件中進行配置）和通過代碼動態創建并以調用Context.registerReceiver()的方式注冊至系統。需要注意的是在AndroidManifest文件中進行配置的廣播接收者會隨系統的啟動而一直處于活躍狀態，只要接收到感興趣的廣播就會觸發(即使程序未運行)。
對于android的組件安全性的問題，主要在于關注組件是否被外部App應用給調用。
1.通過分析App中的AndroidManifest.xml文件，判斷組件屬性是否設置為導出狀態。設置導出狀態外部的App就可以直接調用。
2.通過利用drozer工具進行分析驗證組件是否存在安全性問題。
下面以AndroidManifest.xml文件的android:exported屬性進行判斷組件安全性。
從上圖中可以看到activity組件android:exported設置為true，并且有intent-filter屬性，這個activity表示就可以直接被外部App應用調用。
檢測分析得出結論：android的組件如果設置為導出狀態，那么組件就有被直接調用或被劫持的風險。建議如果組件非必要導出情況下，將組件設置為不導出狀態，如果組件必須提供給外部應用進行調用的話，建議對組件進行權限控制。
調試信息檢測
檢測App應用程序（保護服務端應用）調試信息是否關閉，調試信息中是否寫入敏感信息。
通過運行App程序，查看logcat等調試日志信息方式，分析是否有泄漏重要的URL地址、提示信息、調試信息等敏感關鍵字以及程序邏輯的關鍵流程信息。
通過利用DDMS工具進行查看App運行過程中是否有調試日志信息。
通過DDMS中LogCat窗口，進行右擊打開過濾窗口，可以選擇針對只顯示指定進程或Pid的數據，這樣就可以進行精準查看分析App中是否有敏感日志信息輸出。
鍵盤輸入安全性檢測
在App應用中，默認情況下使用系統自帶的軟鍵盤，在App安裝后，如果直接使用系統自帶鍵盤，會有被記錄、劫持的風險。我們可以通過在App應用輸入信息的時候，觀察是否會彈出自定義的軟鍵盤。安全的做法通過實現自定義的軟鍵盤并且鍵盤碼會進行變動。
以下對鍵盤應用進行做定義分析
1、APP輸入調用安卓系統鍵盤
一般認為高風險，可能被劫持利用。
2、APP調用應用中自帶鍵盤輸入
一般認為中風險，可能被其他APP以觸摸點絕對定位方式劫持。
3、APP調用應用中自帶鍵盤并隨機打亂鍵盤順序 （這種設置一般銀行APP比較多 有 打亂數字和鍵盤按鍵的 還有在這個界面下禁止截圖的）
一般認為低風險，就算被劫持，利用可能性也很低。
本地數據安全檢測
App本地數據安全性問題需要關注的問題分別為:App所在目錄的文件權限、SQLite數據庫文件的安全性、敏感數據明文直接存儲Sdcard。
對于App所在目錄的文件權限問題，通過驗證App所在目錄的文件權限是否進行設置，如果是非root用戶是否可以進行讀寫執行App目錄下的文件。安全的情況下App所在的目錄，其他用戶必須無法進行讀寫操作。
對于SQLite數據庫文件問題，SQLite是一個輕型的數據庫文件，它是很多App都是使用的一種數據存儲方式，其中微信就是利用SQLite文件方式進行存儲數據。可以通過SQLiteSpy和其他第三方工具，進行打開查看SQLite文件的數據。主要需要關注下db文件是否直接存儲敏感信息，是否對db文件有做加密處理。
對于敏感數據是否存儲在Sdcard上，可以通過運行App應用，然后進行查看是否有在“sdcard/Android/data/包名/” 目錄下，釋放一些敏感文件或敏感的數據。
安全做法是對于釋放在sdcard目錄上的數據和文件都應該做加密處理。
數據傳輸安全
App中的通信數據傳輸主要可以借助第三方抓包工具，采取代理方式進行對HTTP、HTTPS數據包抓取和分析。驗證App的通訊方式是否采用HTTPS加密信道，通過抓取App數據包確認是否進行加密以及是否進行證書校驗。安全的做法是通過代理抓App數據是抓取不到，或者檢測有用戶抓取App數據時候進行強制退出。
下面以charles工具設置代理方式進行抓包。
電腦主機上設置要代理端口。
手機環境下設置電腦主機的IP地址和charles電腦端設置的相同端口。
這樣就可以進行對手機環境下的App應用進行數據抓包分析了（具體包分析過程，具體需求具體分析）。
App服務器安全
App服務端安全需要關注的是服務端API安全、業務邏輯安全、中間件安全、服務器應用安全。主要可以通過滲透測試的方式對App的服務器進行安全檢測，通過模擬惡意攻擊方式進行對服務器攻擊。從而提高App服務器的安全性。
