解説

解説要約

外部からの入力によりパス名を作成し、制限された親ディレクトリ配下に位置するファイルやディレクトリを識別するために用いるようなソフトウェアにおいて、パス名に含まれる特殊な要素の無効化が適切に行われない場合、制限されたディレクトリの外側のパス名解決が可能です。

詳細な解説

制限されたディレクトリの外へ抜け出し、システム内の他のファイルやディレクトリへのアクセスを可能にします。典型的な特殊文字列の例として、現在のディレクトリの親ディレクトリとして解釈される "../" が挙げられます。これは相対パスのトラバーサルと呼ばれます。また、パストラバーサルは、"/usr/local/bin" のような絶対パスも利用でき、予期しないファイルへのアクセスに悪用されます。これは絶対パスのトラバーサルと呼ばれます。

多くのプログラミング言語において、生成されたパス名中への null 文字（0 または NUL）の挿入は、その文字以降の文字列の切り捨てを意味します。攻撃者は null 文字の挿入により、攻撃できる領域を広げます。例えば、全てのパス名に ".txt" を付与するソフトウェアにより攻撃範囲をテキストファイルのみに限定しようとした場合でも、null 文字の挿入によりこの制限は事実上無効化されます。

別名

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

パストラバーサル

"ディレクトリトラバーサル" よりも "パストラバーサル" の方が推奨されますが、いずれも攻撃に焦点を置いた名称です。

名称補足

他の脆弱性と同様に、名称は根本的な脆弱性ではなく操作する手法に基づくことがあります。一部で呼ばれている"ディレクトリトラバーサル"という名称は、ディレクトリを越えるという特別な意味を持つ ".." 及び同様のシーケンスのインジェクションのみに言及するものです。

"絶対パス名" 及び "ドライブ名" といった類似の名称はディレクトリトラバーサルの*効果*を持ちますが、".." あるいは同等の文字列は含まれないため、ディレクトリトラバーサルと呼ばれることはほとんどありません。

脆弱性の発生時期

アーキテクチャおよび設計
実装

該当するプラットフォーム

言語

言語に依存

一般的な影響

 

影響を受ける範囲	影響
完全性	技術的インパクト：権限のないコードやコマンドの実行 攻撃者は、プログラムやライブラリのようなコード実行に使用される機密ファイルの作成又は上書きが可能です。
完全性	技術的インパクト：ファイルやディレクトリの改ざん 攻撃者は、プログラム、ライブラリや重要データのような機密ファイルの作成又は上書きが可能です。標的のファイルがセキュリティのメカニズムに使用されている場合、攻撃者はそのメカニズムを回避することが可能となります。例えば、パスワードファイルの末尾に新規アカウントを加えることで、攻撃者は認証を回避することが可能です。
機密性	技術的インパクト：ファイルやディレクトリの読み取り 攻撃者は、予期しないファイルの内容を読むことが可能であり、極秘データを漏えいさせることが可能です。標的のファイルがセキュリティのメカニズムに使用されている場合、攻撃者はそのメカニズムを回避することが可能となります。例えば、パスワードファイルの読み取りにより、攻撃者はシステムのアカウントを使用して侵入をするために、ブルートフォース攻撃によってパスワードを推測することが可能です。
可用性	技術的インパクト：DoS: crash / exit / restart 攻撃者はプログラム、ライブラリや重要データのような予期しない機密ファイルを、上書き、削除、破損することが可能です。これによりソフトウェアの機能が妨げられ、認証のような保護メカニズムの場合には、ソフトウェアの全てのユーザがロックアウトされる可能性があります。

 

攻撃を受ける可能性

高い〜非常に高い

検出手段

自動静的分析

自動化された手法により、パストラバーサルの脆弱性が存在するエリアを探すことが可能です。一方で、パストラバーサルの脆弱性を取り除くことや、ソフトウェアの管理者や特権ユーザだけが攻略可能なようにして優先度を下げるためには、ソフトウェアのチューニングやカスタマイズが必要となります。

有効性：高

手動静的分析

