(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サーバが提供することを許されているもの領域を踏み越えているので、エラーを返す。