ディレクトリトラバーサルとは？ 10分でわかりやすく解説

UnsplashのRicardo Cruzが撮影した写真      

Webアプリケーションの開発者や運用者にとって、ディレクトリトラバーサルは見過ごしにくい代表的な脆弱性のひとつです。入力値の扱い方を誤ると、本来公開していないはずのファイルや設定情報が読まれてしまうことがあります。この記事では、ディレクトリトラバーサルの仕組みと起こりやすい実装パターン、現場で取りやすい対策、検出・運用の勘所をまとめます。読み終えたときに、「どこが危ないのか」「自分の環境では何を優先して直すべきか」を判断できる状態を目指します。

ディレクトリトラバーサルとは

ディレクトリトラバーサルの定義

ディレクトリトラバーサルとは、Webアプリケーションが扱うファイルパスの指定やファイル参照処理を悪用して、攻撃者が本来アクセスできないはずのファイルやディレクトリに到達できてしまう脆弱性です。入力値に相対パス（例：../）などを混ぜ、ディレクトリ構造を遡らせることで、意図しないファイルを読まれたり、状況によっては書き換えられたりする危険があります。

ポイントは「Webサーバー上のファイルを直接触られる」ことではなく、アプリ側が“ファイル名を受け取って処理する”実装があるときに、入力の検証不足で想定外の場所まで参照できてしまう点です。テンプレート表示、ログ閲覧、画像の動的配信、PDFのダウンロードなど、意外と起点は多岐にわたります。

ディレクトリトラバーサルの仕組み

ディレクトリトラバーサルは、Webアプリケーションがユーザー入力をファイルパスの一部として利用しているのに、入力値を適切に検証していない場合に起こります。攻撃者は、相対パスやエンコードされた文字列などを含むリクエストを送ることで、意図しないディレクトリやファイルにアクセスを試みます。

例えば、次のようなURLが典型例として挙げられます。

この例では「..」を使ってディレクトリを遡り、本来アクセスできないはずの「/etc/passwd」に到達しようとしています。入力値がそのままファイル参照処理に渡ってしまうと、攻撃者はサーバー上の重要ファイル（設定、鍵、ログ、ソース断片など）を読める可能性があります。

なお、現場では「../」がそのまま通るとは限りません。次のような“すり抜け”が問題になることがあります。

• URLエンコード（例：%2e%2e%2f など）や二重エンコード
• バックスラッシュ（Windows系のパス）や区切り文字の違い
• 「..」自体は弾いているが、正規化（canonicalize）前にチェックしている
• 拡張子チェックのみで、ディレクトリ部分の検証が弱い

ディレクトリトラバーサルの脅威

ディレクトリトラバーサルの脅威は、単なる「ファイルが読まれる」だけにとどまりません。参照できてしまう対象によって、被害の質が変わります。

1. 機密情報の漏洩：設定ファイル、環境変数、秘密鍵、APIキー、DB接続情報、ログなどが読まれる可能性があります。
2. システム侵害の足がかり：設定情報やソース断片が漏れると、別の攻撃（認証回避、RCE、横展開など）の準備が進みやすくなります。
3. サービス停止や改ざん：読み取りだけでなく書き込み系の処理（アップロード、キャッシュ生成、テンポラリ出力）と絡むと、改ざんや破壊につながる場合があります。

ディレクトリトラバーサルは、機密性（Confidentiality）を中心に、完全性（Integrity）や可用性（Availability）にも波及し得る脆弱性です。特に「設定ファイルに到達できる」「認証前でも到達できる」ケースは優先度が高くなります。

ディレクトリトラバーサルが起きやすい実装パターン

攻撃の入口は「fileパラメータ」だけではありません。次のような機能は、設計次第でリスクが上がります。

• ファイル閲覧：ログビューア、帳票閲覧、バックアップ閲覧、エクスポートのダウンロード
• 動的配信：画像・動画・PDFをパス指定で返すエンドポイント
• テンプレート／言語切替：テンプレート名やlocaleをパスとして扱う
• アップロード後の参照：アップロードIDではなくファイル名で参照する

