學習更多滲透技能！體驗靶場實戰練習
滲透影片教程 思路技巧 面試案例 滲透思維導圖 練手靶場 聯絡小助理領取
寫好報告
漏洞賞金獵人的工作不僅僅是尋找漏洞；它還向組織的安全團隊解釋它們。
如果您提供一份寫得很好的報告，您將幫助與您合作的團隊重現漏洞利用，將其分配給適當的內部工程團隊，並更快地解決問題。
商業化的報告模板是一個不錯的形式，但比它更出色的是，觀察與思考。
從工作流程的角度來說，漏洞管理與賬面核對也非常重要。
一個組織如果長時間接收到報告，那麼面臨到的問題一定是一些個性化的。
比如，漏洞管理過程中，命名的規範直接導致這個能否一眼看出是否重複提交，是否易於管理與記賬，是否存在資料之間的關聯與匹配性。
文件名稱規範化：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漏洞
關於反序列化的精彩案例可以參考 https：//www。freebuf。com/articles/web/290759。html
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 步：推薦可能的緩解措施
您還可以推薦安全團隊採取的緩解漏洞的可能步驟。
這將節省團隊開始研究緩解措施的時間。通常，由於您是發現該漏洞的安全研究人員，您將熟悉該應用程式功能的特定行為，因此可以很好地提出全面修復。
但是，除非您對問題的根本原因有很好的瞭解，否則不要提出修復建議。內部團隊可能有更多的背景和專業知識來提供適用於其環境的適當緩解策略
如果您不確定導致漏洞的原因或可能的修復方法，請避擴音供任何建議，以免混淆讀者。
您可以提出以下可能的緩解措施：
您不必深入瞭解修復的技術細節，因為您不瞭解應用程式的底層程式碼庫。但作為了解漏洞類別的人，您可以提供緩解方向。
步驟 8：驗證報告
最後，始終驗證您的報告。
最後一次檢查您的報告，以確保沒有技術錯誤或任何可能阻止安全團隊理解它的內容。
遵循您自己的重現步驟以確保它們包含足夠的詳細資訊。檢查所有 POC 檔案和程式碼以確保它們正常工作。
透過驗證您的報告，您可以最大限度地減少提交無效報告的可能性。
報告寫得越多，所花費的時間越久，但因為價值性大，可以適度加錢。貴一點不是問題，問題是花得值不值，時間投入得值不值。
編寫精彩報告的其他提示
以下是幫助您儘可能提供最佳報告的其他提示。
不要假設任何事情
請記住，我們不是犯罪，有時候給不出完美的攻擊鏈。適度的假設或者引經論點不是不行。如果不想假設，儘量引用已經發生的案件或者行業內的共識。而不是讓自己犯罪。
首先，不要假設安全團隊能夠理解您報告中的所有內容。請記住，您可能已經使用此漏洞一週了，但對於收到報告的安全團隊來說，這是全新的資訊。
他們肩負著許多其他職責，而且通常不像您那樣熟悉該功能。此外，報告並不總是分配給安全團隊。
較新的程式、開源專案和初創公司可能依賴開發人員或技術支援人員來處理錯誤報告，而不是擁有專門的安全團隊。幫助他們瞭解您的發現。
儘可能詳細，幷包括您能想到的所有相關細節。
包含指向解釋安全團隊可能不熟悉的晦澀安全知識的參考文獻的連結也很好。
想想冗長的潛在後果與遺漏基本細節的後果。
如果您過於冗長，最糟糕的情況是您的報告需要多花兩分鐘的時間來閱讀。
但如果您遺漏了重要的細節，漏洞的修復可能會延遲，惡意駭客可能會利用該漏洞。
簡潔明瞭
另一方面，不要包含任何不必要的資訊，例如冗長的問候、笑話或模因。
安全報告是商業檔案，而不是給您朋友的信。
它應該是直截了當的。在不遺漏關鍵細節的情況下，使您的報告儘可能簡短。您應該始終努力節省安全團隊的時間，以便他們可以立即修復漏洞。
寫你想讀的
在寫作時始終把你的讀者放在心上，並努力為他們建立良好的閱讀體驗。
用對話的語氣寫作，不要使用利茲語、俚語或縮寫。這些會使文字更難閱讀，並會增加讀者的煩惱。
專業
最後，始終以尊重和專業的態度與安全團隊溝通。耐心、及時地提供有關報告的說明。
您在撰寫報告時可能會犯錯誤，並且不可避免地會發生誤傳。
但請記住，作為安全研究人員，您有能力透過在寫作中投入時間和精力來最大限度地減少這種可能性。
透過磨練你的報告技巧和你的駭客技能，你可以節省每個人的時間並最大化你作為駭客的價值。
與開發團隊建立關係
您作為駭客的工作不會在您提交報告的那一刻停止。作為發現漏洞的人，您應該幫助公司修復問題並確保漏洞已完全修補。
與安全團隊建立牢固的關係將有助於更快、更順利地解決您的報告。
如果您能夠始終如一地為組織的安全做出貢獻，它甚至可能會導致更大的錯誤賞金支出。
一些漏洞賞金獵人甚至因為他們的漏洞賞金結果而獲得了頂級科技公司的面試或工作機會！
我們將討論您報告的不同狀態、在緩解過程的每個階段您應該做什麼，以及在與安全團隊溝通時如何處理衝突。
您不必在乎目前在哪，什麼公司，崗位，證書，學歷等問題。一直與組織建立關係，終有一天可以突圍。
瞭解報告狀態
提交報告後，安全團隊會將其歸類為報告狀態，該狀態描述了報告的當前狀態。隨著緩解過程的推進，報告狀態將發生變化。
您可以在漏洞賞金平臺的介面上或從安全團隊收到的訊息中找到列出的報告狀態。
在組織內部的SDLC平臺裡也有類似的漏洞管理狀態。
需要更多資訊
您將看到的最常見的報告狀態之一是需要更多資訊。
這意味著安全團隊沒有完全理解您的報告，或者無法使用您提供的資訊重現問題。安全團隊通常會跟進有關漏洞的其他資訊的問題或請求。
在這種情況下，您應該修改您的報告，提供任何缺失的資訊，並解決安全團隊的其他問題。
開發人員在修復時是真的找不到某個引數在哪裡，一時半會兒無法定位到位置。會提起OA流程，讓您提供其他缺失的資訊。
資訊量大
如果安全團隊將您的報告標記為資訊豐富，他們將不會修復錯誤。這意味著他們認為您報告的問題是一個安全問題，但不足以保證修復。
不影響其他使用者的漏洞，例如在網路遊戲中提高自己分數的能力，通常屬於這一類。
另一種通常標記為資訊性的錯誤是缺少安全最佳實踐，例如允許使用者重複使用密碼。
報告沒有接收可能性其實非常多：比如難於修復，難於理解，難於復現，組織人員流動性，歷史遺留，測試環境與真實環境的差異性等。
在這種情況下，您對報告無能為力！
公司不會給你賞金，你也不必跟進，除非你認為安全團隊犯了錯誤。
但是，我確實建議您跟蹤資訊豐富的問題，並嘗試將它們連結成更大、更有影響力的錯誤。
重複提交
重複報告狀態意味著另一個駭客已經發現了該漏洞，並且公司正在修復漏洞。不幸的是，由於公司僅將漏洞獎勵獎勵給第一個發現漏洞的駭客，因此您不會因重複而獲得報酬。除了幫助公司解決問題外，報告與此無關。
您還可以嘗試將錯誤升級或連結為更具影響力的錯誤。
這樣，安全團隊可能會將新報告視為一個單獨的問題並獎勵您。
N/A
不適用 （N/A） 狀態意味著您的報告不包含具有安全影響的有效安全問題。
當您的報告包含技術錯誤或錯誤是有意的應用程式行為時，可能會發生這種情況。
N/A 報告不付款。除了繼續前進並繼續駭客攻擊之外，您沒有什麼可做的！
不要沮喪：每個人都需要成長，您可以購買專業書籍已觀察別人的知識和方法。
漏洞管理與分類
安全團隊在最終驗證報告後對報告進行分類。這對您來說是個好訊息，因為這通常意味著安全團隊將修復錯誤並獎勵您。
對報告進行分類後，您應該幫助安全團隊解決問題。及時跟進他們的問題，並提供他們要求的任何其他資訊。
解決
當您的報告被標記為已解決時，報告的漏洞已被修復。在這一點上，拍拍自己的後背，為您讓網際網路變得更安全而感到高興。
如果您正在參與付費漏洞賞金計劃，您也可以在此時收到付款！
除了慶祝和繼續駭客攻擊之外，與報告沒有任何關係。
處理衝突
並非所有報告都能快速順利地得到解決。當駭客和安全團隊在錯誤的有效性、錯誤的嚴重性或適當的支付金額上存在分歧時，衝突不可避免地發生。
即便如此，衝突可能會破壞您作為駭客的聲譽，因此專業地處理它們是成功尋找漏洞的關鍵。
如果您發現自己與安全團隊發生衝突，您應該這樣做。
當您與安全團隊不同意錯誤的有效性時，首先要確保您的初始報告中的所有資訊都是正確的。通常，由於技術或寫作錯誤，安全團隊將報告標記為資訊性或 N/A。
例如，如果您在 POC 中包含不正確的 URL，安全團隊可能無法重現該問題。
如果這導致了分歧，請儘快傳送包含正確資訊的後續報告。
另一方面，如果您沒有在報告中犯錯，但仍然認為他們錯誤地標記了問題，請傳送後續郵件，解釋您認為該錯誤是安全問題的原因。
如果仍然不能解決誤解，您可以請求漏洞賞金平臺或團隊中的其他安全工程師進行調解。
大多數情況下，如果漏洞不屬於眾所周知的錯誤類別，其他人很難看到它的影響。如果安全團隊不理會所報告問題的嚴重性，您應該解釋一些潛在的攻擊場景，以充分說明其影響。
最後，如果您對賞金金額不滿意，請不要怨恨地進行交流。
詢問組織分配賞金的理由，並解釋為什麼你認為你應該得到更高的獎勵。
例如，如果你報告的負責人低估了 bug 的嚴重性，你可以在要求更高的獎勵時詳細說明問題的影響。無論你做什麼，總是避免在沒有解釋的情況下索要更多的錢。
錢不是問題，合理的理由與解釋不能少，確保充分的溝通。
記住，我們都會犯錯。如果您認為處理您報告的人處理不當，請禮貌地要求重新考慮。
一旦你提出你的理由之後，請尊重公司關於修復和賞金金額的最終決定。
建立夥伴關係
解決報告後，漏洞賞金之旅不會停止。
您應該努力與組織建立長期合作伙伴關係。這可以幫助您更順利地解決您的報告，甚至可能會讓您獲得面試或工作機會。
您可以透過尊重他們的時間並以專業精神進行溝通來與公司建立良好的關係。
首先，透過始終提交經過驗證的報告來獲得尊重。不要透過傳送垃圾郵件、纏著他們索取金錢或口頭辱罵安全團隊來破壞公司的信任。
反過來，他們會尊重你並優先考慮你作為研究人員。公司經常禁止不尊重或不講道理的獵人，因此不惜一切代價避免落入這些類別。
還要了解與您合作的每個組織的溝通方式。他們期望報告中有多少細節？
您可以透過閱讀他們公開披露的報告，或將他們對您的報告的反饋納入未來的訊息中，瞭解安全團隊的溝通方式。
他們是否希望有大量照片和影片來記錄錯誤？自定義您的報告，讓讀者的工作更輕鬆。
它們可能在未來孵化出更多的商業化產品
最後，確保您支援安全團隊，直到他們解決問題。
許多組織會在報告分類時向您支付賞金，但請不要在收到獎勵後對安全團隊進行保釋！
如果需要，請提供建議以幫助緩解漏洞，並幫助安全團隊確認問題已得到修復。有時，組織會要求您進行收費的重新測試。
如果可以，請務必抓住這個機會。您不僅可以賺錢，還可以幫助公司更快地解決問題。
原文地址：
http://33h.co/9t054
宣告：本公眾號所分享內容僅用於網安愛好者之間的技術討論，禁止用於違法途徑，否則需自行承擔，本公眾號及作者不承擔相應的後果