連載

2003年5月7日

サーバのファイルが丸見え？！：Webアプリケーションに潜むセキュリティホール（1）

[国分裕，三井物産セキュアディレクション] PC用表示関連情報

LINE

Hatena

※ご注意

他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。

本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。

また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。

　最近Webアプリケーションに存在するセキュリティホールが注目を浴びている。その中でも「クロスサイトスクリプティング（XSS）」と呼ばれる脆弱性が有名で、「特集クロスサイトスクリプティング対策の基本」という記事で詳細に解説した。しかし、Webアプリケーションに潜む脆弱性はXSSだけではなく、XSSよりもはるかに危険性の高いセキュリティーホールが存在する。

　本稿では、Webアプリケーションに潜むXSS以外のセキュリティホールについて解説を行っていくので、開発者の方にはどのような危険が潜んでいるのかを認識していただき、セキュアなアプリケーション開発に役立てていただきたい。

Webアプリケーションに対する攻撃

　「特集クロスサイトスクリプティング対策の基本」でも紹介したが、Webアプリケーションに対する代表的な攻撃手法を再度紹介する。

Buffer Overflow（バッファオーバーフロー）
Cross Site Scripting（クロスサイトスクリプティング）
Parameter Manipulation（パラメータ改ざん）
Backdoor & Debug Options（バックドアとデバッグオプション）
Forceful Browsing（強制的ブラウズ）
Session Hijacking／Replay（セッション・ハイジャック／リプレイ）
Path Traversal（パスの乗り越え）
SQL Injection（SQLの挿入）
OS Command Injection（OSコマンドの挿入）
Client Side Comment（クライアント側コメント）
Error Codes（エラーコード）

　これらの攻撃のほとんどは、ファイアウォールやIDS（不正侵入検知システム）では守ることも検知することもできない、ということを再度強調しておく（テスト環境をお持ちの方は、本稿中で挙げる脆弱なアプリケーション例とそれに対する攻撃例を試してみるといいだろう）。

　つまり Webアプリケーションは、何からも守られず無防備なままインターネット上にさらされている状態にある。これを守るためには注意深く開発を行う以外にないということを、アプリケーション開発者の方は肝に銘じていただきたい。

Forceful Browsing（強制的ブラウズ）

　この攻撃は、Webアプリケーションだけでなくhttpdの設定も関係してくる。手法としてはとても単純で、「ブラウザにURLを入力する」というだけだ。ではどのようなURLを入力するかというと、通常のブラウジングではアクセスするはずのないURLを入力する。

　例えば、次のようなURLのページがあるとしよう。

http://www.example.com/some/path/filename1.html

　攻撃者はこのURLを見ただけで、さまざまなURLを想像するだろう。

（1） http://www.example.com/some/path/

（2） http://www.example.com/some/

（3） http://www.example.com/

（4） http://www.example.com/some/path/core

（5） http://www.example.com/some/path/admin.cgi

（6） http://www.example.com/some/path/backup/

（7） http://www.example.com/some/path/test/

（8） http://www.example.com/some/path/filename1.html.bak

（9） http://www.example.com/some/path/filename1.html~

（10） http://www.example.com/some/path/filename1.shtml

（11） http://www.example.com/some/path/filename1.cgi

（12） http://www.example.com/some/path/filename.html

（13） http://www.example.com/some/path/filename0.html

（14） http://www.example.com/some/path/filename2.html

（15） https://www.example.com/some/path/filename1.html

↓


（1）～（3）：	ファイルパス途中のディレクトリ
（4）～（5）：	よくありそうなファイル名
（6）～（7）：	よくありそうなディレクトリ名
（8）～（9）：	バックアップファイル
（10）～（12）：	異なる拡張子
（13）～（14）：	連番になっているファイル
（15）：	https
想像できるURLの例

　もちろん上に挙げた種類だけでもないし、複数のパターンを組み合わせて新しいURLを作り出してくるだろう。これらのURLがどのページからもリンクが張られていないとしても、さらに実際に存在してようがしていまいが、攻撃者はアクセスしてくる。

　リンクされていないコンテンツとしては、コメントアウトされているURLもある。あるコンテンツの提供期間が終了したため、そのページへのリンクを消すことがあるが、ページからリンクを削除するのではなく、単にコメントアウトしている場合が多々見られる。

<!-- <a href="present.html">期間限定（3/31まで）</a> -->

コメントアウトの例

　ブラウザの画面上には表示されないこのリンクも、HTMLのソースを見ればすぐに見つかってしまう。過去に公開していたコンテンツなのでアクセスされても問題がない場合もあるが、アプリケーションのテスト用に使っていたページなど、見られるとうれしくないページもあるだろう。

　攻撃者はHTMLを読んだりURLを想像して手当たり次第アクセスするしかないのに対して、サーバ管理者側はマシンにログインしてファイルの一覧を見れば公開する必要のないファイルがあるかどうかは一目瞭然だろう。定期的にチェックをして不要なファイルを公開ディレクトリに置いておかないようにしておこう。

　さらに、どこかのページからリンクされているページで、特定のユーザーだけしか見られないはずのコンテンツがだれでも見られるようになっている場合もある。いまブラウザのURL欄を見ていただくと、このページのURLしか表示されていないだろう。しかし実際にはもっと多くのコンテンツの組み合わせでこのページは構成されていて、すべてURLが存在する。その1つが画像ファイルで、このページにも数十個の画像があり、それぞれの画像ファイルにアクセスするためのURLが存在する。

　このページのトップにある画像は、次のようなURLでアクセスすることができる。