「ユーザーが指定するのは“ファイル名だけ”のつもり」でも、実装上は文字列結合でパスを組み立てていることが多く、ここが弱点になります。

ディレクトリトラバーサルの対策

ディレクトリトラバーサルを防ぐには、入力値の取り扱いとファイルアクセスの設計をセットで見直すのが基本です。「弾く」だけでなく、「そもそも危ない形で受け取らない」方向に寄せるほど安定します。

入力値のバリデーション

ディレクトリトラバーサルを防ぐうえで、ユーザー入力を適切にバリデーションすることは必須です。ただし、ブラックリスト的に「../を消す」だけだと抜け道が生まれやすいので、基本はホワイトリストに寄せます。

• 入力値のホワイトリスト化：許可する値（ID、固定名、許可拡張子）を定義し、それ以外は拒否します。
• 入力値のサニタイズ：危険文字を消すより、受け取る形式そのものを限定します（例：数値IDのみ、UUIDのみ）。
• 正規表現による検証：ファイル名を受け取る場合でも、使用可能文字や長さ、拡張子を厳密にします。

実務上は「ファイル名を受け取る」より、アプリが発行したIDで参照し、サーバー側で対応するパスを引く構成が安全です。ユーザーがパスを“組み立てられない”形にすると、脆弱性の芽が減ります。

ファイルパスの正規化

パスの正規化（canonicalization）は、「../」や重複スラッシュなどを解消して、最終的にどこを指すのかを確定させる処理です。重要なのは、正規化した後のパスを基準に“許可されたディレクトリ配下か”を判定することです。

よくある落とし穴は、正規化前に「..が含まれるか」だけを見てしまうことです。エンコードや区切り文字の違いで抜ける可能性があるため、

• 入力値→結合→正規化→許可ディレクトリ配下の確認→ファイル参照

の順で処理します。言い換えると「正規化してから境界チェック」が鉄則です。

ファイルアクセス権限の適切な設定

アプリ側の対策に加え、OSやミドルウェアの権限設計も効きます。重要ファイルやディレクトリには、必要最小限のアクセス権限のみを付与し、Webサーバープロセスが触れられない領域を増やします。

• Webプロセスの実行ユーザーを分離し、読み取り不要な領域を読めないようにする
• 設定ファイルや鍵ファイルの権限を厳格にする（配置場所も見直す）
• アップロード領域とアプリ実行領域を分離する（同一ディレクトリに置かない）

権限で“被害の上限”を下げておくと、もしバグが残っても致命傷になりにくくなります。

安全な設計への寄せ方

対策の質を上げるなら、実装テクニックだけでなく設計を見直します。次の方針は効果が大きいです。

• パスを受け取らない：ファイル参照はID化し、DBやマッピングで解決する
• 固定ディレクトリ＋固定拡張子：参照できる領域と形式を限定する
• ディレクトリ一覧を返さない：ユーザーに構造を推測させる情報を減らす
• エラーメッセージを控えめに：実パスやスタックトレースを返さない

最新のセキュリティパッチの適用

ディレクトリトラバーサルはアプリ実装が原因であることが多い一方、フレームワークやライブラリの不備が絡む場合もあります。Webサーバー、フレームワーク、依存ライブラリを最新に保ち、セキュリティアップデートを適用する運用は、土台として外せません。

ディレクトリトラバーサルの検出方法

検出は「作る前（開発）」「作った後（運用）」の両方で考えると安定します。単発の診断より、継続して気づける仕組みがあるほど再発を減らせます。

脆弱性スキャナーの利用

脆弱性スキャナーは、Webアプリケーションの弱点を自動的に探すツールです。自動スキャンでディレクトリトラバーサルの兆候を効率よく拾える一方、誤検知や見落としがあり得ます。

現場では「スキャナーで出た＝即アウト」ではなく、

• 該当エンドポイントが本当にファイル参照をしているか
• 正規化後の境界チェックがあるか
• 認証前に到達できるか

を確認し、優先度を付けて潰していくのが実務的です。

