午前I問題
Webアプリケーションにおけるディレクトリトラバーサル攻撃に関する記述として、適切なものはどれか。
ア)攻撃者がリクエストパラメータに ../ などの相対パス表記を含めることで、アプリケーションが本来アクセスを許可していないディレクトリのファイルを不正に読み取らせる攻撃である。
イ)攻撃者がSQL文の一部をパラメータに注入し、データベースの内容を不正に取得する攻撃である。
ウ)攻撃者がリクエストヘッダのHostフィールドを改ざんし、キャッシュサーバに偽の内容をキャッシュさせる攻撃である。
エ)攻撃者がログイン済みユーザのセッションIDを窃取し、なりすましでシステムにアクセスする攻撃である。
午前I の解答・解説を見る
正解: ア
解説:
- ア)正解。ディレクトリトラバーサル(パストラバーサル)は
../(親ディレクトリへの移動)を利用してアプリケーションの想定するディレクトリ範囲外のファイルにアクセスする攻撃です。 - イ)不正解。これはSQLインジェクションの説明です。
- ウ)不正解。これはWebキャッシュポイズニングの説明です。
- エ)不正解。これはセッションハイジャックの説明です。
午前II問題
次のコードは、ファイル名をパラメータで受け取り、指定ディレクトリ配下のファイルを返すPHPの処理である。
$filename = $_GET['file'];
$path = "/var/www/uploads/" . $filename;
readfile($path);
このコードに対し、file=../../../../etc/passwd というリクエストを送信した場合に生じる問題と、最も効果的な対策の組み合わせはどれか。
ア)問題:SQLインジェクションが発生する。対策:プリペアドステートメントを使用する。
イ)問題:ディレクトリトラバーサルにより意図しないファイルが読み取られる。対策:basename() 等でパス区切り文字やディレクトリ指定を除去し、さらに正規化後のパスが許可ディレクトリ配下であることを検証する。
ウ)問題:クロスサイトスクリプティングが発生する。対策:出力時にHTMLエスケープを行う。
エ)問題:ディレクトリトラバーサルにより意図しないファイルが読み取られる。対策:../ という文字列のみをブラックリストとして置換・除去する。
午前II の解答・解説を見る
正解: イ
解説:
- ア)不正解。このコードはファイルパス操作の処理であり、SQL文は関与しません。
- イ)正解。
../を連結してディレクトリを遡る典型的なディレクトリトラバーサルです。対策は「入力からファイル名部分のみを抽出する(basename()等)」に加え、「パスを正規化した上で許可ディレクトリのプレフィックスと一致するか検証する」というホワイトリスト的な多層対策が効果的です。 - ウ)不正解。出力エスケープはXSS対策であり、このファイル読み取り処理には無関係です。
- エ)不正解。
../のみを除去・置換するブラックリスト方式は、....//(除去後に../が再構成される)や絶対パス指定(/etc/passwd)、URLエンコード(%2e%2e%2f)、ヌルバイト(%00)等の手法で容易に迂回されるため、根本対策として不十分です。
| 対策 | 効果 |
|---|---|
basename()でファイル名のみ抽出 | パス区切り文字を無効化 |
| 正規化後にホワイトリストディレクトリと照合 | 根本対策 |
../ の文字列置換のみ | 迂回されやすく不十分 |
| 固定のファイルIDとマッピング | 最も安全(パスを直接受け取らない) |
午後問題
K社のファイル管理システムでは、ユーザがアップロードした帳票PDFをダウンロードする機能を提供している。ダウンロードURLは以下の形式である。
https://k-sha.example.com/download?file=report_2026.pdf
セキュリティ診断の結果、以下の指摘を受けた。
file=../../../etc/passwdというリクエストを送信したところ、サーバのシステムファイルの内容がレスポンスとして返された。file=....//....//....//etc/passwd(../を除去する簡易フィルタの回避を狙ったペイロード)でも同様にファイルが読み取れることが確認された。file=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd(URLエンコードされたペイロード)でも読み取り可能であった。
調査の結果、開発者は入力値から文字列 ../ を単純に除去(置換)するフィルタのみを実装していたことが判明した。
設問1
....//....//....//etc/passwd というペイロードが、../ を除去するフィルタを回避できてしまう理由を50字以内で説明せよ。
設問1の解答・解説を見る
正解例: フィルタが ../ の1回の除去のみで再帰的に処理しないため、除去後に ../ が再構成されてしまうため。
解説・採点基準(計15点):
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 「除去が1回限り(非再帰的)」である旨の説明 | 1回のみの置換/再帰的でない | 8点 |
除去後に../が再構成される点への言及 | 除去後に文字列が再結合される | 7点 |
解説: ....// から中央の ../ に相当する部分を1回だけ除去すると ..//(実質 ../)が残ってしまいます。これは典型的な「不完全なブラックリストフィルタ」の弱点であり、1回限りの文字列置換ではなく、パスを正規化した上でチェックする設計が必要な理由を示す好例です。
設問2
K社が実装すべき恒久的な対策を、URLエンコードされたペイロードへの対応も含めて2つ述べよ。
設問2の解答・解説を見る
正解例:
- リクエストパラメータをURLデコードし、さらにOS/言語の標準APIでパスを正規化(絶対パス化)した上で、その結果が許可されたベースディレクトリのプレフィックスと一致するかを検証する。一致しない場合はアクセスを拒否する。
- ファイル名を直接パラメータとして受け取る設計をやめ、DBに保存したファイルIDとサーバ内の実ファイルパスをマッピングし、ユーザには常にIDのみを渡す設計に変更する。
解説・採点基準(計15点):
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 対策1 | デコード後の正規化+ホワイトリストディレクトリとの照合 | 8点 |
| 対策2 | ファイルIDへのマッピング/パスを直接受け取らない設計 | 6点 |
| URLエンコードへの言及 | デコード処理を明示している | 1点(部分点) |
解説: ブラックリスト型の文字列置換(../ の除去)は、二重エンコード・多重連結・OS依存の区切り文字(Windowsの \)など無数のバリエーションで迂回されるため、根本対策になりません。最も安全なのは「ユーザにファイルパスを直接扱わせない」設計(IDマッピング)であり、やむを得ずパスを扱う場合は正規化後のホワイトリスト照合が必須です。
重要キーワード
| 用語 | 説明 |
|---|---|
| ディレクトリトラバーサル | 相対パス表記等を用いてアプリケーションの想定範囲外のファイルにアクセスする攻撃 |
| パス正規化 | ../ や ./ 等を解決し、パスを一意な絶対パス表現に変換する処理 |
| ブラックリスト型フィルタ | 既知の危険な文字列のみを除去・拒否する方式。迂回されやすい |
| ホワイトリスト型検証 | 許可された範囲・形式のみを受け入れる方式。より安全 |
| ヌルバイト攻撃 | %00 等を挿入し文字列処理系にパスの終端と誤認させる古典的な回避手法 |
| ファイルIDマッピング | ユーザにファイルパスを直接渡さず、内部IDで実ファイルと対応付ける設計 |
まとめ
- 午前I視点: ディレクトリトラバーサルは
../による相対パス操作がキーワード。SQLi・キャッシュポイズニング・セッションハイジャックとの選択肢の混同に注意 - 午前II視点: ブラックリスト型の文字列置換(
../の単純除去)は多重連結やエンコードで迂回される点を理解し、正規化+ホワイトリスト照合が根本対策である点を押さえる - 午後視点: フィルタ回避ペイロード(二重連結・URLエンコード)の仕組みを説明できるようにし、恒久対策としてパス正規化とファイルIDマッピングの両方を挙げられるようにする