滲透測試報告怎麼寫？報告架構、漏洞描述格式與撰寫注意事項
2025 年 2 月 17 日
滲透測試做得再漂亮，客戶最後拿到的只有一份報告。報告寫不清楚，發現的漏洞就修不了，測試的價值也打了折扣。這篇整理滲透測試報告書的標準架構、每個段落該寫什麼，以及撰寫時最常被忽略的注意事項。
先從測試紀錄開始
好的報告建立在完整的測試紀錄上。執行過程中就要隨手記錄，事後才不用憑記憶補寫。每一筆紀錄至少包含：
- 測試重點與檢測項目：測了哪些目標、哪些範圍
- 使用的工具與方法論：例如 OWASP Testing Guide、PTES
- 過程描述：時間、指令、參數、操作步驟
- 檢測結果與截圖：截圖、截圖、再截圖，這是證明漏洞存在最直接的證據
多人協作的專案可以使用 Dradis Framework 這類平台，集中管理每位成員的發現與證據，最後直接匯出報告。
滲透測試報告的標準架構
滲透測試報告就像在寫論文，結構要清楚、證據要充分。一份完整的報告通常包含：
| 章節 | 內容重點 | 主要讀者 |
|---|---|---|
| 前言 | 測試背景、目的、委託單位 | 全部 |
| 聲明 | 授權範圍、測試期間、免責與保密條款 | 法務、管理層 |
| 摘要（Executive Summary） | 整體風險等級、關鍵發現、優先處理建議，避免技術術語 | 管理層 |
| 執行方式 | 測試範圍、方法論、工具清單、測試帳號與限制 | 技術主管 |
| 執行過程說明 | 依時間或攻擊鏈描述測試步驟 | 技術人員 |
| 發現事項與改善建議 | 每個漏洞的描述、風險等級、重現步驟、證據、修補建議 | 開發與維運 |
| 附件或參考 | 原始掃描結果、完整截圖、CVE 與參考文件連結 | 技術人員 |
單一漏洞該怎麼寫？
「發現事項」是報告最核心的部分，每個漏洞建議用固定格式呈現：
- 標題：漏洞類型與影響位置，例如「會員查詢 API 存在 SQL Injection」
- 風險等級：Critical / High / Medium / Low，建議附 CVSS 分數與計算向量
- 影響範圍：受影響的主機、URL、參數
- 漏洞描述：成因與可能的影響
- 重現步驟：讓對方照著做就能重現
- 證據：截圖、請求與回應內容
- 修補建議：具體可執行的修正方式，而不是只寫「請修正」
撰寫注意事項
- 圖表重於文字：攻擊路徑、風險分布用圖表呈現，比大段文字更好懂
- 術語採中英對照：例如「跨站腳本攻擊（XSS）」，兼顧不同背景的讀者
- 摘要寫給非技術人員：管理層通常只看摘要，要能直接看出風險與優先順序
- 敏感資料要遮蔽：密碼、個資、Token 在截圖中打碼
- 建議要可執行：附上設定範例或官方修補連結
- 交付前交叉檢查：確認每個發現都有證據、風險等級一致
如何提升滲透測試能力？
報告寫得好，前提是測得夠深入。建議從以下幾個方向打底：
- 網路原理：TCP/IP、HTTP、DNS，可搭配 Wireshark 封包分析 練習
- 密碼學：雜湊、加解密與常見誤用
- 漏洞研究：閱讀 CVE 與漏洞分析文章，例如 Local File Inclusion
- 注入技巧：SQL Injection、Command Injection、SSRF 等
- 資料管理：整理測試紀錄與證據，讓報告撰寫事半功倍