第三章 Android 應(yīng)用的逆向和審計
作者：Aditya Gupta
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
在本章中，我們將查看 Android 應(yīng)用程序或.apk文件，并了解其不同的組件。 我們還將使用工具（如 Apktool，dex2jar 和 jd-gui）來逆向應(yīng)用程序。 我們將進一步學(xué)習(xí)如何通過逆向和分析源代碼來尋找 Android 應(yīng)用程序中的各種漏洞。 我們還將使用一些靜態(tài)分析工具和腳本來查找漏洞并利用它們。
3.1 Android 應(yīng)用程序拆解
Android 應(yīng)用程序是在開發(fā)應(yīng)用程序時創(chuàng)建的數(shù)據(jù)和資源文件的歸檔文件。 Android 應(yīng)用程序的擴展名是.apk，意思是應(yīng)用程序包，在大多數(shù)情況下包括以下文件和文件夾：
-
Classes.dex(文件) -
AndroidManifest.xml(文件) -
META-INF(文件夾) -
resources.arsc(文件) -
res(文件夾) -
assets(文件夾) -
lib(文件夾)
為了驗證這一點，我們可以使用任何歸檔管理器應(yīng)用程序（如 7zip，WinRAR 或任何首選應(yīng)用程序）簡單地解壓縮應(yīng)用程序。 在 Linux 或 Mac 上，我們可以簡單地使用unzip命令來展示壓縮包的內(nèi)容，如下面的截圖所示：
這里，我們使用-l（list）標志，以便簡單地展示壓縮包的內(nèi)容，而不是解壓它。 我們還可以使用file命令來查看它是否是一個有效的壓縮包。
Android 應(yīng)用程序由各種組件組成，它們一起創(chuàng)建可工作的應(yīng)用程序。 這些組件是活動，服務(wù)，廣播接收器，內(nèi)容供應(yīng)器和共享首選項。 在繼續(xù)之前，讓我們快速瀏覽一下這些不同的組件：
- 活動（Activity）：這些是用戶可以與之交互的可視界面。這些可以包括按鈕，圖像，
TextView或任何其他可視組件。 - 服務(wù)（Service）：這些 Android 組件在后臺運行，并執(zhí)行開發(fā)人員指定的特定任務(wù)。這些任務(wù)可以包括從 HTTP 下載文件到在后臺播放音樂的任何內(nèi)容。
- 廣播接收器（Broadcast Receiver）：這些是 Android 應(yīng)用程序中的接收器，通過 Android 系統(tǒng)或設(shè)備中存在的其他應(yīng)用程序，監(jiān)聽傳入的廣播消息。一旦它們接收到廣播消息，就可以根據(jù)預(yù)定義的條件觸發(fā)特定動作。條件可以為收到 SMS，來電呼叫，電量改變等等。
- 共享首選項（Shared Preference）：應(yīng)用程序使用這些首選項，以便為應(yīng)用程序保存小型數(shù)據(jù)集。此數(shù)據(jù)存儲在名為
shared_prefs的文件夾中。這些小數(shù)據(jù)集可以包括名值對，例如游戲中的用戶得分和登錄憑證。不建議在共享首選項中存儲敏感信息，因為它們可能易受數(shù)據(jù)竊取和泄漏的影響。 - 意圖（Intent）：這些組件用于將兩個或多個不同的 Android 組件綁定在一起。意圖可以用于執(zhí)行各種任務(wù)，例如啟動動作，切換活動和啟動服務(wù)。
- 內(nèi)容供應(yīng)器（Content Provider）：這些組件用于訪問應(yīng)用程序使用的結(jié)構(gòu)化數(shù)據(jù)集。應(yīng)用程序可以使用內(nèi)容供應(yīng)器訪問和查詢自己的數(shù)據(jù)或存儲在手機中的數(shù)據(jù)。
現(xiàn)在我們知道了 Android 應(yīng)用程序內(nèi)部結(jié)構(gòu)，以及應(yīng)用程序的組成方式，我們可以繼續(xù)逆向 Android 應(yīng)用程序。 當(dāng)我們只有.apk文件時，這是獲得可讀的源代碼和其他數(shù)據(jù)源的方式。
3.2 逆向 Android 應(yīng)用
正如我們前面討論的，Android應(yīng)用程序只是一個數(shù)據(jù)和資源的歸檔文件。 即使這樣，我們不能簡單地解壓縮歸檔包（.apk）來獲得可讀的源代碼。 對于這些情況，我們必須依賴于將字節(jié)代碼（如在classes.dex中）轉(zhuǎn)換為可讀源代碼的工具。
將字節(jié)碼轉(zhuǎn)換為可讀文件的一種方法，是使用一個名為 dex2jar 的工具。 .dex文件是由 Java 字節(jié)碼轉(zhuǎn)換的 Dalvik 字節(jié)碼，使其對移動平臺優(yōu)化和高效。 這個免費的工具只是將 Android 應(yīng)用程序中存在的.dex文件轉(zhuǎn)換為相應(yīng)的.jar文件。 請遵循以下步驟：
從
https://code.google.com/p/dex2jar/下載 dex2jar 工具。現(xiàn)在我們可以使用它來運行我們的應(yīng)用程序的
.dex文件，并轉(zhuǎn)換為.jar格式。-
現(xiàn)在，我們需要做的是，轉(zhuǎn)到命令提示符并訪問 dex2jar 所在的文件夾。 接下來，我們需要運行
d2j-dex2jar.bat文件（在 Windows 上）或d2j-dex2jar.sh文件（在 Linux / Mac 上），并提供應(yīng)用程序名稱和路徑作為參數(shù)。 這里的參數(shù)中，我們可以簡單地使用.apk文件，或者我們甚至可以解壓縮.apk文件，然后傳遞classes.dex文件，如下面的截圖所示：正如我們在上面截圖中看到的，dex2jar 已經(jīng)成功地將應(yīng)用程序的
.dex文件轉(zhuǎn)換為名為helloworld-dex2jar.jar的.jar文件。 現(xiàn)在，我們可以在任何 Java 圖形查看器（如 JD-GUI）中打開此.jar文件，JD-GUI 可以從其官方網(wǎng)站http://jd.benow.ca/下載。 -
一旦我們下載并安裝 JD-GUI，我們現(xiàn)在可以繼續(xù)打開它。 它看起來像下面的截圖所示：
-
在這里，我們現(xiàn)在可以打開之前步驟中轉(zhuǎn)換的
.jar文件，并查看 JD-GUI 中的所有 Java 源代碼。 為了打開.jar文件，我們可以簡單地訪問File | Open。
在右側(cè)窗格中，我們可以看到 Java 應(yīng)用程序的 Java 源代碼和所有方法。 請注意，重新編譯過程會為你提供原始 Java 源代碼的近似版本。 這在大多數(shù)情況下無關(guān)緊要; 但是，在某些情況下，你可能會看到轉(zhuǎn)換的.jar文件中缺少某些代碼。 此外，如果應(yīng)用程序開發(fā)人員使用一些防止反編譯的保護，如 proguard 和 dex2jar，當(dāng)我們使用 dex2jar 或 Apktool 反編譯應(yīng)用程序時，我們不會看到準確的源代碼; 相反，我們將看到一堆不同的源文件，這不是原始源代碼的準確表示。
3.3 使用 Apktool 逆向 Android 應(yīng)用
另一種逆向 Android應(yīng)用程序的方法是將.dex文件轉(zhuǎn)換為 smali 文件。 smali 是一種文件格式，其語法與稱為 Jasmine 的語言類似。我們現(xiàn)在不會深入了解 smali 文件格式。有關(guān)更多信息，請參閱在線 wikihttps://code.google.com/p/smali/wiki/，以便深入了解 smali。
一旦我們下載 Apktool 并配置它，按照前面的章節(jié)的指示，我們都做好了進一步的準備。 與 JD-GUI 相比，Apktool 的主要優(yōu)點是它是雙向的。這意味著如果你反編譯一個應(yīng)用程序并修改它，然后使用 Apktool 重新編譯它，它能跟完美重新編譯，并生成一個新的.apk文件。然而，dex2jar 和 JD-GUI 不能做類似功能，因為它提供近似代碼，而不是準確的代碼。
因此，為了使用 Apktool 反編譯應(yīng)用程序，我們所需要做的是，將.apk文件與 Apktool 二進制文件一起傳遞給命令行。一旦反編譯完成，Apktool 將使用應(yīng)用程序名稱創(chuàng)建一個新的文件夾，其中會存儲所有的文件。為了反編譯，我們只需調(diào)用apktool d [app-name].apk。這里，-d標志表示反編譯。
在以下屏幕截圖中，我們可以看到使用 Apktool 進行反編譯的應(yīng)用程序：
現(xiàn)在，如果我們進入 smali 文件夾，我們將看到一堆不同的 smali 文件，它們包含開發(fā)應(yīng)用程序時編寫的 Java 類的代碼。在這里，我們還可以打開一個文件，更改一些值，并使用 Apktool 再次構(gòu)建它。為了從 smali 構(gòu)建一個改動的應(yīng)用程序，我們將使用 Apktool 中的b（build）標志。
apktool b [decompiled folder name] [target-app-name].apk
但是，為了反編譯，修改和重新編譯應(yīng)用程序，我個人建議使用另一個名為 Virtuous Ten Studio（VTS）的工具。這個工具提供與 Apktool 類似的功能，唯一的區(qū)別是 VTS 提供了一個漂亮的圖形界面，使其相對容易使用。此工具的唯一限制是，它只在 Windows 環(huán)境中運行。我們可以從官方下載鏈接http://www.virtuous-ten-studio.com/下載 VTS。以下是反編譯同一項目的應(yīng)用程序的屏幕截圖：
3.4 審計 Android 應(yīng)用
Android 應(yīng)用程序通常包含許多安全漏洞，大多數(shù)時候是由于開發(fā)人員的錯誤和安全編碼實踐的無視。 在本節(jié)中，我們將討論基于 Android 應(yīng)用程序的漏洞，以及如何識別和利用它們。
內(nèi)容供應(yīng)器泄露
許多應(yīng)用程序使用內(nèi)容供應(yīng)器來存儲和查詢應(yīng)用程序中的數(shù)據(jù)或來自電話的數(shù)據(jù)。 除非已經(jīng)定義了內(nèi)容提供者可以使用權(quán)限來訪問，否則任何其他應(yīng)用都可以使用應(yīng)用所定義的內(nèi)容供應(yīng)器，來訪問應(yīng)用的數(shù)據(jù)。 所有內(nèi)容供應(yīng)器具有唯一的統(tǒng)一資源標識符（URI）以便被識別和查詢。 內(nèi)容提供者的 URI 的命名標準慣例是以content://開始。
如果 Android API 版本低于 17，則內(nèi)容供應(yīng)器的默認屬性是始終導(dǎo)出。 這意味著除非開發(fā)人員指定權(quán)限，否則任何應(yīng)用程序都可以使用應(yīng)用程序的內(nèi)容供應(yīng)器，來訪問和查詢數(shù)據(jù)。 所有內(nèi)容供應(yīng)器都需要在AndroidManifest.xml中注冊。 因此，我們可以對應(yīng)用程序使用 Apktool，并通過查看AndroidManifest.xml文件檢查內(nèi)容供應(yīng)器。
定義內(nèi)容供應(yīng)器的一般方法如下所示：
<provider
android:name="com.test.example.DataProvider"
android:authorities ="com.test.example.DataProvider">
</provider>
所以現(xiàn)在，我們將舉一個漏洞應(yīng)用程序的例子，并嘗試利用內(nèi)容供應(yīng)器泄漏漏洞：
為了反編譯應(yīng)用程序，我們將使用 Apktool 來使用
apktool d [appname].apk反編譯應(yīng)用程序。-
為了找到內(nèi)容供應(yīng)器，我們可以簡單地查看定義它們的
AndroidManifest.xml文件，或者我們可以使用一個簡單的grep命令，從應(yīng)用程序代碼中獲取內(nèi)容供應(yīng)器，如下所示： -
我們可以使用
grep命令來查找內(nèi)容提供者，使用grep –R 'content://'。 此命令將在每個子文件夾和文件中查找內(nèi)容供應(yīng)器，并將其返回給我們。 -
現(xiàn)在，我們在模擬器中安裝應(yīng)用程序。 為了查詢內(nèi)容供應(yīng)器并確認漏洞是可利用的，我們需要在 Android 設(shè)備或模擬器中安裝該應(yīng)用程序。 使用以下代碼，我們將在設(shè)備上安裝易受攻擊的
app.apk文件：$ adb install vulnerable-app.apk 1869 KB/s (603050 bytes in 0.315s) pkg: /data/local/tmp/vulnerable-app.apk Success -
我們可以通過創(chuàng)建另一個沒有任何權(quán)限的應(yīng)用程序來查詢內(nèi)容供應(yīng)器，然后查詢漏洞應(yīng)用程序的內(nèi)容供應(yīng)器。 為了快速獲得信息，我們還可以使用
adb查詢內(nèi)容供應(yīng)器，我們可以在以下命令中看到：adb shell content query - - uri [URI of the content provider]以下是在漏洞應(yīng)用程序上運行的命令，輸出展示了存儲在應(yīng)用程序中的注釋：
在這里，我們還可以使用 MWR 實驗室的另一個名為 Drozer 的工具，以便在 Android 應(yīng)用程序中找到泄漏的內(nèi)容供應(yīng)器漏洞。 我們可以從官方網(wǎng)站
https://labs.mwrinfosecurity.com/tools/drozer/下載并安裝 Drozer。 -
一旦我們安裝了它，我們需要將代理組件
agent.apk安裝到我們的模擬器，它位于下載的.zip文件內(nèi)。 該代理是系統(tǒng)和設(shè)備相互交互所需的。 我們還需要在每次啟動模擬器時轉(zhuǎn)發(fā)一個特定的端口（31415），以便建立連接。 要在 Mac 和其他類似平臺上安裝設(shè)備，我們可以按照https://www.mwrinfosecurity.com/system/assets/559/original/mwri_drozer-users-guide_2013-09-11.pdf上提供的在線指南。 -
一旦完成，我們可以啟動應(yīng)用程序，并單擊"Embedded Server（嵌入式服務(wù)器）"文本。 從那里，我們需要回到設(shè)備，啟動 Drozer 應(yīng)用程序，并通過單擊名為 Disabled 的左上角切換按鈕啟用服務(wù)器。
-
此后，我們需要訪問終端并啟動 Drozer，并將其連接到模擬器/設(shè)備。 為此，我們需要輸入
drozer console connect，如下面的截圖所示： -
在這里，我們可以運行
app.provider.finduri模塊來查找所有內(nèi)容供應(yīng)器，如下所示：dz> run app.provider.finduri com.threebanana.notes Scanning com.threebanana.notes… content://com.threebanana.notes.provider.NotePad/notes content://com.threebanana.notes.provider.NotePadPending/notes/ content://com.threebanana.notes.provider.NotePad/media content://com.threebanana.notes.provider.NotePad/topnotes/ content://com.threebanana.notes.provider.NotePad/media_with_owner/ content://com.threebanana.notes.provider.NotePad/add_media_for_note content://com.threebanana.notes.provider.NotePad/notes_show_deleted content://com.threebanana.notes.provider.NotePad/notes_with_images/ -
一旦我們有了 URI，我們現(xiàn)在可以使用 Drozer 應(yīng)用程序查詢它。 為了查詢它，我們需要運行
app.provider.query模塊并指定內(nèi)容供應(yīng)器的 URI，如下面的截圖所示：如果 Drozer 能夠查詢和顯示來自內(nèi)容供應(yīng)器的數(shù)據(jù)，這意味著內(nèi)容供應(yīng)器泄漏數(shù)據(jù)并且存在漏洞，因為 Drozer 沒有被明確地授予使用數(shù)據(jù)集的任何權(quán)限。
為了修復(fù)此漏洞，開發(fā)人員需要做的是，在創(chuàng)建內(nèi)容供應(yīng)器時指定參數(shù)
android:exported = false，或者創(chuàng)建一些新的權(quán)限，另一個應(yīng)用程序在訪問供應(yīng)器之前必須請求它。
3.5 不安全的文件存儲
通常，開發(fā)人員為應(yīng)用程序存儲數(shù)據(jù)時，未指定文件的正確文件權(quán)限。 這些文件有時被標記為全局可讀，并且可以由任何其它應(yīng)用程序訪問而不需要請求權(quán)限。
為了檢查這個漏洞，我們所需要做的是訪問adb shell，之后使用cd進入/data/data/[package name of the app]。
如果我們在這里執(zhí)行一個簡單的ls -l，就可以看到文件和文件夾的文件權(quán)限：
# ls -l /data/data/com.aditya.example/files/userinfo.xml
-rw-rw-rw- app_200 app_200 22034 2013-11-07 00:01 userinfo.xml
這里我們可以使用find來搜索權(quán)限。
find /data/data/ -perm [permissions value]
如果我們執(zhí)行cat userinfo.xml，它儲存了應(yīng)用的用戶的用戶名和密碼。
#grep 'password' /data/data/com.aditya.example/files/userinfo.xml
<password>mysecretpassword</password>
這意味著任何其他應(yīng)用程序也可以查看和竊取用戶的機密登錄憑據(jù)。 可以通過在開發(fā)應(yīng)用程序時指定正確的文件權(quán)限，以及一起計算密碼與鹽的散列來避免此漏洞。
目錄遍歷或本地文件包含漏洞
顧名思義，應(yīng)用程序中的路徑遍歷漏洞允許攻擊者使用漏洞應(yīng)用程序的供應(yīng)器讀取其他系統(tǒng)文件。
此漏洞也可以使用我們之前討論的工具 Drozer 進行檢查。 在這里，我們用例子來說明由 Seafastian Guerrero 發(fā)現(xiàn)的 Adobe Reader Android 應(yīng)用程序漏洞（http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-adobe-reader-android-application）。 此漏洞存在于 Adobe Reader 10.3.1 中，并在以后的版本中進行了修補。 你可以從http://androiddrawer.com下載各種 Android 應(yīng)用程序的舊版本。
我們將啟動 Drozer，并運行app.provider.finduri模塊來查找內(nèi)容供應(yīng)器 URI。
dz> run app.provider.finduri com.adobe.reader
Scanning com.adobe.reader...
content://com.adobe.reader.fileprovider/
content://com.adobe.reader.fileprov
一旦我們找到了 URI，我們現(xiàn)在可以使用app.provider.read搜索并利用本地文件包含漏洞。 在這里，我嘗試從系統(tǒng)中讀取一些文件，如/etc/hosts和/proc/cpuinfo，它們默認存在于所有的 Android 實例中，因為它是基于 Linux 的文件系統(tǒng)。
dz> run app.provider.read content://com.adobe.reader.fileprovider/../../../../etc/hosts
127.0.0.1 localhost
正如我們在下面的屏幕截圖中看到的，我們已經(jīng)成功地使用 Adobe Reader 漏洞內(nèi)容供應(yīng)器讀取了 Android 文件系統(tǒng)中的文件。
客戶端注入攻擊
客戶端攻擊通常發(fā)生在應(yīng)用程序未檢查用戶輸入的時候。 例如，在對 SQLite 數(shù)據(jù)庫的查詢期間，應(yīng)用程序正在解析用戶輸入，因為它位于查詢語句中。
讓我們舉一個應(yīng)用程序的示例，它檢查本地 SQLite 數(shù)據(jù)庫，來根據(jù)登錄憑據(jù)驗證用戶。 因此，當(dāng)用戶提供用戶名和密碼時，正在運行的查詢將如下所示：
SELECT * FROM 'users' where username='user-input-username' and password='user-input-password'
現(xiàn)在，在正常情況下，這將正常工作，用戶輸入其真正的登錄憑據(jù)，并且查詢?nèi)Q于條件將返回true或false。
SELECT * FROM 'users' where username='aditya' and password='mysecretpass
但是，如果攻擊者輸入 SQL 語句而不是正常的用戶名怎么辦？ 請參考以下代碼：
SELECT * FROM 'users' where username='1' or '1' = '1' - - and password='mysecretpassword
因此，在這種情況下，即使用戶不知道用戶名和密碼，他們可以通過使用1'or'1'='1查詢來輕松繞過它，這在所有情況下都返回true。 因此，應(yīng)用程序開發(fā)人員必須在應(yīng)用程序中進行適當(dāng)?shù)臋z查，來檢查用戶輸入。
我們還可以使用 Drozer 的app.provider.query來利用 SQL 注入漏洞。 其語法看起來像：
run app.provider.query [Content Provider URI] --projection "* FROM SQLITE_MASTER WHERE type='table';- -"
現(xiàn)在，這將返回 SQLite 數(shù)據(jù)庫中整個表的列表，它的信息存儲在SQLITE_MASTER中。 您還可以繼續(xù)并執(zhí)行更多的 SQL 查詢，來從應(yīng)用程序提取更多的信息。 為了使用 Drozer 實戰(zhàn)漏洞利用，你可以從https://www.mwrinfosecurity.com/products/drozer/community-edition/下載他們的漏洞應(yīng)用程序。
3.6 OWASP 移動 Top10
Web 應(yīng)用程序開放安全項目（OWASP）是涉及安全和漏洞搜索的標準之一。 它還發(fā)布了前 10 名漏洞的列表，其中包括在各種平臺中最常見和重要的漏洞。
可以在https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks上找到 OWASP 移動版的前 10 個指南。 如果我們查看 OWASP 移動項目，以下是它涵蓋的移動應(yīng)用程序的 10 個安全問題：
- 服務(wù)端弱控制
- 不安全的數(shù)據(jù)存儲
- 傳輸層保護不足
- 意外的數(shù)據(jù)泄漏
- 缺少授權(quán)和認證
- 無效的加密
- 客戶端注入
- 通過不可信輸入的安全決策
- 不正確的會話處理
- 缺乏二進制保護
讓我們逐一介紹它們，并快速了解它們在移動應(yīng)用程序中的關(guān)系，以及我們?nèi)绾螜z測它們：
服務(wù)端弱控制
第一個 OWASP 漏洞是服務(wù)端弱控制，顧名思義，服務(wù)端不以安全的方式將數(shù)據(jù)從移動應(yīng)用程序發(fā)送到服務(wù)端，或者在發(fā)送數(shù)據(jù)時暴露一些敏感的 API。 例如，考慮一個 Android 應(yīng)用程序發(fā)送登錄憑據(jù)到服務(wù)器進行身份驗證，而不驗證輸入。 攻擊者可以以這樣的方式修改憑證，以便訪問服務(wù)器的敏感或未授權(quán)區(qū)域。 此漏洞可視為移動應(yīng)用程序和 Web 應(yīng)用程序中的一個漏洞。
不安全的數(shù)據(jù)存儲
這僅僅意味著，應(yīng)用相關(guān)信息以用戶可訪問的方式在設(shè)備上存儲。 許多 Android 應(yīng)用程序在共享首選項，SQLite（純文本格式）或外部存儲器中，存儲與用戶相關(guān)的私密信息或應(yīng)用程序信息。 開發(fā)人員應(yīng)該始終記住，即使應(yīng)用程序在數(shù)據(jù)文件夾（/data/data/package-name）中存儲敏感信息，只要手機已 root，惡意應(yīng)用程序/攻擊者就可以訪問它。
傳輸層保護不足
許多 Android 開發(fā)人員依賴于通過不安全模式的網(wǎng)絡(luò)來發(fā)送數(shù)據(jù)，例如 HTTP 或沒有正確實現(xiàn) SSL 的形式。 這使得應(yīng)用程序易受到網(wǎng)絡(luò)上發(fā)生的所有不同類型的攻擊，例如流量攔截，從應(yīng)用程序向服務(wù)器發(fā)送數(shù)據(jù)時操縱參數(shù)，以及修改響應(yīng)來訪問應(yīng)用程序的鎖定區(qū)域。
意外的數(shù)據(jù)泄漏
當(dāng)應(yīng)用程序?qū)?shù)據(jù)存儲在本身易受攻擊的位置時，會出現(xiàn)此漏洞。 這些可能包括剪貼板，URL 緩存，瀏覽器 Cookie，HTML5DataStorage，統(tǒng)計數(shù)據(jù)等。 一個例子是用戶登錄到他們的銀行應(yīng)用程序，他們的密碼已經(jīng)復(fù)制到剪貼板。 現(xiàn)在，即使是惡意應(yīng)用程序也可以訪問用戶剪貼板中的數(shù)據(jù)。
缺少授權(quán)和認證
如果 Android 應(yīng)用程序或一般的移動應(yīng)用程序在沒有適當(dāng)安全措施的情況下，嘗試基于客戶端檢查來驗證或授權(quán)用戶，則這些應(yīng)用程序最容易受到攻擊。 應(yīng)該注意的是，一旦手機已 root，大多數(shù)客戶端保護可以被攻擊者繞過。 因此，建議應(yīng)用程序開發(fā)人員使用服務(wù)器端身份驗證和授權(quán)進行適當(dāng)?shù)臋z查，一旦驗證成功，請使用隨機生成的令牌，以便在移動設(shè)備上驗證用戶。
無效的加密
這僅僅表示使用不安全的密碼函數(shù)來加密數(shù)據(jù)部分。 這可能包括一些已知存在漏洞的算法，如 MD5，SHA1，RC2，甚至是沒有適當(dāng)?shù)陌踩胧┑亩ㄖ扑惴ā?/p>
客戶端注入
這在Android應(yīng)用程序中是可行的，主要成因是使用 SQLite 進行數(shù)據(jù)存儲。 我們將在本書的各章中執(zhí)行注入攻擊。
通過不可信輸入的安全決策
在移動應(yīng)用程序中，開發(fā)人員應(yīng)始終過濾和驗證用戶提供的輸入或其他相關(guān)輸入，并且不應(yīng)該像在應(yīng)用程序中那樣使用它們。 不受信任的輸入通常會導(dǎo)致應(yīng)用程序中的其他安全風(fēng)險，如客戶端注入。
不正確的會話處理
在為移動應(yīng)用程序執(zhí)行會話處理時，開發(fā)人員需要處理很多因素，例如認證 cookie 的正常過期，安全令牌創(chuàng)建，cookie 生成和輪換，以及無法使后端的會話無效。 必須在 Web 應(yīng)用程序和 Android 應(yīng)用程序之間維護正確的安全同步。
缺乏二進制保護
這意味著不能正確地防止應(yīng)用程序被逆向或反編譯。 諸如 Apktool 和 dex2jar 之類的工具可用于逆向 Android 應(yīng)用程序，如果沒有遵循正確的開發(fā)實踐，它會暴露應(yīng)用程序的各種安全風(fēng)險。 為了防止通過逆向攻擊來分析應(yīng)用程序，開發(fā)人員可以使用 ProGuard 和 DashO 等工具。
總結(jié)
在本章中，我們學(xué)習(xí)了使用各種方法來逆轉(zhuǎn) Android 應(yīng)用程序并分析源代碼。 我們還學(xué)習(xí)了如何修改源代碼，然后重新編譯應(yīng)用程序，來繞過某些保護。 此外，我們還看到了如何使用 Drozer 等工具尋找 Android 應(yīng)用程序中的漏洞。 你還可以通過http://labs.securitycompass.com/exploit-me/親自嘗試 Exploit-Me 實驗室中的各種漏洞，它由 Security Compass 開發(fā)。
在下一章中，我們將進一步嘗試 Android 應(yīng)用程序的流量攔截，并在我們的滲透測試中使用它。
