行動應用程式是否未針對其他行動應用程式或行動作業系 統之檔案,在未授權情況下,嘗試進行查詢、新增、修改、刪 除、存取遠端服務、提權等行為
行動應用程式是否未包括可導致行動作業系統,發生未預 期錯誤、資源明顯耗損、重新啟動或關閉等行為
檢測中心一般會使用防毒軟體,或黑箱掃描工具進行檢測
另外如果App 功能剛好被測試到閃退,這一項也會不符合要求
檢查行動應用程式是否不存在已知安全性漏洞
可使用 CVE Details (註) 查詢App 是否已被通報有安全漏洞
註:CVE 為漏洞披露(Common Vulnerabilities and Exposures,CVE)CVE Details平台
內涵了目前所有的漏洞,編號,可以使用漏洞ID 或產品進行搜尋,是否有無漏洞
https://www.cvedetails.com/index.php
行動應用程式引用之函式庫是否不存在已知安全性漏洞
App使用套件可逐項 使用 CVE Details 查詢是否漏洞
圖為 使用 CVE Details 查詢 FREAK顯示關於open_ssl 漏洞
行動應用程式是否針對預期使用者輸入之字串驗證型別, 如欄位本身須要接受特殊字元,亦屬於可預期的輸入字串型別
行動應用程式是否針對使用者輸入字串驗證長度。
所有輸入欄位長度一定要在前端限制長度,且都要驗證格式
APP 欄位期待輸入數字,但輸入文字或其他特殊符號,就需要阻擋下來
檢驗輸入不能只在後端,一定要放在App 端
此項為檢驗時最容易遇到不符合的項目
是否防護使用者輸入 SQL Injection 字串之設計
式是否防護使用者輸入 JavaScript Injection 字串之設計
是否防護使用者輸入 Command Injection 字串之設計
是否防護使用者輸入 Local File Inclusion 字串之設計
是否防護使用者輸入 XML Injection 字串之設計
是否防護使用者輸入 Format String Injection 字串之設計
是否防護使用者輸入 IPC (Inter process communication) Injection 字串之設計
輸入欄位都會被測試注入字串測試
除了加強格式檢核,長度檢核 (4.1.5.4.1 行動應用程式使用者輸入檢查)
還可以使用字元轉換,加入跳脫符號等都是不錯的防護方式
行動應用程式開發者提供應用程式雜湊值(Hash),供使用者驗證行動應用程式之完整性
採用混淆(Obfuscation)技術,保護行動應用程式商業邏輯
如果大家還有印象的話,我們在Day5 談論文件時候有聊到這一個項目
這一項目不會檢驗,但難度相當之高
後面的章節會聊到怎麼混淆程式碼,混淆後有什麼缺點跟優點
有興趣的讀者可以期待一下,期待寫的有多爛