Inside a large self-hosted VRP by Sam Erb | Bug Bounty Village, DEF CON 33

Google 的虛擬研發工程師 Sam 介紹了 Google 漏洞賞金計劃 (VRP) 的運作體系與一個具體的技術漏洞案例。作為 Alphabet 安全工程師團隊的成員，Sam 每天面臨的任務是對數千份漏洞報告進行分類、重現與驗證。與業界依賴 HackerOne 或 BugCrowd 等第三方平台不同，Google VRP 完全自主運作，確保所有處理流程由內部安全團隊主導。從規模看，團隊每週處理約 250 份漏洞報告，其中 15-25% 被升級進入評估流程，最終約 50% 的升級報告會獲得獎勵。Alphabet 去年為 VRP 計劃支付近 1200 萬美元，迄今為止累計支付 6500 萬美元，涵蓋 Android、Chrome 與多個開源項目。

Google VRP 與業界其他計劃的核心區別在於評估與獎勵的邏輯。首先，Google 不使用 CVSS（通用漏洞評分系統）評分來決定獎勵，而是根據漏洞對 Google 用戶的實際影響程度進行評判。當研究人員提交報告時，系統先進行初步篩選（Google 內部稱為「分診」），然後由人工審核決定是否升級。若安全工程師發現漏洞的實際危害超過初始評估，會主動升級等級，研究人員因此獲得更高獎勵——這是一種雙贏的做法。其次，Google 鼓勵公開披露漏洞，對於意外洩露的內部文件或敏感訊息，給予統一 500 美元的獎勵，而非懲罰研究人員。不使用聲譽系統意味著每份報告都基於本身的優點評估，而非報告人的過往記錄。

演講的另一重點是對一個真實漏洞的技術分析——透過 GZIP 壓縮實現任意代碼注入的 XSS 攻擊。GZIP 是 1990 年代的壓縮算法，基於 Deflate 協議，結合了兩項更古老的技術：LZ77 和霍夫曼編碼。LZ77 檢測並標籤化重複字符串，霍夫曼編碼則將常見字符的位數從 8 位壓縮至更少。根據 RFC 標準，LZ77 只對連續 3 個或以上的字符進行匹配以避免低效。發現者（Tom）利用雙字符字符串技巧繞過匹配邏輯，然後通過隨機化字符與長度來每次產生不同的霍夫曼編碼表。這樣做的目的是在壓縮過程中，將任意字符串的編碼值插入到輸出中。透過刪除先前的字符出現記錄確保編碼表維持不變，最後以蠻力破解修正檢驗和（每 8 次嘗試成功一次）來完成攻擊。使用 Go 語言實現的程式碼實際上能將 `<script>` 標籤等任意內容列印到壓縮輸出中，並在瀏覽器中有效執行。這是首次在不受控環境下成功將任意字符串注入 GZIP 壓縮流，區別於過往受控場景與自我壓縮 GZIP quines 等奇異例子。

漏洞發現後，Google 安全團隊決定升級其嚴重性等級並要求修復。這個案例展示了 Google VRP 團隊與研究人員的協作方式：當發現報告價值時，主動與研究人員一起證明其影響力，爭取更高的獎勵。問答環節中提及，Google 在不同漏洞類別中設有獎勵區間，具體金額取決於影響程度、影響人數及技術難度等因素，但 Google 傾向於在未來進一步提高透明度。最後，演講強調了 Google 與行業標準的另一差異：CVE 提交時才使用 CVSS 評分，而內部流程完全不涉及 CVSS，使用 P0-P2 等級系統，保持決策靈活性與對實際威脅的準確回應。