LASSIC Media らしくメディア

2026.07.30 らしくコラム

ディレクトリトラバーサルとは|仕組みと対策

Webシステムのセキュリティに関する話題で、「ディレクトリトラバーサルの指摘が脆弱性診断でありました」「ファイルを扱う機能に注意が要ると言われた」といった場面に出会うことはないでしょうか。ディレクトリトラバーサルは、パストラバーサルとも呼ばれる古典的な攻撃手法で、SQLインジェクションやXSSと並び、長年にわたり注意が促されてきた脆弱性の一つです。IT事業部でシステムの発注や運用に関わる立場であれば、名前は聞いたことがあっても、それが具体的に何を突く攻撃で、なぜ危ないのか、どう防ぐのかまでは説明しにくいかもしれません。とはいえ、その大まかな仕組みを理解しておくと、ベンダーの提案や脆弱性診断の報告を受けたときに、対策が妥当かどうかを判断する助けになるでしょう。本記事では、攻撃コードの書き方といった実践的な手順ではなく、ディレクトリトラバーサルとはそもそも何を突く攻撃なのか、なぜ起こり、どんな被害につながり、どう防ぐのかを、発注・運用の視点から順に整理します。専門的な用語をすべて覚える必要はありませんが、「ファイル名の指定を悪用して、本来見えないファイルまで遡られる」という勘所をつかんでおくと、セキュリティの会話が理解しやすくなるはずです。

ファイルとフォルダをイメージした図

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

ディレクトリトラバーサル(Directory Traversal、パストラバーサルとも呼ばれます)とは、攻撃者がファイル名の指定を悪用して、本来アクセスできないはずのサーバ上のファイルを読み取ったり、操作したりする攻撃です。「トラバーサル(traversal)」は「横断・たどること」を意味し、フォルダ(ディレクトリ)の階層をたどって、公開されていない領域まで入り込む、というイメージからこの名前が付いています。

もう少しかみ砕いてみましょう。Webサービスには、利用者が指定したファイルを表示したり、ダウンロードさせたりする機能がしばしばあります。たとえば、指定した資料をダウンロードする、アップロードした画像を表示する、といった処理です。このとき、利用者が入力したファイル名を、そのままサーバ上のファイルの場所として使ってしまうと、攻撃者は、ファイル名のつもりで「別の場所を指す文字列」を入力できます。その結果、本来は特定のフォルダの中しか見せないはずが、そのフォルダの外にある、見せてはいけないファイルまで読み取られてしまうのです。

この攻撃が古くから知られているのは、ファイルを扱う機能がWebサービスではごく一般的で、かつ「入力されたファイル名をそのまま使う」という作りが、気をつけないと生まれやすいためです。情報処理推進機構(IPA)も、届出の多い脆弱性として長年にわたり注意を促しています。

なぜ起こるのか(攻撃の仕組み)

ディレクトリトラバーサルが成立してしまう根っこには、「利用者が指定したファイル名を、置き場所の確認をせずに、そのままファイルの場所として使ってしまう」という問題があります。

ファイルの場所は、フォルダの階層で表されます。そして多くの仕組みには、「一つ上のフォルダ」を表す特別な記号(「..」)が用意されているのです。攻撃者は、ファイル名の部分にこの「..」を繰り返し並べることで、本来見せるつもりの公開フォルダから、どんどん上の階層へと遡っていきます。そうして、サーバの設定ファイルや、認証に関わる情報など、外部に見せてはならないファイルの場所を指し示します。サーバは「指定された場所のファイルを返すだけ」なので、それが公開してよいものかを確かめないまま、中身を返してしまうのです。次の図は、この流れを単純化して示したものです。

正常時はファイル名が公開フォルダ内を指すが、相対パスを使われると公開フォルダの外の非公開ファイルまで遡られる。パスを正規化して基準の外なら拒否する図
図: 「..」で親フォルダへ遡られる。パスを正規化し、基準フォルダの外を指すなら拒否する

ここで大切なのは、ディレクトリトラバーサルは特別に高度な技術というより、「入力されたファイル名を無防備に信じてしまう」ことから生まれるという点です。逆にいえば、利用者からの入力を、そのままファイルの場所として使わない仕組みにしておけば、多くの場合は防げます。この考え方が、後述する対策の中心になります。

この記事のポイント

  • ディレクトリトラバーサルは、ファイル名の指定を悪用して非公開のファイルまで遡る攻撃です。
  • 原因は、利用者が入力したファイル名を、置き場所を確かめずにそのまま使うことにあります。
  • 入力をそのままファイルの場所として使わず、基準フォルダ配下に限定するのが対策の中心です。

具体例:ファイルを扱う機能で起こること

