情報セキュリティマネジメント試験情報＆徹底解説

情報セキュリティマネジメント試験 用語辞典

(Wikipedia ディレクトリトラバーサルより)

ディレクトリトラバーサル (directory traversal) とは、利用者が供給した入力ファイル名のセキュリティ検証/無害化が不十分であるため、ファイルAPIに対して「親ディレクトリへの横断 (traverse)」を示すような文字がすり抜けて渡されてしまうような攻略方法のことである。

この攻撃の目標は、アクセス可能にすることを意図していないファイルへのアクセスをアプリケーションに命令することである。この攻撃は、コードに含まれるバグの攻略とは対照的に、セキュリティの欠如 (ソフトウェアがまさにそう振る舞うことになっている動作) を攻略する。

ディレクトリトラバーサルにはthe ../ (ドットドットスラッシュ) 攻撃、 ディレクトリクライミング、およびバックトラッキングのような別名がある。この攻撃の一部の形態は、正規化攻撃でもある。

例

脆弱なアプリケーションの典型例は以下の通り:

このシステムに対する攻撃として、以下のようなHTTP要求の送信が考えられる:

GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

生成されるサーバの応答は以下のようになる:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache
root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh 
daemon:*:1:1::/tmp: 
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh

/home/users/phpguru/templates/ の後に繰り返される ../ 文字列がルートディレクトリへさかのぼるを引き起こし、それからUNIXパスワードファイル /etc/passwd をインクルードする。

UNIX /etc/passwd はクラッカーがパスワードクラッキングにしばしば使うため、ディレクトリトラバーサルの実演でよく使われるファイルである。

ディレクトリトラバーサルの変化形

ディレクトリトラバーサルを防ぐのは見かけより困難である。「既知のまずい文字を取り除く」防御戦略は失敗する可能性が高い。

ディレクトリトラバーサルが実際に機能するかどうか決定する他の入り組んだ要因が多数存在する。しかしながら、もしアプリケーションがパラメータなどの正当性を検証しなかったら、攻撃者がこの機能性を悪用する小さな隙間を見つけ出す可能性は非常に高い。

以下は既知のディレクトリトラバーサル攻撃文字列の一部である:

UNIXにおけるディレクトリトラバーサル

UNIXライクOSに共通のディレクトリトラバーサルは ../ 文字列を使う。

Microsoft Windowsにおけるディレクトリトラバーサル

Microsoft WindowsやDOSのディレクトリトラバーサルは ..\ 文字列を使う。

現在は、多くのWindowsプログラムやAPIがUNIXライクなディレクトリトラバーサル文字列も受け付ける。

各パーティションは独立したルートディレクトリ (パーティション C の場合 C:\ とラベル付けされる) を持ち、その上に共通のルートディレクトリは存在しない。このため、Windows上のディレクトリトラバーサル脆弱性のほとんどは攻撃先が1パーティションに限られることになる。

パーセントエンコードされたディレクトリトラバーサル

正規化問題。

クエリ文字列は通常使用する前にURIデコードされるが、行儀の悪いWebアプリケーションの中には、ディレクトリトラバーサルを防ぐためURIデコード前のクエリ文字列から以下のような危険な文字列を走査するものが存在する:

• ..
• ..\
• ../

ゆえにこのような「デコード前に走査する」アプリケーションは以下のようなパーセントエンコードされたディレクトリトラバーサルに対して脆弱である:

• %2e%2e%2f (../ に変換される)
• %2e%2e/ (../ に変換される)
• ..%2f (../ に変換される)
• %2e%2e%5c (..\ に変換される)

etc.

Unicode / UTF-8エンコードされたディレクトリトラバーサル

正規化問題。

UTF-8はブルース・シュナイアーとJeffrey Streiflingによるにおいて脆弱性と攻撃媒介の源として注目された。

Microsoftが彼らのWebサーバにUnicode対応を追加したとき、../ をエンコードするための新しい方法がそのコードに入り込み、ディレクトリトラバーサル防止の試みの迂回を引き起こす原因となった。

• %c1%1c
• %c0%9v
• %c0%af

のような複数のパーセントエンコードが / や \ の文字列に変換された。

なぜか? パーセントエンコードはMicrosoftのWebサーバにより対応する8ビット文字にデコードされたからである。WindowsとDOSはASCIIを基にした正規化された8ビット文字集合を伝統的に使っていたため、これは歴史的には正しい動作だった。

しかしながら、初期のUTF-8は正規化されておらず、今や数種類の文字列が同じ文字列に変換されることになった。MicrosoftはUTF-8を正規化することなくトラバーサル対策チェックを行っていたため、(HEX) C0AF と (HEX) 2F が文字列比較を行うとき同じ文字となることに気付かなかった。

ディレクトリトラバーサルを防ぎうる手法

ディレクトリトラバーサルを防げる可能性のあるアルゴリズムは以下のようなものである:

• URIの要求がファイルの要求にならないように処理する。たとえば、後続の処理を続ける前にユーザーコード内にフックを実行する。
• ファイルやディレクトリへのURI要求がなされるべきときは、存在するならファイルやディレクトリへのフルパスを構築し、すべての文字を正規化する (たとえば、%20 をスペースに変換する)。
• '文書ルート'は完全修飾されており、正規化されており、パスは既知で、この長さNの文字列であると仮定する。このディレクトリ外のファイルは提供できないと想定する。
• 要求されたファイルへの完全修飾パスの先頭N文字が'文書ルート'と正確に同じであることを確認する。
• もしそうなら、ファイルを返すことを許す。
• そうでなければ、要求は明らかにWebサーバが提供することを許されているもの領域を踏み越えているので、エラーを返す。

• 総当たり攻撃
• 辞書攻撃
• パスワードリスト攻撃
• レインボーテーブル
• サイドチャネル攻撃
• クロスサイトスクリプティング
• クロスサイトリクエストフォージェリ
• クリックジャッキング
• ドライブバイダウンロード
• SQLインジェクション
• ディレクトリトラバーサル
• ディレクトリリスティング
• OSコマンドインジェクション
• 中間者攻撃
• MITB攻撃
• 第三者中継
• DNSキャッシュポイズニング
• DNS水責め攻撃
• IPスプーフィング
• セッションハイジャック
• セッションID固定化攻撃
• リプレイ攻撃
• DoS攻撃
• DDoS攻撃
• EDoS攻撃
• メールボム
• 標的型攻撃
• APT
• 水飲み場型攻撃
• フィッシング
• ワンクリック詐欺
• スミッシング
• ゼロデイ攻撃
• テンペスト攻撃
• ポートスキャン
• ダウングレード攻撃
• フットプリンティング
• SEOポイズニング

• 情報セキュリティの考え方(10)
• 情報セキュリティの重要性(2)
• 脅威(23)
• 脆弱性(2)
• 不正のメカニズム(1)
• 攻撃者の種類(3)
• 攻撃の動機(1)
• サイバー攻撃手法(38)
• 暗号技術(11)
• 認証技術(5)
• 利用者認証(8)
• 生体認証技術(3)
• 公開鍵基盤(6)

• 情報セキュリティ(113)
• 情報セキュリティ管理(44)
• セキュリティ技術評価(9)
• 情報セキュリティ対策(41)
• セキュリティ実装技術(19)

このページのWikipediaよりの記事は、ウィキペディアの「ディレクトリトラバーサル」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。