手機應用程序開發者安全檢查表 (下)
一. 基本原理
(一) 會話(Session)管理
1. 會話超時應具有合理的值且可配置
這是取決於上下文的通用要求。
2. 會話終止或意外終止時應刪除會話數據
應用程序操作的異常終止可能會使數據被暫存。因此，在應用程序崩潰或意外終止的情況下，應該預見到所有會話數據都將被刪除，即使應用程序最初構建為不儲存任何敏感數據。
3. GET命令不得用於查詢敏感數據；POST命令應該優先於HTTPS
在處理 Web 程式碼時，使用 POST 請求而不是 GET 請求來查詢敏感數據更安全。即使使用 TLS，GET 請求也可以在不受保護的位置記錄在應用程序控制之外的位置，例如瀏覽器歷史記錄。
(二) 錯誤處理和記錄
1. 應用程序不得在系統日誌或文件系統上記錄敏感數據
不得記錄通行碼、密碼和其他憑據等數據，以及標識符、姓名、電話號碼和付款訊息等私人訊息。這可以防止可能試圖操縱應用程序以恢復此訊息的攻擊者。
2. 崩潰和偵錯日誌不應包含敏感數據
崩潰期間儲存的記錄數據通常發送到服務器或儲存在應用程序中，用於發現應用程序中的錯誤。該數據不應包含敏感數據，例如密碼、密碼和其他憑據，以及私人訊息，例如標識符、姓名、電話號碼和付款訊息。
(三) 權限
1. 授予應用程序的權限和資源（即 AndroidManifest.xml、iOS Entitlements）應僅限於應用程序需要運行的內容（如果重複使用第三方程式碼，這也適用於第三方程式碼）
通常情況下，應用程序請求的權限和訊息訪問權限比它們實際運行所需的要多。這使得該應用程序成為攻擊者的目標，攻擊者可能試圖利用該應用程序的權限來獲取對用戶私人訊息的訪問權限。應用程序有時會以比所需更多的權限運行，因為開發人員會在他們的應用程序中重用現有的資料庫。預設情況下，這些資料庫通常會請求某些權限。
開發人員應確保他們的程式碼和他們利用的外部資料庫不會請求不必要的權限。
作為一個具體的例子，在Android中，MODE_WORLD_WRITEABLE 和 MODE_WORLD_READABLE 模式允許訪問任何應用程序，以及任何數據格式。這可能會導致惡意應用程序訪問敏感數據。因此，Android 應用程序不得創建具有 MODE_WORLD_READABLE 或 MODE_WORLD_WRITABLE 權限的文件。
(四) 篡改保護
1. 不得採用 Method Swizzling（在極少數情況下，需要使用 Swizzling 時，必須提供並記錄針對漏洞的徹底安全測試）
Method swizzling 是某些開發人員在 iOS Objective-C 和 Swift 應用程序中使用的技術（在較小程度上，在 Android Java 應用程序中）。Swizzling 本身並不是惡意的，可以提供一定的性能優勢；但是，如果使用不當，可能會導致安全問題。使用 iOS 應用程序的 Swizzling 包括動態重定向方法調用。這種動態性使攻擊者可以重定向到惡意方法，而不是預期的方法。
2. 使用的第三方資料庫應經過測試和驗證，沒有漏洞和惡意程式碼
開發人員傾向於使用可以支持他們希望在應用程序中具有的功能的第三方資料庫。這些第三方資料庫通常是應用程序漏洞的主要來源，可能是因為它們沒有被正確編寫，或是因為它們擁有過多的權限。應使用信譽良好的 API，並在使用前對其進行驗證，以驗證它們不是惡意的，且不會引入任何漏洞。
3. 應用程序應使用伺服器端檢查，不應依賴客戶端檢查可被操縱以竊取訊息或危害應用程序的功能
如果驗證用戶身份或應用程序完整性等檢查由駐留在移動應用程序上的客戶端負責，則存在攻擊者可能危及客戶端並繞過這些控制的風險。
4. 該應用程序應盡量減少與其他應用程序的通訊並在這樣做時採取適當的措施
為與第三方應用程序自由共享數據而編寫的應用程序可能是洩漏來源，因為它們可能會被攻擊者利用。因此，如果應用程序不打算共享數據，則應將其鎖定。例如，在 Android 中，不共享數據的應用程序應在應用程序清單中報告 android:exported="false"。如果應用程序旨在與其他應用程序共享數據，則應採取預防措施。在同一個Android示例中，如果採用企業應用之間的共享，則應選擇android:protectionLevel“signature”，以便系統檢查兩個應用是否使用相同的證書進行簽名。
5. 對於敏感數據，應避免使用不使用時無法覆蓋的不可變結構，而應首選可變結構
不可變對像只能寫入一次，不能被清除。這不僅不方便，而且在處理敏感數據時可能很危險。
6. 該應用程序不應支持 Android 的隱式意圖
Android 編程中的意圖是對應用程序可以執行的操作的描述。有兩種可能的方法來解析意圖：顯式和隱式。隱式意圖不以顯式方式指定目標組件（例如，數據的應用程序接收者）。在這種情況下，為了識別接收者，Android 會利用組件過濾器將意圖的內容與潛在的接收者組件進行比較。
自 Android 5.0 以來，Android 平台一直在消除隱式意圖的選項，因為惡意應用程序可以將自己偽裝成能夠接收和處理來自隱式意圖的數據的應用程序。訊息只能以明確的意圖發送到 Android 系統的其他組件。
7. 應用程序應使用地址空間佈局隨機化 (ASLR)，如果可用
地址空間佈局隨機化 (ASLR) 是大多數現代移動設備支持的功能。這種隨機性使攻擊者更難利用該應用程序。
8. 應用程序應驗證收到的所有輸入
輸入驗證包括驗證應用程序中的數據輸入是否符合預期的格式和長度。這避免了許多最常見的攻擊技術，例如緩衝區溢出。這些技術試圖利用輸入驗證的缺乏來發送可以執行不需要的操作的不可預見的輸入。
在已註冊 URL 方案的 iOS 應用程序的特定情況下，它應從 URL 所接收的輸入做驗證。它應該只能接收特定的輸入，以避免目錄遍歷、緩衝區溢出和其他類似的攻擊。
9. 應用程序應有必要的措施來避免競爭條件
競爭條件出現在對特定條件進行控制以導致應用程序採取行動的情況下。典型的控制可以是在獲取特定文件或特定訊息之前驗證用戶是否有權請求它。當對一個應用程序或一個用戶執行控制，但資源被另一個應用程序或用戶訪問時，就會發生競爭條件。攻擊者可以利用它未經授權訪問資源。
在共享預期資源的地方，競爭條件不僅僅取決於特定的應用程序。但是，開發人員可以採取一些預防措施來最大程度地降低競爭條件的風險。預防措施取決於具體情況。在處理可以覆蓋的臨時文件時，典型的預防措施是確保存在同名的臨時文件。另一個典型的操作是在預期操作期間鎖定資源。
10. 應用程序應能夠檢測權限提升條件，包括越獄/Root和解鎖引導加載程序
這是 A 類應用程序的要求和 B 類應用程序的建議。這些類型的檢查習慣性地委託給勞動力設備上的企業移動管理 (EMM) 工具，而它們由應用程序本身在面向消費者的應用程序中使用。
這些是在應用程序運行之前或期間執行的檢查，並以資料庫的形式出現。最常見的檢查形式是檢測 Android root或 iOS 越獄。用於檢測這種做法的各種技術包括尋找設備上是否存在 Cydia（一種用於越獄 iOS 設備的流行應用程序）。另一個控制可能是應用程序未在調試器中運行。
這種性質的控件可能被視為侵犯隱私，因為它們在應用程序的邊界之外進行調查。應用程序的協議條款（或企業應用程序的移動策略）應反映這一點並通知用戶。
處理這些檢查的方式將取決於上下文。在高安全性 B2E 情況下，終止應用程序可能是可以接受的，但面向客戶的應用程序應使用此訊息根據風險對用戶進行分類，而不是拒絕服務。
11. 應用程序應檢查妥協指標
移動平台一直為開發人員提供工具來檢查設備的狀態，而不僅僅是檢查越獄/Root檢測。儘管該功能主要與 Android 相關，但主要的活躍威脅在 Android 中。
開發人員應該利用 Android 平台中的這種內置功能來確保設備運行的環境不會受到損害。一些示例包括檢查設備上是否存在惡意軟體、驗證設備是否為機器人以及對設備上的入侵指標進行全面檢查。
12. 應用程序程式碼應被混淆
混淆通常用於面向消費者的應用程序和具有敏感數據或知識產權的應用程序。某些商業應用程序商店也會向應用程序添加自己的混淆。
程式碼混淆會打亂程式碼，使攻擊者更難理解應用程序在做什麼。例如，這可以通過重命名可能洩露應用程序功能的類來實現。
混淆使應用程序更難受到攻擊，是一種勸阻措施。但是，只要有足夠的時間和精力，就可以繞過混淆保護，開發人員應確保混淆不會取代，而是增強本清單中考慮的所有其他安全保護。
(五) 生命週期
1. 應從應用程序容器中刪除所有測試數據（.ipa、.apk 等）
有時，開發人員會忽略從應用程序中刪除測試數據。例如，在測試期間，開發人員有時會允許某些操作（例如，按鍵序列）繞過身份驗證，以便能夠快速測試多組數據。這些構成生產應用程序中的漏洞，應事先將其刪除。
2. 在最終的應用程序中不應設置Debug標誌
可以禁止偵錯器與應用程序交互。這使得攻擊者更難對應用程序進行逆向工程並了解後台進程。
3. 應用程序應通過應用程序安全測試
這是一個通用要求。手機應用安全檢測揭示了可能被駭客利用或無意中洩露敏感訊息的漏洞。此工具包中的安全檢查表提醒開發人員要避免的陷阱，但仍不能取代測試。
