Black Hat Europe 2025 | Stress-Testing SAST And LLMs On Modern Web Backends

傳統 SAST 工具聲稱對常見漏洞的檢測率達 80-85%，但講者團隊在測試現實中的複雜、多層次漏洞時發現，檢測率竟跌至 0%。這不是配置問題，而是反映了 SAST 架構本身的根本局限。

漏洞隱藏在「好的」代碼實踐中。開發者為遵守單一責任原則和 DRY 原則，會將驗證邏輯和執行邏輯分離到不同函數。表面上代碼結構清晰，但這種分離卻創造了新的攻擊面——驗證和執行操作的對象不一致。

第一個案例是優惠券漏洞。驗證函數接收優惠券列表，移除重複項後返回集合；執行函數卻遍歷原始列表而非集合，導致重複優惠被多次應用。第二個案例是小費詐騙漏洞：驗證中檢查 `tip >= 0`，但獲取參數時同時從查詢字符串和 JSON body 讀取，攻擊者可通過 JSON body 傳遞負數繞過驗證。兩個漏洞共同點都是違反了安全不變式——驗證和執行的輸入不一致。

第三個案例更複雜，涉及多層防禦的交互缺陷。開發者使用授權裝飾器進行緩存，防止跨租戶訪問；同時在數據庫層進行作用域限制；還引入消費助手函數來檢測異常行為。單獨看每一層都是安全的。但當舊端點因向後兼容性手動複製授權邏輯，而後來又改造消費函數支持批量操作時，攻擊者可以精心構造包含多個值的列表——一個值通過授權檢查，另一個值在數據庫層執行，實現跨租戶數據篡改。

為什麼 SAST 無法檢測？污點分析（taint analysis）方法追蹤數據從源到目的地的流動。它可檢測「直接」的流動——例如未驗證的用戶輸入直接進入數據庫查詢。但上述案例漏洞涉及多個輸入源、不同驗證點、複雜的數據轉換邏輯，超出了污點分析的模型範圍。編寫自定義規則來檢測這些模式也異常困難——一旦代碼重構、變量重命名或調用鏈改變，規則就失效。

有趣的是，AI 工具在同一基準上的檢測率達 100%。Claude Code、Gemini 等工具能理解業務邏輯、跨越多個代碼單元推理、識別不一致的模式。這推翻了「複雜漏洞無法檢測」的定論，但 AI 也有缺點——不如 SAST 那樣確定性和可擴展。

講者的實踐建議分三層面：首先，對現代 Web 應用應主動編寫自定義 SAST 規則，基於業務邏輯和內部代碼約定；其次，把 SAST 當作理解代碼的工具而非安全門禁；第三，若規則難以編寫，這往往說明代碼架構不清晰，應考慮重構以建立明確的安全邊界。

展望未來，改進方向應是：將 SAST 更緊密地集成到開發流程（如 IDE 插件、LSP），提供更易用的代碼查詢語言（類似 SQL），簡化自定義規則的編寫。只有當 SAST 變得更動態、更交互、更貼近開發者日常工作時，才能真正應對現代代碼中的複雜漏洞。