ペネトレーションテストの実施

ペネトレーションテストは、攻撃者の視点で手動検証する方法です。スキャナーが拾いにくい“アプリ固有の入口”を発見しやすいため、重要システムや公開範囲が大きいサービスでは有効です。

特に、ファイル閲覧・ダウンロード・ログ表示・テンプレート切替のような機能は、手動で深掘りすると見つかることがあります。

ソースコードレビューによる検出

ソースコードレビューでは、「ユーザー入力がどこでパスになるか」を追います。入力→結合→正規化→境界チェック→ファイルアクセスの流れが守られているか、あるいはそもそも「パスを受け取っていないか」を確認します。

• ファイル参照API（open/readFile/include/template load等）に渡る直前の処理
• 正規化の有無、境界チェックの有無
• 拡張子チェックだけで済ませていないか

レビュー観点を固定化しておくと、同種のバグを横展開で減らせます。

ログの監視とアラート設定

運用では「侵入の兆候に早く気づく」ことが重要です。ログに不審なパスパターン、異常な404/403の連続、エンコードされた“..”の試行などが出ていないかを見ます。

アラートの例としては、

• 特定パラメータに「../」「%2e%2e」「%2f」などが一定回数以上出現
• 同一IPから短時間に多数のパス探索がある
• 本来アクセスされない管理系パスへの連続アクセス

などが挙げられます。誤検知が多い場合は、対象URLや閾値を調整して運用に乗せます。

ディレクトリトラバーサル対策のベストプラクティス

対策は単体ではなく、開発プロセスと運用の両輪で回すと強くなります。ここでは実務で効きやすい“型”を整理します。

セキュアなコーディングプラクティスの採用

ディレクトリトラバーサルを防ぐには、危ない受け取り方をしないのが最も堅い方針です。ファイルパスを入力として受け取らず、IDで参照する設計を優先し、それが難しい場合でも、正規化・境界チェック・ホワイトリストを徹底します。

• ユーザー入力はID化し、サーバー側で安全なパスに解決する
• 正規化してから、許可ディレクトリ配下かを判定する
• 拡張子の許可リストを持ち、想定外の形式は返さない
• エラー応答に実パスや内部情報を出さない

定期的なセキュリティ教育の実施

この脆弱性は「知っているかどうか」で減らせるタイプでもあります。開発者・運用者が“なぜ危ないのか”を具体例とセットで理解している状態を作ると、レビューや設計の段階で止めやすくなります。

• 入力値検証と正規化の違い（順番の重要性）
• パスを受け取る設計のリスクと、ID参照への置き換え
• ログで見える兆候（探索の典型パターン）

セキュリティ監査の定期的な実施

定期監査は“抜け”を見つける場として有効です。監査でチェックしやすい項目を表にまとめます。

インシデント対応計画の策定

万が一のときは、被害拡大を止める速さが重要です。ディレクトリトラバーサルを疑う兆候が出た場合に備え、一次対応の手順を決めておくと復旧が早くなります。

1. 検知：WAF/ログ監視のアラート、異常なアクセスパターンの確認
2. 封じ込め：該当エンドポイントの一時遮断、ルール追加、緊急パッチ適用
3. 調査：アクセスログ、参照された可能性のあるファイル、漏えい範囲の確認
4. 復旧：根本修正（設計見直し含む）、再発防止策、テスト追加
5. 報告：必要に応じた社内外への連絡、記録の保全

まとめ

ディレクトリトラバーサルは、入力値の扱いを誤ることで、本来公開していないファイルや設定情報に到達され得る脆弱性です。対策の基本は、パスを入力として受け取らない設計（ID参照）に寄せ、やむを得ず扱う場合でも、正規化後の境界チェックとホワイトリストを徹底することです。あわせて、Webプロセスの権限設計で被害の上限を下げ、スキャン・レビュー・監視を継続して回すことで、検出と再発防止の精度が上がります。開発と運用の両方で“危ない形を作らない”ことが、長期的に効くディレクトリトラバーサル対策になります。