ディレクトリトラバーサル

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

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

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

例

PHPによる脆弱なアプリケーションの典型例を以下に示す:

<?php
$template = 'blue.php';
if ( is_set( $_COOKIE['TEMPLATE'] ) )
   $template = $_COOKIE['TEMPLATE'];
include ( "/home/users/phpguru/templates/" . $template );
?>

このシステムに対する攻撃として、以下のような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/ の後に繰り返される ../ 文字列がルートディレクトリへさかのぼるinclude()を引き起こし、それから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はブルース・シュナイアー (Bruce Schneier) とジェフリー・シュトレイフリング (Jeffrey Streifling) によるCryptogram Newsletter July 2000において脆弱性と攻撃媒介の源として注目された。

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 が文字列比較を行うとき同じ文字となることに気付かなかった。

→「Unicode正規化」も参照

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

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

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