title: “Web Pentest のワークフロー” part: “Part 3” chapter: “3-2”

Web Pentest のワークフロー

本章では、Burp Suite を用いた典型的な Web Pentest のワークフローを、「情報収集 → アタックサーフェス（攻撃面 / Attack Surface）の把握 → 脆弱性仮説の立案 → 検証・PoC 作成」という流れで整理する。

本章のゴール

• 前提：Burp Suite の基本操作とセットアップ（前章）を完了している。
• 到達目標：情報収集、アタックサーフェス整理、仮説立案、検証、結果整理を一連のワークフローとして説明し、再現性を意識して運用できる。
• 対応演習：exercises/juice-shop/ または exercises/dvwa/ を対象に、Target でサイトマップを整理し、重要操作を Repeater に保存した上で、仮説ベースでパラメータを変更して挙動差分を記録する（起動手順は 付録「演習環境クイックスタート」 を参照）。

図3-2: Web Pentest ワークフロー（概要）

flowchart TB
    Recon[1. 情報収集（Reconnaissance）\nProxy + ブラウザ操作] --> Auth[2. 認証/セッション確認\nCookie・ログイン挙動]
    Auth --> Surface[3. アタックサーフェス整理\nTarget（サイトマップ）]
    Surface --> Hypo[4. 仮説に基づく検証\nRepeater / Intruder]
    Hypo --> Findings[5. 発見事項の整理・評価\n優先度付け]
    Findings --> Repro[6. 再現性の確保\nリクエスト/レスポンス保存]
    Repro --> Report[PoC・レポーティング]

図3-2 は、本章で扱う 1〜6 の流れをまとめたものである。以降は、各ステップで「何を観察し、どのように記録するか」を具体化する。

1. 情報収集（Reconnaissance）

最初のステップは、対象アプリケーションの構造と機能を把握することである。Burp Proxy を有効にした状態で、通常のユーザとしてアプリケーションを一通り操作し、次の点に着目する。

• ホスト、パス、パラメータの一覧
• 認証機能（ログイン、ログアウト、パスワードリセットなど）
• 権限レベル（一般ユーザ、管理者、API クライアントなど）
• 入力フォーム（検索、登録、更新、削除など）

Burp の Target タブでは、観測したパスがツリービューで表示されるため、「どの URL がどの機能に対応しているか」を整理しやすい。対象範囲外のドメインはスコープから除外しておく。

2. セッション管理と認証の確認

次に、セッション管理と認証周りの挙動を確認する。

• ログイン前後で Cookie（セッション ID）がどのように変化するか
• Secure / HttpOnly / SameSite 属性の有無
• 多要素認証や IP 制限など追加のセキュリティ層の存在

ログインリクエストおよび重要な操作（権限変更、パスワード変更など）は、必ず Repeater に送っておき、後続の検証で再利用できるようにする。

3. アタックサーフェスの特定

情報収集の結果をもとに、どこにアタックサーフェスが存在しうるかを整理する。

• 外部入力を受け取るポイント（パラメータ、ヘッダ、ボディ、JSON、GraphQL など）
• 状態変更を伴う POST/PUT/DELETE リクエスト
• ファイルアップロード、リダイレクト、外部 URL 参照機能

Burp の「Issue definitions」や OWASP WSTG の分類を参考にしつつ、「このエンドポイントでは XSS が成立しうるか」「この API では BOLA があり得るか」といった仮説を立てる。

4. 仮説に基づく検証（Repeater / Intruder）

アタックサーフェスが整理できたら、個別の仮説に基づいて検証を行う。

• Repeater を用いた手動テスト
  パラメータやヘッダを少しずつ変更し、レスポンスの変化を観察する。XSS、SQL インジェクション、アクセス制御不備など、主に論理的な検証に向く。
• Intruder を用いた半自動テスト
  認証試行（ブルートフォース／クレデンシャルスタッフィング）、IDOR / BOLA 調査（連番 ID の列挙）、入力長や文字種の境界テストなど、一定パターンを持つ繰り返しテストに適する。

検証結果は、後述の PoC 作成とレポーティングに利用できるよう、パラメータ値・レスポンスコード・レスポンス本文などを記録しておく。

5. 発見事項の整理とリスク評価

発見した挙動が「仕様上の想定」であるのか、「脆弱性」と言えるのかを判断するため、Part 1 で扱ったリスク評価の観点（DREAD やビジネスインパクト）を適用する。

• 認証を要する機能に対して、認証なしでアクセス可能か
• 他者のデータを閲覧／変更できるか（IDOR / BOLA）
• セキュリティ上のベストプラクティス（ASVS 等）から明らかに逸脱しているか

ここでの整理が、そのままレポートの章立てや優先度に直結する。

6. 再現性の確保

Pentest の結果は、「一度だけ再現できた」だけでは不十分である。将来の検証や修正確認のため、次の点を意識して再現性を確保する。

• Repeater のタブに、脆弱性の再現に必要な最小限のリクエストを保存する
• オプションとして、Burp のプロジェクトファイルに一連のテスト状態を保存する
• 後のレポートで利用できるよう、画面キャプチャや重要なレスポンスを整理しておく

次章『PoC 作成とレポーティング』では、これらのワークフローからどのように PoC とレポートを作成するかを扱う。

本章のポイント

• Web Pentest は「情報収集 → アタックサーフェス整理 → 仮説立案 → 検証 → 結果整理」の順で進めると再現性を確保しやすい。
• Burp Suite の Target / Repeater / Intruder を使い分け、重要リクエストを保存して検証の土台にする。
• 発見事項は DREAD や ASVS 等の観点で評価し、報告に直結する形で記録しておく。