前言

隨着運營商新技術新業務的發展，運營商層面對安全的要求有所變化，滲透測試工作將會面臨內容安全、計費安全、業務邏輯及APP等方面的挑戰。隨着運營商自主開發的移動APP越來越多，這些APP可能並不會通過應用市場審覈及發佈，其中的安全性將面臨越來越多的挑戰。

在海量的APP應用中，可能會遇到各種各樣的威脅：木馬、病毒、篡改、破解、釣魚、二次打包、信息泄露、資源篡改、信息劫持等。

爲有效的針對上述各種威脅進行有效防範，保障運營商和客戶的業務安全，本手冊將着重從下表所列項目針對APP應用（安卓）安全進行檢測。

APP應用安全測試要點（安卓）
客戶端安全	APK簽名	進程和內存保護	內存訪問和修改
反編譯保護	動態注入
應用完整性校驗	通信安全	通信加密
組件安全	證書有效性
敏感信息安全	數據文件	關鍵數據加密和校驗
logcat日誌	訪問控制
密碼安全	鍵盤劫持	客戶端更新安全
隨機佈局鍵盤	短信重放攻擊
屏幕錄像	業務安全	越權操作
安全策略	密碼複雜度檢測	交易篡改
賬號登陸限制	重放攻擊
賬號鎖定策略	用戶枚舉
密碼問題驗證	暴力破解
會話安全	注入/XSS/CSRF
界面切換保護	其他
UI信息泄露
驗證碼安全
安全退出
密碼修改驗證
Activity界面劫持

表1  APP應用安全測試要點

第一章   測試環境

1.1 SDK

Java JDK 1.8.0_151，Android SDK。

1.2 工具

MobSF框架，GameGuardian（內存DUMP），夜神模擬器（運行環境模擬），Android Killer（反編譯集成）,改之理（反編譯集成），7zip，dex2jar（文件轉換），jd-gui，apktool，activity 劫持測試工具等，詳細清單請參照附錄。

第二章   客戶端程序安全

2.1 安裝包簽名

2.1.1描述

在Android中，包名相同的兩個APK會被認爲是同一個應用。當新版本覆蓋舊版本時，簽名證書必須一致，否則會被拒絕安裝（即使開啓了“允許未知來源的應用”）。如果APK沒有使用自己的證書進行簽名，將會失去對版本管理的主動權。本項檢測是檢測客戶端是否經過恰當簽名（正常情況下應用都應該是簽名的，否則無法安裝），簽名是否符合規範。

2.1.2測試步驟

打開cmd，進入到JDK的安裝路徑，C:\Program Files\Java\jdk1.8.0_111\bin，輸入命令:

jarsigner.exe -verify APK文件路徑

測試結果如下：

圖1 簽名驗證

如上圖，如果證書指紋與客戶一致，說明測試結果爲安全。

檢測簽名的字段是否正確標示客戶端程序的來源和發佈者身份，輸入命令：

jarsigner.exe -verify -verbose -certs APK文件路徑

若各個字段與預期的一致，則測試通過

要說明的是，只有在使用直接客戶的證書籤名時，才認爲安全。Debug證書、第三方（如開發方）證書等均認爲存在風險。

2.1.3威脅等級

安裝包簽名的威脅等級判斷一般如下：

若客戶端安裝包簽名有異常（例如簽名證書爲第三方開發商而不是客戶端發佈方），此時高風險；若無異常則無風險。

2.1.4安全建議

將安裝包進行簽名並檢測安裝包簽名的異常。

2.2 反編譯保護

2.2.1描述

測試客戶端安裝程序，判斷是否能反編譯爲源代碼，java 代碼和so 文件是否存在代碼混淆等保護措施。未作保護的 java 代碼，可以輕易分析其運行邏輯，並針對代碼中的缺陷對客戶端或服務器端進行攻擊。

成功的反編譯將使得攻擊者能夠完整地分析APP的運行邏輯，尤其是相關業務接口協議、和通信加密的實現。

2.2.2 名詞解釋

smali語言是一種Android系統特有的中間代碼語言。Android系統使用Dalvik指令（可執行文件爲*.dex）代替了通常的JVM中間代碼（可執行文件爲*.class、*.jar）。對應Dalvik指令的“彙編語言”便是smali。因此，從*.dex中恢復smali代碼比恢復JAVA代碼要容易，成功率更高。如果APK經過花指令處理，會導致無法恢復smali代碼（表現爲apktool解包失敗）。

花指令：由設計者特別構思，希望使反彙編的時候出錯，讓破解者無法清楚正確地反彙編程序的內容，迷失方向。經典的應用，目標位置是另一條指令的中間，這樣在反彙編的時候便會出現混亂。

2.2.3 測試步驟

把apk當成zip並解壓（後綴改爲zip），得到classes.dex文件（有時可能不止一個dex文件，文件名均以classes***開頭），如下圖：

圖2      APK文件結構

使用dex2jar執行如下命令：

dex2jar.bat classes.dex 文件路徑

得到classes.dex.jar，然後使用jd-gui打開jar文件，即可得到JAVA代碼。或者直接使用smali2java打開apk文件，也可反編譯回Java代碼。

圖3 反編譯後的APK

有時用apktool能夠解包並查看smali，但dex2jar卻不行。如果dex2jar反編譯失敗，可以試試看能不能恢復smali代碼。

如上圖，逆向後發現是沒混淆的情況，是不安全的。

如果代碼經過混淆，或者有加殼措施，不能完整恢復源代碼的，都可以認爲此項安全。

