ディレクトリトラバーサルとは？仕組み・攻撃例・対策をわかりやすく解説

「ファイルをダウンロードする機能を作っただけなのに、サーバーの設定ファイルが丸見えになっていた」――Webアプリケーションの脆弱性診断で、こんな報告を受けたことはないでしょうか。

ディレクトリトラバーサル（パストラバーサル）は、Webアプリケーションにおける代表的な脆弱性の一つです。IPA（情報処理推進機構）への届出でも毎年上位に入っており、攻撃の原理は単純でありながら、被害は深刻になりがちです。

この記事では、ディレクトリトラバーサルの仕組み・攻撃パターン・実践的な防御策を、現場のセキュリティエンジニアの視点で解説します。「聞いたことはあるけど、自分のシステムが安全かどうか判断できない」という方にも分かるように整理しました。

ディレクトリトラバーサルとは？概要と危険性

ディレクトリトラバーサル（Directory Traversal）とは、Webアプリケーションのファイル参照機能を悪用して、本来アクセスできないはずのファイルやディレクトリを読み取る攻撃手法です。「パストラバーサル（Path Traversal）」という名前でも知られています。

攻撃のカギになるのは「../」（ドットドットスラッシュ）という文字列です。これはファイルシステム上で「一つ上のディレクトリに移動する」という意味を持ちます。この文字列をファイルパスに紛れ込ませることで、Webアプリケーションが公開しているディレクトリの外にあるファイルにアクセスさせるのが攻撃の基本原理です。

なぜこの脆弱性が危険なのか、理由を整理します。

・機密ファイルの漏洩に直結する: サーバーのパスワードファイルやデータベース接続情報など、外部に見せてはいけない情報が一発で抜き取られる可能性がある
・攻撃の敷居が非常に低い: URLのパラメータに「../」を足すだけで試行できるため、専門的なツールや高度な知識がなくても実行できてしまう
・二次被害が広がりやすい: 漏洩したファイルにAPIキーやパスワードが含まれていれば、そこからデータベース侵入やシステム乗っ取りにつながる

SQLインジェクションがデータベースを狙う攻撃であるのに対して、ディレクトリトラバーサルはファイルシステムを狙う攻撃です。ファイルのダウンロード・表示・読み込みといった機能を持つWebアプリケーションであれば、どれもこの脆弱性のリスクを抱えています。

攻撃の仕組み ― ディレクトリトラバーサルはこう成立する

攻撃がどのように成立するのか、段階を追って見ていきましょう。防御策を考えるうえで、攻撃者の手口を正しく知ることは欠かせません。

1. ファイル名をパラメータで受け取る処理がある

たとえば、PDFのダウンロード機能やユーザーアイコンの表示機能で、URLパラメータにファイル名を指定してサーバー上のファイルを返す処理があるとします。

# 正常なリクエストの例
# https://example.com/download?file=manual.pdf
# サーバー側の処理イメージ:
#   ベースディレクトリ /var/www/files/ + manual.pdf
#   → /var/www/files/manual.pdf を返す

この仕組み自体は珍しいものではありません。問題は、パラメータの値をどこまで信頼するか、という設計にあります。

2. 攻撃者が「../」でパスを遡る

攻撃者はパラメータの値に「../」を繰り返し挿入し、ベースディレクトリの外にあるファイルを指定します。

# 攻撃リクエストの例（概念レベル）
# https://example.com/download?file=../../../../etc/passwd
# サーバー側の処理:
#   /var/www/files/ + ../../../../etc/passwd
#   → /etc/passwd に到達してしまう

「../」を4回繰り返すことで、/var/www/files/ からルートディレクトリ「/」まで遡り、/etc/passwd に到達しています。「../」を多めに入れても、ルートディレクトリより上には行けないため、攻撃者は念のため多めに入れてきます。

3. パス検証が不十分だとファイルが返される

アプリケーション側でパラメータの値を検証・正規化していなければ、サーバーは攻撃者が指定したファイルをそのまま返してしまいます。

