実務で使えるペネトレーションテスト大全

典型的な Web 脆弱性の整理

本章では、後続の Part 3 以降で詳細に扱う代表的な Web 脆弱性を、プロトコルレベルの観点から概観する。ここでは「名前と概要」「成立の前提」「大まかな検証イメージ」に留め、具体的な手順やツール操作は後続の Part に委ねる。

本章のゴール

  • 前提：HTTP / Cookie / セッション / トークンの基礎（本 Part 前半）を把握している。
  • 到達目標：代表的な脆弱性（XSS、インジェクション、認可不備、SSRF 等）について、成立の前提をプロトコル視点で説明できる。
  • 対応演習：exercises/juice-shop/ や exercises/dvwa/ で、各脆弱性が成立する入口と「どのリクエストが変わると挙動が変わるか」を観察する。
    起動手順は 付録「演習環境クイックスタート」 を参照し、観察結果は 学習ログテンプレート（Burp Academy / 演習） に記録する。具体手順は Part 3 以降で扱う。

図2-5 は、本章で扱う代表的な脆弱性クラスを「どの通信・処理の境界で起きる問題か」という観点で対応付けた概要図である。以降は、各脆弱性について「入力」「出力」「権限」「サーバ側リクエスト」といった観点で成立条件を整理する。

図2-5: 典型的な Web 脆弱性の対応関係（プロトコル視点の整理）

flowchart LR
    U[ブラウザ（被害者）] -->|HTTP リクエスト| W[Web アプリケーション]
    W -->|HTTP レスポンス| U

    W -->|クエリ/更新| DB[(DB)]
    W -->|サーバ側リクエスト| S[外部/内部サービス]
    W -->|リダイレクト| U

    VInj[インジェクション/トラバーサル\n（入力処理の不備）] -.-> W
    VXSS[XSS\n（出力処理の不備）] -.-> U
    VAuth[認可不備\n（アクセス制御の不備）] -.-> W
    VSSRF[SSRF\n（サーバ側リクエストの悪用）] -.-> S
    VRedir[オープンリダイレクト\n（遷移先の検証不備）] -.-> U

クロスサイトスクリプティング（XSS）

XSS は、攻撃者が用意したスクリプトが被害者のブラウザ上で実行される脆弱性であり、主なパターンは以下のとおりである。

  • 反射型（Reflected XSS）
    リクエストパラメータがそのままレスポンスに反映されるケース。
  • 蓄積型（Stored XSS）
    掲示板やコメント欄などに保存されたデータが、閲覧時にスクリプトとして実行されるケース。
  • DOM ベース XSS
    クライアントサイド JavaScript のみで DOM 操作が行われる結果、XSS が成立するケース。

成立要件としては、入力値の不足したエスケープ／サニタイズ、およびコンテキスト不一致（HTML/属性/JavaScript コンテキストの混在）などが挙げられる。影響としては、Cookie やローカルストレージの窃取、CSRF トークンの窃取、任意操作の実行などが考えられる。

インジェクション（SQL インジェクション等）

インジェクション系脆弱性は、ユーザー入力が適切に検証・エスケープされないまま、コマンドやクエリとして評価されることで発生する。

  • SQL インジェクション
    入力値を通じて SQL クエリの構造が変更され、データベースの情報漏えいや改ざんが発生する。
  • コマンドインジェクション
    OS コマンドの引数にユーザー入力が埋め込まれ、任意コマンド実行が可能となる。
  • LDAP / NoSQL インジェクションなど
    特定のクエリエンジン固有の構文を悪用するパターン。

代表的な対策は、プレースホルダ（バインド変数）によるパラメータ化、ホワイトリストベースの入力検証、および最小権限の付与である。Pentest では、典型的なペイロードによる挙動変化の確認に加え、「誤ったエラー応答」「タイミングの変化」など副次的なシグナルにも注意を払う。

パス・ディレクトリトラバーサル

ユーザー入力がファイルパスに利用される場合、../ などを用いて想定外のディレクトリにアクセスできる場合がある。これにより、アプリケーションの設定ファイルや OS の機密ファイルが漏えいするリスクがある。

対策としては、パスの正規化とホワイトリストによる制限（特定ディレクトリ配下に限定する）、拡張子の固定、OS 依存のショートカット（C:\、//?/ など）への考慮などが挙げられる。

不適切なアクセス制御（認可不備）

OWASP Top 10 2021 の A01（Broken Access Control）に代表されるように、認可不備は近年の Web / API における最重要カテゴリの一つである。

典型的なパターンには次のようなものがある。

  • URL 変更や ID 変更により、他者のリソースにアクセス可能（IDOR / BOLA）
  • クライアント側の UI から隠されているだけで、バックエンドではアクセス制御されていない機能
  • ロールや権限による制御が、クライアント側のフラグに依存している

Pentest では、単一リクエストの挙動だけでなく、「異なるユーザー・ロール間で同一リクエストを再現した場合の違い」に着目してテストを行う。

SSRF（Server-Side Request Forgery）

SSRF は、サーバ側が外部に対して HTTP リクエストを行う機能（URL 取得、Webhook、API プロキシなど）を悪用し、本来アクセスできない内部ネットワークやメタデータサービス（例：AWS の IMDS）にアクセスさせる攻撃である。

クラウド環境では、SSRF を起点として IMDSv1 から認証情報を取得し、クラウドリソースへの不正アクセスに繋がるケースがある。Part 6 では、この攻撃パスをより詳細に扱う。

オープンリダイレクト

アプリケーションがリダイレクト先 URL をユーザー入力に依存して決定している場合、任意の外部サイトへのリダイレクトが可能となることがある。これ自体は単独で致命的な脆弱性とならないケースも多いが、フィッシングや OAuth2 フローの悪用（認可コードの奪取など）と組み合わせると影響が大きくなる。

本 Part 以降との関係

本章で挙げた脆弱性は、いずれも HTTP / Cookie / CORS / SameSite、セッション管理、JWT / OAuth2 / OIDC といった基盤要素と密接に関係する。Part 3 以降では、これらを前提として次のような観点を詳細に扱う。

  • 実際のリクエスト／レスポンスをどのように観察し、アタックサーフェスを特定するか
  • Burp Suite や各種ツールを用いて、どのように PoC を構築するか
  • 発見した脆弱性を、どのようなリスクシナリオとして整理し、報告するか

Part 2 を通じて、これらの脆弱性が「なぜ成立するか」を整理しておくことで、後続の実践 Part での理解が大きく向上する。

次に読む Part

本章のポイント

  • 代表的な Web 脆弱性（XSS、インジェクション、トラバーサル、認可不備、SSRF 等）は、入力・出力・権限・通信経路の前提が崩れることで成立する。
  • 重要なのは手法の暗記ではなく、HTTP / Cookie / セッション / トークン等の基盤要素と結びつけて「成立条件」を説明できることである。
  • Part 3 以降では、Burp Suite 等を用いて実リクエストを観察しながら、PoC 作成と報告への落とし込みを具体化する。
Edit this page on GitHub