http://www.atmarkit.co.jp/fsecurity/rensai/webhole01/webhole_topimage.gif

画像ファイルにアクセスするためのURL例

　フレームで上下2つに分割されているページであれば、ページ全体、上側のページ、下側のページ、合計3つのコンテンツから構成されていることになる。

図1 あるWebページの構成例

　3つのページそれぞれがURLを持っている。フレーム内のページのURLを直接URL欄に入力すれば、フレームの一部だけにアクセスすることもできる。

　これはごく当たり前のことで、Webコンテンツを作ったことのある方ならだれでも知っているだろう。それなのに、特定ユーザー専用ページになるとこれを忘れてしまっている場合が多い。画像を含んだ“HTMLページ”に対しては認証を掛けて制限しているが、そのページに含まれるコンテンツへの制限は必要ないだろうか。特定のユーザーだけが見られるはずのコンテンツすべてに、適切に認証が掛かっているだろうか。

　これらのURLとしては一見見えないコンテンツに対してのアクセス制限を忘れていると、会員専用のコンテンツに実はだれでもアクセスできていた、ということになってしまう。

Path Traversal（パスの乗り越え）

　アプリケーションに渡されるパラメータを基にファイルの読み込みをしている場合に、この危険がある。例えば、すべてのページを共通のフォーマットにするためにテンプレートを使用して、メインのコンテンツをパラメータで指定するようなアプリケーションが挙げられる。

図2 テンプレートを使ってすべてのページを共通フォーマットにしているサイト例（クリックで拡大）

　これが、次のようなPerlプログラムで実装されているとする。

#!/usr/bin/perl 
# ヘッダ部分の出力
&print_header（）;  
# メインコンテンツの出力
open FILE, "$PARAMETER{file}.html";
while（<FILE>）{
print;
} 
# フッタ部分の出力
&print_footer（）;

リスト1 /var/www/html.cgi

　このアプリケーションには大きな落とし穴がある。もし、

../admin/secret

という値がパラメータにわたされたらどうだろう。本来は/var/www以下のファイルしか表示されないはずが、実際に開かれるファイルは、

/var/admin/secret.html

となり、別のディレクトリのファイルが表示対象となる。このように別のディレクトリのファイルにアクセスさせることから、Path Traversal（パスの乗り越え）と呼ばれる。前述のForceful

Browsing（強制的ブラウズ）対策としてユーザーがアクセスできるファイルに認証を掛けていたとしても、アプリケーションがアクセスできるファイルの制限とは別物のため、表示されてしまうことになる。同様の手法で、DocumentRoot以下のファイルだけではなく、サーバ上の任意の場所のファイルが読めるだろう。

　また、ファイル名の後ろに「.html」と付けているHTMLファイルだけに制限しているようにも思えるが、実はそうではない。もし、

/etc/passwd%00

と入力されたらどうなるだろうか。%00はNULL文字といい、PerlやC言語などで文字列の終端として認識される。つまり実行されるopen命令は、

open FILE, "/etc/passwd";

となり、/etc/passwdの内容がすべて出力されてしまうことになる。

図3 /etc/passwd の内容がすべて出力されてしまった（クリックで拡大）

　もちろん/etc/passwdに限らず、アプリケーションのソースファイル、サーバの設定ファイル、顧客情報データベースなどほぼすべてのファイルが対象になるだろう。

　しかし、この対策はそう難しくない。パラメータとして受け付ける値を制限してしまえばよい。上記の例ではfileというパラメータを使っているが、どういう値を受け付けるのかあらかじめ分かっているのならば、それ以外の値を受け付けないようにする。Perlで書くと次のようになるだろう。

if（$PARAMETER{file} =~ /^company$/ 
||
$PARAMETER{file} =~ /^concept$/ ||
$PARAMETER{file} =~ /^index$/ ||
$PARAMETER{file} =~ /^service$/）{
#正常処理
# メインコンテンツの出力
} else {
#エラー処理
}

リスト2 決められた値以外を受け付けないようにする

　分かっていても多すぎてアプリケーションに書ききれなかったり、頻繁にコンテンツが更新されてそのたびにアプリケーションを修正していられないならば、若干セキュリティ強度は落ちるが、正規表現などである程度の範囲を指定すればよいだろう。英数字のみを許可する場合は、次のような正規表現で指定できる。

if（$PARAMETER{file} =~ /^[0-9a-zA-Z]+$/）{
#正常処理
# メインコンテンツの出力
} else {
#エラー処理
}

リスト3 英数字のみを許可する

　テンプレートを使ったアプリケーションに限らず、渡されたパラメータを基にファイルを開くアプリケーションは数多くある。十分に注意していただきたい。

　今回は、任意のファイルを読み出されてしまう危険性について紹介した。Path Traversalについて脆弱なプログラムをリスト1に載せたが、実はこのプログラムはPath Traversalの問題だけでなくさらに危険なセキュリティホールを含んでいる（リスト2、3の対策をしていれば防げる）。次回はそれらについて説明するが、どのような危険があるかぜひ考えておいていただきたい。

著者紹介

国分裕（こくぶゆたか）

三井物産セキュアディレクション勤務。セキュリティコンサルタントとして、不正アクセス監視やセキュリティ検査などに従事している。金融機関、官公庁、大手製造業などへのセキュリティシステムの導入、セキュリティ検査などの実績を持つ。

三井物産セキュアディレクション

主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サービスも実施中。

「次回」へ

「Webアプリケーションに潜むセキュリティホール」バックナンバー