頭條楓林網
文章摘要： 可以向任意郵箱傳送驗證 郵箱直接傳送明文原密碼（後臺明文存密碼） 郵箱修改密碼連結可以修改使用者 ID、登入賬號等資訊（直接明文或做了簡單編碼或雜湊） 越權修改其他使用者密碼 使用手機號找回手機驗證碼爆破 簡訊介面濫用 未驗證手機號有效性 越權修改其他使用者密碼 客服找回 社工 2.6 會話管理風險 常見
1 使用者認證模組功能介紹
1.1 註冊
就是在系統裡建立一個新賬號，目前常見的方式使用者名稱註冊、郵箱註冊、手機號中註冊，因國情的原因，部分系統在註冊過程需做實名驗證，一般註冊的最後一步是補充個人資訊。另外有些系統在使用者註冊完後需要管理員稽覈，完成稽覈一步纔算正式註冊完成。
部分系統在註冊之前會提示使用協議，同意協議才能進行註冊。
1.2 登入
已註冊使用者進入系統的認證過程，可能是輸入使用者名稱和密碼，輸入使用者名稱密碼、密碼和驗證碼的過程。
1.3 密碼找回
通過驗證郵箱和手機號的方式找回密碼，早期的應用一般通過驗證問題找回密碼，驗證問題容易忘，現在很少用了。
1.4 會話控制
HTTP 是無狀態的協議，成功登入後系統跟瀏覽器生成一個同樣的會話字串，用於判斷當前請求是否來自已登入的那個使用者，使用者退出後需要登出當前會話。
1.5 許可權控制
一般系統存在管理員、普通使用者、業務員賬戶、審計賬戶等不同許可權的賬戶，在系統設計階段有許可權矩陣實現控制，分為水平許可權和垂直許可權。
1.6 日誌
賬戶的登入情況進行記錄，通常包含時間、登入賬戶名、源IP、登入結果。
1.7 賬戶登出
《資訊保安技術 個人資訊保安規範》推出後，要求系統有登出賬戶的功能，刪除賬戶相關的所有資訊。
2 使用者認證模組風險
在使用者認證模組有幾個通用的安全措施，實施不當可導致安全措施失效的風險
2.1 圖形驗證碼
簡單的圖形驗證碼完全不安全，一般的影象 OCR 識別，可以識別大部分的字母和數字，現在 AI 的影象識別技術基本可以達到 99% 以上的識別率，目前成本也比較低，另外有人工的打碼平臺可以處理一些複雜的驗證碼。圖形驗證碼的風險一般有：
- 驗證碼易識別
- 服務端返回驗證碼明文
- 驗證碼複用/固定
- 空驗證碼
- 無效驗證，任意驗證碼可用
- 客戶端生成驗證碼
- 設計缺陷，邏輯繞過
- http://bugs.boomeye.com/bug_detail.php?wybug_id=wooyun-2012-014563
2.2 簡訊驗證碼
強認證的三個因素：知道什麼，有什麼，是什麼。簡訊驗證碼屬於有什麼的範圍，結合密碼（知道什麼），實現強認證。簡訊驗證碼通過簡訊介面/閘道器實現，有一定的成本，在實際實現上跟圖形驗證碼有些不同，簡訊驗證碼發風險：
- 驗證碼爆破
- 簡訊介面濫用
- 服務端返回驗證碼明文
- 無效驗證
- 客戶端驗證繞過
- 驗證碼與手機號未繫結
- 手機號複用
- 簡訊驗證碼洩露
2.3 註冊風險
註冊過程通常是多步驟過程，涉及使用者的輸入驗證以及註冊過程的邏輯安全問題。常見風險：
- SQLi
- XSS
- 批量註冊
- 有效使用者名稱猜解
- 註冊流程跳躍
- 弱密碼註冊
- 中間人攻擊
- GET 請求提交引數
2.4 登入風險
登入過程比較簡單，登入涉到未使用加密傳輸導致的中間人攻擊、攔截流量等攻擊，會洩露登入資訊。常見漏洞：
- SQLi
- XSS
- 暴力破解
- 掃號
- 撞庫
- 詳細的報錯資訊（使用者名稱猜解）
- 使用者名稱列舉
- 中間人攻擊
- GET 請求提交引數
使用者名稱猜解是可以猜使用者名稱，如中國常用名 Top 500；使用者名稱列舉是指有固定順序的使用者名稱，如工卡號。
2.5 密碼找回風險
有4種找回密碼的方式以及相關風險：
- 使用「記住問題」找回；
- 問題洩露，問題容易猜出
- 社會工程學攻擊
- 使用郵箱找回；
- 找回郵箱無驗證，可以向任意郵箱傳送驗證
- 郵箱直接傳送明文原密碼（後臺明文存密碼）
- 郵箱修改密碼連結可以修改使用者 ID、登入賬號等資訊（直接明文或做了簡單編碼或雜湊）
- 越權修改其他使用者密碼
- 使用手機號找回；
- 手機驗證碼爆破
- 簡訊介面濫用
- 未驗證手機號有效性
- 越權修改其他使用者密碼
- 客服找回
2.6 會話管理風險
常見風險如下：
- 登入前後會話不變
- 會話有效時間超長，2小時以上，看業務情況
- 修改密碼不清除會話
- 退出登入狀態後，服務端不銷燬會話
- Cookie 注入
- Cookie 未設定安全屬性
2.7 個人資料管理風險
個人資料管理的頁面，一般都有修改個人資料（如：修改住址、郵箱、手機號等）的功能，常見風險有：
- SQLi
- 儲存型 XSS
- 上傳漏洞
- 越權檢視和修改其他使用者資料
2.8 許可權控制風險
2 種：
- 水平越權（同許可權的不同使用者）
- 垂直越權（不同許可權的不同使用者，如管理員和普通使用者）
發現越權的方式，常見修改需改使用者 ID 類的數值，另外可以測試2個使用者不同的 UUID，使用其他使用者的 UUID 測試越權行為。
3 認證模組安全措施
3.1 通用安全措施
- 認證功能使用加密通訊，禁用不安全的方法和協議（TLS 1.1 以上）；
- 設定一致的密碼強度驗證功能，告警使用者設定弱密碼或者連續 n 次內使用的相同密碼；
- 密碼加鹽雜湊儲存，不在資料庫儲存明文密碼；
- 密碼設定更新週期。
3.2 圖形驗證碼加固
圖形驗證碼是常見和成本最低的防護措施，可用於防登入爆破、防自動化爬蟲、防
3.3 簡訊驗證碼加固
考慮簡訊驗證碼的風險，簡訊驗證碼通常是使用簡訊介面實現，關於 API 的防護策略可以通用。簡訊驗證碼防護措施主要有：
- 使用圖形驗證碼，防止介面濫用
- 限制傳送頻率
- 限制傳送次數，可以限制一定時間段的總次數
- 簡訊驗證碼長度和有效期控制
3.4 安全註冊流程設計
註冊根據實際業務情況進行設計，要避免上面說的註冊風險，又要滿足業務的需求，考慮國內的應用有實名制的需求，可以在註冊過程加入實名驗證的流程。
舉個註冊過程的例子：
- 首先驗證註冊使用者郵箱，確認使用者可用的郵箱地址；
- 驗證使用者手機號，驗證使用者郵箱和手機號的過程可以在使用者賬號發生異常時進行告警提示
- 驗證完郵箱和手機號後，接著實際註冊資訊，如設定使用者名稱、密碼等
- 最後一步填寫個人其他資訊，如性別、生日等資訊。
如果需要進行實名認證，可以在認證完手機號之後進行，需要填寫身份證資訊和上傳身份證照片，或者呼叫實名認證介面實現。這種多階段的註冊流程，需要在每一步驟都驗證之前使用者提交的資訊是否有被篡改。
這麼設計有幾個好處：
- 使用郵箱和手機號驗證能防止自動化註冊；
- 使用者註冊完後就能獲取註冊使用者有效聯繫方式，如果系統設計了賬號異常檢測功能，檢測到賬號異常後可以直接給使用者傳送告警；
- 登入可以使用郵箱或手機號方式，防止遺忘帳戶名。
安全註冊流程可以在源頭上防止「薅羊毛」的攻擊，可以結合安全情報直接遮蔽一部分手機號的註冊。
3.5 登入安全
根據業務重要程度可以設定 4 種登入方式：
- 使用者名稱、密碼、（驗證碼）登入，考慮到使用者體驗，可以在使用者輸入密碼幾次錯誤後再啟用驗證碼；
- 手機號、手機驗證碼登入；
- 使用者名稱、密碼、手機驗證碼登入
- 使用者名稱、密碼、證書登入
根據實際安全需求選擇合適的登入方式。
可以實施的安全措施：
- 設定使用者業務認證登入策略，限定失敗登入次數（按賬戶、IP、裝置）、鎖定時間、解鎖方式
- 在異常登入行為發生後，可以支援使用者主動通過其他方式（如電話）凍結賬號功能
- 如果是移動裝置，使用自定義的隨機鍵盤，啟用移動 OS 的防截圖功能；
- 設定使用者業務認證登入失敗提醒策略，當用戶登入失敗超過限定次數時傳送簡訊
- 設定使用者不在常用登入地址的提請功能
- 提醒使用者在不同終端登入的情況
- 根據業務重要情況，可以增加登入提醒功能
3.6 密碼找回安全
主要有 2 種方式找回密碼，通過郵箱和通過手機號，最早還有通過驗證問題找回的，現在應用比較少用了。通過郵箱找回，找回的連結不要出現跟身份相關的資訊，包括一些編碼問題。通過手機號找回，主要防止爆破。
驗證完郵箱或手機號後，需要重新設定密碼，判斷郵箱或手機號跟賬號的關聯性，身份使用後臺的資料，只從前端獲取使用者修改的密碼，也可以通過提醒功能通知使用者賬戶密碼做了變更。
3.7 會話管理安全
會話管理有主要防禦前面說的風險：
- 根據實際業務需求確定是否允許同一賬戶同時有不同的會話；
- 賬戶在修改密碼後銷燬當前全部跟這個賬戶關聯的會話；
- 賬戶超時時間的設定；
- 退出登入後，服務端立即銷燬會話；
- 設定 Cookie 的 http only 屬性；
- 檢查 Cookie 引數輸入。
3.8 個人資料管理安全
對使用者輸入的資料進行嚴格控制，如身份證號、電話號、郵箱等位置使用嚴格的正規表示式匹配實現；對使用者輸入的字串進行檢查，對輸出的字元進行淨化；根據會話返回使用者個人資料資訊，防止越權；採用防止上傳漏洞的防禦措施等。
這部分使用者輸入或修改的內容較多，很常見出現 XSS 漏洞和上傳漏洞，，記住所有使用者的輸入都不可信，採取必要的防護措施。
3.9 許可權管理
在設計階段做好許可權表，許可權管理完全由後臺實現，不從使用者獲取任何關於許可權控制的引數。
3.10 日誌
應配置日誌功能，對使用者登入和退出活動進行記錄，登入日誌內容至少包括使用者登入使用的賬號，使用的 IP 地址，登入時間，以及遠程登錄時， 登入是否成功；
對使用者的重要操作進行記錄，如修改密碼、找回密碼、修改通訊方式等；
可以對使用者的重要業務操作進行記錄。
可以通過對日誌的自動審計發現各種違規和異常行為，如連續失敗的登入、異常地點或 IP 的登入、非常規時間的登入等。
4 Oauth 2.0 認證和風險
嚴格參考 Oauth 2.0 的要求不會有安全問題，有安全問題的都是接收使用者輸入的引數。