Wei-Cheng Chiu
邱偉誠
Taipei, Taiwan · UTC+8
making every FLOP count
滲透測試入門技術
On this page
滲透測試不是掃描器：從授權邊界到可複測證據¶
2025-01-10 · updated 2026-07-21 · cybersecurity / methodology
弱點掃描器告訴你「這個版本可能有問題」。滲透測試要回答更難的問題：在明確授權 的範圍內，攻擊路徑是否真的成立、能造成什麼業務影響、修復後能否用同一份證據 確認風險消失。
判斷一份工作是否算滲透測試，要看它有沒有可追溯的假設、最小化驗證和測試風險控制。
先寫 Rules of Engagement¶
沒有書面授權，就沒有滲透測試。開始前至少要把以下內容寫進 Rules of Engagement （RoE）：1
- 明確的 IP、domain、API、帳號與環境範圍；第三方 SaaS 是否另有授權。
- 允許與禁止的手法，例如 social engineering、DoS、password spraying 或資料外傳。
- 測試時段、來源 IP、速率上限、緊急停止條件與 24/7 聯絡窗口。
- 敏感資料的處理方式：能否讀取、最多保留多久、如何加密與銷毀。
- 成功證明的界線。通常一個無害 marker 或最小資料樣本就足夠，不需要把整個資料庫 搬走。
RoE 同時決定測試方法。Production 禁止 destructive write 時，要先準備 read-only proof； 系統承受不了掃描 burst 時，則把 rate limit 寫進測試參數，避免臨場猜測。
Black box、gray box、white box 的差別在已知資訊量¶
| 模式 | 已知資訊 | 適合回答的問題 | 盲點 |
|---|---|---|---|
| Black box | 公開入口與極少背景 | 外部攻擊面暴露到什麼程度？ | 時間大量耗在 discovery，深層 coverage 低 |
| Gray box | 一般使用者帳號、部分架構 | 權限邊界與 authenticated flow 是否安全？ | 可能漏掉 source-level 缺陷 |
| White box | 原始碼、架構、測試帳號與設定 | 關鍵路徑能否被系統性覆蓋？ | 與真實外部攻擊者的資訊條件不同 |
實務上我偏好用 gray/white box 提高 coverage，再保留一段 black-box validation 檢查 公開面。把資訊藏起來不會自動讓測試更真實，只會把有限工時換成 enumeration。
一條可審核的測試流程¶
1. Scope 與 attack-surface inventory¶
先把資產、信任邊界、身份角色、資料流與第三方依賴畫出來。DNS、port、route、API schema 與 cloud identity 是 inventory；此時還不是在證明漏洞。
2. 先寫 threat hypothesis¶
每個測試項目應該能寫成一句可否證假設，例如：「tenant A 的 object identifier 能否在 tenant B 的 session 被讀取？」這比「跑一遍 scanner」更容易知道 coverage 到哪裡， 也能直接對照 OWASP Web Security Testing Guide 的測試類別。2
3. Discovery 與人工 triage¶
Scanner、SAST、dependency audit 與 service enumeration 適合找候選點，不適合直接當 finding。版本 banner 可能是 backport，status code 也可能被 WAF 改寫；每個候選結果都 要人工驗證 prerequisite、可達性與既有控制。
4. 最小化 exploitation¶
驗證做到足以證明影響就停。能用讀取一筆 synthetic record 證明 IDOR，就不要批次列舉；
能用 whoami 類無害命令證明 execution，便不需要建立 persistence。
任何超出 RoE 的 pivot 都先停下來重新取得授權。
5. Evidence chain 與 cleanup¶
一個可複測 finding 應包含時間、測試來源、前置身份、完整 request/response、受影響資產、 最小 PoC、觀察到的影響與 cleanup 記錄。Token、cookie、個資與 secret 在報告裡要遮罩， 原始證據則依約定加密保存。
6. 修復複測¶
複測不能只看頁面是否回 403。先重播原始 PoC，再測相鄰 bypass（不同 method、encoding、角色、object type）， 最後確認修復沒有破壞合法 flow。結論分成 fixed、partially fixed、not fixed 與 cannot retest，避免用模糊的「已處理」。
風險分數要連回業務影響¶
CVSS 提供可比較的 technical severity，但優先順序仍需結合 exposure、asset value、 existing controls 與 exploit preconditions。可以把 triage 想成
因此相同的 injection primitive，在隔離的測試工具與公開付款 API 上不應得到相同處理 順序。報告需要同時保留 CVSS vector 與 organization-specific rationale，不能只留一個 紅色數字。4
按測試問題選工具¶
- 資產與網路面：DNS/ASN inventory、Nmap 類 service discovery。
- Web/API：intercepting proxy、schema-driven API tests、OWASP ZAP 類自動化輔助。
- 程式與供應鏈：SAST、secret scan、SBOM/dependency audit。
- Cloud / identity：IAM policy analysis、role assumption 與 storage exposure checks。
- 證據與重現：可版本控制的 request fixtures、時間戳、hash 與 retest scripts。
Kali 提供工具，測試流程則由 PTES、NIST SP 800-115 與 OWASP WSTG 定義，包括如何 規劃、執行、記錄與溝通測試。312
一份 finding 至少要讓修復者回答六件事¶
- 哪個資產與版本受到影響？
- 需要什麼身份與前置條件？
- 最短的重現步驟是什麼？
- 實際觀察到的技術與業務影響是什麼？
- 建議修復的是 root cause 還是暫時 compensating control？
- 用什麼 acceptance test 判斷修復完成？
交付時，團隊應能確認成立的攻擊路徑、重現與修復所需的證據，以及整次測試是否守住 授權與營運邊界。