攻撃の本質は「ユーザーが入力した値を、検証なしにファイルパスとして使っている」というプログラムの設計上の問題です。入力値の妥当性チェックやパスの正規化を行っていれば、この攻撃は成立しません。

4. 「../」だけではない ― エンコードによる回避手法

入力値から「../」を単純に除去するだけの対策を施しているケースがありますが、攻撃者はこれを回避する手法も持っています。

・URLエンコード: 「../」を「%2e%2e%2f」に変換して送信する
・二重エンコード: 「%252e%252e%252f」のように二重にエンコードする
・Windowsのバックスラッシュ: 「..\」を使用する（Windows環境のサーバーが対象）
・Null Byte: パスの途中にNullバイト（%00）を挿入して拡張子チェックを回避する

このように、単純な文字列除去だけでは防御しきれない点が、ディレクトリトラバーサル対策の難しさです。

狙われるファイルとその影響

ディレクトリトラバーサルで攻撃者が狙う代表的なファイルを整理します。

Linuxのファイル権限管理については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

特に.envファイルやデータベースの設定ファイルが漏洩した場合、そこに書かれた認証情報を使ってデータベースに直接接続される危険があります。ディレクトリトラバーサル単体の被害にとどまらず、連鎖的に被害が拡大するのがこの脆弱性の怖さです。

具体的な防御手順

ディレクトリトラバーサルに対する防御策を、優先度の高い順に解説します。一つの対策だけに頼るのではなく、複数の対策を重ねる「多層防御」の考え方が重要です。

1. ファイル名の直接指定を避ける設計にする

最も確実な対策は、ユーザー入力をファイルパスにそのまま使わない設計にすることです。具体的には、ファイルに対応するIDや番号をマッピングテーブルで管理し、ユーザーにはIDだけを指定させます。

# 脆弱な設計（NG）
# https://example.com/download?file=manual.pdf
# → ユーザー入力がそのままファイルパスに使われる

# 安全な設計（OK）
# https://example.com/download?id=42
# → IDに対応するファイル名をサーバー側で解決
# → ユーザー入力がファイルパスに含まれない

この設計であれば、攻撃者がIDにどんな値を入れても「../」を含むファイルパスにはなりません。

2. パスの正規化（カノニカライゼーション）を行う

やむを得ずファイル名をパラメータで受け取る場合は、パスの正規化処理を必ず入れます。正規化とは、「../」やシンボリックリンクを解決して、実際の絶対パスに変換する処理です。

# パス正規化の考え方（概念的な流れ）
# 1. ユーザー入力を受け取る
# 2. ベースディレクトリとユーザー入力を結合
# 3. 結合したパスを正規化（絶対パスに変換）
# 4. 正規化後のパスがベースディレクトリ配下か確認
# 5. ベースディレクトリの外なら拒否する

正規化の後に「正規化されたパスが、許可されたディレクトリの中に収まっているか」を確認する点がポイントです。「../」の文字列を除去するのではなく、最終的なパスの位置で判断します。

3. ホワイトリスト方式で許可するファイル名を制限する

ユーザーが指定できるファイル名をホワイトリスト（許可リスト）で限定する方法も有効です。英数字・ハイフン・アンダースコアのみを許可し、「.」「/」「\」などのパス区切り文字を拒否します。

# ホワイトリスト方式の考え方
# 許可する文字: a-z A-Z 0-9 - _
# 拒否する文字: . / \ % （パスに関わる文字すべて）
# ファイル拡張子はサーバー側で付与する

「ブラックリスト（禁止リスト）で危険な文字を弾く」方式よりも、「ホワイトリストで安全な文字だけを通す」方式の方が安全です。ブラックリスト方式は、エンコードや新しい回避手法に対応しきれないリスクがあります。

4. Webアプリケーションの実行権限を最小化する

仮にディレクトリトラバーサルが成立しても、被害を最小限に抑えるための対策です。Webアプリケーションのプロセスが動作するOSユーザーの権限を最小限に絞ります。

・Webアプリケーション専用のOSユーザーを作成し、必要最低限のディレクトリにだけ読み取り権限を与える
・/etc/shadow やデータベース設定ファイルなど、機密性の高いファイルにはWebアプリケーションユーザーからの読み取り権限を設定しない
・chrootやコンテナでファイルシステムを隔離し、アクセス可能な範囲そのものを制限する