下圖爲混淆後的代碼樣例：

圖4 有混淆的代碼

2.2.4威脅等級

若客戶端進行加固保護，此時認爲無風險。

若大部分代碼（包括核心代碼）經過混淆，此時低風險。

若部分代碼混淆，關鍵代碼（加密或通信等）可以獲知其關鍵代碼，此時中風險。

2.2.5安全建議

建議客戶端程序可以把關鍵代碼以 JNI 方式放在 so 庫裏。so 庫中是經過編譯的arm 彙編代碼，可以對其進行加殼保護，以防止逆向分析。

第三章   應用完整性校檢

3.1描述

測試客戶端程序是否對自身完整性進行校驗。攻擊者能夠通過反編譯的方法在客戶端程序中植入自己的木馬，客戶端程序如果沒有自校驗機制的話，攻擊者可能會通過篡改客戶端程序竊取手機用戶的隱私信息。

3.2測試步驟

用ApkTool將目標APK文件解包，命令如下；

java -jar apktool.jar d -f apk文件路徑 -o 解包目標文件夾

圖5 解包後的APK資源目錄

隨便找一個解包目錄裏的資源文件進行修改，推薦找到splash.png進行修改（容易確認結果）；將APK拖入Androidkiller,搜索splash.png，修改替換，，然後簽名打包回APK。

將簽了名的APK安裝、運行、確認是否存在自校驗；需要注意的是，如果之前安裝的APK和修改後的APK簽名不同，就不能直接覆蓋安裝，一般來說，先卸載之前安裝的APP即可。

注：APK必須進行簽名後，方可安裝和運行。如果開啓了“允許未知來源的應用”，那麼Debug證書、自簽名證書、過期證書的簽名都是可以的，但是不可以不簽名。

將客戶端程序文件反編譯，修改源碼或資源文件後重新打包安裝運行如果可運行，說明文件完整。

3.3威脅等級

若應用完整性校驗不使用MANIFEST.MF 中的數據，且核心代碼通過 JNI 技術寫入.so庫，同時於服務端進行相關校驗，此時無風險。

若應用完整性於本地進行驗證而不存在其他問題或使用 MANIFEST.MF 中的數據作爲驗證憑證（有新文件時提示應用完整性驗證失敗），此時低風險；

若在本地進行驗證的基礎上只通過MANIFEST.MF 對客戶端原有文件進行校驗而忽略新增文件的檢驗，此時中風險；若未進行應用完整性校驗此時高風險。

3.4安全建議

建議客戶端在每次開機啓動時進行客戶端自身的應用完整性校驗，在驗證邏輯中不使用MANIFEST.MF中的數據作爲驗證憑證，同時需驗證是否有不屬於該客戶端版本的新文件添加，驗證過程於服務器端完成。

第四章   組件安全

4.1描述

本項主要測試客戶端是否包含後臺服務、Content Provider、第三方調用和廣播等組件，Intent 權限的設置是否安全。應用不同組成部分之間的機密數據傳遞是否安全。檢查客戶端是否存在組件劫持風險，查看客戶端程序具有導出哪些應用信息的權限。反編譯APK文件後，檢查AndroidManifest文件中是否有多餘的android:export聲明，客戶端是否存在導出其他應用信息的權限等。

4.2名詞解釋

1.組件:安卓APP以組件爲單位進行權限聲明和生命週期管理；

2.組件的作用：安卓系統的組件共有四種，其主要用途分別爲：

Activity：呈現可供用戶交互的界面，是最常見的組件；
Service：長時間執行後臺作業，常見於監控類應用；
Content Provider：在多個APP間共享數據，比如通訊錄數據；
Broadcast Receiver：註冊特定事件，並在其發生時被激活；

3.權限聲明：安卓系統定義了許多權限聲明項，分別對應一些操作系統功能；

4.權限聲明的作用：如果一個APP或組件在沒有聲明權限的情況下就調用相關API，會被拒絕訪問；但如果聲明瞭相關權限，安裝的時候就會有提示；

5.組件導出：簡而言之，就是別的APP也可以訪問這個組件。

6.組件導出的作用：有些APP的功能需要提供一些接口給其它APP訪問，就需要把相關的接口功能放在一個導出的組件上。

7.組件導出的危害：因爲權限聲明是以組件爲單位的，A組件調用B組件的功能來訪問操作系統API時，適用於B組件的權限聲明。

如果B作爲導出組件，沒有進行嚴格的訪問控制，那麼A就可以通過調用B來訪問原本沒有聲明權限的功能，構成本地權限提升。

4.3測試步驟

4.3.3方案一：

使用ApkTool解包，打開解包目錄中AndroidManifest.xml，對其中聲明的各個組件，根據以下規則判斷是否可導出：

 1.顯示聲明瞭android:exported=”true”，則可導出；
 2.顯示聲明瞭android:exported=”false”，則不可導出；
 3.未顯示聲明android:exported：
     a) 若組件不是Content Provider：
 i.       若組件包含<intent-filter>則可導出，反之不可；
     b) 若組件是Content Provider：
       i.  若SDK版本<17則可導出，反之不可。

從測試的角度上，只能判斷組件是否導出，但能否構成危害需要詳細分析源代碼後才能得出結論。一般來說，在測試時儘管寫清所有的導出組件，由客戶開發側確認相關組件是否確實需要導出即可。

圖6 安全的組件導出示例

由於功能需要，啓動Activity和ContentProvider大多是導出組件，一般無須理會。如上圖的組件導出就是安全的。

4.3.4 方案二：

