security-bounty-hunter

Security Bounty Hunter

當目標是為了負責任揭露或漏洞獎金提交而進行實用漏洞發現時使用此工具，而非廣泛的最佳實務審查。

使用時機

• 掃描儲存庫以尋找可被利用的漏洞
• 準備 Huntr、HackerOne 或類似漏洞獎金提交
• 分類時，問題是「這真的能賺錢嗎？」而非「這理論上不安全嗎？」

運作方式

傾向於可遠端觸發、使用者可控的攻擊路徑，並捨棄那些平台經常拒絕視為資訊性或超出範圍的模式。

範圍內模式

這些是 consistently 重要的問題類型：

模式	CWE	典型影響
透過使用者可控 URL 的 SSRF	CWE-918	內部網路存取、雲端中繼資料竊取
中介軟體或 API 防護中的認證繞過	CWE-287	未經授權的帳戶或資料存取
遠端反序列化或上傳至 RCE 路徑	CWE-502	程式碼執行
可觸及端點中的 SQL 注入	CWE-89	資料外洩、認證繞過、資料破壞
請求處理器中的命令注入	CWE-78	程式碼執行
檔案服務路徑中的路徑遍歷	CWE-22	任意檔案讀取或寫入
自動觸發的 XSS	CWE-79	工作階段竊取、管理員帳戶淪陷

跳過這些

這些通常訊號微弱或超出漏洞獎金範圍，除非計畫另有說明：

• 僅限本機的 pickle.loads、torch.load 或類似功能，且無遠端路徑
• 僅限 CLI 工具中的 eval() 或 exec()
• 完全硬編碼命令上的 shell=True
• 僅缺少安全標頭
• 沒有利用影響的一般速率限制投訴
• 需要受害者手動貼上程式碼的自 XSS
• 非目標計畫範圍內的 CI/CD 注入
• 僅限示範、範例或測試程式碼

工作流程

1. 先檢查範圍：計畫規則、SECURITY.md、揭露管道和排除項目。
2. 尋找真實入口點：HTTP 處理器、上傳、背景工作、webhook、解析器和整合端點。
3. 在有用時執行靜態工具，但僅將其視為分類輸入。
4. 從頭到尾閱讀真實的程式碼路徑。
5. 證明使用者控制能到達有意義的接收點。
6. 用最小安全 PoC 確認可利用性和影響。
7. 在草擬報告前檢查是否重複。

範例分類迴圈

semgrep --config=auto --severity=ERROR --severity=WARNING --json

然後手動過濾：

• 移除測試、示範、fixtures、供應商程式碼
• 移除僅限本機或不可觸及的路徑
• 僅保留具有明確網路或使用者控制路由的發現

報告結構

## 說明
[漏洞是什麼以及為何重要]

## 漏洞程式碼
[檔案路徑、行數範圍和一小段程式碼]

## 概念驗證
[最小可運作的請求或腳本]

## 影響
[攻擊者可以達成什麼]

## 受影響版本
[測試過的版本、提交或部署目標]

品質門檻

提交前：

• 程式碼路徑可從真實使用者或網路邊界觸及
• 輸入確實由使用者控制
• 接收點有意義且可被利用
• PoC 可運作
• 問題尚未被公告、CVE 或公開工單涵蓋
• 目標確實屬於漏洞獎金計畫的範圍