手機應用程序開發者安全檢查表 (上)
一. 基本原理
(一) 身份驗證和訪問控制
這是一個通用要求，什麼被認為是足夠的將取決於上下文和監管環境。建議為企業應用程序使用六字符字母數字密碼，因為它們可以提供足夠的保護來抵禦暴力攻擊。例如，在 iOS 中，六位字母數字密碼需要 1.7 年的蠻力破解時間，而四位 PIN 碼可以在 40 分鐘內猜到。
但是，例如，許多銀行應用程序提供四位 PIN 碼，並且許多應用程序支持在較新的設備上進行生物識別身份驗證。基於指紋的用戶身份驗證比四位密碼強，但不強於六位字母數字密碼。在這種情況下，組織決定吸收產品中的殘餘風險。在這些情況下，最佳做法是將設備與手機應用程序緊密連接。這種做法稱為設備綁定。有多種方法可以執行設備綁定，通常涉及使用設備標識符來連接設備。
2. 不可變設備標識符，例如唯一設備 ID (UDID) 和國際移動站設備標識 (IMEI)，不得用作憑證
儘管使用唯一設備標識符 (UDID) 執行設備綁定是最佳實踐，但手機應用程序使用設備標識符作為安全憑證是一個常見的陷阱。標識符不被視為秘密，因此，它們不能用作密碼或身份驗證憑證。iOS 和 Android 越來越難以利用這些標識符，並提供替代方法來允許應用程序使用的標識符被派生。
3. 應用程序應相互驗證用戶和服務器
App 身份驗證通常理解為手機客戶端需要向服務器進行身份驗證。但是，調整和重新發布應用程序，將身份驗證重定向到惡意服務器（命令和控制中心）是一種常見的攻擊。因此，為避免惡意服務器攻擊，服務器還必須向手機客戶端驗證自身。
客戶端和服務器應正確驗證傳輸層安全 (TLS) 或類似證書
此特定建議假定應用程序正在利用安全通訊端層 (SSL)/傳輸層安全性 (TLS) 或其他協議。在整個研究中，我們假設 TLS 或 SSL 被用作安全傳輸協議。如果有安全協議，也可以使用其他協議。無論選擇哪種協議，都必須驗證證書。不驗證允許中間人攻擊的 TLS 證書是一個常見的錯誤。（在所有這些研究中，我們指的是 TLS，而不是舊的 SSL。）
通過驗證證書，手機客戶端驗證憑證的來源是否合法。通常，TLS 證書驗證包括驗證證書的簽名。
投標攻擊利用客戶端和服務器之間的協商階段來削弱應用程序的防禦。例如，如果服務器支持三種加密類型，受感染的客戶端可能會假裝只支持三種加密類型中最弱的一種，以試圖進一步破解加密。
通常，防止投標攻擊的最簡單方法是淘汰易受攻擊的協商選項。在 TLS 剝離的特定情況下，降級攻擊包括將連接從安全連接 (HTTPS) 降級到 HTTP 連接。這在基於 Web 的攻擊中尤為常見，也適用於基於 WebView 和混合應用程序。實施 HTTP 嚴格傳輸安全 (HSTS) 使得在客戶端/服務器通信時始終強制執行 HTTPS。iOS 中的應用程序傳輸安全 (ATS) 等功能使開發人員越來越容易遵循此指南。
固定證書包括僅接受特定證書，而不是驗證證書的一般有效性。傳統驗證在某些情況下仍然適用，例如與各種服務器進行交互的情況（請參閱上面對 TLS 證書驗證的要求）。
證書鎖定用於防止中間人攻擊和欺詐性證書，對於內部開發的應用程序特別有用，其中服務器的身份已經建立。
(二) 數據保護
這個錯誤是手機應用程序開發中最常見的錯誤之一。應用程序中寫死的密鑰、密碼、密碼和憑據很容易被下載應用程序並對其進行逆向工程的攻擊者竊取。有幾種寫死密碼的替代方法。一個範例是註冊和部署可用作身份驗證材料的證書。
為避免對憑證（例如密鑰）進行寫死，它們應從動態設置的值中派生。一種簡單的方法是利用用戶密碼（如果使用密碼對應用程序進行身份驗證）。一個簡單的密碼會削弱加密密鑰，因此使用的密鑰材料應該包含與密鑰無關的其他值。
靜止數據應受到保密保護。移動設備提供設備級加密。應用程序級加密由操作系統本地提供或由應用程序提供。具有非常高安全要求的實體（通常是垂直行業，例如政府、國防，以及根據上下文，醫療保健、金融和保險）可能會選擇使用獨立加密，而大多數其他應用程序可以使用本機機制。
使用操作系統原生加密機制加密應用程序數據時，必須確保使用適當的保護級別。例如，在使用 iOS 默認加密時，應使用 NSFileProtectionComplete。此類將在設備鎖定時保持文件加密，以防被盜或丟失。在這種情況下，加密強度部分取決於設備密碼的複雜性。因此，開發人員應該記住，較弱的密碼將導致較弱的保護。在面向消費者的應用程序中，應用程序的發布者無法控制密碼的強度。但是，在企業對員工 (B2E) 環境中，組織可以通過策略強制執行此操作，並要求密碼具有足夠複雜性（建議使用六字符字母數字密碼）。
大多數手機應用程序使用 TLS 作為傳輸安全協議，為動態數據提供加密。在大多數情況下，這足以作為保護動態數據的措施。定制解決方案可能會使用專有方法通過加密隧道或其他機制對動態數據進行加密。
5. 敏感數據（包括身份驗證憑據）應加密，即使儲存在鑰匙串中
什麼是敏感數據取決於上下文和特定的監管環境。開發安全應用程序的一個基本部分是識別敏感數據。該數據必須進行加密並格外小心地處理（例如，該數據不應被導出，如清單中的其他項目所述）。
在 iOS 和 Android 中，有鑰匙串機制，它們是安全的儲存空間，用於儲存憑據（例如密碼、密鑰和證書）。在鑰匙串中，可以在本地施加幾個級別的安全性。例如，在 iOS 中，設置 kSecAttrAccessibleAlways 允許始終訪問鑰匙串中的數據，而 kSecAttrAccessibleWhenUnlocked 允許僅在用戶解鎖設備時訪問鑰匙串中的數據。應謹慎選擇這些設置，並應具有最大的安全性。
但是，即使正確設置了這些設置，憑據也可以而且應該為高安全性應用程序提供保護。例如，iOS 設備中的鑰匙包儲存用於保護鑰匙串項目的鑰匙。
用於保護憑證的本機平台資源的替代方法是白盒（或白盒加密）。此方法包含在其自己的代碼中隱藏和保護敏感應用程序數據的技術。
6. 手機應用程序應通過iOS的自動快照功能和類似機制防止敏感數據洩漏
為了促進多任務處理，iOS 提供了應用程序的快照。這允許用戶在不訪問應用程序本身的情況下查看應用程序螢幕。在決定下一步選擇和使用哪個應用程序時會很方便，但它可能導致數據洩漏。有一種方法可以混淆應用程序螢幕並只顯示應用程序的名稱。包含敏感數據的應用程序應遵循此方法。
Android 設備上提供了一個類似的功能，即概覽螢幕；但是，我們尚未確定是否可以類似地混淆螢幕截圖。
7. 移動應用程序不得將敏感數據儲存、共享或黏貼到可移動或共享媒體和外部資源上
此建議將取決於特定用例。除非絕對必要，否則不得利用無法控制和監控的外部媒體。在無法避免的情況下，數據應以加密形式儲存。
敏感文本輸入（例如密碼）的自動完成會導致敏感數據被緩存並在用戶嘗試登錄時作為選擇提示。這是 Web 和移動應用程序的常見陷阱，應該避免。
9. 退出應用程序後應最小化並刪除緩存數據（例如，HTTP、相機圖像和 GUI 對象）
特別是對於混合和移動 Web 應用程序，一個主要問題是如何保護緩存內容。有一些內置方法，但所選方法的安全性通常取決於用戶是否在設備上設置了足夠複雜的密碼。因此，建議盡量減少儲存的數據，避免緩存敏感數據並在不再使用數據時將其刪除。
10. 敏感數據不得儲存在設備上的 SQLite 數據庫中；如果不可避免，應使用工具對數據庫進行加密
應避免緩存數據（請參閱上一個項目）。但是，在某些用例和應用程序中，這是不可避免的。在這些情況下，最好的選擇是將數據儲存在 SQLite 中並對其進行加密。在這些情況下常用的工具是 SQLCipher。
11. 通過鍵盤記錄的數據不得包含憑據、財務信息或其他敏感數據
iOS 鍵盤緩存用戶提供的項目。這樣做是為了幫助自動完成和更正功能。但是，敏感數據在設備上緩存時會面臨風險，超出了應用程序後端的控制範圍。Gartner 建議在輸入憑據或財務信息等敏感數據時禁用緩存。
Android 與此類似，提供了一個用戶字典，其中記錄了輸入的單詞和術語。要禁用緩存，可以實現自定義鍵盤。對於需要高安全性的選定設備，可以利用可信執行環境中可用的可信用戶界面。
12. 密碼學的強度和密鑰長度應符合 FIPS 140-2 批准的安全功能
FIPS 140-2 認證的加密是特定行業和國家/地區的監管要求。但是，遵循 FIPS 140-2 中所謂的“批准的安全功能”是一種很好的做法。這是因為安全算法會隨著時間的推移而過時。計算能力變得強大到足以破解某些較短密鑰的算法，研究人員有時會發現使算法易被破解的漏洞。