檢查 AndroidManifest.xml 文件中各組件定義標籤的安全屬性是否設置恰當。如果組件無須跨進程交互，則不應設置 exported 屬性爲 true。例如，如下圖所示，當 MyService 的 exported屬性爲 true 時，將可以被其他應用調用。（當有設置權限(permissions)時，需要再考察權限屬性。如 android:protectionLevel 爲 signature 或 signatureOrSystem 時，只有相同簽名的 apk才能獲取權限。

圖7 可調用的組件

可以使用“組件安全測試工具”來檢測組件的 exported 屬性（有些應用在代碼中動態註冊組件，這種組件無法使用“組件安全測試工具”測試，需要通過閱讀代碼確定是否安全。

凡是列出來的組件都是 exported 屬性爲true 的。

當發現有可利用的組件導出時，（當然，並不是說所有導出的組件都是不安全的，如果要確定，必須看代碼，對代碼邏輯進行分析）可利用drozer測試工具進行測試。

4.4威脅等級

若不存在組件暴露的情況，此時無風險。

如存在組件暴露的情況，但暴露的組件無關客戶端邏輯核心或不會泄露用戶敏感信息，此時低風險；若暴露的組件會泄露用戶敏感信息（例如郵件客戶端存在消息組件的暴露，攻擊者可以通過編寫 APK，通過組件利用的方式讀取用戶郵件信息）。

4.5安全建議

避免不必要的組件導出。

第五章   敏感信息安全

5.1數據文件

5.1.1 描述

檢測客戶端是否保存明文敏感信息，能否防止用戶敏感信息的非授權訪問。

文件敏感信息泄露以明文存儲“記住密碼”居多。

5.1.2 測試步驟

首先查看相關文件的權限配置。正常的文件權限最後三位應爲空（類似“rw-rw—-”），即除應用自己以外任何人無法讀寫；目錄則允許多一個執行位（類似“rwxrwx—x”）。如下圖所示，（lib 子目錄是應用安裝時由 android 系統自動生成，可以略過）：

圖8 文件的權限

當客戶端使用MODE_WORLD_READABLE 或MODE_WORLD_WRITEABLE 模式創建文件時，shared_prefs 目錄下文件的權限也會多出一些，這不一定是安全問題，如下圖（Google已不推薦使用這些模式）：

圖 9 不推薦的文件權限模式

權限檢測完整後，再檢查客戶端程序存儲在手機中的 SharedPreferences 配置文件，通常是對本目錄下的文件內容（一般是xml）進行檢查，看是否包含敏感信息。

使用數據庫查看工具即可查看這些文件中是否有敏感信息（sqllite等）。

還有些時候，客戶端程序 apk 包中也是是保存有敏感信息的，比如檢查 apk 包中各類文件是否包含硬編碼的的敏感信息等。如下圖APP的相關編碼信息：

圖10 包含敏感代碼的APK

5.2 威脅等級

根據敏感信息泄露的程度進行威脅等級評分。若私有目錄中存在存儲了用戶登陸密碼（明文或只進行過一次單項哈希散列），手勢密碼（明文或只進行過一次單項哈希散列）或曾經訪問過網址的 Cookie 等敏感信息的文件，此時爲高風險，若不存在則無風險。

5.3 安全建議

儘量避免在文件、數據庫、日誌等位置寫入敏感信息。如果確實需要存儲，應當進行加密。對於內存中的信息泄露，可以通過反注入、反調試來解決。

此外，正常的文件權限最後三位應爲空（類似“rw-rw—-”），目錄則允許多一個執行位（類似“rwxrwx—x”）。

5.4 Logcat日誌

5.4.1 描述

本項主要是檢查客戶端程序存儲在手機中的日誌是否含有敏感信息。

5.4.2 測試步驟

將內存DUMP到SD卡，然後用adb到主機上查看。

使用adb工具連接設備：

adb devices                // 查看安卓設備列表

adb -s  設備名稱 其它命令       //當連接了多個設備時，選擇操作的目標設備，否則會出錯

adb pull  手機目錄名 PC目錄名      //從安卓設備中複製文件到電腦中

然後使用WinHex打開

圖11 查看遺留內存信息

這是查看內存遺留的信息，還可以直接使用adb查詢logcat日誌，在adb shell中，有下列命令可用：

logcat         // 持續輸出日誌，直到Ctrl+C

logcat-d      // 一次性輸出日誌緩存，不會阻塞

logcat-c      // 清空日誌緩存

5.4.3 威脅等級

根據敏感信息泄露的程度進行威脅等級評分。若相關信息中存在存儲了用戶登陸密碼（明文或只進行過一次單項哈希散列），手勢密碼（明文或只進行過一次單項哈希散列）或曾經訪問過網址的 Cookie 等敏感信息，此時爲高風險，若不存在則無風險。

5.4.4 安全建議

數據傳輸應做到加密處理，敏感信息不應輸出在logcat日誌中。

第六章  密碼安全

6.1 鍵盤劫持

6.1.1 描述

測試客戶端程序在密碼等輸入框是否使用自定義軟鍵盤。安卓應用中的輸入框默認使用系統軟鍵盤，手機安裝木馬後，木馬可以通過替換系統軟鍵盤，記錄手機鍵盤輸過的密碼。

6.1.2 測試步驟

通常來說，只有使用系統輸入法的編輯框才能夠進行鍵盤碼記錄。如果是自制的軟鍵盤，則可以嘗試進行觸摸屏記錄。不使用系統輸入法，且按鍵隨機分佈的軟鍵盤是安全的。

