APP安全檢測手冊
時間:2022-07-19
本文章向大家介紹APP安全檢測手冊，主要內容包括其使用實例、應用技巧、基本知識點總結和需要注意事項，具有一定的參考價值，需要的朋友可以參考一下。
前言
隨著運營商新技術新業務的發展，運營商層面對安全的要求有所變化，滲透測試工作將會面臨內容安全、計費安全、業務邏輯及APP等方面的挑戰。隨著運營商自主開發的移動APP越來越多，這些APP可能并不會通過應用市場審核及發布，其中的安全性將面臨越來越多的挑戰。
在海量的APP應用中，可能會遇到各種各樣的威脅：木馬、病毒、篡改、破解、釣魚、二次打包、信息泄露、資源篡改、信息劫持等。
為有效的針對上述各種威脅進行有效防范，保障運營商和客戶的業務安全，本手冊將著重從下表所列項目針對APP應用（安卓）安全進行檢測。
APP應用安全測試要點（安卓）
客戶端安全
APK簽名
進程和內存保護
內存訪問和修改
反編譯保護
動態注入
應用完整性校驗
通信安全
通信加密
組件安全
證書有效性
敏感信息安全
數據文件
關鍵數據加密和校驗
日志
訪問控制
密碼安全
鍵盤劫持
客戶端更新安全
隨機布局鍵盤
短信重放攻擊
屏幕錄像
業務安全
越權操作
安全策略
密碼復雜度檢測
交易篡改
賬號登陸限制
重放攻擊
賬號鎖定策略
用戶枚舉
密碼問題驗證
暴力破解
會話安全
注入/XSS/CSRF
界面切換保護
其他
UI信息泄露
驗證碼安全
安全退出
密碼修改驗證
界面劫持
表1 APP應用安全測試要點
第一章 測試環境1.1 SDK
Java JDK 1.8.0_151， SDK。
1.2 工具
MobSF框架，（內存DUMP），夜神模擬器（運行環境模擬）， （反編譯集成）,改之理（反編譯集成），7zip，（文件轉換），jd-gui，， 劫持測試工具等，詳細清單請參照附錄。
第二章 客戶端程序安全2.1 安裝包簽名
2.1.1描述
在中，包名相同的兩個APK會被認為是同一個應用。當新版本覆蓋舊版本時，簽名證書必須一致，否則會被拒絕安裝（即使開啟了“允許未知來源的應用”）。如果APK沒有使用自己的證書進行簽名，將會失去對版本管理的主動權。本項檢測是檢測客戶端是否經過恰當簽名（正常情況下應用都應該是簽名的，否則無法安裝），簽名是否符合規范。
2.1.2測試步驟
打開cmd，進入到JDK的安裝路徑，C: .8.，輸入命令:
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語言是一種系統特有的中間代碼語言。系統使用指令（可執行文件為.dex）代替了通常的JVM中間代碼（可執行文件為.class、.jar）。對應指令的“匯編語言”便是smali。因此，從.dex中恢復smali代碼比恢復JAVA代碼要容易，成功率更高。如果APK經過花指令處理，會導致無法恢復smali代碼（表現為解包失敗）。
花指令：由設計者特別構思，希望使反匯編的時候出錯，讓破解者無法清楚正確地反匯編程序的內容，迷失方向。經典的應用，目標位置是另一條指令的中間，這樣在反匯編的時候便會出現混亂。
2.2.3 測試步驟
把apk當成zip并解壓（后綴改為zip），得到.dex文件（有時可能不止一個dex文件，文件名均以*開頭），如下圖：
圖2 APK文件結構
使用執行如下命令：
dex2jar.bat classes.dex 文件路徑得到.dex.jar，然后使用jd-gui打開jar文件，即可得到JAVA代碼。或者直接使用打開apk文件，也可反編譯回Java代碼。
圖3 反編譯后的APK
有時用能夠解包并查看smali，但卻不行。如果反編譯失敗，可以試試看能不能恢復smali代碼。
如上圖，逆向后發現是沒混淆的情況，是不安全的。
如果代碼經過混淆，或者有加殼措施，不能完整恢復源代碼的，都可以認為此項安全。
下圖為混淆后的代碼樣例：
圖4 有混淆的代碼
2.2.4威脅等級
若客戶端進行加固保護，此時認為無風險。
若大部分代碼（包括核心代碼）經過混淆，此時低風險。
若部分代碼混淆，關鍵代碼（加密或通信等）可以獲知其關鍵代碼，此時中風險。
2.2.5安全建議
建議客戶端程序可以把關鍵代碼以 JNI 方式放在 so 庫里。so 庫中是經過編譯的arm 匯編代碼，可以對其進行加殼保護，以防止逆向分析。
第三章 應用完整性校檢3.1描述
測試客戶端程序是否對自身完整性進行校驗。攻擊者能夠通過反編譯的方法在客戶端程序中植入自己的木馬，客戶端程序如果沒有自校驗機制的話，攻擊者可能會通過篡改客戶端程序竊取手機用戶的隱私信息。
3.2測試步驟
用將目標APK文件解包，命令如下；
java -jar .jar d -f apk文件路徑 -o 解包目標文件夾
圖5 解包后的APK資源目錄
隨便找一個解包目錄里的資源文件進行修改，推薦找到.png進行修改（容易確認結果）；將APK拖入,搜索.png，修改替換，，然后簽名打包回APK。
將簽了名的APK安裝、運行、確認是否存在自校驗；需要注意的是，如果之前安裝的APK和修改后的APK簽名不同，就不能直接覆蓋安裝，一般來說，先卸載之前安裝的APP即可。
注：APK必須進行簽名后，方可安裝和運行。如果開啟了“允許未知來源的應用”，那么Debug證書、自簽名證書、過期證書的簽名都是可以的dnf客戶端安全組件加載失敗 為更好的保障，但是不可以不簽名。
將客戶端程序文件反編譯，修改源碼或資源文件后重新打包安裝運行如果可運行，說明文件完整。
3.3威脅等級
若應用完整性校驗不使用.MF 中的數據，且核心代碼通過 JNI 技術寫入.so庫，同時于服務端進行相關校驗，此時無風險。
若應用完整性于本地進行驗證而不存在其他問題或使用 .MF 中的數據作為驗證憑證（有新文件時提示應用完整性驗證失敗），此時低風險；
若在本地進行驗證的基礎上只通過.MF 對客戶端原有文件進行校驗而忽略新增文件的檢驗，此時中風險；若未進行應用完整性校驗此時高風險。
3.4安全建議
建議客戶端在每次開機啟動時進行客戶端自身的應用完整性校驗，在驗證邏輯中不使用.MF中的數據作為驗證憑證，同時需驗證是否有不屬于該客戶端版本的新文件添加，驗證過程于服務器端完成。
第四章 組件安全4.1描述
本項主要測試客戶端是否包含后臺服務、 、第三方調用和廣播等組件， 權限的設置是否安全。應用不同組成部分之間的機密數據傳遞是否安全。檢查客戶端是否存在組件劫持風險，查看客戶端程序具有導出哪些應用信息的權限。反編譯APK文件后，檢查文件中是否有多余的:聲明，客戶端是否存在導出其他應用信息的權限等。
4.2名詞解釋
1.組件:安卓APP以組件為單位進行權限聲明和生命周期管理；
2.組件的作用：安卓系統的組件共有四種，其主要用途分別為：
：呈現可供用戶交互的界面，是最常見的組件；：長時間執行后臺作業，常見于監控類應用； ：在多個APP間共享數據，比如通訊錄數據； ：注冊特定事件，并在其發生時被激活；
3.權限聲明：安卓系統定義了許多權限聲明項，分別對應一些操作系統功能；
4.權限聲明的作用：如果一個APP或組件在沒有聲明權限的情況下就調用相關API，會被拒絕訪問；但如果聲明了相關權限，安裝的時候就會有提示；
5.組件導出：簡而言之，就是別的APP也可以訪問這個組件。
6.組件導出的作用：有些APP的功能需要提供一些接口給其它APP訪問，就需要把相關的接口功能放在一個導出的組件上。
7.組件導出的危害：因為權限聲明是以組件為單位的，A組件調用B組件的功能來訪問操作系統API時，適用于B組件的權限聲明。
如果B作為導出組件，沒有進行嚴格的訪問控制，那么A就可以通過調用B來訪問原本沒有聲明權限的功能，構成本地權限提升。
4.3測試步驟
4.3.3方案一：
使用解包，打開解包目錄中.xml，對其中聲明的各個組件，根據以下規則判斷是否可導出：
1.顯示聲明了:=”true”，則可導出；
2.顯示聲明了:=”false”，則不可導出；
3.未顯示聲明:：
a) 若組件不是Content Provider：
i. 若組件包含則可導出，反之不可；
b) 若組件是Content Provider：
i. 若SDK版本<17則可導出，反之不可。
從測試的角度上，只能判斷組件是否導出，但能否構成危害需要詳細分析源代碼后才能得出結論。一般來說，在測試時盡管寫清所有的導出組件，由客戶開發側確認相關組件是否確實需要導出即可。
圖6 安全的組件導出示例
由于功能需要，啟動和大多是導出組件，一般無須理會。如上圖的組件導出就是安全的。
4.3.4 方案二：
檢查 .xml 文件中各組件定義標簽的安全屬性是否設置恰當。如果組件無須跨進程交互，則不應設置 屬性為 true。例如，如下圖所示，當 的 屬性為 true 時，將可以被其他應用調用。（當有設置權限()時，需要再考察權限屬性。如 : 為 或 時，只有相同簽名的 apk才能獲取權限。
圖7 可調用的組件
可以使用“組件安全測試工具”來檢測組件的 屬性（有些應用在代碼中動態注冊組件，這種組件無法使用“組件安全測試工具”測試，需要通過閱讀代碼確定是否安全。
凡是列出來的組件都是 屬性為true 的。
當發現有可利用的組件導出時，（當然，并不是說所有導出的組件都是不安全的，如果要確定，必須看代碼，對代碼邏輯進行分析）可利用測試工具進行測試。
4.4威脅等級
若不存在組件暴露的情況，此時無風險。
如存在組件暴露的情況，但暴露的組件無關客戶端邏輯核心或不會泄露用戶敏感信息，此時低風險；若暴露的組件會泄露用戶敏感信息（例如郵件客戶端存在消息組件的暴露，攻擊者可以通過編寫 APK，通過組件利用的方式讀取用戶郵件信息）。
4.5安全建議
避免不必要的組件導出。
第五章 敏感信息安全5.1數據文件
5.1.1 描述
檢測客戶端是否保存明文敏感信息，能否防止用戶敏感信息的非授權訪問。
文件敏感信息泄露以明文存儲“記住密碼”居多。
5.1.2 測試步驟
首先查看相關文件的權限配置。正常的文件權限最后三位應為空（類似“rw-rw——”），即除應用自己以外任何人無法讀寫；目錄則允許多一個執行位（類似“—x”）。如下圖所示，（lib 子目錄是應用安裝時由 系統自動生成，可以略過）：
圖8 文件的權限
當客戶端使用 或 模式創建文件時， 目錄下文件的權限也會多出一些，這不一定是安全問題，如下圖（已不推薦使用這些模式）：
圖 9 不推薦的文件權限模式
權限檢測完整后，再檢查客戶端程序存儲在手機中的 配置文件，通常是對本目錄下的文件內容（一般是xml）進行檢查，看是否包含敏感信息。
使用數據庫查看工具即可查看這些文件中是否有敏感信息（等）。
還有些時候，客戶端程序 apk 包中也是是保存有敏感信息的，比如檢查 apk 包中各類文件是否包含硬編碼的的敏感信息等。如下圖APP的相關編碼信息：
圖10 包含敏感代碼的APK
5.2 威脅等級
根據敏感信息泄露的程度進行威脅等級評分。若私有目錄中存在存儲了用戶登陸密碼（明文或只進行過一次單項哈希散列），手勢密碼（明文或只進行過一次單項哈希散列）或曾經訪問過網址的 等敏感信息的文件，此時為高風險，若不存在則無風險。
5.3 安全建議
盡量避免在文件、數據庫、日志等位置寫入敏感信息。如果確實需要存儲，應當進行加密。對于內存中的信息泄露，可以通過反注入、反調試來解決。
此外，正常的文件權限最后三位應為空（類似“rw-rw——”），目錄則允許多一個執行位（類似“—x”）。
5.4 日志
5.4.1 描述
本項主要是檢查客戶端程序存儲在手機中的日志是否含有敏感信息。
5.4.2 測試步驟
將內存DUMP到SD卡，然后用adb到主機上查看。
使用adb工具連接設備：
adb //**查看安卓設備列表**adb -s **設備名稱 其它命令 //當連接了多個設備時，選擇操作的目標設備，否則會出錯**adb pull **手機目錄名 PC目錄名 //從安卓設備中復制文件到電腦中**
然后使用打開
圖11 查看遺留內存信息
這是查看內存遺留的信息，還可以直接使用adb查詢日志，在adb shell中，有下列命令可用：
//**持續輸出日志，直到Ctrl+C**-d //**一次性輸出日志緩存，不會阻塞**-c //**清空日志緩存**
5.4.3 威脅等級
根據敏感信息泄露的程度進行威脅等級評分。若相關信息中存在存儲了用戶登陸密碼（明文或只進行過一次單項哈希散列），手勢密碼（明文或只進行過一次單項哈希散列）或曾經訪問過網址的 等敏感信息，此時為高風險，若不存在則無風險。
5.4.4 安全建議
數據傳輸應做到加密處理，敏感信息不應輸出在日志中。
第六章 密碼安全6.1 鍵盤劫持
6.1.1 描述
測試客戶端程序在密碼等輸入框是否使用自定義軟鍵盤。安卓應用中的輸入框默認使用系統軟鍵盤，手機安裝木馬后dnf客戶端安全組件加載失敗 為更好的保障，木馬可以通過替換系統軟鍵盤，記錄手機鍵盤輸過的密碼。
6.1.2 測試步驟
通常來說，只有使用系統輸入法的編輯框才能夠進行鍵盤碼記錄。如果是自制的軟鍵盤，則可以嘗試進行觸摸屏記錄。不使用系統輸入法，且按鍵隨機分布的軟鍵盤是安全的。
6.1.3 威脅等級
能夠劫持鍵盤風險為高，不能則為無風險。
6.1.4 安全建議
盡量使用系統自定義的隨機軟鍵盤（而非系統輸入法）來輸入敏感信息。或者對層輸入記錄功能進行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 //bin/ -p 輸出png路徑（安卓設備中）
如圖：
圖12 截屏并生成文件
在/mnt//路徑下，可以看到1a.png：
圖13 生成的png截圖文件
打開：
圖14 瀏覽截屏圖片內容
攻擊者可以在用戶進入登錄頁面，在輸入密碼的同時，進行連續截圖，即可記錄用戶輸入的密碼。如果沒有防截屏，那么即使是隨機分布的、沒有視覺反饋的軟鍵盤也會被記錄：
還有一種驗證方式是從代碼方面進行驗證：
檢測需較高安全性的窗口（如密碼輸入框），看代碼中在窗口加載時是否有類似下圖的代碼。按照 SDK的要求，開啟 選項的窗口不能被截屏。
圖15 選項
6.3.3 威脅等級
當使用第三方程序（或系統截屏）可以對客戶端內容進行截屏時，為中風險；當客戶端會對截屏操作進行有效抵抗時（無法截屏或截屏結果為黑屏等無意義圖片）無風險。
6.3.4 安全建議
在敏感信息的輸入過程盡量避免視覺反饋，或者在操作系統層面對截屏相關功能進行Hook以阻止敏感信息輸入期間其它程序的截屏操作（需要root權限）。
6.4手勢密碼
6.4.1 描述
主要從手勢密碼的復雜度、修改和取消、本地信息保存、鎖定策略、抗攻擊測試等方面進行測試。
6.4.2 測試步驟
手勢密碼的復雜度：
進入客戶端設置手勢密碼的頁面進行手勢密碼設置。進行手勢密碼設置，觀察客戶端手勢密碼設置邏輯是否存在最少點位的判斷。反編譯 APK 為 jar 包，通過jd-gui觀察對應代碼邏輯是否有相應的判斷和限制條件。（一般設置手勢密碼若輸入點數過少時會有相應的文字提示，通過此文字提示可以快速定位到代碼位置）
手勢密碼的修改和取消：
進入客戶端設置手勢密碼的位置，一般在個人設置或安全中心等地方。進行手勢密碼修改或取消操作，觀察進行此類操作時是否需要輸入之前的手勢密碼或普通密碼。觀察在忘記手勢密碼等其他客戶端業務邏輯中是否存在無需原始手勢或普通密碼即可修改或取消手勢密碼的情況。多次嘗試客戶端各類業務，觀察是否存在客戶端邏輯缺陷使得客戶端可以跳轉回之前業務流程所對應頁面。若存在此類邏輯（例如手勢密碼設置），觀察能否修改或取消手勢密碼。反編譯 APK 為 jar 包，通過jd-gui觀察對應代碼邏輯，尋找客戶端對于手勢密碼的修改和刪除是否存在相應的安全策略。
手勢密碼的本地信息保存：
首先通過正常的操作流程設置一個手勢密碼并完整一次完整的登陸過程。尋找/data/data 的私有目錄下是否存在手勢密碼對應敏感文件，若進行了相關的信息保存，基本在此目錄下。（關鍵詞為 .key 等）若找到對應的文件，觀察其存儲方式，為明文還是二進制形式存儲，若為二進制形式，觀察其具體位數是否對應進行 MD5（二進制 128 位，十六進制32位或 16 位）、SHA-1（二進制 160 位，十六進制 40 位）等散列后的位數。如果位數對應，即可在反編譯的 jar包中搜索對應的關鍵字以迅速對應代碼。通過代碼定位確認其是否進行了除單項哈希散列之外的加密算法，若客戶端未將手勢密碼進行加密或變形直接進行散列處理可認為其不安全，一是因為現階段 MD5、SHA-1 等常用的哈希算法已被發現碰撞漏洞，二是網絡中存在 等散列值查詢網站可以通過大數據查詢的方式獲取散列前的明文手勢密碼。
手勢密碼的鎖定策略：
首先通過正常的操作流程設置一個手勢密碼。輸入不同于步驟 1 中的手勢密碼，觀察客戶端的登陸狀態及相應提示。若連續輸入多次手勢密碼錯誤，觀察當用戶處于登陸狀態時是否退出當前的登陸狀態并關閉客戶端；當客戶未處于登錄狀態時是否關閉客戶端并進行一定時間的輸入鎖定。反編譯 APK 為 jar 包，通過jd-gui觀察對應代碼邏輯，尋找客戶端是否針對輸入次數及鎖定時間有相應的邏輯處理。
手勢密碼的抗攻擊測試：
下載并安裝 框架及 插件。啟動客戶端并進入手勢密碼輸入頁。啟動 插件，觀察是否可以通過滑動關閉手勢密碼輸入頁的方式進入登陸后的頁面。
6.4.3 威脅等級
手勢密碼的復雜度：
當用戶設置或修改手勢密碼時服務器會對手勢密碼安全性（使用點數）進行判斷時無風險，否則低風險。
修改和取消：
當取消或修改手勢密碼時，如果不會驗證之前的手勢密碼則為中風險；若存在驗證則無風險。
本地信息保存：
當本地保存了明文存儲（數組形式）的手勢密碼時為高風險；當本地保存了只進行單項哈希散列的手勢密碼時為中風險。
鎖定策略：
當服務器不會驗證手勢密碼輸入錯誤次數時為中風險，會進行驗證時無風險。
抗攻擊測試：
若客戶端采用附著的方式將手勢密碼放置于登陸后的界面上時，如果無法抵抗 插件的滑動攻擊則高風險，如果可以抵抗則無風險。
6.4.4 安全建議
上述手勢密碼哪方面出現問題就根據哪方面的風險提出針對性的建議。
第七章 安全策略
安全策略在實際測試中受限較多，因此建議的風險等級：安全策略類全部為低危。
7.1 密碼復雜度檢測
7.1.2 描述
測試客戶端程序是否檢查用戶輸入的密碼強度，禁止用戶設置弱口令。
7.1.3 測試步驟
人工測試，嘗試將密碼修改為弱口令，如：，，， 等，查看客戶端是否拒絕弱口令。也可以閱讀逆向后的客戶端 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 測試步驟
觀察驗證碼組成，若簡單，可以嘗試使用的驗證碼識別工具進行識別：
圖16 驗證碼識別工具
7.8.3 威脅等級
當圖形驗證碼由本地生成而不是從服務器獲取時為中風險；當驗證碼安全性低或不存在驗證碼時為中風險；不存在以上兩個問題時無風險。
7.8.4 安全建議
加強驗證碼的識別難度，對于驗證碼的驗證做到“一次一驗”。
7.9 安全退出
7.9.1 描述
測試客戶端退出時是否正常終止會話。
7.9.2 測試步驟
檢查客戶端在退出時，是否向服務端發送終止會話請求。客戶端退出后，還能否使用退出前的會話 id 訪問登錄后才能訪問的頁面。
7.9.3 威脅等級
若客戶端退出登錄時不會和服務器進行的相關通信則為中風險，否則無風險。
7.9.4 安全建議
客戶端退出時要做到和服務器進行的相關通信。
7.10 密碼修改驗證
7.10.1描述
測試客戶端在修改密碼時是否驗證舊密碼正確性。
7.10.2 測試步驟
人工測試。
7.10.3威脅等級
當進行密碼修改時是否要求輸入原密碼已驗證其正確性，若需要輸入則無風險；如不需輸入原密碼則中風險。
7.10.4 安全建議
修改密碼需要驗證原密碼的正確性。
7.11 界面劫持
7.11.1 描述
檢查是否存在 劫持風險，確認客戶端是否能夠發現并提示用戶存在劫持。
7.11.2 測試步驟
安裝.apk，使用 界面劫持工具，在工具中指定要劫持的應用進程名稱。如圖所示，從列表中選擇被測試的應用，點擊 OK。打開應用，測試工具會嘗試用自己的窗口覆蓋被測的應用。
圖17 .apk劫持工具
如果劫持成功，會出現如下界面：
圖18 成功劫持
7.11.3 威脅等級
若客戶端無法抵抗 界面劫持攻擊時為中風險；若可以抵抗攻擊則無風險。
7.11.4 安全建議
劫持通常依靠注冊響應...事件。客戶端程序可以在啟動前檢查并報警；
由于界面劫持攻擊通常是將自己的頁面附著在客戶端之上，因此需要進行界面切換操作，因此在界面切換到后臺時彈出警告信息也可以達到一定的效果。
除此之外，因為進程棧的工作原理，建議開發客戶端時針對進程棧進行相應的保護，可禁止其他進程放置于客戶端之上。
第八章 進程保護8.1 內存訪問和修改
8.1.1 描述
通過對客戶端內存的訪問，木馬將有可能會得到保存在內存中的敏感信息（如登錄密碼，帳號等）。測試客戶端內存中是否存在的敏感信息（賬號、明文密碼等等）。
8.1.2 測試步驟
需要 root 權限，可以使用 查看、搜索和修改客戶端內存數據。用戶名、密碼等數據通常會在/dev//-heap 內存段。（目前大多數工具都是通過接口修改客戶端內存，可以使用 機制本身防護。）
8.1.3 威脅等級
當進行敏感操作后在內存中可以搜索到用戶輸入的敏感信息時為高風險，否則無風險。
8.1.4 安全建議
對于內存中的信息泄露，可以通過反注入、反調試來解決。
8.2 動態注入
8.2.1 描述
通過注入動態鏈接庫，hook 客戶端某些關鍵函數，從而獲取敏感信息或者改變程序執行。
8.2.2 測試步驟
使用工具動態注入應用進程內存。 或者使用 hook 框架來進行測試。
8.2.3 威脅等級
當客戶端存在動態注入隱患時高風險，否則無風險。
8.2.4 安全建議
防止應用程序被Hook。
第九章 通信安全9.1 通信加密
9.1.1 描述
如果客戶端與服務器之間的通信加密協議實現不當，攻擊者將有機會對當前網絡環境中其他合法用戶的通信內容進行竊聽甚至篡改。
9.1.2 測試步驟
為了對服務器端進行測試，至少要先弄清楚客戶端與服務器的通信協議。
一般來說，有以下三種情況：