這是「從零開始的資安獵人」第 11 篇。上一篇AI 時代的漏洞獎金看了 AI 對這條路的影響。這篇回到兩個很實際的問題：找到洞之後，一份報告怎麼寫才不會被打折？以及，整件事到底值不值得你花時間？
讀完你應該能做到兩件事：用一頁紙的模板寫出報告，並用自己的假設算出一個粗略的期望值，決定願意投入多少時間。
先講清楚一件事：不同計畫對報告的要求不一樣，以各計畫自己的頁面為準。這篇用的是 Google、Microsoft、Meta 三家頁面上寫明的規則，加上我自己的建議。建議會標明是建議。
報告怎麼被評分：Google 的品質表
Google VRP 規則頁有一節「Report quality」。規則頁寫的是：Google 獎勵品質，因為品質有助於分流（triage）、分析與修補；最終獎金會依報告品質乘上 0.8x、1x 或 1.2x，品質由評審小組（panel）自行判定。
規則頁同時說，要拿到 Good 或 Exceptional，上面列的條件都要滿足。七個維度如下，我把每一格的判準濃縮成白話，括號內是原文的關鍵字：
| 維度 | Low（0.8x） | Good（1x） | Exceptional（1.2x） |
|---|---|---|---|
| 漏洞描述 | 沒寫、不完整或寫錯 | 不完整但正確 | 描述有效（Effectively described） |
| 攻擊前提 | 沒寫、不完整或寫錯 | 不完整但正確 | 描述有效 |
| 影響分析 | 沒寫、不完整或寫錯；影響只是理論或臆測 | 不完整但正確 | 簡潔有效，含該產品專屬的分析；或不攻擊非測試使用者就無法分析 |
| 重現步驟／PoC | 沒寫、不完整或寫錯 | 有，只有小錯 | 完整、好懂、好重現；可行時附自動化 PoC |
| 目標資訊（裝置、版本、網址） | 沒寫、不完整或寫錯 | 適當時提供完整資訊 | 同左 |
| 重現輸出（影片、除錯器、HTTP 回應等） | 沒寫、不完整或寫錯 | 有，但缺資訊 | 簡潔有效地呈現問題 |
| 回應速度 | 明顯延遲、回覆不完整或事實錯誤、非技術討論、AI slop | 盡力回覆（兩週內），或缺少重要資訊 | 快（三個工作天內）、簡潔、技術精確 |
幾個值得注意的地方：
- Good 允許「不完整但正確」。不過表上 Low 與 Good 的措辭都出現「不完整」，Low 另外包含「沒寫」和「寫錯」，兩者的界線由評審判斷。能確定的是：寫錯和沒寫一定落在最差那一欄。
- 影響分析最容易被扣。Low 那格明寫「理論或臆測的影響」。如果要證明影響就得去碰別人的資料，規則頁的 Exceptional 欄把「不攻擊非測試使用者就無法分析」也算進去，所以你不必為了寫影響去越線（測試範圍見第 1 篇）。
- 回應速度是送出後的行為，不是報告內容。回得慢、回得空洞或回得離題，會直接影響這一格。
- 規則頁另外寫，部分維度如果不適用或研究者不可能判斷，評審可以忽略。
只認分流前的資訊
這一條很容易被忽略。規則頁原文大意是：報告被分流之後（通常是已經開出內部 bug 給產品團隊），安全團隊開始修補流程；為了維持一致與效率，決定獎金時只能考慮分流前已有的資訊，之後補上的內容通常不影響獎金評等。
換句話說，第一次送出的版本就是你的成績單。先送一份粗糙的、想之後再補，在 Google 的規則下通常補不回來。
規則頁另外有兩處和「補資料」有關。一是申訴：認為獎金決定與規則不符，可以在收到獎金通知後一個月內申訴，而且通常要有報告裡沒討論過的新資訊才容易成功。二是 FAQ 裡「我找到漏洞但不知道怎麼利用」那一題：金額依漏洞的最大影響決定，評審願意根據新資訊（例如串連多個 bug、修正過的攻擊情境）重新考慮金額。後者只是那一題的語境，不是對所有報告的保證。
規則頁沒有明說品質係數能不能申訴。我的理解是，品質評等看送出當下，而金額與規則是否相符可以靠新資訊申訴；這是我對兩個機制的區分，不是規則頁寫明的，實際怎麼處理要看評審。
兩個很具體的 Google 建議
Google 的 Bug Hunters 學習頁有兩篇我覺得對新手最實用：
- Write down the attack scenario：攻擊情境就是簡短交代「誰、為了什麼好處、用什麼方式」要利用這個洞，重點不是重複重現步驟。文章還提到，寫攻擊情境時有時會發現影響其實比想像小，例如攻擊者得先有高權限，利用這個洞也得不到新東西。
- Create an exceptional automated PoC：好的自動化 PoC 要小、自給自足、有說明、讓對方能換上自己的 cookie 或憑證。文章也說，如果自動化沒有用（例如要瀏覽器執行 JavaScript 的 DOM 型 XSS），不要硬附，寫明為什麼就好。
規則頁還有一句：請精簡，一個短的 PoC 連結比一支解釋 XSS 後果的影片更有價值。
Microsoft 的做法：三級品質，Hyper-V 要求最重
Microsoft Hyper-V 計畫頁把品質直接綁進獎金表，不是乘數，而是不同的上限。第 0 篇已經整理過 L1 guest 逃脫那一組：有可運作的 exploit 且品質高最高 250,000 美元；沒有 exploit，品質高 200,000、中 100,000、低 50,000。頁面表頭寫的是 Maximum Award。
同一頁說，高品質報告要提供工程師能快速重現、理解與修補所需的資訊，通常包含精簡的說明（必要背景、漏洞描述），以及一個不靠除錯器介入（例如暫停執行緒、修改記憶體或程式碼）就能重現的 PoC。
MSRC 另有一頁範例報告與品質定義，把三級定義得很清楚：
| 等級 | 內容 |
|---|---|
| Low | 資訊足以重現，但沒有可靠的 PoC。需要：漏洞類型、受影響元件（名稱、版本）、目標環境（類型、版本）、重現輸出、PoC |
| Medium | 在 Low 之上，PoC 可靠且最小化 |
| High | 在 Medium 之上，有詳細且正確的分析，且重現不依賴除錯器 |
那一頁還附了一份高品質與一份低品質的範例（高品質那份有標題、平台、類別、摘要、描述、PoC、預期結果與觀察結果，並提出修補方向）。低品質那份主要是反組譯片段與日誌，我沒有在裡面看到重現步驟。這兩份值得打開來看，看過比讀十段說明有感。
Hyper-V 頁的「Eligible submissions」還要求報告要包含漏洞的影響，以及攻擊途徑（如果不明顯的話）。
一頁紙模板（這是我的建議，不是任何計畫的規定）
下面這個格式是我根據上面幾家的品質維度整理的，不是官方規定。送出前請先看目標計畫自己的表單與規則，有欄位就照它的。
| 欄位 | 寫什麼 | 對應的官方維度 |
|---|---|---|
| 標題 | 漏洞類型 + 哪個功能或端點 + 一句後果 | 漏洞描述 |
| 摘要 | 兩三句：是什麼洞、在哪、最糟會怎樣 | 漏洞描述 |
| 目標資訊 | 產品名稱、版本、網址、測試帳號類型、日期 | 目標資訊 |
| 前提 | 攻擊者起點（要不要登入？要不要先拿到受害者的什麼？）、受害者需不需要做事 | 攻擊前提 |
| 重現步驟 | 編號步驟，每步一個動作；能附自動化腳本就附 | 重現步驟／PoC |
| 預期與實際 | 一行預期、一行實際，附回應片段或截圖 | 重現輸出 |
| 影響 | 實測證明了什麼、沒測什麼；最壞情況與其前提分開寫 | 影響分析 |
| 修補建議 | 一兩句方向，可省略但有幫助 | 無對應維度（MSRC 範例報告有提） |
寫的時候三個習慣：
- 一份報告一個問題。Meta 的流程也寫明一份報告一個議題。
- 實測的和推論的分開寫。「我確認了 X」與「我推測可能 Y」放不同句子，也避免被當成理論或臆測的影響。
- 寫完讓別人照步驟跑一次。同學、朋友、隔天的自己都行。照 Google 的說法，你的讀者是分流的工程師，不是你。
示範：用第 3 篇的 IDOR 玩具程式寫一份報告
目標是第 3 篇那支只綁在 127.0.0.1 的 demo.mjs，不是任何真實網站。下面這份報告是示範格式，漏洞原理與輸出都取自那篇。
標題：Notes demo：GET /notes/{id} 缺少擁有者檢查，登入使用者可讀取他人筆記（IDOR）
摘要
有洞版伺服器的 /notes/{id} 只確認請求者「有登入」，沒有確認該筆記屬於請求者。
alice 帶自己的 session 請求 /notes/2，回傳 bob 的筆記全文。
目標資訊
- 程式：demo.mjs（本系列第 3 篇的玩具程式，有洞版實例）
- 環境：Node.js v22.22.0，伺服器只綁 127.0.0.1
- 測試帳號：alice（session=alice-token）、bob（session=bob-token），皆為程式內建假資料
前提
- 攻擊者需要任一有效登入（此例為 alice）。
- 筆記 id 是連續整數（1、2、3），不需要猜測。
- 不需要受害者做任何事。
重現步驟
1. 存檔 demo.mjs，執行 node demo.mjs。
2. 看輸出的「== IDOR」區段。腳本以 alice 的 session 請求 /notes/2。
（手動等價請求：GET /notes/2，Cookie: session=alice-token）
預期：404 not found（id=2 是 bob 的，不該讓 alice 讀到）
實際：200 Bob 的銀行備忘
影響
- 已實測：任何登入者可以讀取任意 id 的筆記全文。id 為連續整數，
所以可以依序走訪全部筆記。
- 未測：寫入、刪除（此端點只實作了讀取）。
- 依賴前提：真實系統的 id 若不是連續整數，就要先取得對方的 id；
此玩具程式不適用。
修補建議
讀取後比對 note.owner 與登入者，不符就回 404（與「不存在」同樣的回應）。
修法版程式已示範，alice 讀自己的 id=1 仍正常。
附件
demo.mjs 完整輸出（第 3 篇有記錄）。逐欄對照 Google 的品質表
這是自評，用來練習看懂判準；實際品質由 Google 評審小組判定，而且這份報告是玩具，沒有真實的獎金可言。
| Google 維度 | 示範報告怎麼對應 | 想達到的那一格 |
|---|---|---|
| 漏洞描述 | 標題與摘要用兩句話交代類型、端點、缺了什麼檢查 | Exceptional：描述有效 |
| 攻擊前提 | 「前提」欄列出要登入、id 連續、不需受害者互動 | Exceptional：描述有效 |
| 影響分析 | 分成「已實測」「未測」「依賴前提」；沒有寫「可能導致大量資料外洩」這種沒測過的話 | 避開 Low 的「理論或臆測」 |
| 重現步驟／PoC | 兩步，外加整支腳本本身就是自動化 PoC | Exceptional：完整且附自動化 PoC |
| 目標資訊 | 程式、Node 版本、綁定位址、帳號 | Good 與 Exceptional 的要求相同 |
| 重現輸出 | 預期與實際各一行，回應內容直接貼出 | Exceptional：簡潔有效 |
| 回應速度 | 不在報告裡，送出後才算：被問問題時三個工作天內回覆 | Exceptional：快、簡潔、技術精確 |
再看一次「影響」那一欄。如果寫成「此漏洞非常嚴重，可能洩漏所有使用者的機密資料」，沒有任何實測，就是 Low 欄寫的理論或臆測。實測了什麼、沒測什麼，分開寫，是這份示範報告最值得照抄的地方。
品質係數到底值多少錢
拿 Google 規則頁自己的例子算：一個 *.google.com 上的 IDOR，可外洩使用者的已存地址，規則頁的格子是 13,337 美元（T2、S2b）。品質係數只會讓它在 0.8 倍到 1.2 倍之間移動：
- 0.8 倍：13,337 × 0.8 = 10,669.6 美元
- 1 倍：13,337 美元
- 1.2 倍：13,337 × 1.2 = 16,004.4 美元
乘法是我自己算的，最後金額仍由評審小組裁量。重點是看大小：好報告和差報告的差距是 1.5 倍（1.2 ÷ 0.8），遠小於「這個洞落在哪一格」造成的差距。以規則頁一般 Google 應用（T2）那一欄為例，XSS（C0）是 10,000 美元，IDOR 一類的三格分別是 3,133.7、13,337、31,337 美元，光是 IDOR 自己的最低格和最高格就差約 10 倍。所以報告寫得好，是把已經有的價值拿滿；它不會把一個沒有影響的洞變成有價值的洞。
報告被退回，常見是哪些原因
寫得再好，如果一開始就不屬於這個計畫，也拿不到錢。Meta 的計畫範圍頁有一節「Conditions for closing reports as invalid」，列出主要原因：
- 報告描述的是一般軟體錯誤，不是安全問題。
- 報告描述的是缺少的功能或功能改進建議。
- 問題超出計畫範圍，例如問題出在 Meta 無法控制的東西。
- 情境是社交工程或垃圾訊息攻擊。
- 問題低於發放獎金的門檻。
重複報告的規則也在同一頁：發生重複時，獎金發給第一個提交的人，Meta 自行判定是否重複，也沒有義務告訴你先前的類似報告。有一個例外：如果後來的報告揭露漏洞仍然存在，或比原先評估的更嚴重，Meta 可能發放獎金。Google 的 FAQ 說得更直白：「First in, best dressed」，只有第一個通報先前未知問題的人符合資格。
Meta 的頁面還有兩個對新手有用的細節：獎金金額由影響、利用難易度與報告品質等因素決定，如果發放，最低是 500 美元；以及「極低風險的問題可能完全不符合獎金資格」。
把這些對回報告：先確認範圍與是不是安全問題，再談寫得好不好。範圍判斷見第 1 篇。
值不值得投入：用假設數字算一次期望值
這一節的所有機率和時數都是我編的假設，用來示範算術，不是統計，也不代表任何人的實際成績。我沒有讀到可以對應新手的官方或研究數字（成功率、平均獎金、新手收入），所以不引用，也請你不要把下面的數字當事實。
期望值的意思是：每種結果的金額乘上它發生的機率，再加起來。對一次投入來說，可以粗略寫成：
每小時期望 = 機率 × 金額 ÷ 投入小時數
這裡的「機率」要同時滿足四件事：你找得到洞、在計畫範圍內、被認定為有效的安全問題、沒有被別人搶先通報。前面看過的規則剛好對應後三個：範圍、無效原因、重複報告。四個機率相乘，會比單看其中任何一個都小很多。
兩個假設情境：
| 情境 A：小額、常見類型 | 情境 B：頂級格子 | |
|---|---|---|
| 假設的金額 | 500 美元 | 100,000 美元 |
| 假設的投入 | 40 小時 | 400 小時 |
| 假設的機率（四件事同時成立） | 10% | 0.2% |
| 期望值 | 0.10 × 500 = 50 美元 | 0.002 × 100,000 = 200 美元 |
| 每小時期望 | 50 ÷ 40 = 1.25 美元 | 200 ÷ 400 = 0.5 美元 |
幾件事看這張表：
- 上限高不等於期望高。B 的金額是 A 的 200 倍，期望值只是 4 倍，每小時期望反而更低，因為時數多 10 倍、機率低 50 倍。獎金表上的數字是上限：Hyper-V 頁表頭寫 Maximum Award，Google 的格子是基準，最終金額由評審決定。
- 機率是你最不知道的數字，也是影響最大的。把 A 的機率減半到 5%，每小時期望就變成 0.625 美元。算出來的是一個區間，不是一個答案。
- 這個算式漏掉了很多東西：學到的技能、履歷上的紀錄、你的時間在別處的價值。我刻意不把它們換算成金額，因為我沒有可靠的算法。
怎麼把它變成決定
我的建議是：不要把這條路當成收入來源來算，先把它當成一筆有上限的學習預算。
- 先定一個時數上限。例如每週 5 小時、做 12 週，共 60 小時。這是你願意為了學習付出的成本，不是預期要賺回來的錢。
- 自己記帳。每次寫下花了幾小時、碰到什麼情況：被判重複、被判無效、超出範圍、沒找到。三個月後，你會有一組屬於自己的比例，比我給的任何數字都準。
- 用自己的比例重算。把你的紀錄代進上面的算式。如果每小時期望跟你的時間價值差很多，而學習的收穫也不夠，就調降投入。
- 避開需要大量前置功力的格子，先挑你能做到的。第 0 篇整理過，頂級價碼背後常是可運作的 exploit 與高品質報告，門檻比一般 Web 漏洞高很多。
這幾點是我的判斷，不是任何計畫的建議。
今晚能做的事
- 打開 Google VRP 規則頁的 Report quality 表，對照上面的示範報告，用紅筆標出你覺得最弱的一格。
- 打開 MSRC 的範例報告頁，比較高品質與低品質兩份，各列出三個差別。
- 把第 3 篇的
demo.mjs跑一次，用上面的模板為「XSS 那一段」寫一份報告，只寫玩具程式，不碰真實網站。 - 拿一張紙，寫下你自己的三個假設（機率、金額、小時數），算一次每小時期望，再寫下你打算投入的總時數。
限制
- 這篇的規則來自 Google、Microsoft、Meta 三家頁面，我於 2026-10-14 讀過。各計畫的表單、格式與評分標準不同，也會改版，送出前以當下頁面為準。
- 品質判定是各計畫評審的自由裁量。我的逐欄對照是練習，不是預測。
- 模板是我的建議。除了 Microsoft 要求寫明影響與（不明顯時的）攻擊途徑外，我沒有找到哪個計畫規定固定欄位。
- 期望值的機率與時數全是假設。我沒有引用 HackerOne 或 Bugcrowd 的年度報告，因為這次沒有讀到可以對應「新手」的數字，不想拿不相干的樣本充當依據。
- 這篇不教怎麼利用漏洞。測試範圍與法律邊界見第 1 篇。
下一篇是認證與學習地圖。
參考資料
- Google and Alphabet VRP Rules（Report quality 表、分流前資訊、申訴、獎金範例、FAQ）
- Google Bug Hunters：Write down the attack scenario
- Google Bug Hunters：Create an exceptional automated PoC
- Microsoft Hyper-V Bounty Program（MSRC）
- Example Report Submissions to the MSRC（品質定義與範例）
- Meta Bug Bounty：Program scope（無效報告原因、重複報告、獎金考量因素）
- 本系列：第 0 篇 頂級獎金查證、第 1 篇 規則與邊界、第 3 篇 XSS 與 IDOR、第 10 篇 AI 時代的漏洞獎金、第 12 篇 認證與學習地圖
Loading...