手動によるホワイトボックス手法において、制限時間の制約内で全てのファイルアクセス操作を評価することができる場合、十分なコード範囲をカバーした上で、フォールスポジティブを減少させることが可能です。

有効性：高

脆弱なコード例

例 1:

 

以下のコードは、各ユーザのプロフィール情報が個別のファイルとして格納されている、ソーシャルネットワーキングアプリケーションの例です。全てのファイルは同一のディレクトリに保存されています。

サンプル言語： Perl （悪い例）

my $dataPath = "/users/cwe/profiles";
my $username = param("user");
my $profilePath = $dataPath . "/" . $username;


open(my $fh, "<$profilePath") || ExitError("profile read error: $profilePath");
print "<ul>¥n";
while (<$fh>) {
print "<li>$_</li>¥n";
}
print "</ul>¥n;"	

プログラマは "/users/cwe/profiles/alice" や "/users/cwe/profiles/bob" といったアクセスファイルを想定しているため、ユーザパラメータの入力には一切確認を行っていません。攻撃者は以下のような文字列を入力します。

（攻撃）

../../../etc/passwd			

プログラムは以下のようなパス名を作成します。

（結果）

/users/cwe/profiles/../../../etc/passwd

ファイルが開かれるとき、オペレーティングシステムはパスの正規化において "../" の解決を行い、実際には以下のファイルにアクセスします。

（結果）

/etc/passwd

その結果、攻撃者はパスワードファイルの全文を読むことが可能となります。

フルパス名が入力され、ユーザのパラメータが存在するファイルを作成しなかった場合、このコードが error message information leak (CWE-209) の脆弱性も含む可能性があることに注意してください。取り出されたファイルの出力エンコーディングが欠如していて、かつ、プロフィールに HTML が含まれている場合には、クロスサイトスクリプティング(CWE-79) の脆弱性も発生する可能性があります。そのため、本脆弱性に該当するファイル以外においても検査する必要があります。

 

例 2:

 

以下の例では、システムプロパティによりディクショナリファイルへのパスが読まれ、File オブジェクトの初期化に使用されます。

サンプル言語： Java （悪い例）

String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename);

しかしこのパスは、ファイルオブジェクトを作成する前に相対パスや絶対パスシーケンスを含むことを防ぐための、妥当性の確認や修正が行われていません。これにより、システムプロパティをコントロールできる人であれば、どのファイルを使用するか決定できます。パスはある種のアプリケーションやユーザのホームディレクトリに対して解決されるべきです。

 

例 3:

 

以下のコードは、信頼できない入力を受け取り、入力から "../" をフィルタするために正規表現を使用しています。その後、その結果に対し /home/user/ ディレクトリを付加し、その最終結果のパス内のファイルを読み込もうとしています。

サンプル言語： Perl （悪い例）

my $Username = GetUntrustedInput();
$Username =" s/¥.¥.¥///;
my $filename = "/home/user/" . $Username;
ReadAndSendFile($filename);

上記の正規表現では g オプション (global match modifier) を使用していないため、発見した"../" の最初のインスタンスのみ除去します。そのため、以下のような値の入力においては、

（攻撃）

../../../etc/passwd

１つ目の "../" が除去され、以下の結果となります。

（結果）

../../etc/passwd

この値は /home/user/ の後に付与され、以下の結果となります。

（結果）

/home/user/../../etc/passwd

これにより、オペレーションシステムがパス名に含まれる ../ シーケンスを解釈した時点で /etc/passwd ファイルを読み取られます。この問題は relative path traversal (CWE-23) を引き起こします。

 

例 4:

 

以下のコードは、入力されたパスに対しホワイトリストによる妥当性の検証を行い、いったん与えられたファイルに対し、検証された削除を行います。このケースでは、"/safe_dir/" という文字列から始まる場合、パスは妥当であると判断されます。

サンプル言語：Java （悪い例）

String path = getInputPath();
if (path.startsWith("/safe_dir/"))
{
File f = new File(path);
f.delete()
}

攻撃者は次のような入力が可能です。

/safe_dir/../important.dat