もう少し具体的な場面で考えてみましょう。ある社内システムに、利用者がダウンロードしたい資料の名前を指定すると、その資料を返してくれる機能があったとします。通常は「report.pdf」のような資料名が入力され、システムは決められた資料フォルダの中から、その資料を探して返すという流れです。ここまでは想定どおりの動きです。

ところが、攻撃者は資料名の欄に、資料名ではなく「一つ上のフォルダをたどる記号」を並べた文字列を入力します。すると、システムは指示されたとおりに階層を遡り、資料フォルダの外にある、システムの設定ファイルのような、本来は利用者に見せないファイルの場所へたどり着いてしまいます。利用者向けの何気ない「資料ダウンロード機能」が、サーバ内部をのぞく入り口として悪用されてしまうわけです。こうした被害は、ファイルの表示・ダウンロード・アップロード・読み込みなど、「入力をもとにファイルを扱う」あらゆる機能で起こりえます。

やっかいなのは、攻撃者が「..」をそのまま入力するとは限らない点です。文字を別の表現に置き換えたり、記号を紛れ込ませたりして、単純な文字チェックをすり抜けようとすることがあります。そのため、「『..』という文字が含まれていたら弾く」という思いつきの対策だけでは、抜け道が残りがちです。この点も、後述する「入力をそのまま場所として使わない」という根本的な考え方が重要になる理由の一つです。

どんな被害につながるのか

ディレクトリトラバーサルが成立すると、攻撃者は、外部に公開していないサーバ上のファイルに手を伸ばせます。代表的な被害を挙げておきましょう。

一つ目は機密情報の読み取りです。サーバの設定ファイルや、データベースへの接続情報、認証にかかわる情報などが読み取られると、そこからさらに深い侵入を許すおそれがあります。二つ目は個人情報や業務データの流出です。サーバ上に保存された個人情報や取引情報のファイルが、そのまま抜き取られてしまう場合があります。三つ目はシステム内部構造の把握です。プログラムのソースコードや設定が読み取られ、他の弱点を探す手がかりにされることがあります。さらに、作りによっては、ファイルの読み取りだけでなく、書き込みや上書きにつながる場合もあり、被害の幅は広がります。

共通しているのは、いずれも「本来は外から見えないはずのファイル」に到達される点です。とりわけ設定ファイルや認証情報が読まれると、そこを足がかりに被害が連鎖しかねません。ディレクトリトラバーサルが軽視できないのは、攻撃の入り口が「よくあるファイル取得機能」でありながら、サーバの内側に踏み込まれてしまうという、その到達範囲の広さにあるといえるでしょう。

基本の対策と発注・運用の観点

ディレクトリトラバーサルにも、有効性が広く知られた対策があります。中心になる考え方と、発注・運用で押さえておきたい観点を整理しておきましょう。

対策 考え方
入力を直接ファイル名にしない 最も基本の対策。利用者にファイル名そのものを渡させるのではなく、番号や識別子で選ばせ、実際のファイルはシステム側で対応付けます。入力が場所を決めない形にします。
パスの正規化と範囲の確認 やむを得ず名前を受け取る場合は、指定された場所を一度きちんと解釈(正規化)し、それが基準フォルダの配下に収まっているかを確認します。外を指すなら拒否します。
入力値の検証 ファイル名にパス区切りや「..」など、場所の移動を意味する文字が含まれていないかを確認し、含まれていればはじきます。想定する形式だけを通す考え方です。
権限の最小化 システムが読み書きできるファイルの範囲を、必要な部分に絞ります。万一すり抜けられても、触れられるファイルが限られていれば、被害を抑えられます。

中心になるのは、利用者の入力を、そのままファイルの場所として使わないという考え方です。番号や識別子で選ばせる、あるいは正規化して基準フォルダ配下に限定する——この土台の上に、入力値の検証や権限の最小化を重ねると、多層的な守りになります。ファイルを扱う機能があるかどうかを意識することが、対策の第一歩です。

発注・運用の立場では、いくつかの観点を押さえておくとよいでしょう。第一に挙げられるのが、ファイルを扱う機能の把握になります。利用者の入力をもとにファイルを表示・ダウンロード・アップロードする機能があるか、提案や仕様の中で確認しておくと、リスクの所在がつかめます。第二に、対策方針の確認です。そうした機能について、入力を直接ファイル名にしない作りになっているかを尋ねておくと、核心をつかめます。第三に、脆弱性診断の活用です。リリース前や定期的なタイミングで診断を受けると、作り込みの不備を早い段階で見つけられます。なお本記事は攻撃手法の実践的な手順ではなく、ディレクトリトラバーサルという脅威の考え方と、発注・運用で押さえたい観点に焦点を当てているものです。個別の対策の実装や診断は、実績のあるベンダーや専門機関への相談が別途必要になります。

