用戶詢問：傳統 SQL 注入失效時，能否利用競態條件繞過「用戶名查詢密碼再比對」的登錄驗證？
競態條件攻擊原理
競態條件發生於「檢查」與「使用」之間存在時間窗口，且並發操作可修改共享狀態。登錄場景下：
- 應用執行
SELECT password FROM users WHERE username = ? 獲取密碼哈希。
- 應用在內存中比對用戶輸入密碼哈希與查詢結果。
- 若此間數據庫記錄被並發修改（如管理員重置密碼、並發登錄嘗試），可能導致邏輯繞過。
實際可行性分析
- 極難利用：登錄查詢通常在單事務中完成，窗口極短（微秒級）。
- 需寫入權限：攻擊者需能並發修改目標用戶密碼記錄，通常不可行。
- 現代框架防護：ORM 多用樂觀鎖、版本號，數據庫行級鎖保護。
更常見的繞過手段（非競態）
- 通用型 SQL 注入：
username: admin'-- 註釋掉密碼檢查（若無參數化）。
- 弱口令/字典爆破：無限制嘗試。
- 會話固定/劫持：繞過登錄直接獲取會話。
- 業務邏輯漏洞：如密碼重置流程缺陷、OAuth 重定向驗證不嚴。
防範建議
- 使用參數化查詢 / PreparedStatement 防 SQL 注入。
- 登錄限流、賬號鎖定、多因子認證 (MFA)。
- 密碼存儲用 bcrypt/Argon2 等慢哈希。
- 關鍵操作（改密、綁定）需二次驗證。
- 代碼審計關注 TOCTOU（Time-of-check to time-of-use）模式。
總結
競態條件理論上存在但極難在登錄驗證中實戰利用。安全防禦應聚焦於參數化查詢、認證強度、業務邏輯審計等成熟體系，而非研究邊緣競態攻擊。
