パス列挙法とパストラバーサルの全体像：脆弱性の仕組みから防御・診断・対策までの実践ガイド
エバープレイ編集部パス列挙法とは
パス列挙法（パス列挙、Path Enumeration / Path Traversal と関連して扱われることが多い）は、ウェブアプリケーションやサーバ上のファイルやディレクトリ構造を探索・特定する手法の総称です。攻撃者が意図的にリクエストのパスやパラメータを操作して、サーバ内部に存在するファイルを特定・取得したり、想定外のファイルにアクセスしたりすることを指します。用途としては、情報収集、機密情報の窃取、さらなる侵害の足がかり作りなどが挙げられます。
背景と分類
- 強制ブラウジング（Forced Browsing）／ディレクトリブルートフォース：既知のファイル名やディレクトリ名のリストを順次リクエストして存在有無を調べる方法。公開されていない管理ページやバックアップファイルを発見することがある。
- パストラバーサル（Path Traversal）：パスに「../」のような上位ディレクトリへ遡る表現やエンコード手法を用いて、本来アクセスできないファイルへ到達しようとする攻撃。CWE-22（不適切なパス名制限）に該当する脆弱性。
- パス開示（Path Disclosure / Path Disclosure Vulnerability）：エラーメッセージやスタックトレースなどでサーバ内部パスが漏れるケース。列挙を容易にする情報源となる。
仕組み（どうやって“列挙”が行われるか）
攻撃者はアプリケーションの入力（URLパス、クエリ文字列、フォームパラメータ、ファイルアップロード名など）を操作して、サーバの挙動の違い（HTTPステータスコード、レスポンス長、エラーメッセージ）を観察します。例えば、存在しないファイルを要求したときの応答と、存在するファイルを要求したときの応答の差異を利用して、ファイルの存在を推測します。パストラバーサルでは「../」やそのエンコード表現を使い、ドキュメントルートの外側にある機密ファイルへアクセスを試みます。
具体例（概念を示すための例）
以下は概念説明のための単純化した例です（悪用を助長する目的ではありません）。
- 通常の要求: GET /images/logo.png
- 強制ブラウジングの試行例: GET /admin/, GET /backup/, GET /config.bak — 存在すれば 200、なければ 404 など
- パストラバーサルの試行例（概念）: GET /download?file=../../../../etc/passwd — サーバ側で不適切にパスを検証していると、意図しないファイルが返る可能性がある
実際の攻撃では、URLエンコードやUTF-8の多重エンコード、特殊文字、シンボリックリンク、Filesystemの違い（Windows: C:\path、UNCパス）などを駆使してバイパスを試みることがあります。
影響（リスク）
- 機密情報の漏洩（設定ファイル、パスワード、APIキー、データベース接続情報など）
- アプリケーションの内部構造の露呈（管理ページ、バックアップファイルの存在確認）による追加攻撃の足がかり
- 場合によっては任意コード実行や権限昇格に繋がる（重要設定の流出やログイン情報の取得等）
- 信頼失墜や法的・経済的な損害
発見・診断方法（防御・検査の視点）
開発・運用チーム、セキュリティ担当者が検出・診断するときに有効なポイントを列挙します。
- ログ解析：URLに「../」や長いファイル名、既知のバックアップ拡張子（.bak, .old, .swp など）が含まれるアクセスを監視する。
- 異常レスポンスの検出：通常と異なるステータスコードやレスポンス長の差分、エラーメッセージの出力を検知する。
- 静的解析：ソースコードでファイルアクセス周りの入力検証が適切に行われているか（path normalization をしているか、ホワイトリストか）を確認する。
- ダイナミックテスト（ペネトレーションテスト）：テスト用に作成したワードリストで強制ブラウジングやパス操作を実施し、応答を確認する（実運用環境では責任者の許可のもとで行う）。
対策・予防策（実践的なガイドライン）
以下は一般的かつ実践可能な対策です。複数を組み合わせることで安全性を高めます。
- ホワイトリスト方式の入力検証：許可されるファイル名・ディレクトリ名を明示的に限定する。拡張子のチェックや正規表現による厳格な検証が有効。
- パス正規化（canonicalization）と検証：OSの正規化関数（例：Java の getCanonicalPath、PHP の realpath など）でパスを解決し、想定のベースディレクトリに含まれているかをチェックする。ただし realpath は symlink 等で意図しない挙動をする場合があるため注意が必要。
- 相対パスの遮断：ユーザ入力をファイルパスとして直接結合しない。IDやトークンなど抽象化された参照を用いて内部でパスにマッピングする方式が安全。
- 最小権限の原則：アプリケーション実行ユーザに必要最低限のファイルアクセス権のみを付与し、重要ファイルは別ユーザ/位置に保管する。
- ディレクトリの隔離（chroot/jail）やコンテナ化：アプリケーションがアクセスできるファイルシステム範囲を狭める。
- エラーハンドリング：スタックトレースやフルパスを含むメッセージを外部に出さない（運用ログには残すが、ユーザへは要約したメッセージのみ返す）。
- WAF とシグネチャ検知：不審なパス文字列やエンコードの痕跡を検知してブロックする。ただし誤検知に注意。
開発者向けチェックリスト
- ユーザ入力を直接ファイルパスに結合していないか確認する。
- ファイルアクセス前にパスの正規化を行い、期待するベースディレクトリに収まっているか検証する。
- ファイル名はホワイトリストまたはトークン化で管理する。
- 重要な設定ファイルやキーはアプリケーションとは別の安全な場所に保管する。
- エラーメッセージに内部パスが露出していないか確認する。
- CI/CD に静的解析や動的解析（SAST/DAST）を組み込む。
ツールとリソース（運用・検査でよく使われるもの）
セキュリティ診断や検査で列挙の有無を確認するために使われるツールがいくつかあります。これらは正当な権限のもとでのみ利用してください。
- ワードリストベースの強制ブラウザ（ディレクトリ列挙）ツール（例: gobuster、dirb、wfuzz 等）
- ウェブアプリケーション脆弱性スキャナ（動的解析ツール、ただし誤検知や負荷に注意）
- ログ解析・SIEM：パスに関する異常なアクセスパターンの検出
注意点・限界
対策を講じても完全な安全は存在しません。realpath 等の関数に頼る場合、シンボリックリンクやOS固有の挙動、エンコードバイパスに注意が必要です。また、WAF に頼り過ぎるとアプリケーション側の根本対策が疎かになる可能性があります。したがって、入力検証・最小権限・正規化の三本柱を意識した防御が重要です。
まとめ
パス列挙法は、表面的には単純な手法に見えますが、誤配置されたファイル、弱い入力検証、過剰に情報を返すエラーメッセージなどの組合せによって重大な被害につながることがあります。開発・運用の両面で「どのファイルを誰が参照できるのか」を明確にし、ホワイトリストやパス正規化、最小権限の原則など複数の対策を組み合わせることが重要です。
参考文献
- OWASP — Path Traversal
- OWASP Top Ten（ウェブ脆弱性の全体像）
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- Gobuster（GitHub）
- Wfuzz（GitHub）
- MDN — Percent-encoding（URLエンコードの説明）
投稿者プロフィール