まとめ

  • ディレクトリトラバーサルは、ファイル名の指定を悪用して、本来見せないファイルまで遡って読み取る攻撃です。
  • パストラバーサルとも呼ばれ、SQLインジェクションやXSSと並ぶ古典的な脆弱性の一つです。
  • 原因は、利用者が入力したファイル名を、置き場所を確かめずにそのまま使うことにあります。
  • 被害は、設定ファイルや認証情報・個人情報の読み取り、内部構造の把握など、サーバ内部に及びます。
  • 対策の中心は、入力を直接ファイル名にせず、基準フォルダ配下に限定することです。
  • 入力値の検証や権限の最小化を重ね、多層で守るのが基本になります。
  • 本記事は攻撃手法の手順ではなく、脅威の考え方と発注・運用の観点の整理を狙いとしています。

LASSICに相談するメリット

ディレクトリトラバーサルのような脆弱性への対策は、ファイルを扱う機能の作り込みに関わるため、どの機能に注意が要るのか、どこから手をつけるべきかを社内だけで見極めるのは難しい領域です。LASSICでは、要件のヒアリングから、脆弱性を作り込まないための設計・実装の方針づくり、入力を直接ファイル名にしない作り込み、既存システムの対策状況の確認、脆弱性診断を踏まえた改修まで、上流の検討段階からご相談を承っています。ファイルの受け渡し機能のリスクが気になる、診断で指摘を受けたが対応に迷うといった課題の整理からでも対応が可能です。セキュリティの作り込みに不安がある段階からでも、お気軽にお声がけください。

よくある質問

ディレクトリトラバーサルとパストラバーサルは違うものですか。

基本的には同じ攻撃を指す言葉です。どちらも、ファイル名やパス(ファイルの場所を表す文字列)の指定を悪用して、本来アクセスできないファイルまでフォルダの階層をたどる攻撃を意味します。文献や製品によって「ディレクトリトラバーサル」「パストラバーサル」と呼び方が分かれることがありますが、指している内容はほぼ同じと考えて差し支えありません。報告書などで両方の表記を見かけても、同じ種類の脆弱性の話だと捉えて問題ないでしょう。

WAFを導入すればディレクトリトラバーサル対策は十分ですか。

WAFは補助的な備えにはなりますが、それだけで十分とはいえません。WAFは不審な通信を入り口で検知・遮断する多層防御の一枚で、「..」を含む典型的な攻撃を弾く効果は期待できますが、表現を変えた攻撃をすり抜ける余地は残ります。根本的な対策は、プログラム側で利用者の入力をそのままファイルの場所として使わないことです。番号や識別子で選ばせる、正規化して基準フォルダ配下に限定するといった作り込みを土台に据え、WAFはそれを補う一枚と位置づけて多層で守るのが基本です。

どんな機能があるとディレクトリトラバーサルのリスクが生じますか。

利用者の入力をもとに、サーバ上のファイルを読み書きする機能があるとリスクが生じます。たとえば、指定した資料をダウンロードする、アップロードした画像を表示する、テンプレートのファイルを読み込む、といった機能です。こうした機能自体は一般的で便利なものですが、入力されたファイル名をそのまま場所として使うと、階層を遡られる余地が生まれます。まずは自社のシステムに「入力をもとにファイルを扱う」機能があるかを把握し、あるなら入力を直接ファイル名にしない作りになっているかを確認するとよいでしょう。

古くから動いているシステムも確認すべきですか。

確認しておくことをおすすめします。ディレクトリトラバーサルは古くから知られる脆弱性で、長く稼働しているシステムほど、当時の作り方のまま対策が手薄になりがちです。表面上は正常に動いていても、ファイルを扱う機能に弱点が潜んでいることがあり、読まれるファイル次第では影響が大きくなります。すでに動いているシステムについても、ファイルを扱う機能の作りを一度棚卸しし、必要に応じて脆弱性診断を受けておくと、思わぬリスクの早期発見につながります。

著者:テレリモ総研編集部 鈴木 亮佑

LASSICでは、国内ニアショア開発体制を活かし、ディレクトリトラバーサルをはじめとする脆弱性を作り込まないための設計・実装から、入力を直接ファイル名にしない作り込み、既存システムの対策状況の確認、脆弱性診断を踏まえた改修までを一貫して支援する体制です。ファイルの受け渡し機能のリスクや、診断で受けた指摘への対応にお困りの際もご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セキュリティの作り込みに不安がある段階からでも、ご相談ください。


システム開発・セキュリティ対策のご相談はLASSICへ

元請(プライムベンダー)として、要件整理からご提案・開発・保守までお手伝いします。まずはお気軽にご相談ください。

無料相談はこちら

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典


View