サイト脆弱性をチェックしよう！ --　第7回：「ディレクトリトラバーサル」と「強制ブラウジング」

前回は、SQLインジェクションについて説明した。前回の対策について不明瞭な部分があるとの指摘を受けたので、その部分について、まず説明する。

前回、「SQLインジェクション対策の基本はXSSと同じく適切なエスケープ処理を行うことだが、最近の開発環境の多くは、Prepared Statementあるいはバインドメカニズムと呼ばれる仕組みが実装されているので、それらを用いることが最も簡単な方法といえる」と記述した。

その意図は、「SQLインジェクション対策の基本はエスケープ処理となる。しかし、エスケープ処理を行う代わりに、Prepared Statementあるいはバインドメカニズムをデータベースへのアクセスに利用する方が簡単かつ安全だ」ということだ。

Prepared Statementあるいはバインドメカニズムを使用することで、開発者がコードを書く量を少なくでき、結果として、脆弱性（バグ）の混入を低減することができる。

当然のことながら、動的に検索条件の検索項目を変更したい場合など、バインドメカニズムを利用することは困難な場合がある。その場合は、SQLインジェクションが発生しないように注意して、エスケープ処理を行わなければならない。

さて、今回はSQLインジェクションと並んで情報漏えいにつながる脆弱性である「ディレクトリトラバーサル」と「強制ブラウジング」について説明する。

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

ディレクトリトラバーサルとは、ファイルをウェブアプリケーションが使用する場合に、相対パス表記を用いて任意のファイルにアクセスしてしまう脆弱性だ。

この脆弱性を利用した事件として有名なのは、ACCSのサイトから個人情報が漏えいした2003年の事件だ。この事件では、脆弱性のある「csvmail.cgi」がACCSのサイトで使用されており、Hiddenフィールドで指定したテンプレートを表示する機能を悪用して、任意のファイルの内容が表示可能となってしまった。

• 検査手法
  ディレクトリトラバーサルは、通常の手法では変更できないHiddenフィールドやCookieに脆弱性が存在することが多々ある。このため、「第5回：XSSの脆弱性を検査する方法」にて説明したような検査ツールをこの検査でも用いる。 この脆弱性の検査では、多くの場合、指定したファイルの内容がHTTPレスポンスに含まれるので、そのファイルに存在する文字列を検索することで脆弱性の有無が判断できる。 使用するデータは、OSの設定ファイルなど存在していることがわかっているファイルを相対パス表記で表したものだ。こうしたデータには、以下のようなものがある。

このようなデータを送信し、HTTPレスポンスにファイルの内容が含まれていた場合、脆弱性があると判断できる。上記の例であれば、以下のような文字列を検索する。

• UNIX系OSの場合　root:
• Windowsの場合　　[boot loader]

この手法では、うまく脆弱性を発見できないケースがある。その場合、任意のディレクトリに設置したファイルにアクセス可能かどうかを、OSのログなどを用いて確認する。

例えば、「../../../../../../tmp/test.txt」を入力して、「/tmp/test.txt」に指定したデータが出力されているかといったことを確認する。

• 対策
  ディレクトリトラバーサル対策でもっとも確実な方法には、以下のようなものが考えられる。
  
  
  1. Webアプリケーションがアクセス可能なディレクトリ（たとえば、/var/data/）と、その配下にあるファイルのファイル名（これが入力データとなる。たとえば、../../../etc/passwd）を組み合わせたパス（この例であれば、/var/data/../../../etc /passwd）を開発言語などが用意している方法で正規化する。
  2. 正規化されたパス（先の例であれば、/etc/passwd）がアクセス可能なディレクトリ（先の例であれば、/var/data）の配下にあるかどうかを確認する。これには、正規化されたパスがアクセス可能なディレクトリに前方一致しているかどうかを確認する。
  3. 前方一致している場合のみ、ファイルの読み書きを行う。
  パスの正規化を開発言語などでサポートしていない場合、開発者がパスの正規化を自作する必要がある。しかし、そのようなコードを作成する代わりに、ディレクトリを区切る文字を含まない場合のみファイルの読み書きを行うことなどで対策が可能だ。
  
  この方法の場合、文字コードの違いによる影響についても考慮する必要があるため、除外する文字があることを検出する方法（いわゆるブラックリスト方式）は推奨できない。
  
  使用するファイルが制限されているのであれば、ファイル名を直接指定するのではなく、使用するファイル名を配列などで管理しておき、Hiddenフィールドなどの入力データとして、配列の添え字を指定することで、容易にこの脆弱性が存在しないアプリケーションを作成することができる。

強制ブラウジングとは

強制ブラウジングは、ユーザーが本来アクセス権限のないファイルまたはページにアクセスできる脆弱性だ。 この脆弱性が原因となった事件として、もっとも有名なものは2002年に発生したTBCからの個人情報漏えい事件だ。この事件は、使用していたウェブアプリケーションで、本来利用者にアクセスされてはいけない個人情報を含むファイルをウェブサーバのドキュメントルート上に保存していたため、ウェブサーバ経由で誰でも取得可能になっていたというものだ。 また、1年前まで、会員制サイトにユーザーがアップロードした画像が、会員でないユーザーにもアクセス可能だった。これは、セッション管理が適切に行われておらず、適切なアクセス制御がなされていなかったためだ。 このように、この脆弱性は、データの保存場所の問題だけでなく、セッション管理の問題も原因となる。

• 検査手法
  この脆弱性の検査は、非常に簡単だ。脆弱性の原因によって若干方法は異なるが、いずれも問題となるURLに対してブラウザからアクセスできるかどうかを確認するだけでよい。 データの保存場所に起因する場合は、ブラウザから直接保存場所にアクセスできるかどうかで確認する。
  
  たとえば、検査対象ホスト名が「www.example.com」、 データの保存場所がウェブサーバのドキュメントルート上のディレクトリ「/data/」であり、そのファイルが「user.csv」である場合、以下のようなURLに対してブラウザでアクセスし、閲覧可能かどうかで判断する。
  
  http://www.example.com/data/user.csv
  
  閲覧が可能な場合は、この脆弱性が存在する。
  
  一方、セッション管理の問題に起因する場合は、ログインしていない状態で、ログイン後の画面にアクセスする。その結果、正常にアクセス可能であれば、この脆弱性が存在すると判断できる。

• 対策
  データの保存場所に起因する場合の対策は、外部からアクセスできる場所であるウェブサーバのドキュメントルート上に機密情報を格納しないことだ。レンタルスペースなどで、ドキュメントルート上以外にファイルを保存できない場合、該当ファイルにブラウザでアクセスできないようにアクセス制御を行う。
  
  たとえば、Apacheの場合、「.htaccess」ファイルにて設定を行うことで制御することが可能だ。
  
  一時ファイルからシステム内部の情報が漏えいする危険性があるため、長期間保存する必要があるファイルだけでなく、一時ファイルの保存場所についても、外部からアクセスできない場所にしておく必要がある。
  
  セッション管理の問題に起因する場合の対策では、ログインしているかどうか全てのページで確認を行い、ログインしていない場合、ログインを促すページに転送するなどを行う。
  
  今回は、情報漏えいにつながる可能性の高い脆弱性について説明した。次回は、セッション管理に起因する脆弱性について紹介する。