これは「万が一突破されたときの被害を小さくする」という考え方で、防御の最後の砦になります。

5. WAFによる検知・ブロック

WAF（Web Application Firewall）は、HTTPリクエストに含まれる「../」やそのエンコード形式を検知してブロックします。アプリケーション自体の修正が難しい場合の暫定対策として有効です。

ただし、WAFはあくまで「追加の防御層」であり、アプリケーション側の根本的な対策の代わりにはなりません。WAFのルールを回避する新しい手法が登場する可能性もあるため、アプリケーション側の修正を優先してください。

中小企業でも今日からできること

「セキュリティ専任のエンジニアがいない」「予算も限られている」――そんな中小企業でも、今日から着手できる対策があります。

1. 自社のWebアプリケーションにファイル参照機能があるか棚卸しする

まずは現状把握です。ファイルのダウンロード機能、画像表示機能、レポート出力機能など、URLパラメータでファイル名を指定している箇所を洗い出します。外部に開発を委託している場合は、委託先に「ファイルパスの入力値検証をどのように行っているか」を確認してください。

2. OSSの脆弱性スキャナーで簡易チェックする

OWASP ZAP（オワスプ・ザップ）のようなオープンソースの脆弱性スキャナーを使えば、無料でディレクトリトラバーサルを含む基本的な脆弱性をチェックできます。完璧な診断ではありませんが、明らかな問題の検出には十分です。

3. サーバーのファイル権限を見直す

Webアプリケーションが動作しているOSユーザーが、不要なファイルにアクセスできる権限を持っていないか確認します。特に設定ファイルや.envファイルのパーミッション（アクセス権限）は、所有者のみ読み取り可能（600）に設定するのが基本です。

4. WAFの導入を検討する

クラウド型WAFであれば、月額数千円から利用できるサービスもあります。アプリケーションの改修が難しい場合の暫定策として、費用対効果の高い選択肢です。

よくある誤解と注意点

「../」を除去すれば安全？

これは最もよくある誤解です。先述のとおり、URLエンコードや二重エンコード、バックスラッシュなど、「../」の文字列を直接使わない回避手法が複数存在します。文字列の除去ではなく、パスの正規化後に位置を確認する方法が正解です。

「読み取りだけなら大した被害ではない」？

ディレクトリトラバーサルで直接できるのはファイルの「読み取り」ですが、読み取ったファイルに含まれるパスワードやAPIキーを使えば、データベースの改ざんやシステムの乗っ取りまで発展し得ます。読み取りを軽視するのは危険です。

「HTTPSを使っていれば防げる」？

HTTPS（通信の暗号化）は、通信経路上の盗聴を防ぐ技術です。ディレクトリトラバーサルはサーバー内部のファイルアクセスの問題であるため、HTTPSは無関係です。暗号化通信とアプリケーション脆弱性の対策は、まったく別のレイヤーの話です。

「フレームワークを使っていれば安全」？

モダンなWebフレームワークにはディレクトリトラバーサルを防ぐ仕組みが組み込まれていることが多いですが、開発者が独自にファイル操作のコードを書いた場合はフレームワークの保護の対象外です。フレームワークの保護機能に頼り切るのではなく、自作コードにも入力値の検証を入れてください。

法的観点に関する注意

ディレクトリトラバーサルを他者のシステムに対して行うことは、不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）に抵触する可能性があります。脆弱性の検証は必ず自分の管理するシステムに対して行い、他者のシステムには絶対に試さないでください。法的な詳細は法律の専門家にご確認ください。

本記事のまとめ

ディレクトリトラバーサル（パストラバーサル）の仕組み・攻撃例・対策を振り返ります。

ディレクトリトラバーサルは原理がシンプルな分、対策も明確です。「ユーザー入力をファイルパスに直接使わない」――この原則を設計段階から徹底するだけで、リスクは大きく下がります。既存のシステムについても、ファイル参照機能の棚卸しとパス検証の確認から始めてみてください。