Hello there, ('ω')ノ
✅ 多くのアプリケーションは防御を試みている
現実のWebアプリでは、開発者は ユーザー入力をファイルパスに使うリスクを認識しており パストラバーサル対策を実装している場合が多いです。
しかし、多くの対策は完全ではなくバイパス可能です。
🎯 代表的な防御とバイパス例
1️⃣ ../や..\の除去・ブロック
| 防御内容 | 攻撃者のバイパス |
|---|---|
明示的に../を除去 |
URLエンコード → %2e%2e%2f |
| 大文字小文字での防御 | ..%2F, %2e%2e/, %252e%252e%252f |
Windowsでは\をブロック |
..%5c (%5c = \)でバイパス |
2️⃣ パストラバーサル自体は禁止 → 直接パス指定
アプリによっては
../が含まれていればブロック- しかし 絶対パス指定にはノーチェック
📚 例
GET /loadImage?filename=/etc/passwd
→ 相対パス../を使わずに直接ファイルを指定
→ バイパス成功
3️⃣ 単純パターンマッチでの誤検出
多くの自家製バリデーションは
filename.contains("../") などの
単純な文字列チェックに頼っています。
→ 攻撃者は
%2e%2e%2f....//.//.//などの変種記法で回避できます。
4️⃣ Unicode/Double URLエンコード攻撃
| 手法 | 説明 |
|---|---|
| Double URL Encoding | %252e%252e%252f → %25が%に復元 → %2e%2e%2f |
| Unicode表記 | 特殊文字をUnicode形式（例：%u2216）で表記して解釈ズレを狙う |
✅ 攻撃者が必ず試すバイパスパターン
../../../../../etc/passwd ..%2f..%2f..%2fetc/passwd %2e%2e%2f%2e%2e%2fetc/passwd ..%252f..%252fetc/passwd ....//....//etc/passwd
✅ 防御側への教訓
| 防御策 | 説明 |
|---|---|
| OS標準のパス正規化関数を使う | realpath(), Path.GetFullPath() など |
| 入力値の正規化後にチェック | realpath()後にベースパスと比較 |
| ファイルパスはユーザー入力を直接使わない | IDやハッシュでマッピングする |
| 全エンコードパターンの展開を考慮 | URLエンコード、Unicode、Double Encodingへの対策必須 |
✅ まとめ
パストラバーサル対策は 単純な文字列チェックだけでは必ず破られます。
攻撃者は
- 正規表現の甘さ
- URLエンコード/デコードの順序ズレ
- UnicodeやDouble Encodingの癖 を巧みに突いてきます。
「パスを絶対にユーザー入力から直接組み立てない」 これが最大かつ唯一の防御策です。
Best regards, (^^ゞ
