找到漏洞值得高興，但先別急著送報告。倉促常導致錯誤——報告被駁回、聲望分數扣分、心情低落。本章整理寫好一份漏洞報告的關鍵原則。

1. 先讀計畫政策#

每個 Bug Bounty 計畫都有 policy 文件，列出：

• 排除（out-of-scope）的漏洞類型
• 在範圍內 / 範圍外的網域與系統
• 已知問題（不要回報）
• 獎金結構

作者第一次找到的 Shopify 漏洞——畸形 HTML 觸發 stored XSS。他興奮地送出報告，五分鐘內被告知「這是已知問題，已要求研究者不要再回報」。報告以 invalid 結案，扣 5 點聲望。

教訓：先讀政策。

2. 寫報告：先列細節，再加細節#

每份報告應該至少包含：

• 漏洞 URL 與所有受影響的參數
• 瀏覽器、作業系統、應用版本（若適用）
• 漏洞描述
• 重現步驟（清楚到可逐步操作）
• 影響說明（如何利用、能造成什麼後果）
• 建議的修復方向

加上截圖或短於兩分鐘的影片 PoC——既是證據也是 triager 重現的捷徑。

影響評估的細節#

• Twitter 上的 stored XSS 屬高嚴重度（公司公開、使用者多、平台被信任）
• 沒有使用者帳號的網站上，stored XSS 嚴重度較低
• 處理醫療資料的網站，個資洩漏的影響可能高於 Twitter 上的 XSS

3. 再次驗證漏洞#

「Don’t shout hello before you cross the pond」——別在過河前大喊勝利。

Mathias Karlsson 的故事：他在 macOS 的 Firefox 上發現「畸形主機名造成的 SOP 繞過」，掃描 Alexa 前一萬大網站發現 7% 受影響，興奮 tweet 預告。但檢查後發現他忘了更新作業系統——更新後漏洞消失。問題其實六個月前就修了。

任何看似重大的漏洞，都該：

1. 換另一台機器重現
2. 升級瀏覽器、OS 後再驗證
3. 換不同帳號、不同網路再試
4. 與信任的同行討論一遍

連 Karlsson 這種頂尖駭客都差點出糗——驗證再多次都不嫌。

4. 你的聲望#

把每份報告當成未來會公開揭露的東西——你願意被公開檢視嗎？

作者的痛點：曾被邀請進私有計畫、一天找出 8 個漏洞，但當晚送了一份被判 N/A 的報告——HackerOne 的統計分數降低，隔天回不去那個私有計畫，得等 30 天。

平台用統計分數決定是否邀請你進入更高賞金的私有計畫。一份爛報告會影響很久。

私有計畫通常獎金更高、競爭更少——保護聲望就是保護收入。

5. 對公司保持尊重#

並非每家公司都有資源能即時回應。寫報告與後續追蹤時，記得換位思考：

• 回應時間：新計畫常被淹沒，給公司至少 5 個工作天再禮貌追問
• 修復時間：確認漏洞後可詢問預期修補時間，並約定隔月再檢查
• 溝通：開放、有耐心的計畫值得長期合作；冷漠的計畫可早早撤離

Adam Bacchus 對 Triager 立場的觀察#

時任 HackerOne Chief Bounty Officer 的 Adam Bacchus 提供以下視角：

• 公開計畫常被大量無效報告（noise）淹沒，會延遲對有效報告的回覆
• Bounty 修復必須與既有開發排程協調，特別是低／中嚴重度的漏洞
• 複雜系統的驗證需時間——清楚的描述與重現步驟可加速處理（與你的賞金）
• 小公司未必有專職資安人員跑賞金計畫，回覆會慢
• 真正修補漏洞包含 debug、寫測試、staging 部署——別期待當天上線
• Bounty 計畫希望駭客回流——有經驗的駭客會找到更高嚴重度的漏洞（go deep）
• 壞名聲是真實的——當駭客在社群媒體公開發難，會影響 triager 的工作模式與信任

6. 申訴賞金額度#

收到的賞金不如預期時，禮貌地討論，不要冷暴力或抱怨。

HackerOne 共同創辦人 Jobert Abma 在 Quora 上的建議：

如果不同意收到的金額，討論為什麼你認為值得更高。避免不解釋就要求加碼。同時，公司也應尊重你的時間與貢獻。

作者的範本：

非常感謝您支付的賞金，我很感激。我想了解金額是如何決定的——我原本預期 $X 但收到 $Y。我認為這個 Bug 可被用於 [影響 Z]，對 [系統／使用者] 影響可能很大。希望了解計算邏輯，讓我未來能聚焦在你們最在意的議題上。

歷年回覆結果：

• 公司解釋影響其實較低，金額不變（你學到評估標準）
• 公司同意誤判，加碼
• 公司同意分類錯誤，重新分類後加碼

想佐證你的預期時，可引用同一家公司過去類似的公開報告。不要引用其他公司的賞金——A 公司的賞金不能正當化 B 公司的賞金。

章末總結#

• 寫好報告是 Bug Bounty 駭客的核心技能
• 先讀政策——避開已知問題與超出範圍的回報
• 詳實但不冗長：URL、版本、重現步驟、影響、建議修復、PoC 截圖／影片
• 送出前再驗證一次——不同機器、不同 OS、最新版本
• 保護聲望分數：每份報告影響未來進入私有計畫的機會
• 尊重 triager 的工作節奏——5 個工作天再追問，給予合理修復時間
• 對賞金有疑問時禮貌討論，引用同公司歷史案例