Hello there, ('ω')ノ
✅ 多くのシステムでは単純な../
をブロックしている
現代のWebアプリやWAFでは
../
や ..%2f
の単純なパターンは検出&ブロックされるケースが増えています。
🎯 しかし攻撃者は「ネストトラバーサル」で回避を狙う
✅ ネストトラバーサルとは?
複数の.
や/
,\
を組み合わせてあえて曖昧な文字列を作り、
サーバー側のフィルターや正規化処理の甘さを突くテクニックです。
📚 代表的な例
....//etc/passwd ....\/etc/passwd ..../\../etc/passwd ....%2fetc/passwd
✅ 攻撃の仕組み:
- サーバー側でパストラバーサルフィルターが
../
や..\
しか検出していない ....//
→ 内部的には../
に正規化される- 最終的に 通常のパストラバーサルとして機能する
✅ 実際のサーバーやライブラリの脆弱挙動
- ファイルパス正規化ライブラリが
....//
→../
....\/
→../
と 勝手に置き換えて処理してしまうケースが存在する
🧠 攻撃者の戦略(診断時の試行順)
../../../../../etc/passwd
..%2f..%2fetc/passwd
....//etc/passwd
....\/etc/passwd
..%2e%2e%2fetc/passwd
..%252fetc/passwd
(Double URL Encoding)
✅ まとめ:開発者・診断者への教訓
やるべきこと | 理由 |
---|---|
OS標準のrealpath() でパス正規化 |
あらゆる表現ゆらぎを統一できる |
ユーザー入力値はパスに使わない | 最も確実 |
ネストパターンも必ず想定して診断する | 実際の攻撃では高頻度で使われる |
ファイルシステムAPI前にフィルターではなく検証 | 実ファイルアクセス直前のチェックが必須 |
✅ 結論
「....//」や「..../」は現実の攻撃でもバイパス成功例が多いです。 WAFやアプリ独自フィルターの甘さを突くとても強力な手法です。
攻撃者の観点では 単純トラバーサル → URL Encoding → ネストトラバーサル の順で段階的に試すのが基本戦略になります。
Best regards, (^^ゞ