6.1.3 威脅等級

能夠劫持鍵盤風險爲高，不能則爲無風險。

6.1.4 安全建議

儘量使用系統自定義的隨機軟鍵盤（而非系統輸入法）來輸入敏感信息。或者對Native層輸入記錄功能進行Hook（需要root權限）。

6.2 隨機佈局軟鍵盤

6.2.1 描述

測試客戶端實現的軟鍵盤，是否滿足鍵位隨機布放要求。

6.2.2 測試步驟

人工觀測鍵位分佈是否爲隨機布放。

6.2.3 威脅等級

當客戶端軟鍵盤未進行隨機化處理時爲低風險；當客戶端軟鍵盤只在某一個頁面載入時，初始化一次而不是在點擊輸入框時重新進行隨機化也爲低風險。

6.2.4 安全建議

鍵位隨機布放。

6.3 屏幕錄像

6.3.1 描述

客戶端使用的隨機佈局軟鍵盤是否會對用戶點擊產生視覺響應。當隨機佈局軟鍵盤對用戶點擊產生視覺響應時，安卓木馬可以通過連續截屏的方式，對用戶擊鍵進行記錄，從而獲得用戶輸入。

6.3.2 測試步驟

使用ADB進行測試：

adb shell /system/bin/screencap -p 輸出png路徑（安卓設備中）

如圖：

圖12 截屏並生成文件

在/mnt/sdcard/路徑下，可以看到1a.png：

圖13 生成的png截圖文件

打開：

圖14 瀏覽截屏圖片內容

攻擊者可以在用戶進入登錄頁面，在輸入密碼的同時，進行連續截圖，即可記錄用戶輸入的密碼。如果沒有防截屏，那麼即使是隨機分佈的、沒有視覺反饋的軟鍵盤也會被記錄：

還有一種驗證方式是從代碼方面進行驗證：

檢測需較高安全性的窗口（如密碼輸入框），看代碼中在窗口加載時是否有類似下圖的代碼。按照 android SDK的要求，開啓 FLAG_SECURE 選項的窗口不能被截屏。

圖15 FLAG_SECURE選項

6.3.3 威脅等級

當使用第三方程序（或系統截屏）可以對客戶端內容進行截屏時，爲中風險；當客戶端會對截屏操作進行有效抵抗時（無法截屏或截屏結果爲黑屏等無意義圖片）無風險。

6.3.4 安全建議

在敏感信息的輸入過程儘量避免視覺反饋，或者在操作系統層面對截屏相關功能進行Hook以阻止敏感信息輸入期間其它程序的截屏操作（需要root權限）。

6.4手勢密碼

6.4.1 描述

主要從手勢密碼的複雜度、修改和取消、本地信息保存、鎖定策略、抗攻擊測試等方面進行測試。

6.4.2 測 試步驟

手勢密碼的複雜度：

 1. 進入客戶端設置手勢密碼的頁面進行手勢密碼設置。
 2. 進行手勢密碼設置，觀察客戶端手勢密碼設置邏輯是否存在最少點位的判斷。
 3. 反編譯 APK 爲 jar 包，通過jd-gui觀察對應代碼邏輯是否有相應的判斷和限制條件。（一般設置手勢密碼若輸入點數過少時會有相應的文字提示，通過此文字提示可以快速定位到代碼位置）

手勢密碼的修改和取消：

 1. 進入客戶端設置手勢密碼的位置，一般在個人設置或安全中心等地方。
 2. 進行手勢密碼修改或取消操作，觀察進行此類操作時是否需要輸入之前的手勢密碼或普通密碼。
 3. 觀察在忘記手勢密碼等其他客戶端業務邏輯中是否存在無需原始手勢或普通密碼即可修改或取消手勢密碼的情況。
 4. 多次嘗試客戶端各類業務，觀察是否存在客戶端邏輯缺陷使得客戶端可以跳轉回之前業務流程所對應頁面。若存在此類邏輯（例如手勢密碼設置），觀察能否修改或取消手勢密碼。
 5. 反編譯 APK 爲 jar 包，通過jd-gui觀察對應代碼邏輯，尋找客戶端對於手勢密碼的修改和刪除是否存在相應的安全策略。

手勢密碼的本地信息保存：

1. 首先通過正常的操作流程設置一個手勢密碼並完整一次完整的登陸過程。

2. 尋找/data/data 的私有目錄下是否存在手勢密碼對應敏感文件，若進行了相關的信息保存，基本在此目錄下。（關鍵詞爲 gesture.key 等）

3. 若找到對應的文件，觀察其存儲方式，爲明文還是二進制形式存儲，若爲二進制形式，觀察其具體位數是否對應進行 MD5（二進制 128 位，十六進制32位或 16 位）、SHA-1（二進制 160 位，十六進制 40 位）等散列後的位數。如果位數對應，即可在反編譯的 jar包中搜索對應的關鍵字以迅速對應代碼。

4. 通過代碼定位確認其是否進行了除單項哈希散列之外的加密算法，若客戶端未將手勢密碼進行加密或變形直接進行散列處理可認爲其不安全，一是因爲現階段 MD5、SHA-1 等常用的哈希算法已被發現碰撞漏洞，二是網絡中存在 www.somd5.com 等散列值查詢網站可以通過大數據查詢的方式獲取散列前的明文手勢密碼。

