OWASP 類別： MASVS-PLATFORM：平台互動
總覽
許多行動應用程式會使用外部 API 提供功能。傳統上，應用程式會使用靜態權杖或金鑰向服務進行驗證。
不過，在用戶端/伺服器設定 (或行動應用程式和 API) 的情況下，使用靜態金鑰通常不算是存取機密資料或服務的安全驗證方法。與內部基礎架構不同，只要有權存取這個金鑰，任何人都能存取外部 API 並濫用服務。
舉例來說，靜態金鑰可能會遭到應用程式反向工程，或在行動應用程式與外部 API 通訊時遭到攔截。這個靜態金鑰也較有可能在應用程式中經過硬式編碼。
如果未使用足夠安全的驗證和存取權控管措施，API 資料和服務就會面臨風險。
使用靜態金鑰時，API 可能會遭到濫用，因為攻擊者可以重送要求，或使用 (攔截或反向工程) 金鑰建構新要求，且不受時間限制。
影響
如果開發人員付費使用 AI 或 ML API 服務，攻擊者相對容易竊取這組金鑰，並在服務中累積債務，或用來建立虛假內容。
API 中儲存的任何使用者資料、檔案或 PII 都會公開，導致資料外洩。
攻擊者也可能利用這項存取權進行詐欺、重新導向服務，以及在極少數情況下，完全掌控伺服器。
因應措施
具狀態 API
如果應用程式提供使用者登入功能或可追蹤使用者工作階段，建議開發人員使用 Google Cloud 等 API 服務，與應用程式進行有狀態整合。
此外，請使用 API 服務提供的安全驗證、用戶端驗證和工作階段控制項，並考慮使用動態權杖做為靜態金鑰的替代方案。請確保權杖會在合理的時間內失效 (通常為 1 小時)。
然後使用動態權杖進行驗證，以存取 API。這些指南說明如何使用 OAuth 2.0 達成這個目標。除了上述規範，您還可以實作下列功能，進一步強化 OAuth 2.0，減少 Android 應用程式中的安全漏洞。
導入適當的錯誤處理和記錄機制：
- 妥善處理 OAuth 錯誤，並顯示錯誤訊息，同時記錄錯誤以利偵錯。
- 縮小攻擊面也有助於找出及排解可能發生的問題。
- 請確保記錄或向使用者顯示的任何訊息都清楚明瞭，但不會包含對攻擊者有用的資訊。
在應用程式中安全地設定 OAuth：
- 將
redirect_uri參數傳送至授權和權杖端點。 - 如果應用程式使用 OAuth 搭配第三方服務，請設定跨源資源共享 (CORS)，限制應用程式資源的存取權。
- 這有助於防範未經授權的跨網站指令碼 (XSS) 攻擊。
- 使用 state 參數防止 CSRF 攻擊。
使用安全程式庫：
如需其他驗證方式 (包括 Firebase 和 Google ID 憑證) 的說明，請參閱 OpenAPI 說明文件。
無狀態 API
如果 API 服務未提供上述任何建議的保護措施，且需要無狀態工作階段，但使用者未登入，開發人員可能需要提供自己的中介軟體解決方案。
這會涉及在應用程式和 API 端點之間「Proxy」要求。其中一種方法是使用 JSON Web Token (JWT) 和 JSON Web Signature (JWS)，或是提供先前建議的完整驗證服務。這樣一來，您就能在伺服器端 (而非應用程式/用戶端) 儲存容易遭到攻擊的靜態金鑰。
在行動應用程式中提供端對端無狀態解決方案，會產生許多問題。其中最關鍵的挑戰包括驗證用戶端 (應用程式)，以及在裝置上安全地儲存私密金鑰或密鑰。
Play Integrity API 可驗證應用程式和要求的完整性。這有助於防範濫用存取權的行為。至於金鑰管理，在許多情況下，金鑰儲存區是安全儲存私密金鑰的最佳位置。
部分行動應用程式會在註冊階段檢查應用程式完整性，並透過安全交換提供金鑰。這些方法相當複雜，不在本文的討論範圍內。不過，雲端金鑰管理服務可能就是解決方案。