ディレクトリトラバーサル完全ガイド：仕組み・攻撃手法・防御・検出まで
エバープレイ編集部イントロダクション：ディレクトリトラバーサルとは何か
ディレクトリトラバーサル（Path Traversal、あるいは「ドットドット攻撃」）は、Web アプリケーションやサービスがファイルパスの取り扱いで入力検証や正規化を適切に行わない場合に、不正にサーバ内部のファイルやディレクトリへアクセスされる脆弱性の総称です。攻撃者は相対パス操作（例："../"）やエンコード技術を用いて、公開されるべきでないファイル（設定ファイル、パスワード、証明書、ソースコードなど）を読み出したり、場合によってはシステム上での任意ファイル操作につなげます。
基本的な仕組みと例
多くの Web アプリケーションは、URL パラメータやフォーム入力でファイル名を受け取り、サーバ上のパスと結合してファイルを読み込むような処理を行います。例えば：
アプリ側の処理例（擬似）: open("/var/www/html/files/" + filename)
ここで filename に "../etc/passwd" が渡されると、結合されたパスは "/var/www/html/files/../etc/passwd" となり、正規化すると "/var/www/etc/passwd"（設計次第では "/etc/passwd"）に解決されてしまいます。適切な検証や正規化をしないと、攻撃者は本来アクセスできないファイルに到達できます。
攻撃バリエーション
単純な「../」 を使うドットドット攻撃
URL エンコード（%2E%2E%2F など）や二重エンコードを使う手法：フィルタが生文字列の ".." を検出してブロックしていても、エンコードされた形をデコードする処理が別段で行われると突破されることがあります。
Windows 環境特有のバックスラッシュ（"..\"）やドライブ名（"C:\"）を利用する攻撃
NULL バイト終端攻撃（古い言語や古いライブラリでの問題）: 入力にヌル文字（%00）を挿入してパス処理を誤らせる手法（現在は多くのモダン環境で対策済み）
シンボリックリンクを悪用したトラバーサル：公開ディレクトリ内に作成されたシンボリックリンクを介して別領域へアクセス
影響範囲とリスク
ディレクトリトラバーサルの影響はアプリの設計やホスティング環境によります。代表的なリスクは次のとおりです。
機密情報の漏洩（設定ファイル、データベース接続情報、API キーなど）
ソースコードの盗用や解析により二次的な脆弱性が発見されるリスク
ログやメール情報の取得による権限昇格の足がかり
ファイルの書き込み機能が組み合わさるとリモートコード実行や永続化が可能になる場合
なぜ発生するのか（設計上の原因）
信頼できない入力を直接ファイル処理に渡すこと
パス正規化（正規パスへ解決）や入力の正しい検証が行われていないこと
プラットフォーム差（UNIX と Windows のパス区切りやエンコード挙動）の無理解
公開ディレクトリに過剰な権限を与えていること
ファイルアクセス時に最小権限原則（least privilege）を適用していないこと
検出と診断方法
ログ解析：アクセスログやエラーログで "../" や "%2e%2e" のような頻繁な出現を調べる。
自動スキャナ：OWASP ZAP、Burp Suite、Nikto などのツールはパス・トラバーサルを検出するルールを持っています。
ファジング：ファイル名パラメータに様々なエンコードやトラバーサル文字列を注入して挙動を観察する。
手動テスト：アプリケーションのファイル参照ポイントを洗い出し、相対パスやエンコード変種を試す。
アプリケーションの正規化挙動の確認：サーバ側でパスがどう解釈されるか、ロギング時と実ファイルアクセス時で差がないかを検証する。
実務的な防御策（開発者向け）
ホワイトリストの適用：受け入れるファイル名・拡張子やパスを限定する。可能なら ID ベースでファイルを管理し、ユーザ入力を実ファイル名に直接マップしない。
パス正規化の徹底：入力を受け取ったら必ず正規化（canonicalization）してから比較・アクセスを行う。多くの言語は realpath、Path.resolve、os.path.abspath などを提供しています。
ベースディレクトリの固定化と検査：許可されたベースディレクトリと結合後に、最終パスがそのベースディレクトリの下位にあることを確認する。
入力のエンコード検証：受け取ったパスに URL エンコード、UTF-8 マルチバイトエンコード、二重エンコードが含まれていないかをチェックする。
OS 特有の扱いを考慮：Windows ではバックスラッシュやドライブ名に注意し、正規化処理が予期せぬ解釈をしないか検討する。
最小権限：Web サービスがアクセスできるファイルシステム領域を可能な限り制限する（Web サーバユーザに不要なファイルやディレクトリの読み取り権限を与えない）。
安全な API の利用：直接的なファイル名連結を避け、言語やフレームワークが提供する安全なファイル操作 API を使う。
脆弱性スキャナやCI での自動チェック：新規コミットやデプロイ時にパス関連の脆弱性検査を自動化する。
運用面での防御策
不要なファイルを公開ディレクトリに置かない。設定ファイルや秘密情報はウェブルート外に保管する。
ディレクトリリスティングを無効化する。誤ってファイル一覧が見えると攻撃者に大きなヒントを与える。
Web アプリケーションファイアウォール（WAF）の導入：典型的なトラバーサルシグネチャを検出・ブロックする。ただし WAF は万能ではないため、根本対策が必要。
監査ログとアラート：不正なパス試行や高頻度のエンコード文字列へのアクセスがあればアラートを上げる。
検出ルールやシグネチャの例
代表的な検出パターンは次のとおりです（運用ログでの検出例）。
"../" や "%2e%2e%2f" の出現
複数回のエンコード（%252e%252e%252f など）
予期しない拡張子や長大なファイル名、NULL (%00) 相当のエンコーディング
テストとフォレンジック
テスト時はまずホワイトボックス（ソースコードレビュー）でファイルアクセス箇所を特定し、ブラックボックスでエンドポイントに対して変種の入力を試します。フォレンジックではログを時間軸で追い、疑わしいエンコードや参照先ファイル名を特定して被害範囲を評価します。
実務での注意点と落とし穴
単純なブラックリストでは不十分：".." をブロックしてもエンコード変種や異なる区切り文字で回避されることがある。
アプリ側とサーバ側でのデコード順序差異：例えば Web サーバが URL デコードを行い、アプリがさらにデコードすると意図しない結果になる。
同一文字列がロギング時に変換される問題：ログに残る文字列と実際にファイルアクセスに使用される文字列が異なると、後からの調査で混乱する。
まとめ：予防は多層で行う
ディレクトリトラバーサルは単純に見えるものの、エンコードやプラットフォーム差、運用ミスが複合すると深刻な情報漏洩につながります。対策はひとつだけではなく、入力のホワイトリスト化・正規化・ベースディレクトリ検証・最小権限・WAF といった多層防御を組み合わせることが重要です。開発段階でのコードレビューと自動テスト、運用時のログ監視や迅速なパッチ適用を組み合わせて、リスクを低減してください。
参考文献
- OWASP: Path Traversal
- OWASP Cheat Sheet: File Upload
- CWE-22: Improper Limitation of a Pathname to a Restricted Directory
- CWE-23: Relative Path Traversal
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
投稿者プロフィール