手勢密碼的鎖定策略：

 1. 首先通過正常的操作流程設置一個手勢密碼。
 2. 輸入不同於步驟 1 中的手勢密碼，觀察客戶端的登陸狀態及相應提示。若連續輸入多次手勢密碼錯誤，觀察當用戶處於登陸狀態時是否退出當前的登陸狀態並關閉客戶端；當客戶未處於登錄狀態時是否關閉客戶端並進行一定時間的輸入鎖定。
 3. 反編譯 APK 爲 jar 包，通過jd-gui觀察對應代碼邏輯，尋找客戶端是否針對輸入次數及鎖定時間有相應的邏輯處理。

手勢密碼的抗攻擊測試：

 1. 下載並安裝 Xposed 框架及 SwipeBack 插件。
 2. 啓動客戶端並進入手勢密碼輸入頁。
 3. 啓動 SwipeBack 插件，觀察是否可以通過滑動關閉手勢密碼輸入頁的方式進入登陸後的頁面。

6.4.3 威脅等級

手勢密碼的複雜度：

當用戶設置或修改手勢密碼時服務器會對手勢密碼安全性（使用點數）進行判斷時無風險，否則低風險。

修改和取消：

當取消或修改手勢密碼時，如果不會驗證之前的手勢密碼則爲中風險；若存在驗證則無風險。

本地信息保存：

當本地保存了明文存儲（數組形式）的手勢密碼時爲高風險；當本地保存了只進行單項哈希散列的手勢密碼時爲中風險。

鎖定策略：

當服務器不會驗證手勢密碼輸入錯誤次數時爲中風險，會進行驗證時無風險。

抗攻擊測試：

若客戶端採用附着的方式將手勢密碼放置於登陸後的界面上時，如果無法抵抗SwipeBack 插件的滑動攻擊則高風險，如果可以抵抗則無風險。

6.4.4 安全建議

上述手勢密碼哪方面出現問題就根據哪方面的風險提出針對性的建議。

第七章   安全策略

安全策略在實際測試中受限較多，因此建議的風險等級：安全策略類全部爲低危。

7.1 密碼複雜度檢測

7.1.2 描述

測試客戶端程序是否檢查用戶輸入的密碼強度，禁止用戶設置弱口令。

7.1.3 測試步驟

人工測試，嘗試將密碼修改爲弱口令，如：123456，654321，121212，888888 等，查看客戶端是否拒絕弱口令。也可以閱讀逆向後的客戶端 java 代碼，尋找對用戶輸入口令的檢查方法。

7.1.4 威脅等級

低危。

7.1.5 安全建議

當系統允許用戶設置弱密鑰時爲低風險，如果存在系統存在一定的安全策略（使用數字，大小寫字母，下劃線，特殊字符組合，且至少爲 8位）時無風險。

7.2 賬號登陸限制

7.2.1 描述

測試一個帳號是否可以同時在多個設備上成功登錄客戶端，進行操作。

7.2.2 測試步驟

人工測試。

7.2.3 威脅等級

低危。

7.2.4 安全建議

禁止同一個賬號可以同時在多臺移動終端設備上登陸。

7.3 賬戶鎖定策略

7.3.1 描述

測試客戶端是否限制登錄嘗試次數。防止木馬使用窮舉法暴力破解用戶密碼。

7.3.2 測試步驟

人工測試。

7.3.3 威脅等級

低危。

7.3.4安全建議

設定賬戶鎖定策略。

7.4 問題驗證

7.4.1 描述

測試對賬號某些信息（如單次支付限額）的修改是否有私密問題驗證。私密問題驗證是否將問題和答案一一對應。私密問題是否足夠私密。

7.4.2 測試步驟

人工測試。

7.4.3 威脅等級

當用戶進行忘記密碼操作時，在發送郵件給用戶郵箱前是否進行私密問題的驗證，若驗證則無風險；若不驗證則低風險。

7.4.4 安全建議

對於敏感功能操作時，要進行私密問題驗證。

7.5 會話安全

7.5.1 描述

測試客戶端在超過 20 分鐘無操作後，是否會使會話超時並要求重新登錄。超時時間設置是否合理。

7.5.2 測試步驟

人工測試。

7.5.3 威脅等級

當系統不存在會話超時邏輯判斷時爲低風險，若存在則無風險。

7.5.4 安全建議

設置會話超時。

7.6 界面切換保護

7.6.1 描述

檢查客戶端程序在切換到其他應用時，已經填寫的賬號密碼等敏感信息是否會清空，防止用戶敏感信息泄露。

如果切換前處於已登錄狀態，切換後一定時間內是否會自動退出當前會話。

7.6.2 測試步驟

人工檢測。

在登錄界面（或者轉賬界面等涉及密碼的功能）填寫登錄名和密碼，然後切出，再進入客戶端，看輸入的登錄名和密碼是否清除。登錄後切出，5 分鐘內自動退出爲安全。

7.6.3 威脅等級

當移動終端設備進行進程切換操作，顯示界面不爲客戶端頁面時，若客戶端提示用戶確認是否爲本人操作，則無風險；若無相應提示則爲低風險。

7.6.4 安全建議

對於畫面切換進行提示或者驗證。

7.7 UI信息泄露

7.7.1 描述

檢查客戶端的各種功能，看是否存在敏感信息泄露問題。

7.7.2 測試步驟

人工測試。使用錯誤的登錄名或密碼登錄，看客戶端提示是否不同。在顯示卡號等敏感信息時是否進行部分遮擋。

7.7.3 威脅等級

若在用戶名輸入錯誤和密碼輸入錯誤時提示信息不同則存在 UI 信息泄露問題，此時爲低風險，否則無風險。

7.7.4 安全建議

注意UI信息的防護。

7.8 驗證碼安全

