ディレクトリトラバーサルとは｜攻撃の仕組み・ログの見分け方・対策と午後対策
ディレクトリトラバーサル（パストラバーサル）の仕組みを、実際のアクセスログの読み方と併せて解説。「../ の除去」では防げない理由と、正規化・索引方式による根本対策、情報処理安全確保支援士の午後問題での問われ方まで。
ディレクトリトラバーサル（パストラバーサル、CWE-22）は、Web アプリが「どのファイルを返すか・読むか」を利用者から受け取った文字列で決めているときに、その文字列を無検査でファイルの場所（パス）の組み立てに使ってしまうことで成立する脆弱性です。攻撃者は、本来公開するつもりのないファイル——設定ファイル、データベースの接続情報、/etc/passwd、ソースコードなど——をアプリに読み出させ、外部へ持ち出します。実装言語やフレームワークを問わず、「利用者入力をパスに使う」設計であれば、どこでも起こり得ます。
攻撃の入口はどこか
典型的な入口は、ファイル名や文書 ID をパラメータで受け取る機能です。「?path=2026/annai.pdf」のように配布物を指定する download 機能、「?template=header.html」のようにテンプレートを読み込む機能、画像やレポートのダウンロード機能などが該当します。アプリはこの文字列を基準ディレクトリ（配布物の置き場所）に連結して開こうとします。
BASE_DIR = "/srv/docs"
# 受け取った文字列をそのまま連結している（危険）
target = os.path.join(BASE_DIR, param)
return send_file(target)
# param = "annai.pdf" → /srv/docs/annai.pdf（正常）
# param = "../app/config.ini" → /srv/app/config.ini（外に出た）
# param = "../../../../etc/passwd" → /etc/passwd（もっと外へ）os.path.join や文字列連結は「../」を特別扱いしません。連結した結果を OS がパスとして解決するとき、「..」は一つ上の階層へ移動するため、基準ディレクトリの外側にあるファイルを指せてしまいます。
ログでの見分け方
インシデント対応では、まずアクセスログとアプリのログを突き合わせます。着目点は次の3つです。
- 要求に「../」や、その符号化表記（%2e%2e%2f、..%2f、二重エンコードの %252e など）を含む行がないか。通常の利用ではまず現れない
- 応答コード。404 は「そのファイルは無かった（外れた試行）」、200 は「返してしまった（成功）」。攻撃者は当たりを探して何度も試すため、同じ相手の 404 と 200 が並ぶ
- アプリ側のログに「実際に返したファイルの絶対パス」が残っていれば、何が持ち出されたかを確定できる。アクセスログの「要求」だけでは、成功したかどうかまでは分からない
「404 の件数が一番多い相手」が攻撃者とは限らない点にも注意します。単にワードリストで巡回しているスキャナは 404 を大量に出しますが、何も取れていないことが多い。むしろ「200 を返した ../ 付きの要求」を出した相手こそ、実害につながっています。
なぜ「../ を除去する」だけでは防げないのか
「入力から ../ を取り除けばよい」という発想は、拒否リスト（ブラックリスト）方式です。これは「消すべき危険な表記」を、防御側があらかじめ数え上げられている範囲でしか働きません。同じ「一つ上へ」を意味する表記は多数あります。
- URL エンコード：%2e%2e%2f（= ../）
- 二重エンコード：%252e%252e%252f（サーバが一度デコードすると %2e%2e%2f に戻る）
- バックスラッシュ：..\（Windows 系）
- 冗長な表記や、絶対パスの直接指定（/etc/passwd）
一箇所でも数え漏らせば、そこが穴になります。除去処理を一度通したあとにデコードが走ると、除去をすり抜けた表記が復活することもあります。だから「危険を列挙して消す」方向ではなく、次の「安全を確かめる」方向で守ります。
根本対策
- 正規化してから検査する：組み立てた経路を正規化（realpath / os.path.realpath 相当）して実体のパスに解決し、それが基準ディレクトリの内側にあることを確認する。外れていれば拒否してログに残す
- 入力をパスに使わない（索引方式）：利用者からは文書 ID だけを受け取り、ID と実ファイル名の対応表を引く。利用者の文字列は照合にしか使わず、パスの組み立てには一切使わない。これが最も堅い
- 許可リスト：拡張子や文字種を、許すものだけに限定する（拒否リストの逆）
- 多層防御：仮に経路が通っても読めないよう、機微ファイルの権限を最小化し、アプリの実行ユーザを限定する
base = os.path.realpath(BASE_DIR)
target = os.path.realpath(os.path.join(base, param))
# 正規化後の経路が、基準ディレクトリの内側にあるかを検査する
if not target.startswith(base + os.sep):
abort(403) # 外を指していたら拒否
return send_file(target)情報処理安全確保支援士 試験での問われ方
午前Ⅱでは、脆弱性の種類の識別（ディレクトリトラバーサルと、SQL インジェクション・OS コマンドインジェクションの区別）が問われます。いずれも「利用者からの文字列を、解釈される場所へそのまま渡した」点は共通で、渡した先が何か（ファイルパスか、SQL か、シェルか）で名前が変わる、と整理すると覚えやすいです。午後問題では、アクセスログの断片を読ませ「攻撃の種類」「成功したか否か」「流出した情報」「対策」を記述させる形が多く、応答コードと応答サイズ、要求に含まれる相対経路が根拠になります。対策の記述では、暫定対策（設定変更で経路を断つ）と恒久対策（実装で正規化と検査を入れる）の書き分けが求められます。
実際に出た形を見ておきます。令和5年度 秋期 午前Ⅱ 問1 は、「入力した文字列が PHP の exec 関数などに渡されることを利用し、不正にシェルスクリプトを実行させる」攻撃がどれに分類されるかを問うものでした。選択肢には HTTP ヘッダインジェクション・OS コマンドインジェクション・CSRF・セッションハイジャックが並びます。答えは OS コマンドインジェクションですが、ここで効くのは攻撃名の暗記ではなく「渡した先はシェルか、SQL か、ファイルパスか」という切り分けです。ファイルパスに渡っていればディレクトリトラバーサル、という同じ物差しで判断できます。
IPA 公式 PDF：令和5年度 秋期 午前Ⅱ問題（問1 が脆弱性の識別） ↗解答例と採点講評も公式サイトで公開されています。
IPA 公式：過去問題（情報処理安全確保支援士試験） ↗各年度の問題冊子・解答例・採点講評の PDF を、公式サイトで確認できます（本文の転載はしていません）。
確認しておきたいこと
- 利用者入力をファイルパスの組み立てに使っている箇所はどこか
- 組み立てた経路を正規化し、基準ディレクトリ内かを検査しているか
- エンコードされた表記（%2e など）でも防げるか（除去だけに頼っていないか）
- 機微ファイルの権限は最小化され、経路が通っても読めない状態か