>
>
最終更新日
本記事は、Webサイトの運用を担う情シス部門やアプリケーション開発者（特にPC環境での実務担当者）向けに、現在も深刻な脅威であるディレクトリトラバーサル（トラバーサル攻撃）の全貌を解説します。
サイバー攻撃の中でも、古くからある手法でありながら、今なお甚大な被害を発生させているのが、ディレクトリトラバーサルです。「トラバーサルとはどのような意味なのか？」という基本的な疑問から、この攻撃を受けると本来公開していないはずの機密情報が盗み見られたり、最悪の場合サーバーを乗っ取られたりするリスクについて掘り下げます。
本記事では、LFI（ローカルファイルインクルード）との決定的な違いや、開発現場で陥りやすいブラックリスト方式の失敗パターン、そして最新の統計データに基づく実践的な多層防御のノウハウまで、2026年時点の最新情報を踏まえて網羅的に解説します。
ディレクトリトラバーサル（トラバーサル攻撃）とは
本記事のポイント
ディレクトリトラバーサルは、ファイルパスを不正操作して非公開領域のファイルにアクセスする攻撃である。
複数の調査では、OSSの脆弱性においてパストラバーサル系が上位にランクインするほど頻出している（詳細は各年度の公式レポートをご参照ください）。
単純なファイルの「閲覧」にとどまらず、LFIと組み合わさることでリモートコード実行（RCE）の引き金となる。
ブラックリスト方式による防御はエンコード回避などで突破されるため、クラウド型WAFなど複数の対策を組み合わせる必要がある。
ディレクトリトラバーサル（Directory Traversal）とは、Webアプリケーションにおけるファイルパスの検証不備を突き、意図しないディレクトリやファイルへ不正アクセスする攻撃手法です。パス（Path）をトラバース（横断・遡る）するという意味から、トラバーサル攻撃とも呼ばれます。
攻撃者は、入力値に「../」などの相対パスを示す文字列を混入させることで、Webルートディレクトリから上位階層へ遡り、本来は非公開であるシステム設定ファイル（/etc/passwdなど）やソースコードを読み取ります。
最新の統計データが示す脅威の深刻さ
古い攻撃手法と見なされがちですが、その脅威は現在も拡大し続けています。独立行政法人情報処理推進機構（IPA）が公開する脆弱性関連情報の届出状況によれば、ウェブサイトの脆弱性届出においてディレクトリトラバーサルは毎年上位に位置しており、累積件数は200件を超えています（詳細はIPA公式サイトの届出統計をご参照ください）。また、株式会社サイバーセキュリティクラウドの「2023年Webアプリケーションへのサイバー攻撃検知レポート」では、1秒間に23回のサイバー攻撃が検知されており、CMS（WordPress等）を狙った攻撃の増加が特に顕著で、ディレクトリトラバーサルを含むパス操作系の自動スキャンも継続的に確認されています。さらに、GitHubが公開する「Octoverse」セキュリティレポートを含む複数の調査においても、パストラバーサル系の脆弱性はOSSにおける上位の脅威として継続的に報告されています（詳細は各年度の公式レポートをご確認ください）。
ディレクトリトラバーサルは過去の遺物ではなく、現在も自動化されたボットにより無差別に狙われる深刻な脅威です。
想定される被害事例
ディレクトリトラバーサルが成功すると、甚大な被害につながります。例えば、データベースの接続情報が書かれた設定ファイルが盗まれれば、顧客の個人情報が丸ごと流出する可能性があります。さらに、ソースコードが窃取されたり、後述する手法によってサーバー上で不正なプログラムを実行されたりすることで、Webサイトの改ざんやサーバー乗っ取りといった最悪の事態に発展します。
機密ファイルの漏えいは、企業の信頼失墜と多額の損害賠償に直結します。
パストラバーサルとの違い
ディレクトリトラバーサルとパストラバーサルは、基本的に同じ攻撃手法を指す同義語として扱われます。どちらもファイルパスを不正に操作して非公開領域のファイルにアクセスする攻撃です。公的機関などでは「ディレクトリ・トラバーサル」という表記が主に用いられますが、システムや文脈によってはパストラバーサルと呼ばれます。
呼び方の違いに戸惑う必要はなく、全く同じ脅威メカニズムとして認識して対策を進めましょう。
▲ ディレクトリトラバーサル攻撃の仕組み
LFI（ローカルファイルインクルード）との違いとRCEへの発展
ディレクトリトラバーサルの真の恐ろしさを理解するためには、LFI（Local File Inclusion）との違いや関連性を明確に区別しておく必要があります。多くの記事では単なる「閲覧」の脆弱性として説明されますが、実務の現場では、これが「実行」へと発展する最悪のシナリオを想定しなければなりません。
ディレクトリトラバーサルとLFIの決定的な違い
両者は「外部からの入力によって参照するファイルパスが操作される」という根本的な原因を共有していますが、アプリケーション側の処理結果が異なります。以下の表に違いを整理します。
項目 | ディレクトリトラバーサル | LFI（ローカルファイルインクルード） |
|---|---|---|
主な処理動作 | ファイルを読み込み、文字列として「表示（閲覧）」する | ファイルを読み込み、プログラムとして「実行」する |
原因となる関数の例 | file_get_contents(), readfile() など | include(), require() など |
直接的な被害 | 機密情報、ソースコード、パスワードの漏えい | 任意のスクリプト実行、マルウェア感染 |
ディレクトリトラバーサルは「閲覧」に限定されるのに対し、LFIはファイルに「実行権限」を与えて読み込むという本質的な違いがあります。
ログポイズニング等によるRCE（リモートコード実行）への発展
LFIの脆弱性が存在する場合、単なる情報漏えいにとどまらず、RCE（任意コード実行）という最悪の事態に発展するリスクがあります。例えば「ログポイズニング（Log Poisoning）」と呼ばれる手法では、攻撃者がWebサーバーにアクセスする際、User-Agentヘッダなどに悪意のあるPHPスクリプトを仕込みます。これがサーバーのアクセスログ（access.log）に記録されます。その後、LFIを利用して「../../../../var/log/apache2/access.log」を読み込ませることで、ログ内のスクリプトが実行され、サーバーの完全な乗っ取りが成立します。
LFIと結びつくことで、トラバーサル攻撃は単なる情報漏えいからサーバーの完全乗っ取りへと被害が致命的に拡大します。
▲ ディレクトリトラバーサルとLFIの被害の違い
開発・運用で陥りやすい対策の失敗パターン
セキュアコーディングやシステム運用において、防御設計の出発点として、開発者が陥りがちな誤解や効果が薄い対策の失敗パターンを先に把握しておきましょう。
ブラックリスト方式の限界とエンコードによる回避
入力値から「../」という文字列を削除または拒否する「ブラックリスト方式」は、典型的な失敗パターンです。例えば、単純な文字列置換（str_replace等）を用いた場合、攻撃者が「....//」と入力すると、内側の「../」が削除された結果、外側に再び「../」が形成され、フィルタを回避されます。
さらに、Apache Tomcatでは過去にも繰り返しパストラバーサル関連の脆弱性が報告されており、直近の事例でも、URLの正規化処理とデコード処理の順序不備を突かれるケースが確認されています。攻撃者が「%2e%2e%2f」（../のURLエンコード）を送信すると、正規化処理をすり抜けた後にデコードされ、トラバーサル攻撃が成立してしまいます。
文字列フィルタリングに依存するブラックリスト方式は、エンコード技術によって容易に突破されるため根本的な対策になりません。
「FWやIPSで防げる」という誤解
「ファイアウォール（FW）やIPSを導入しているから安全だ」という認識もよくある誤解です。従来のFWはIPアドレスやポート番号といったネットワーク層（L3/L4）の制御を行うものであり、HTTP/HTTPS通信（L7）の中身は素通りさせます。トラバーサル攻撃は正常なHTTPリクエストのパラメータに紛れ込んで送られてくるため、ネットワーク機器での検知は困難です。
Webアプリケーションへの攻撃を防ぐには、通信のペイロード（中身）を解析できる専用のセキュリティ層が必要です。
「自社は中小企業だから狙われない」という誤解
「自社のサイトは小規模だから標的にならない」と考えるのも危険です。現在のサイバー攻撃は、自動化されたボットを用いてインターネット上のあらゆる公開サーバーに対して無差別な脆弱性スキャンを行っています。脆弱性が発見された瞬間に、企業の規模に関わらず攻撃の踏み台や身代金要求のターゲットにされます。
企業の規模や知名度に関係なく、インターネットに公開されているすべてのシステムは常に攻撃の標的となっています。
ディレクトリトラバーサルへの効果的な対策
ディレクトリトラバーサルの脅威からWebサイトを守るためには、アプリケーション層の改修からインフラ面の防御まで、複数の策を組み合わせる多層防御が必要です。
ホワイトリスト方式と間接参照の採用
最も根本的な対策は、外部からの入力を直接ファイルパスとして扱わない設計（間接参照）にすることです。ファイル名を内部的なID等で管理し、ユーザーにはIDのみを指定させます。やむを得ずファイル名を扱う場合は、ブラックリストではなく「ホワイトリスト方式」を採用し、英数字など許可された文字のみを通すように厳格に制限します。
入力を直接パスに結合する設計を避け、ファイル名をシステム内部で安全に管理することが確実な防御策です。
ファイルパスの検証と正規化
ファイルパスを扱う際は、OSや言語の機能を用いてパスを「正規化」します。例えばJavaの場合、java.io.FileクラスのgetCanonicalPath()メソッドを利用して絶対パスに変換します。その上で、生成されたパスが、公開を許可しているベースディレクトリ（/var/www/html/ など）の配下に正しく含まれているかを前方一致で検証します。
パスの正規化とベースディレクトリの厳密な照合を行うことで、上位階層への不正な遡りをプログラムレベルで遮断できます。
最小権限の原則に基づくファイルアクセス制御
万が一アプリケーションの脆弱性を突破された場合に備え、OSレベルでの「最小権限の原則」を適用します。Webサーバーを実行するユーザーアカウント（例：www-data）に対して、システムファイルや設定ファイルへの読み取り権限を与えないように制限します。
権限を最小限に絞り込むことで、侵入されても致命的な情報漏えいや設定改ざんを防ぐことができます。
Webアプリケーションファイアウォール（WAF）の活用
個別の対策に加えて、Webアプリケーションファイアウォール（WAF）の導入は非常に効果的です。複数の国内調査（バッファロー社の2023年調査など。詳細は同社公式サイトよりレポートをご確認ください）によると、中小企業の約7割がWAF未導入であり、専門知識の不足やコストが障壁となっています。しかし近年は、AIによる振る舞い検知を備え、初期費用が低くベンダーがルールを自動更新する「クラウド型WAF」が急速に普及しています。
自社での実装漏れを補完し、未知の攻撃からシステムを守るためにクラウド型WAFの導入を強く推奨します。
【国内企業の導入事例】株式会社SumarchのAWS WAF活用
クラウド型WAFによる防御力向上の成功事例として、不動産テックを展開する株式会社Sumarchの取り組みが参考になります（公式の事例詳細は同社またはAWSパートナー向け資料をご確認ください）。同社は、AWS環境上で構築された自社システムへのサイバー攻撃の脅威に対し、マネージドルールを活用したAWS WAFを導入しました。これにより、専門的なセキュリティエンジニアを新たに採用することなく、トラバーサル攻撃を含む高度なL7レイヤーの攻撃を自動的にブロックする体制を構築し、運用コストの削減と防御力の向上を両立させています。
クラウド型WAFのマネージドサービスを活用することで、人員リソースが限られる企業でもエンタープライズ水準のセキュリティを実現できます。
▲ ファイルパスを安全に処理・検証する3ステップ
ディレクトリトラバーサルの脆弱性を診断する方法
対策を講じた後は、その対策が有効に機能しているかを客観的に確認する必要があります。ここでは、自社サイトに脆弱性が存在しないかを確認するための診断方法を紹介します。
脆弱性診断ツールの利用
手軽に脆弱性をチェックする方法として、脆弱性診断ツールの利用が挙げられます。OWASP ZAPなどのオープンソースツールや商用の自動スキャンツールを用い、疑似的な攻撃リクエストを自動送信することで、ディレクトリトラバーサルなどの既知の脆弱性を検出します。
サイトの安全性を日常的に担保するため、開発フローの中に定期的な自動診断ツールを組み込みましょう。
専門家によるセキュリティ診断（ペネトレーションテスト）
より高い精度で網羅的に洗い出したい場合は、専門家によるペネトレーションテストが確実です。専門家が実際の攻撃者と同じ思考で、ツールと手動を組み合わせてシステムの弱点を探し出します。ツールの自動スキャンでは発見が難しい、アプリケーション固有の複雑なロジックに起因する脆弱性も検出できます。
顧客の個人情報や機密データを扱う重要システムでは、リリース前や大幅改修時に必ず専門家による診断を実施すべきです。
よくある質問
Q：トラバーサルとはどういう意味ですか？
A：トラバース（Traverse）は「横断する」「遡る」という意味を持つ英単語です。ITセキュリティにおいては、ファイルパスを不正に操作して、ディレクトリ階層を遡り本来アクセスできない領域に侵入する攻撃を指します。
Q：ディレクトリトラバーサルとディレクトリリスティングの違いは何ですか？
A：ディレクトリトラバーサルは「不正な操作によって非公開ファイルにアクセスする攻撃手法」です。一方、ディレクトリリスティングは「サーバーの設定不備により、意図せずフォルダ内のファイル一覧が表示されてしまう状態」を指します。
Q：対策として入力値のサニタイズ（無害化）だけで十分ですか？
A：不十分です。文字列の削除や置換などのブラックリスト方式は、URLエンコードなどの手法で容易に回避されます。ファイルアクセス時は必ず絶対パスに正規化した上で、許可されたディレクトリ内にあるか検証するホワイトリスト方式を併用する必要があります。
まとめ
監修・執筆：本記事はWebアプリケーションセキュリティの実務知見を持つエンジニアが執筆・監修しています。内容に関するご意見・ご指摘はページ下部のお問い合わせフォームよりお寄せください。
安全なWeb運営に向けた第一歩
本記事では、ディレクトリトラバーサルの仕組みから、LFI経由でのRCE発展リスク、ブラックリスト方式の失敗パターン、そしてWAFを活用した具体的な対策までを網羅的に解説しました。この攻撃は古典的でありながら、Webアプリケーションの検証不備を突いて今なお深刻な被害をもたらす脅威です。
自動スキャンが常時実行される現状では、古い脆弱性ほど手軽に悪用されます。まず診断ツールで現状を把握し、対策の優先順位をつけることが現実的な出発点です。以下のチェックリストを参考に、今日できることから着手してください。
✅ OWASP ZAP等の診断ツールによる自社Webサイトのスキャン実施
✅ ファイルパス処理コードのホワイトリスト方式・間接参照への移行確認
✅ Webサーバー実行ユーザーの権限を最小限に設定（最小権限の原則）
✅ クラウド型WAFの導入検討
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