7.8.1 描述

測試客戶端在登錄和交易時是否使用圖形驗證碼。驗證碼是否符合如下要求：由數字和字母等字符混合組成；採取圖片底紋干擾、顏色變換、設置非連續性及旋轉圖片字體、變異字體顯示樣式等有效方式，防範惡意代碼自動識別圖片上的信息；具有使用時間限制並僅能使用一次；驗證碼由服務器生成，客戶端文件中不包含圖形驗證碼文本內容。

7.8.2 測試步驟

觀察驗證碼組成，若簡單，可以嘗試使用PKAVHttpFuzzer的驗證碼識別工具進行識別：

圖16 驗證碼識別工具

7.8.3 威脅等級

當圖形驗證碼由本地生成而不是從服務器獲取時爲中風險；當驗證碼安全性低或不存在驗證碼時爲中風險；不存在以上兩個問題時無風險。

7.8.4 安全建議

加強驗證碼的識別難度，對於驗證碼的驗證做到“一次一驗”。

7.9 安全退出

7.9.1 描述

測試客戶端退出時是否正常終止會話。

7.9.2 測試步驟

檢查客戶端在退出時，是否向服務端發送終止會話請求。客戶端退出後，還能否使用退出前的會話 id 訪問登錄後才能訪問的頁面。

7.9.3 威脅等級

若客戶端退出登錄時不會和服務器進行Logout的相關通信則爲中風險，否則無風險。

7.9.4 安全建議

客戶端退出時要做到和服務器進行Logout的相關通信。

7.10 密碼修改驗證

7.10.1描述

測試客戶端在修改密碼時是否驗證舊密碼正確性。

7.10.2 測試步驟

人工測試。

7.10.3威脅等級

當進行密碼修改時是否要求輸入原密碼已驗證其正確性，若需要輸入則無風險；如不需輸入原密碼則中風險。

7.10.4 安全建議

修改密碼需要驗證原密碼的正確性。

7.11 Activity界面劫持

7.11.1 描述

檢查是否存在 activity 劫持風險，確認客戶端是否能夠發現並提示用戶存在劫持。

7.11.2 測試步驟

安裝HijackActivity.apk，使用 activity 界面劫持工具，在工具中指定要劫持的應用進程名稱。如圖所示，從列表中選擇被測試的應用，點擊 OK。打開應用，測試工具會嘗試用自己的窗口覆蓋被測的應用。

圖17 HijackActivity.apk劫持工具

如果劫持成功，會出現如下界面：

圖18 成功劫持

7.11.3 威脅等級

若客戶端無法抵抗 Activity 界面劫持攻擊時爲中風險；若可以抵抗攻擊則無風險。

7.11.4 安全建議

Activity劫持通常依靠註冊Receiver響應android.intent.action.BOOT_COMPLETED事件。客戶端程序可以在啓動前檢查Receiver並報警；

由於Activity界面劫持攻擊通常是將自己的頁面附着在客戶端之上，因此需要進行界面切換操作，因此在界面切換到後臺時彈出警告信息也可以達到一定的效果。

除此之外，因爲Android進程棧的工作原理，建議開發客戶端時針對進程棧進行相應的保護，可禁止其他進程放置於客戶端之上。

第八章   進程保護

8.1 內存訪問和修改

8.1.1 描述

通過對客戶端內存的訪問，木馬將有可能會得到保存在內存中的敏感信息（如登錄密碼，帳號等）。測試客戶端內存中是否存在的敏感信息（賬號、明文密碼等等）。

8.1.2 測試步驟

需要 root 權限，可以使用 MemSpector 查看、搜索和修改客戶端內存數據。用戶名、密碼等數據通常會在/dev/ashmem/dalvik-heap 內存段。（目前大多數工具都是通過ptrace接口修改客戶端內存，可以使用 ptrace 機制本身防護。）

8.1.3 威脅等級

當進行敏感操作後在內存中可以搜索到用戶輸入的敏感信息時爲高風險，否則無風險。

8.1.4 安全建議

對於內存中的信息泄露，可以通過反注入、反調試來解決。

8.2 動態注入

8.2.1 描述

通過注入動態鏈接庫，hook 客戶端某些關鍵函數，從而獲取敏感信息或者改變程序執行。

8.2.2 測試步驟

使用工具動態注入應用進程內存。Dynamic Dalvik Instrumentation Toolkit或者使用 hook 框架來進行測試。

8.2.3 威脅等級

當客戶端存在動態注入隱患時高風險，否則無風險。

8.2.4 安全建議

防止應用程序被Hook。

第九章   通信安全

9.1 通信加密

9.1.1 描述

如果客戶端與服務器之間的通信加密協議實現不當，攻擊者將有機會對當前網絡環境中其他合法用戶的通信內容進行竊聽甚至篡改。

9.1.2 測試步驟

爲了對服務器端進行測試，至少要先弄清楚客戶端與服務器的通信協議。

一般來說，有以下三種情況：

1.  如果使用HTTP(S)協議，大多可以通過設置系統HTTP代理來進行操作客戶端的網絡訪問。這種情況佔絕大多數：

     a)  在電腦上開啓Burpsuite/Fiddler等代理工具，並設置允許遠程連接；
     b)  如果是真實手機：
       i.  使用netsh wlan開啓承載網絡（具體方法請自行百度）；
       ii. 用手機連接電腦的WIFI，其餘部分同Genymotion。

