前言#
根據個人經驗，滲透測試報告可以分為兩類：簡單報告和正式報告。簡單報告主要是對漏洞內容進行簡要總結，這種報告主要是技術性的，不適合供領導查看。正式報告則比較複雜且正式，可用於項目總結和驗收章報告。
之前看到一篇文章，介紹了如何撰寫高質量的漏洞報告，對於國外的滲透測試報告進行了總結，附件中還有其他報告可以參考。
簡單報告#
| 名稱 | 描述 |
|---|---|
| 摘要 | 對漏洞問題及其範圍進行簡要描述 |
| 影響 | 漏洞的危害程度 |
| 複現步驟 | 包括屏幕截圖、HTTP 請求、POC 或 EXP 等複現流程 |
| 建議 | 修復建議 |
| 參考資料 | 一般不加 |
漏洞評分和漏洞危害等級一般體現了漏洞的危害程度，分別為信息、低、中、高等級。
正式報告#
這篇報告是根據一個名為 securitum-protonmail-security-audit 的報告進行總結，比較實用，附件中還有其他報告可以參考。
一、總結（工作、滲透）
- 測試範圍
- 測試方法（OWASP TOP10、OWASP ASVS）
- 發現的漏洞
在測試過程中，特別強調可能對處理的數據的機密性、完整性或可用性產生負面影響的漏洞。
作為測試的一部分，使用基於手動測試的方法（使用上述方法論）並輔以多種自動化工具進行了測試，其中包括 Burp Suite Professional、DirBuster、ffuf、nmap、Visual Studio Code、semgrep、grep 和 sonarqube。
漏洞在報告的後續部分中進行了詳細描述。
== 漏洞風險等級：==
漏洞按照五級評分進行分類，反映了漏洞被利用的概率和其利用所帶來的業務風險。以下是每個嚴重程度級別的簡要描述含義。
- 嚴重
- 高危
- 中危
- 低危
- 信息
漏洞統計：
圖形化展示
二、版本修改記錄
- 時間
- 版本
- 修改描述
三、漏洞複現過程記錄
- 漏洞名稱
- 漏洞描述
- 攻擊的先決條件
- 技術詳情（POC）
- 漏洞位置
- 修復建議
學習到的內容
在撰寫報告時，建議使用被動語態，而不使用第一人稱。
當你撰寫修復建議時，一般可以以建議開頭，而不是強制性地按照某種方法進行修復漏洞。
國外的報告和我們的報告有一個不同之處是，最終總結的位置不同，國外的報告喜歡將總結放在開頭，我們則喜歡放在結尾，有時也會放在開頭進行總結。
在漏洞複現部分，國外的報告非常詳細，甚至會包括信息類的漏洞，漏洞修復建議更貼近系統，而不是通用的解決建議。
在複現漏洞場景時，以攻擊者和受害者的角度進行複現，讓其他人一眼就能看懂，相比國內的漏洞通報，圖片都不給你，只給文字和鏈接說明，要看懂這個漏洞需要一定的功底。
國外的報告還會對漏洞進行編號，感覺是按項目名稱進行編號的，這樣可以明確區分這些漏洞。
撰寫報告其實沒有太多技術活，但是要讓別人看得懂，寫出一份高質量的報告比較困難，筆者有過這種經歷，一份報告根據客戶的意見改了 5-6 遍才滿意，報告本身也是流程性的，只要弄出模板，根據模板改其他人就行。有些報告則是提交 src 的報告，這種報告只需要簡單報告就行。
參考：best-practices-for-writing-quality-vulnerability-reports
其他的一些報告參考：更多滲透測試報告