使用者身份的基本安全檢查清單
建立使用者身份是任何應用程式的重要組成部分。驗證用戶名和密碼看似最簡單的方法,但還有許多其他方面需要考慮。
介紹
建立使用者身份是任何應用程式的重要組成部分。這使你能夠提供個性化體驗、提升數據質量,並改善使用者留存率。
驗證用戶名和密碼看似最簡單的方法,但還有許多其他方面需要考慮。讓我們開始吧!
基礎架構
強制使用 HTTPS
讓我們從基礎開始。始終強制使用 HTTPS(超文本傳輸協定安全)加密互聯網上的數據傳輸。HTTPS 確保使用者設備與你的伺服器之間交換的數據保持機密和防篡改。
設置 HTTPS 可能看似具有挑戰性,但有很多工具和服務可幫助你:
- 如果你自行託管,Let's Encrypt 提供可用來在你的網站上啟用 HTTPS 的免費 SSL/TLS 憑證。
- 如果你使用的雲提供商(如 AWS、Azure 或 Google 雲),你可以使用他們的管理服務設置 HTTPS。
不允許公共資料庫訪問,僅限於信任來源
儘管這似乎也很基礎,但由於允許公共訪問資料庫而發生了很多安全漏洞,因此值得在此提出。
始終記住,絕不要允許公共訪問你的資料庫。將你的資料庫放在私有網絡中,僅允許來自信任來源的訪問。
安全管理私人令牌
私人令牌,如訪問令牌或 API 金鑰,通常用於編程認證和授權目的。要安全地管理這些令牌:
- 使用短期令牌和刷新令牌,以最大限度降低未經授權訪問的風險。
- 使用安全的令牌存儲機制,如金鑰保管庫,以防止未經授權的訪問。
- 定期旋轉令牌,以防止被破解。一些協議,如 OAuth 2.0,提供令牌輪換機制。
- 控制令牌撤銷,以防安全漏洞。
明智地選擇密碼哈希算法
如果你有密碼哈希方面的經驗,可能知道有很多算法可用,其中一些不再被視為安全,如 MD5、SHA-1 和 SHA-2。
它們不安全的常見原因有:
- 它們並非專為密碼哈希設計,計算速度太快,使得暴力攻擊更容易。
- 缺乏鹽的使用,使得為其創建彩虹表更容易。
- 易受碰撞攻擊,使攻擊者能夠生成不同的密碼但具有相同的哈希值。
業界標準的密碼哈希算法,如 bcrypt 和 Argon2,已被設計為解決這些問題。由於本文的範圍有限,我們不會詳細討論這些問題。請查看密碼哈希的演變以了解更多資訊。
學習並嚴格遵循開放標準
開放標準如 OAuth 2.0 和 OpenID Connect(OIDC)提供了安全和標準化的用戶認證和 授權方法。它們經過戰鬥檢測並被行業廣泛採用。
但是,實施不當可能會導致安全漏洞,即使對於擁有經驗豐富開發人員的大型團隊也是如此。最近的一個例子是 Expo 中發現的 OAuth 漏洞,這是一個用於構建移動應用的流行框架。它是一個很好的例子,說明了一個小錯誤如何導致安全漏洞。
加密靜態數據
靜態數據,如存儲的用戶信息或資料庫備份,應使用強加密算法進行加密。這確保即使數據被泄露,也無法在沒有解密金鑰的情況下閱讀。請仔細檢查你的雲提供商是否支持此功能,因為這通常是合規要求。
設置防火牆
DDoS(分佈式拒絕服務)攻擊,雖然古老,仍然是重大威脅。根據 Cloudflare 2022 年第四季 DDoS 威脅報告,HTTP DDoS 攻擊流量同比增長 79%。與其建立自己的解決方案,不如設置托管防火牆並使用通知器來減輕這一風險。
應用和客戶端
提高公共客戶端的安全級別
公共客戶端,如移動應用或單頁應用,對安全漏洞更敏感。即使你提供它們,你也應該將它們視為安全模型中的不信任來源。例如:
- 如果你使用 OAuth 2.0,使用驗證碼交換的證明密鑰(PKCE)來防止授權碼攔截攻擊。
- 強制執行內容安全政策(CSP),以減輕某些類型的攻擊,包括跨站腳本(XSS)和數據注入攻擊。
永不信任公共輸入數據
用戶輸入可能是安全漏洞的重要來源,常常被忽視。一些常見的被忽視的漏洞類型是跨站腳本(XSS)和SQL 注入。確保在使用所有用戶輸入數據之前進行驗證和清理。
跟踪活動
維護用戶活動的審核軌跡有助於檢測和調查安全事件。記錄並監控用戶操作,如登錄嘗試、密碼更改或敏感操作。分析這些日誌可以為潛在的安全漏洞或可疑活動提供有價值的見解。
實施堅實的認證
實施強大的認證機制來驗證用戶身份。如前所述,可以考慮使用安全協議如 OAuth 2.0 或 OpenID Connect 進行認證。更多資訊可以參考 CIAM 101: 認證、身份、SSO。
構建堅實的授權(例如,實施基於角色的訪問控制)
除了認證,還需有適當的授權機制。實施基於角色的訪問控制(RBAC),以確保用戶只能訪問他們被授權執行的資源和操作。更多資訊可以參考 CIAM 102: 授權與基於角色的訪問控制。
實施多因素認證(MFA)
多因素認證(MFA)通過要求用戶提供一種或多種形式的身份驗證,增加了一層安全性,如密碼和發送到其移動設備的一次性代碼。另一個 MFA 的好例子是當 GitHub 要求用戶在執行敏感操作(如刪除存儲庫)時輸入其移動應用上的一次性代碼,該代碼也顯示在網頁上。
不過,對於大多數早期的初創企業來說,擁有 MFA 並不是必需的,特別是如果你沒有現成的解決方案。可能過於繁瑣,並對用戶體驗產生負面影響。
文化
以上建議主要覆蓋了 "被動" 安全措施,這些是在發生安全事件之前所知的。然而,你也可以採取 "主動" 安全措施來改善整體安全姿勢,這在長期來看更為有效。
教育你的團隊和用戶有關網絡釣魚和社會工程學
網絡釣魚攻擊和社會工程學是關鍵,因為它們可以使上述許多安全措施變得無效。例如,如果用戶被騙提供他們的密碼或點擊看似無害的貓圖片而實際上包含惡意代碼,那麽你的密碼哈希算法或防火牆規則的強度就變得無關緊要。
大多數人覺得安全培訓很無聊,通常確實如此。所以,改變你教導團隊和用戶的方式。例如,你可以在真正的攻擊者之前模擬一次網絡釣魚電子郵件,並演示如何識別它。你甚至可以提供獎勵給報告該電子郵件給安全團隊的人。
設置 DevSecOps
除了手動安全審查外,你還可以實行 DevSecOps 實踐來自動化安全檢查。例如,你可以設置 CI/CD 管道來運行靜態代碼分析工具,如 CodeQL,並使用工具如 OWASP ZAP 自動進行滲透測試。
擁抱最嚴格的配置,而不影響用戶體驗
在安全方面,始終選擇不會對用戶體驗產生負面影響的最安全配置。避免走捷徑或為了方便而妥協安全。安全應始終是首要任務。
作為一家初創公司或個人開發者,你可能覺得缺乏必要的資源來實施這些措施。儘管如此,市場上有專業安全服務提供免費或對初創友好的選項。花些時間審查並考慮利用它們。
總結
安全是一個複雜的話題,無法在一篇文章中涵蓋所有內容。我們希望這篇文章能幫助你或你的團隊建立更強的安全意識。如果你正在構建一個新的應用,你可能也想看看 Logto,這是一個幫助你輕鬆開發、管理和保護產品用戶身份的平台。