2.  如果是HTTP(S)協議，但是不接受操作系統代理：

     a)  如果設備已經root，可以安裝 “ProxyDroid” APP；
     b)  如果設備不能root，可以把安卓虛擬機裝在Windows虛擬機裏，在Windows虛擬機上安裝Proxifier，掛到物理機的代理工具上；

3.  如果不是HTTP協議：

     a)  那麼一般就是由TCP或UDP實現的私有協議，大多數是TCP；
     b)  雖然也可以用一些辦法來操作TCP網絡訪問（比如用WPE附加到Emulator的進程上），但由於TCP是全雙工流式協議，傳輸層上沒有明確的報文邊界。如果私有協議是請求-響應式的還勉強可以編輯，如果是委託-回調式，或者其它複雜形式的協議，使用通用工具進行操作是非常困難的。
     c)  這種情況可以通過Wireshark抓包分析，如果協議不復雜，可以自行實現代碼進行仿製；
     d)  如果協議複雜，就需要對APP的代碼進行分析，找到通信的部分，將其摘出並調用，或者自行實現代碼進行仿製；

此外，通信過程如果有加密、簽名等措施，通常需要從客戶端代碼入手，進行傳統逆向分析以破解其加密。如果其實現非常複雜，此項可以認爲安全。

逆向分析的常見入手位置主要有數據（字符串內容等）和特定API（如界面、網絡、文件、Native操作等）兩種。

有時會遇到客戶端檢查了HTTPS證書的情況（表現爲，代理工具如果不替換SSL證書則正常代理，替換SSL證書則客戶端網絡異常），會有以下兩種情況：

 1.  客戶端使用操作系統證書鏈驗證服務端證書：
     a)  此種情況下，可以從代理工具中導出證書，然後安裝到安卓設備中。
 2.  客戶端預存了服務端證書的公鑰或Hash，甚至整個證書：
     a)  此種情況下，如果客戶端本身缺少完整性校驗，可以嘗試分析其代碼，並修改其存儲的證書信息爲代理工具的證書信息；

所有需要對客戶端程序/設備進行操作後，才能解除的保密性或完整性措施，不算作風險。

加密簽名措施的破解，最終還是要根據客戶端的具體實現方式進行分析。

9.1.3 威脅等級

當客戶端和服務器的通信不經過 SSL 加密（或沒有參考 TLS 協議，RF**346 等實現加密信道）時爲高風險；當自實現通信算法存在漏洞可被解析或繞過時爲高風險；使用低版本SSL 協議（SSLV2，SSLV3 均存在漏洞，至少使用 TLSV1.1 以上算法）時爲高風險；以上問題均不存在時無風險。

9.1.4 安全建議

建議使用SSL協議，並在客戶端對服務端的證書進行驗證。如果自行實現加密協議，建議在客戶端預先存儲服務端公鑰，在建立會話時隨機生成對稱加密密鑰，用服務端公鑰加密併發送給服務端，隨後服務端用私鑰解密後，正式開始進行通信。加密過程儘量避免使用CBC模式。

9.2 證書有效性

9.2.1 描述

主要測試SSL 協議安全性、SSL證書驗證等。

9.2.2 測試步驟

首先測試客戶端程序是否嚴格檢查服務器端證書信息。

通過修改 DNS，將客戶端鏈接到的主頁地址改爲 https://mail.qq.com/ ，然後使用客戶端訪問服務端，查看客戶端是否會提示連接錯誤。此項測試主要針對客戶端是否對 SSL 證書中的域名進行確認。

也可以查閱代碼中是否有 SSL 驗證。

如下圖相關驗證：

圖19 SSL驗證

還需要檢測SSL 協議安全性。主要是檢測客戶端使用的 SSL 版本號是否不小於 3.0（或 TLS v1），加密算法是否安全。（安全規範要求）。

測試命令如下：

Openssl s_client -host 測試網址 -port 443

圖20 測試結果

9.2.3 威脅等級

當客戶端和服務器互相不驗證證書時高風險，當只有客戶端驗證服務器證書時爲中風險；

當服務器不通過白名單的方式驗證客戶端時爲中風險；當客戶端和服務器進行雙向認證，並且服務器通過白名單方式驗證客戶端證書時無風險。

9.2.4 安全建議

使用Https方式進行加密，且服務器通過白名單方式驗證客戶端證書。

9.4 關鍵數據加密和校檢

9.4.1 描述

測試客戶端程序提交數據給服務端時，密碼、收款人信息等關鍵字段是否進行了加密，防止惡意用戶嗅探到用戶數據包中的密碼等敏感信息。

9.4.2 測試步驟

在手機上配置好代理，觀察客戶端和服務端的交互數據。檢查關鍵字端是否加密。

如果客戶端對根證書進行了嚴格檢測，導致代理無法使用。則可以將代理的根證書安裝到設備上，使根證書可信。或是替換客戶端apk 中的根證書文件。如果上述方法均失效，則反編譯爲 java 代碼，將客戶端逆向後，通過閱讀java 代碼的方式尋找客戶端程序向服務端提交數據的代碼，檢查是否存在加密的代碼。

9.4.3 威脅等級

當賬號，密碼，卡號等數據明文傳輸，未進行二次加密時爲高風險；當密碼只進行了單項散列而未經過加密時爲高風險；當返回數據中包含更新的 URL 且數據不加密時爲高風險；

當校驗字段刪除後服務器仍會處理所發送的數據包時爲高風險；當校驗字段的散列中不包含隨機因子時爲高風險。以上問題均不存在時無風險。

9.4.4 安全建議

對於重要的敏感信息傳輸時要進行嚴格的加密和校檢。

9.5 訪問控制