ソフトウェアは、パスが "/safe_path/" シーケンスから始まっているため妥当であると見なしますが、 "../" シーケンスにより親ディレクトリ内の important.dat ファイルを削除してしまいます。

 

例 5:

 

以下のコードは、Java サーブレットによる制限されていないファイルのアップロード、及びパストラバーサルの脆弱性のデモンストレーションを行います。HTML コードは、前に示したフォームの action 属性を使ったファイルのアップロード送信の例と同様のもので、PHP コードの代わりに Java サーブレットを用いたものです。

サンプル言語：HTML （良い例）

<form action="FileUploadServlet" method="post" enctype="multipart/form-data">

Choose a file to upload: 
<input type="file" name="filename"/>
<br/>
<input type="submit" name="submit" value="Submit"/>

</form>

Java サーブレットの doPost メソッドがリクエストを受け取ったとき、HTTP リクエストヘッダからファイル名を取り出し、リクエストされたファイルの内容を読み込み、ファイルをローカルのアップロードディレクトリへ出力します。

サンプル言語：Java （悪い例）

public class FileUploadServlet extends HttpServlet {
...
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html");
PrintWriter out = response.getWriter();
String contentType = request.getContentType();

// the starting position of the boundary header
int ind = contentType.indexOf("boundary="); 
String boundary = contentType.substring(ind+9);

String pLine = new String(); 
String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value

// verify that content type is multipart form data 
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {

// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine(); 
String filename = pLine.substring(pLine.lastIndexOf("¥¥"), pLine.lastIndexOf("¥""));
...
// output the file to the local upload directory
try {
BufferedWriter bw = new BufferedWriter(new FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; ) {
if (line.indexOf(boundary) == -1) {
bw.write(line);
bw.newLine();
bw.flush();
}
} //end of for loop
bw.close(); 

} catch (IOException ex) {...}
// output successful upload response HTML page
}
// output unsuccessful upload response HTML page
else 
{...}
}
...
}

このコードは、ヘッダから与えられたファイル名のチェックを行いません。そのため攻撃者は "../" シーケンスを使用し、意図したディレクトリの外へファイルを書き込むことが可能です。実行環境によっては、攻撃者は任意のファイルの読み書きや、コード実行、クロスサイトスクリプティング（CWE-79）、システムクラッシュ等、様々な結果をもたらすことが可能です。

また、このコードはアップロードされるファイルタイプのチェックを行っていません。これにより、攻撃者は実行ファイルや、悪意のあるコードを含むファイルをアップロードすることが可能です（CWE-434）。

 

発見された事例

 

参照	詳細
CVE-2010-0467	Newsletter module allows reading arbitrary files using "../" sequences.
CVE-2009-4194	FTP server allows deletion of arbitrary files using ".." in the DELE command.
CVE-2009-4053	FTP server allows creation of arbitrary directories using ".." in the MKD command.
CVE-2009-0244	OBEX FTP service for a Bluetooth device allows listing of directories, and creation or reading of files using ".." sequences..
CVE-2009-4013	Software package maintenance program allows overwriting arbitrary files using "../" sequences.
CVE-2009-4449	Bulletin board allows attackers to determine the existence of files using the avatar.
CVE-2009-4581	PHP program allows arbitrary code execution using ".." in filenames that are fed to the include() function.
CVE-2010-0012	Overwrite of files using a .. in a Torrent file.
CVE-2010-0013	Chat program allows overwriting files using a custom smiley request.
CVE-2008-5748	Chain: external control of values for user's desired language and theme enables path traversal.

 

被害の緩和策

フェーズ：実装

戦略： 入力の妥当性チェック
全ての入力は悪意のあるものと想定してください。仕様に厳密に従い許可する入力のホワイトリストを使用する等、既知の受け入れられている入力の妥当性チェック手法を用いてください。仕様に反する入力を拒否する、あるいは入力を仕様に適応する形に変化させてください。ブラックリストに依存してしまう等、悪意のある、あるいは不正な入力を探すことのみに頼らないでください。しかし、ブラックリストは予測される攻撃の検知や、無条件に拒否するべき不正な入力を決定する際に役立ちます。

入力値の妥当性をチェックする際、関連しそうな全ての要素（長さ、入力タイプ、許容する値の範囲、入力の過不足、構文、関連するフィールド間の一貫性、及びビジネスルールの一致、等）について考慮してください。ビジネスルールの例として、"boat" は英数字しか含まないため構文的に有効ですが、もし開発者が "red" や "blue" のような色の名前を想定する場合には有効ではない、というロジックが挙げられます。

ファイル名には、使用される文字セットを厳しく制限したホワイトリストを使用してください。可能であれば、CWE-23 のような脆弱性を防ぐために、"." のみをファイル名に含めることを許可し、CWE-36 のような脆弱性を防ぐために、"/" のようなディレクトリセパレータを除外するよう制限してください。

警告：データを無害化する場合は、最終結果が危険な形式にならないようにしてください。サニタイジングにより、 "." および ";" などの危険な文字列を除去することが可能ですが、攻撃者により、サニタイジング機能が欺かれ、データを危険な形へ "サニタイジング" される可能性があります。攻撃者がファイル名 "sensitiveFile" に "." を挿入し、"sensi.tiveFile" とした場合を想定します。 サニタイジングにより危険な文字列 "." が除去されると、有効なファイル名 "sensitiveFile" となります。入力データが安全と判断された場合、ファイルのセキュリティ制限は侵害されます。CWE-182 (Collapse of Data Into Unsafe Value) を参照して下さい。

フェーズ：アーキテクチャおよび設計

CWE-602 を防ぐために、クライアント側で行われる全てのセキュリティチェックがサーバ側でも同様に行われていることを確認してください。攻撃者はチェックが行われたあとに値を改ざんする、あるいはチェックを完全に消去することで、クライアント側のチェックを回避することが可能です。その場合、改ざんされた値がサーバに送信されます。

フェーズ：実装

戦略：入力の妥当性チェック
入力されたパス名の妥当性を確認する前に、アプリケーションの内部表現にデコードし、正規化して下さい。二重デコードに注意して下さい。妥当性の確認の後に危険な入力を取り込み、ホワイトリストによる検証を回避される可能性があります。

正規化されたパス名を提供する、ビルドインのパスの正規化関数（例：C言語の realpath() ）を使用してください。 ".." シーケンスやシンボリックリンク（CWE-23、CWE-59）を効果的に削除します。正規化関数は以下のものを含みます：
・C： realpath()
・Java： getCanonicalPath()
・ASP.NET： GetFullPath()
・Perl： realpath() or abs_path()
・PHP： realpath()

フェーズ：アーキテクチャおよび設計

戦略： ライブラリ、フレームワーク
本脆弱性の発生を防ぐ、あるいは本脆弱性を回避しやすい構造を提供する、十分に検査されたライブラリやフレームワークを使用してください。

フェーズ：オペレーション

戦略： ファイアウォール
本脆弱性に対する攻撃を検知するアプリケーションファイアウォールを使用してください。（サードパーティ管理により）コードが修正できなかった場合において、より総合的なソフトウェアの保証手段となるため、緊急回避策として、または多層防御の目的として効果的です。

有効性：中
アプリケーションファイアウォールは全ての入力ベクターを網羅することができない可能性があります。加えて、入力を検証する処理に対して不正な形式の入力により、防御メカニズムを迂回するような行為が可能です。機能性によっては、アプリケーションファイアウォールは不用意に正当なリクエストを拒否、または修正してしまう可能性があります。最終的に、手動によるカスタマイズが必要です。

フェーズ：アーキテクチャおよび設計、オペレーション

戦略： 環境の強化
必要なタスクを実行するために求められる最小限の権限を使用してコードを実行してください。可能であれば、一つのタスクのみに使用される、権限を限定した単独のアカウントを作成してください。それにより、攻撃が成功した場合でも、即座に他のソフトウェアやその環境へアクセスされることは防ぐことができます。例えば、特に日常的なオペレーションにおいて、めったにデータベースの管理者権限を必要としないデータベースアプリケーションが挙げられます。

フェーズ：アーキテクチャおよび設計、オペレーション

戦略： 変換による強制
ファイル名やURLのような条件に適合するオブジェクトが制限されている場合、あるいは既知である場合、固定した入力値（数字のID等）から実際のファイル名やURLのマッピングを作成し、それ以外の入力を拒否してください。
例えば、ID１は "inbox.txt" に、ID２は "profile.txt" にマップしていきます。ESAPI AccessReferenceMap のような機構はこの機能を提供します。

フェーズ：アーキテクチャおよび設計

戦略： サンドボックス、Jail
プロセスとオペレーティングシステムの間で厳重な境界を強制する "jail" や、類似するサンドボックス環境の中でコードを実行してください。これにより、個々のディレクトリにおいてどのファイルに対しアクセス可能か、あるいは、そのソフトウェアによってどのコマンドが実行可能かを効果的に制限可能です。

OSレベルの例として、Unix chroot jail、AppArmor 及び SELinux が挙げられます。一般的に、マネージドコードはいくつかの防御機能を提供します。例えば、Java SecurityManager の持つ java.io.FilePermission は、ファイル処理における制限を指定することが可能です。

これは、ふさわしい解決策ではない可能性があります。また、オペレーティングシステムへの被害を限定するだけであり、残りのアプリケーションは侵害の対象のままです。

CWE-243 及びその他の jail に関連する脆弱性の回避には注意してください。

フェーズ：アーキテクチャおよび設計、作業

戦略： 攻撃面の特定と縮小
可能であれば、ライブラリファイル、include ファイル及びユーティリティファイルは web ドキュメントの root の外に保管してください。あるいは、攻撃者が直接それらのファイルを要求することを防ぐために、分離したディレクトリに保管し web サーバのアクセス制御機能を使用してください。一般的な方法の一つとしては、それぞれの呼び出すプログラムに固定の定数を定義し、ライブラリや include ファイルに定数が存在するかをチェックします。もし定数が存在しない場合、そのファイルは直接要求されたものであり、即座に終了が可能です。

これにより、攻撃者がinclude ファイル内にはないベースプログラム内にある、あらゆる防御メカニズムを回避する機会を著しく減少させることが可能です。また、これにより全体における攻撃可能な面を減少させることが可能です。

フェーズ：実装

エラーメッセージが対象となる読者にとってのみ有益な、最小限の詳細情報しか含まないことを確認してください。メッセージは適度に曖昧になるようバランスを取る必要があります。エラー内容を判別する方法を公開する必要は必ずしもありません。そのような詳細情報は攻撃が成功する機会を増やすための攻撃手法の改良に利用される可能性があります。

もし、エラーが詳細を追跡する必要がある場合、ログメッセージに記録するようにしてください。しかし、攻撃者がログメッセージを閲覧可能である場合に何が起こるかも考慮してください。どんな形式であってもパスワードのような極秘情報が記録されることは避けるべきです。また、ユーザ名が有効か否かといった、攻撃者に内部の構文をほのめかしてしまうような、一貫性のないメッセージにならないよう避けてください。

パストラバーサルの背景において、パスの情報を開示するようなエラーメッセージは、攻撃者によるファイルシステム階層を移動するような攻撃文の作成を促してしまう可能性があります。

フェーズ：オペレーションおよび実装

戦略： 環境の強化
PHP を使用している場合は、register_globals を使用しないようにアプリケーションを設定してください。実装においては、この機能に頼らないようアプリケーションを開発してください。register_globals の類似機能の実装においては CWE-95、CWE-261 及び類似する脆弱性の対象とならないよう警戒してください。

その他の補足

不完全な脆弱性の分析または報告により、影響を与える亜種の特定が困難な場合があります。例えば、"..\" について、その脆弱性が指摘される一方、同様の脆弱性がある "../" については検証していない場合があります。

以下の項目のすべての組合せはパストラバーサルの亜種となる可能性があります。CVE-2004-0325 にて報告された "//../" は、一覧にはありません。

発生における他の脆弱性との依存関係

 

依存関係	詳細
独立的	他の脆弱性の有無に関係せず、独立して発生
依存的	他の脆弱性が存在することにより発生

 

関係性

 

Nature	Type	ID	Name	View(s) this relationship pertains to
ChildOf	Category	21	Pathname Traversal and Equivalence Errors	Development Concepts (primary)699
ChildOf	Category	632	Weaknesses that Affect Files or Directories	Resource-specific Weaknesses (primary)631
ChildOf	Weakness Class	668	Exposure of Resource to Wrong Sphere	Research Concepts1000
ChildOf	Weakness Class	706	Use of Incorrectly-Resolved Name or Reference	Research Concepts (primary)1000
ChildOf	Category	715	OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference	Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOf	Category	723	OWASP Top Ten 2004 Category A2 - Broken Access Control	Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOf	Category	743	CERT C Secure Coding Section 09 - Input Output (FIO)	Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOf	Category	802	2010 Top 25 - Risky Resource Management	Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors(primary)800
ChildOf	Category	813	OWASP Top Ten 2010 Category A4 - Insecure Direct Object References	Weaknesses in OWASP Top Ten (2010)(primary)809
ParentOf	Weakness Base	23	Relative Path Traversal	Development Concepts (primary)699
				Research Concepts (primary)1000
ParentOf	Weakness Base	36	Absolute Path Traversal	Development Concepts (primary)699
				Research Concepts (primary)1000
MemberOf	View	635	Weaknesses Used by NVD	Weaknesses Used by NVD (primary)635
CanFollow	Weakness Class	20	Improper Input Validation	Research Concepts1000
CanFollow	Weakness Class	73	External Control of File Name or Path	Research Concepts1000
CanFollow	Weakness Class	172	Encoding Error	Research Concepts1000

 

関係性の補足

パス名の同値は、正規化エラーの一種とみなされる場合があります。

パス名と同等の問題のうちのいくつかは、直接的にはディレクトリトラバーサルと関係はなく、むしろ、攻撃者からのファイル、ディレクトリへのアクセス可否を判断するためのセキュリティ関連のチェックを回避するために利用されています。

要調査事項 （CWE の見解）

パストラバーサル攻撃の多くの種類においては、rootが引き起こすものに関して未だ研究中です。CWE-790 及び CWE-182 はこのギャップの一部を埋め始めています。

影響を受けるシステムリソース

ファイル/ディレクトリ

関連するプロパティ

Equivalence

機能分野

ファイル処理

原因の性質

明確

他組織での分類

 

組織名または組織での分類	ノード ID	CWEの分類との適合度	分類名
PLOVER			Path Traversal
OWASP Top Ten 2007	A4	CWEの方が詳細	Insecure Direct Object Reference
OWASP Top Ten 2004	A2	CWEの方が詳細	Broken Access Control
CERT C Secure Coding	FIO02-C		Canonicalize path names originating from untrusted sources
WASC	33		Path Traversal

 

関連する攻撃パターン

 

CAPEC-ID	攻撃パターン名 (CAPEC Version 1.5)
23	File System Function Injection, Content Based
64	Using Slashes and URL Encoding Combined to Bypass Validation Logic
78	Using Escaped Slashes in Alternate Encoding
79	Using Slashes in Alternate Encoding
76	Manipulating Input to File System Calls
139	Relative Path Traversal

 

参照

[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 11, "Directory Traversal and Using Parent Paths (..)" Page 370. 2nd Edition. Microsoft. 2002.  
[REF-17] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
OWASP. "Testing for Path Traversal (OWASP-AZ-001)". <http://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
Johannes Ullrich. "Top 25 Series - Rank 7 - Path Traversal". SANS Software Security Institute. 2010-03-09. <http://blogs.sans.org/appsecstreetfighter/2010/03/09/top-25-series-rank-7-path-traversal/>.

更新履歴

[2011年04月21日]
  2010年10月12日時点のデータを元に更新
[2009年06月29日]
  2009年02月02日時点の下記 URL を元に作成
    http://cwe.mitre.org/data/definitions/22.html