寫好報告

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

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

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

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

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

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

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

【技術(shù)學習】

第 1 步：制作描述性標題

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

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

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

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

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

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

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

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

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

第 3 步：包括嚴重性評估

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

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

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

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

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

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

第 4 步：給出明確的重現(xiàn)步驟

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

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

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

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

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

第 5 步：提供概念證明

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

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

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

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

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

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

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

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

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

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

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

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

步驟 8：驗證報告

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

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

編寫精彩報告的其他提示

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

不要假設任何事情

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

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

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

簡潔明了

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

寫你想讀的

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

專業(yè)

最后，始終以尊重和專業(yè)的態(tài)度與安全團隊溝通。耐心、及時地提供有關(guān)報告的說明。

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

與開發(fā)團隊建立關(guān)系

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

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

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

了解報告狀態(tài)

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

在組織內(nèi)部的SDLC平臺里也有類似的漏洞管理狀態(tài)。

需要更多信息

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

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

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

信息量大

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

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

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

重復提交

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

N/A

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

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

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

漏洞管理與分類

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

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

解決

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

除了慶祝和繼續(xù)黑客攻擊之外，與報告沒有任何關(guān)系。

處理沖突

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

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

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

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

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

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

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

建立伙伴關(guān)系

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

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

還要了解與您合作的每個組織的溝通方式。他們期望報告中有多少細節(jié)？您可以通過閱讀他們公開披露的報告，或?qū)⑺麄儗δ膱蟾娴姆答伡{入未來的消息中，了解安全團隊的溝通方式。他們是否希望有大量照片和視頻來記錄錯誤？自定義您的報告，讓讀者的工作更輕松。

它們可能在未來孵化出更多的商業(yè)化產(chǎn)品

最后

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

如果你正在學習怎么去尋找漏洞的話，可以關(guān)注我，學習更多網(wǎng)絡安全黑客技術(shù)

點擊查看【網(wǎng)絡安全學習資料·攻略】

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。