寫好報告

漏洞賞金獵人的工作不僅僅是尋找漏洞；它還向組織的安全團隊解釋它們。如果您提供一份寫得很好的報告，您將幫助與您合作的團隊重現漏洞利用，將其分配給適當的內部工程團隊，并更快地解決問題。

商業化的報告模板是一個不錯的形式，但比它更出色的是，觀察與思考。

從工作流程的角度來說，漏洞管理與賬面核對也非常重要。一個組織如果長時間接收到報告，那么面臨到的問題一定是一些個性化的。比如，漏洞管理過程中，命名的規范直接導致這個能否一眼看出是否重復提交，是否易于管理與記賬，是否存在數據之間的關聯與匹配性。

文檔名稱規范化：XXX平臺（hackerone）-XXXX編號。
文檔名的規范化，保證組織與眾測平臺之間的唯一性，不會出現這個報告聊成了其他報告。

內容標題規范化：XXX項目或者應用-XXX部門或者元數據-XXX漏洞。
價值性于一份報告在手就能看清所有資產，極大的幫助組織推動報告的分發到負責人手中。

內容標題追加：XXXX編號
方便復制粘貼，不需要再關閉文檔，然后右鍵文檔復制編號記賬。

您不必中規中矩的模仿任何報告，以下例子是給您一個良好的借鑒，因地制宜的修改自己報告。

【技術學習】

第 1 步：制作描述性標題

優秀漏洞報告的第一部分總是一個描述性的標題。目標是用一句話概括問題的標題。理想情況下，它應該允許安全團隊立即了解漏洞是什么、發生的位置以及潛在的嚴重性。為此，它應該回答以下問題：您發現的漏洞是什么？它是否是眾所周知的漏洞類型的實例，例如 IDOR 或 XSS？您在目標應用程序中的何處找到它？例如，而不是像“關鍵端點上的 IDOR”這樣的報告標題，使用“https://example.com/change_password 上的 IDOR 導致所有用戶的帳戶接管”之類的。您的目標是讓閱讀您的報告的安全工程師對您將在其余部分討論的內容有一個很好的了解。

漏洞內容標題追加：XSS漏洞，SQL注入，信息泄露或者IDOR等。
漏洞內容的核心價值觀在于，組織易于復現與確認。能復現能觀察就是說服組織接收最好的方式。
比如：1.目標URL，測試賬號 張三/密碼 2.點擊UI界面的忘記密碼 3.bp中發現未授權的API（并截圖） 4.重放API發現信息泄露 5.建議：對API做驗證和授權。
閉環了兄弟們，這個報告解決了組織從哪里開始復現，觀察哪里，危害在哪，行云流水。

第 2 步：提供清晰報告摘要

此部分包含您無法在標題中傳達的所有相關詳細信息，例如用于攻擊的 HTTP 請求參數、您如何找到它等。以下是有效報告摘要的示例：https://example.com/change_password 端點采用兩個 POST 正文參數：user_id 和 new_password。對此端點的 POST 請求會將用戶 user_id 的密碼更改為 new_password。此端點不驗證 user_id 參數，因此，任何用戶都可以通過操作 user_id 參數來更改其他任何人的密碼。一份好的報告摘要是清晰簡潔的。它包含了解漏洞所需的所有信息，包括錯誤是什么、發現錯誤的位置以及攻擊者在被利用時可以做什么。

并非每一個漏洞，組織都能成功的復現，比如IOS，安卓的證書繞過等，它們即有可能在您測試時，使用了一到兩個實體機器，并root了一些權限。因此，報告中如果出現復現依賴與環境部署，是您獨有的優勢之一，為職業化，交互性，商業化，營銷化，達不溜化建立了多個良好的發展之路。

漏洞內容的核心價值觀在于，組織易于復現與確認。
考慮到組織接收人員的整個大背景，最好從實施開始描述。
比如： 漏洞內容標題：反序列化導致RCE漏洞