9.5.1 描述

測試客戶端訪問的 URL 是否僅能由手機客戶端訪問。是否可以繞過登錄限制直接訪問登錄後才能訪問的頁面，對需要二次驗證的頁面（如私密問題驗證），能否繞過驗證。

9.5.2 測試步驟

人工測試。在 PC 機的瀏覽器裏輸入 URL，嘗試訪問手機頁面。

9.5.3 威脅等級

當 PC 端也可訪問手機頁面時低風險，當可以繞過登陸限制訪問登陸後才能訪問的頁面時中風險。

9.5.4 安全建議

對也頁面訪問權限進行嚴格控制。

9.6 客戶端更新安全性

9.6.1 描述

測試客戶端自動更新機制是否安全。如果客戶端更新沒有使用官方應用商店的更新方式，就可能導致用戶下載並安裝惡意應用，從而引入安全風險。

9.6.2 測試步驟

使用代理抓取檢測更新的數據包，嘗試將服務器返回的更新 url 替換爲惡意鏈接。看客戶端是否會直接打開此鏈接並下載應用。在應用下載完畢後，測試能否替換下載的 apk 文件，測試客戶端是否會安裝替換後的應用。

9.6.3 威脅等級

當客戶端返回明文 URL 地址並可以通過篡改的方式控制用戶下載惡意 APK包進行安裝，則高風險；若返回數據包經過二次加密則無風險。

9.6.4 安全建議

對於返回的數據包要進行二次加密處理。

9.7 短信重放攻擊

9.7.1 描述

檢測應用中是否存在數據包重放攻擊的安全問題。是否會對客戶端用戶造成短信轟炸的困擾。

9.7.2 測試步驟

嘗試重放短信驗證碼數據包是否可以進行短信轟炸攻擊。

9.7.3 威脅等級

當存在短信轟炸的情況時爲中風險，若短信網關會檢測短時間內發送給某一手機號的短信數量則無風險。

9.7.4 安全建議

對於驗證碼的發送要進行相關身份驗證，如：驗證碼。

第十章   業務安全

業務安全基本上檢測的業務邏輯安全。對於業務邏輯安全在進行測試的時候可以參考業務邏輯滲透測試思維導圖：

圖21 業務邏輯滲透測試思維導圖

手機APP的業務安全和WEB測試並無太大差別，僅做簡單說明。

10.1 越權操作

10.1.1 描述

服務器端對客戶提出的數據操作請求過分信任，忽略了對該用戶操作權限的判定，導致攻擊賬號擁有了其他賬戶的增刪改查功能。

10.1.2 測試步驟

屬於業務邏輯相關的測試，因此需要手工測試。

10.1.3 威脅等級

根據越權操作的危害性進行定級。

10.1.4 安全建議

1、基礎安全架構，完善用戶權限體系。要知道哪些數據對於哪些用戶，哪些數據不應該由哪些用戶操作；

2、鑑權，服務端對請求的數據和當前用戶身份做校驗；

10.2 交易篡改

10.2.1 描述

本項測試主要是修改金額信息（如：轉帳金額爲負值），訂單信息（如：訂單的數量）等。

10.2.2 測試步驟

手工抓包測試。

10.2.3 威脅等級

高（此項業務一般爲核心業務，只要能修改相關信息，基本上都是高危漏洞）。

10.2.4 安全建議

服務端要做到嚴格的驗證。（根據業務情形不同，安全建議也不相同，因此這裏只能簡單的一句話描述）。

10.3 重放攻擊

10.3.1 描述

主要就是進行抓包重放（如：重放產品購買、訂單創造等）測試。

10.3.2 測試步驟

人工測試。

10.3.3 威脅等級

根據重放業務進行判定危險等級。

10.2.4 安全建議

根據業務具體情境提供不同的安全建議。

10.4 用戶枚舉

10.4.1 描述

嘗試爆破枚舉用戶。

10.4.2 測試步驟

手工測試。

此類漏洞情境一般是：登錄界面無驗證碼、有明顯的返回信息（如：該賬號不存在、密碼錯誤等）。

10.4.3 威脅等級

要看公司的規模、用戶名的形式（如：***號碼）等來判定危險等級。

10.4.4 安全建議

一般的安全建議是設置嚴格的登錄信息驗證，如驗證碼、手機驗證碼等。

10.5 暴力破解

10.5.1 描述

主要是測試業務中查詢、登錄等功能，嘗試使用暴力枚舉的方式進行破解。

10.5.2 測試步驟

手工測試。

10.5.3 威脅等級

根據暴力破解的業務和結果進行判定（如：若成功爆破出用戶賬號和密碼，風險等級爲高）。

10.5.4 安全建議

一般的安全建議是設置嚴格的信息驗證，如驗證碼、手機驗證碼等。

10.6 注入/XSS/CSRF

10.6.1 描述

和WEB測試類似，主要測試站點存在的常見的WEB漏洞。

10.6.2 測試步驟

可手工測試也可以使用工具掃描、測試。

10.6.3 威脅等級

此類漏洞一般爲高，具體的可以看存在漏洞的業務進行判定。

10.6.4 安全建議

參考WEB漏洞的安全建議。

第十一章   附錄

測試工具清單 吞龍

MobSF

signapk

jd-gui-windows

dex2jar

apktool

adb

AndroidKiller

改之理

drozer

Burpsuite

GameGuardian

ApkIDE少月版V3.5.0

GDA3.33

IDA Pro

Reflector

APP應用安全測評表

安卓安全思維導圖

APK攻防思維導圖