只報你能利用的
每筆發現都要有具體攻擊情境。要的是「送出這個請求,得到這個結果」,而不是「攻擊者理論上可以……」。
原則與嚴重度
原則與嚴重度
把「有用的稽核」和「checklist 大雜燴」區分開來的哲學——以及嚴重度到底怎麼判。
對抗式驗證
驗證發現的代理,絕不是找到它的代理。獵人負責找;另一個驗證者負責試圖推翻。
嚴重度需要影響
嚴重度=可能性 × 影響,兩軸並看。若你說不出具體損害,那它的嚴重度比你想的低。
防禦縱深缺口不是漏洞
若 Layer A 已擋住攻擊,缺少 Layer B 只是強化建議——另外列出即可,別灌嚴重度。
動態決定基準
找出可比較的同類軟體並校準。同樣的模式在別處被打穿過?那是更強的發現。二十年來從沒被打穿?先搞懂為什麼。
多跑幾次提升覆蓋
單次執行大約只找到一半。帶著先前的發現再跑,會持續挖出新的地盤。
// 嚴重度判準
業務邏輯的 HIGH 與 MEDIUM 分界:這筆發現是否「擊潰了一個明確的安全邊界」?
未經認證的 RCE、整個資料庫被倒出、無需憑證即可接管管理員帳號。
已認證的 RCE、可外洩資料的 SQLi、對所有使用者觸發的 stored XSS、認證繞過,或某個有實際後果的動作其 RBAC 權限模型被完全擊潰。
需特定條件的針對性 XSS、能造成實質狀態變更的 CSRF、機密外洩,或影響真實但有限的業務邏輯繞過。
非機密資訊外洩、需要持續施力的 DoS、強化缺口。
// 要避免的反模式
讓資安稽核變得毫無用處的那些錯誤。
把 OWASP 當 bug 清單
把所有「偏離 OWASP」的東西都列為發現。OWASP 是 checklist,不是 bug 清單;真實應用都在做取捨。
灌水防禦縱深
在查詢建構器已對識別字加引號的情況下,把缺少的冗餘檢查評為 HIGH/CRITICAL。
忽略部署模型
在 CDN 層做流量限制是合理架構;不是每個應用都需要應用層級的 rate limiting。
把設計行為當 bug
若信任模型說管理員是完全受信任的,那管理員做管理員的事就不是發現。
用 LOW 灌篇幅
十個 LOW 撐不出一份有用的報告;三個真正的 MEDIUM 才行。
「潛在」發現
要嘛你能利用,要嘛不能。如果你需要用到「潛在地」,代表研究做得不夠。
無視做得好的地方
說出「認證很穩」會強化你真正報出之發現的可信度,也幫助排序。
臆測 parser/runtime 行為
最有說服力的誤報都來自「runtime 會把它解讀成……」卻沒驗證。要引規格或實測。
略過邏輯與創意攻擊
掃描器查的是 SQLi/XSS/SSRF;人工稽核的價值在邏輯錯誤、狀態機違規與串連攻擊。
太早放棄
「它用了參數化查詢」是偷懶結論。檢查每個 sql.raw()、動態識別字、搜尋/FTS,以及繞道路徑。再逼一下。