1.復現依賴：需要自動化利用工具Ysoserial （使用上類似于sqlmap）
需要下載Ysoserial (https://github.com/frohoff/ysoserial/)測試時使用 JRE 11 TLS版本

2.漏洞利用（加截圖）
java -jar ysoserial.jar CommonsCollections1 calc.exe

3.修復建議
輸入檢查
白名單反序列化允許的類
防止篡改序列化 cookie，可以跟蹤服務器上的會話狀態
使用簡單的數據類型，如字符串和數組，能不用序列化就別用
留意補丁并確保依賴項是最新的
owasp反序列化備忘單：https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

第 3 步：包括嚴重性評估

您的報告還應包括對錯誤嚴重性的誠實評估。除了與您合作修復漏洞之外，安全團隊還有其他職責需要處理。包括嚴重性評估將幫助他們優先修復哪些漏洞，并確保他們立即處理關鍵漏洞。

比如： 追加標題： 漏洞評級：嚴重
攻擊者可以從外網任何一個地方，利用ysoserial.jar工具發起反序列化RCE攻擊。

比如：追加標題： 漏洞評級：低危
攻擊者需要配合釣魚或者xss，才能結合CORS一起實施攻擊。

如果您無法給出一個定論：可以參考其他評分組織。

在 https://www.first.org/cvss/ 研究通用漏洞評分系統 (CVSS)，以大致了解每種類型的漏洞的重要性。 CVSS 等級考慮了諸如漏洞如何影響組織、漏洞利用的難度以及漏洞是否需要任何特殊權限或用戶交互才能利用等因素。 然后，試著想象一下您的客戶公司關心什么，以及哪些漏洞會對業務產生最大的影響。定制您的評估以適應客戶的業務優先級。

例如，約會網站可能會發現一個錯誤，該錯誤將用戶的出生日期暴露為無關緊要，因為用戶的年齡已經是網站上的信息，而求職網站可能會發現類似的錯誤，因為申請人的年齡應該是機密的在求職過程中。另一方面，用戶銀行信息泄露幾乎總是被認為是一個高嚴重性問題。如果您不確定您的漏洞屬于哪個嚴重等級，請使用漏洞賞金平臺的評級量表。例如，Bugcrowd 的評級系統考慮了漏洞的類型和受影響的功能（https://bugcrowd.com/vulnerability-rating-taxonomy/），而 HackerOne 提供了一個基于 CVSS 等級的嚴重性計算器（https:// docs.hackerone.com/hackers/severity.html）。

第 4 步：給出明確的重現步驟

包括您能想到的所有相關設置先決條件和詳細信息。最好假設另一端的工程師不了解該漏洞，也不知道應用程序是如何工作的。例如，一份還可以的報告可能包括以下重現步驟：

1.登錄該站點并訪問 https://example.com/change_password。
2.單擊更改密碼按鈕。
3.攔截請求，將user_id參數改成另一個用戶的ID。

請注意，這些步驟并不全面或明確。他們沒有指定您需要兩個測試帳戶來測試漏洞。他們還假設您對應用程序及其請求格式有足夠的了解，無需更多說明即可執行每個步驟。現在，這是來自更好報告的示例：

1.在 example.com 上創建兩個帳戶：帳戶 A 和帳戶 B。
2.以A賬號登錄example.com，訪問https://example.com/更改密碼。
3.在位于頁面左上角的新密碼字段中填寫所需的新密碼。
4.單擊位于頁面右上角的更改密碼按鈕。（UI位置截圖）
5.攔截發往https://example.com/change_password的POST請求，將user_id POST參數修改為賬號B的用戶ID。
6.您現在可以使用您選擇的新密碼登錄帳戶 B。

盡管安全團隊可能仍會理解第一份報告，但第二份報告要具體得多。通過提供許多相關詳細信息，您可以避免任何誤解并加快緩解過程。這將有助于您所在公司的整體形象與帶來更多的業務。

第 5 步：提供概念證明

對于簡單的漏洞，您提供的步驟可能就是安全團隊重現問題所需的全部步驟。但是對于更復雜的漏洞，包含記錄您的漏洞利用的視頻、屏幕截圖或照片會很有幫助，稱為概念驗證 (POC) 文件。

例如，對于 CSRF 漏洞，您可以包含一個嵌入了 CSRF 負載的 HTML 文件。這樣，安全團隊重現問題所需要做的就是在瀏覽器中打開 HTML 文件。對于 XML 外部實體攻擊，包括用于執行攻擊的精心制作的 XML 文件。對于需要多個復雜步驟才能重現的漏洞，您可以拍攝您在整個過程中走動的屏幕截圖視頻。像這樣的 POC 文件可以節省安全團隊的時間，因為他們不必自己準備攻擊負載。您還可以包含用于攻擊應用程序的任何精心制作的 URL、腳本或上傳文件。

你的屏幕截圖視頻，可以推動整個行業的發展，讓組織與平臺一看，對。我們需要這樣的功能性。

第 6 步：描述影響和攻擊場景

為了幫助安全團隊充分了解漏洞的潛在影響，您還可以說明漏洞可能被利用的合理場景。請注意，此部分與我之前提到的嚴重性評估不同。嚴重性評估描述了攻擊者利用漏洞的后果的嚴重性，而攻擊場景則解釋了這些后果的實際情況。

以下是影響部分的示例：
使用此漏洞，攻擊者更改用戶密碼所需的只是他們的 user_id。由于每個用戶的公開個人資料頁面都列出了帳戶的 user_id，因此任何人都可以訪問任何用戶的個人資料，找到他們的 user_id 并更改他們的密碼。而且因為 user_ids 只是序列號，黑客甚至可以枚舉所有 user_ids 并更改所有用戶的密碼！這個漏洞可以讓攻擊者以最小的努力接管任何人的帳戶。

一個好的影響部分說明了攻擊者如何實際利用漏洞。它考慮了任何緩解因素以及可以實現的最大影響。它永遠不應該夸大錯誤的影響或包含任何假設。

第 7 步：推薦可能的緩解措施

您還可以推薦安全團隊采取的緩解漏洞的可能步驟。這將節省團隊開始研究緩解措施的時間。通常，由于您是發現該漏洞的安全研究人員，您將熟悉該應用程序功能的特定行為，因此可以很好地提出全面修復。

但是，除非您對問題的根本原因有很好的了解，否則不要提出修復建議。內部團隊可能有更多的背景和專業知識來提供適用于其環境的適當緩解策略。如果您不確定導致漏洞的原因或可能的修復方法，請避免提供任何建議，以免混淆讀者。

您可以提出以下可能的緩解措施：
應用程序應在更改密碼請求中驗證用戶的 user_id 參數，以確保用戶有權進行帳戶修改。應用程序應拒絕并記錄未經授權的請求。

您不必深入了解修復的技術細節，因為您不了解應用程序的底層代碼庫。但作為了解漏洞類別的人，您可以提供緩解方向。

步驟 8：驗證報告

最后，始終驗證您的報告。最后一次檢查您的報告，以確保沒有技術錯誤或任何可能阻止安全團隊理解它的內容。遵循您自己的重現步驟以確保它們包含足夠的詳細信息。檢查所有 POC 文件和代碼以確保它們正常工作。通過驗證您的報告，您可以最大限度地減少提交無效報告的可能性。

報告寫得越多，所花費的時間越久，但因為價值性大，可以適度加錢。貴一點不是問題，問題是花得值不值，時間投入得值不值。

編寫精彩報告的其他提示

以下是幫助您盡可能提供最佳報告的其他提示。

不要假設任何事情

請記住，我們不是犯罪，有時候給不出完美的攻擊鏈。適度的假設或者引經論點不是不行。如果不想假設，盡量引用已經發生的案件或者行業內的共識。而不是讓自己犯罪。

首先，不要假設安全團隊能夠理解您報告中的所有內容。請記住，您可能已經使用此漏洞一周了，但對于收到報告的安全團隊來說，這是全新的信息。他們肩負著許多其他職責，而且通常不像您那樣熟悉該功能。此外，報告并不總是分配給安全團隊。較新的程序、開源項目和初創公司可能依賴開發人員或技術支持人員來處理錯誤報告，而不是擁有專門的安全團隊。幫助他們了解您的發現。

盡可能詳細，并包括您能想到的所有相關細節。包含指向解釋安全團隊可能不熟悉的晦澀安全知識的參考文獻的鏈接也很好。想想冗長的潛在后果與遺漏基本細節的后果。如果您過于冗長，最糟糕的情況是您的報告需要多花兩分鐘的時間來閱讀。但如果您遺漏了重要的細節，漏洞的修復可能會延遲，惡意黑客可能會利用該漏洞。

簡潔明了

另一方面，不要包含任何不必要的信息，例如冗長的問候、笑話或模因。安全報告是商業文件，而不是給您朋友的信。它應該是直截了當的。在不遺漏關鍵細節的情況下，使您的報告盡可能簡短。您應該始終努力節省安全團隊的時間，以便他們可以立即修復漏洞。

寫你想讀的

在寫作時始終把你的讀者放在心上，并努力為他們建立良好的閱讀體驗。用對話的語氣寫作，不要使用利茲語、俚語或縮寫。這些會使文本更難閱讀，并會增加讀者的煩惱。

專業

最后，始終以尊重和專業的態度與安全團隊溝通。耐心、及時地提供有關報告的說明。

您在撰寫報告時可能會犯錯誤，并且不可避免地會發生誤傳。但請記住，作為安全研究人員，您有能力通過在寫作中投入時間和精力來最大限度地減少這種可能性。通過磨練你的報告技巧和你的黑客技能，你可以節省每個人的時間并最大化你作為黑客的價值。

與開發團隊建立關系

您作為黑客的工作不會在您提交報告的那一刻停止。作為發現漏洞的人，您應該幫助公司修復問題并確保漏洞已完全修補。

與安全團隊建立牢固的關系將有助于更快、更順利地解決您的報告。如果您能夠始終如一地為組織的安全做出貢獻，它甚至可能會導致更大的錯誤賞金支出。一些漏洞賞金獵人甚至因為他們的漏洞賞金結果而獲得了頂級科技公司的面試或工作機會！我們將討論您報告的不同狀態、在緩解過程的每個階段您應該做什么，以及在與安全團隊溝通時如何處理沖突。

您不必在乎目前在哪，什么公司，崗位，證書，學歷等問題。一直與組織建立關系，終有一天可以突圍。

了解報告狀態

提交報告后，安全團隊會將其歸類為報告狀態，該狀態描述了報告的當前狀態。隨著緩解過程的推進，報告狀態將發生變化。您可以在漏洞賞金平臺的界面上或從安全團隊收到的消息中找到列出的報告狀態。

在組織內部的SDLC平臺里也有類似的漏洞管理狀態。

需要更多信息

您將看到的最常見的報告狀態之一是需要更多信息。這意味著安全團隊沒有完全理解您的報告，或者無法使用您提供的信息重現問題。安全團隊通常會跟進有關漏洞的其他信息的問題或請求。

在這種情況下，您應該修改您的報告，提供任何缺失的信息，并解決安全團隊的其他問題。

開發人員在修復時是真的找不到某個參數在哪里，一時半會兒無法定位到位置。會提起OA流程，讓您提供其他缺失的信息。

信息量大

如果安全團隊將您的報告標記為信息豐富，他們將不會修復錯誤。這意味著他們認為您報告的問題是一個安全問題，但不足以保證修復。不影響其他用戶的漏洞，例如在網絡游戲中提高自己分數的能力，通常屬于這一類。另一種通常標記為信息性的錯誤是缺少安全最佳實踐，例如允許用戶重復使用密碼。

報告沒有接收可能性其實非常多：比如難于修復，難于理解，難于復現，組織人員流動性，歷史遺留，測試環境與真實環境的差異性等。

在這種情況下，您對報告無能為力！公司不會給你賞金，你也不必跟進，除非你認為安全團隊犯了錯誤。但是，我確實建議您跟蹤信息豐富的問題，并嘗試將它們鏈接成更大、更有影響力的錯誤。

重復提交

重復報告狀態意味著另一個黑客已經發現了該漏洞，并且公司正在修復漏洞。不幸的是，由于公司僅將漏洞獎勵獎勵給第一個發現漏洞的黑客，因此您不會因重復而獲得報酬.除了幫助公司解決問題外，報告與此無關。您還可以嘗試將錯誤升級或鏈接為更具影響力的錯誤。這樣，安全團隊可能會將新報告視為一個單獨的問題并獎勵您。

N/A

不適用 (N/A) 狀態意味著您的報告不包含具有安全影響的有效安全問題。當您的報告包含技術錯誤或錯誤是有意的應用程序行為時，可能會發生這種情況。

N/A 報告不付款。除了繼續前進并繼續黑客攻擊之外，您沒有什么可做的！

不要沮喪：每個人都需要成長，您可以購買專業書籍已觀察別人的知識和方法。

漏洞管理與分類

安全團隊在最終驗證報告后對報告進行分類。這對您來說是個好消息，因為這通常意味著安全團隊將修復錯誤并獎勵您。

對報告進行分類后，您應該幫助安全團隊解決問題。及時跟進他們的問題，并提供他們要求的任何其他信息。

解決

當您的報告被標記為已解決時，報告的漏洞已被修復。在這一點上，拍拍自己的后背，為您讓互聯網變得更安全而感到高興。如果您正在參與付費漏洞賞金計劃，您也可以在此時收到付款！

除了慶祝和繼續黑客攻擊之外，與報告沒有任何關系。

處理沖突

并非所有報告都能快速順利地得到解決。當黑客和安全團隊在錯誤的有效性、錯誤的嚴重性或適當的支付金額上存在分歧時，沖突不可避免地發生。即便如此，沖突可能會破壞您作為黑客的聲譽，因此專業地處理它們是成功尋找漏洞的關鍵。如果您發現自己與安全團隊發生沖突，您應該這樣做。

當您與安全團隊不同意錯誤的有效性時，首先要確保您的初始報告中的所有信息都是正確的。通常，由于技術或寫作錯誤，安全團隊將報告標記為信息性或 N/A。例如，如果您在 POC 中包含不正確的 URL，安全團隊可能無法重現該問題。如果這導致了分歧，請盡快發送包含正確信息的后續報告。

另一方面，如果您沒有在報告中犯錯，但仍然認為他們錯誤地標記了問題，請發送后續郵件，解釋您認為該錯誤是安全問題的原因。如果仍然不能解決誤解，您可以請求漏洞賞金平臺或團隊中的其他安全工程師進行調解。

大多數情況下，如果漏洞不屬于眾所周知的錯誤類別，其他人很難看到它的影響。如果安全團隊不理會所報告問題的嚴重性，您應該解釋一些潛在的攻擊場景，以充分說明其影響。

最后，如果您對賞金金額不滿意，請不要怨恨地進行交流。詢問組織分配賞金的理由，并解釋為什么你認為你應該得到更高的獎勵。例如，如果你報告的負責人低估了 bug 的嚴重性，你可以在要求更高的獎勵時詳細說明問題的影響。無論你做什么，總是避免在沒有解釋的情況下索要更多的錢。

錢不是問題，合理的理由與解釋不能少，確保充分的溝通。

記住，我們都會犯錯。如果您認為處理您報告的人處理不當，請禮貌地要求重新考慮。一旦你提出你的理由之后，請尊重公司關于修復和賞金金額的最終決定。

建立伙伴關系

解決報告后，漏洞賞金之旅不會停止。您應該努力與組織建立長期合作伙伴關系。這可以幫助您更順利地解決您的報告，甚至可能會讓您獲得面試或工作機會。您可以通過尊重他們的時間并以專業精神進行溝通來與公司建立良好的關系。

首先，通過始終提交經過驗證的報告來獲得尊重。不要通過發送垃圾郵件、纏著他們索取金錢或口頭辱罵安全團隊來破壞公司的信任。反過來，他們會尊重你并優先考慮你作為研究人員。公司經常禁止不尊重或不講道理的獵人，因此不惜一切代價避免落入這些類別。

還要了解與您合作的每個組織的溝通方式。他們期望報告中有多少細節？您可以通過閱讀他們公開披露的報告，或將他們對您的報告的反饋納入未來的消息中，了解安全團隊的溝通方式。他們是否希望有大量照片和視頻來記錄錯誤？自定義您的報告，讓讀者的工作更輕松。

它們可能在未來孵化出更多的商業化產品

最后

確保您支持安全團隊，直到他們解決問題。許多組織會在報告分類時向您支付賞金，但請不要在收到獎勵后對安全團隊進行保釋！如果需要，請提供建議以幫助緩解漏洞，并幫助安全團隊確認問題已得到修復。有時，組織會要求您進行收費的重新測試。如果可以，請務必抓住這個機會。您不僅可以賺錢，還可以幫助公司更快地解決問題。參考文獻

如果你正在學習怎么去尋找漏洞的話，可以關注我，學習更多網絡安全黑客技術

點擊查看【網絡安全學習資料·攻略】

總結

以上是生活随笔為你收集整理的教怎样写好一份“漏洞报告”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。