![]() |
【連載】
セキュアなWebサイトを運営するための
Webアプリケーションに潜むセキュリティホール
第1回 サーバのファイルが丸見え?!
国分裕
三井物産セキュアディレクション
2003/5/7
| ※ご注意 他社および他組織の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を想像するだろう。
|
||||||||||||||||||||||||||||||||||||||||||||||
|
想像できる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/ |
|
画像ファイルにアクセスするためのURL例 |
フレームで上下2つに分割されているページであれば、ページ全体、上側のページ、下側のページ、合計3つのコンテンツから構成されていることになる。
![]() |
| 図1 あるWebページの構成例 |
3つのページそれぞれがURLを持っている。フレーム内のページのURLを直接URL欄に入力すれば、フレームの一部だけにアクセスすることもできる。
これはごく当たり前のことで、Webコンテンツを作ったことのある方ならだれでも知っているだろう。それなのに、特定ユーザー専用ページになるとこれを忘れてしまっている場合が多い。画像を含んだ
“HTMLページ”に対しては認証を掛けて制限しているが、そのページに含まれるコンテンツへの制限は必要ないだろうか。特定のユーザーだけが見られるはずのコンテンツすべてに、適切に認証が掛かっているだろうか。
これらのURLとしては一見見えないコンテンツに対してのアクセス制限を忘れていると、会員専用のコンテンツに実はだれでもアクセスできていた、ということになってしまう。
| Path Traversal(パスの乗り越え) |
アプリケーションに渡されるパラメータを基にファイルの読み込みをしている場合に、この危険がある。例えば、すべてのページを共通のフォーマットにするためにテンプレートを使用して、メインのコンテンツをパラメータで指定するようなアプリケーションが挙げられる。
![]() |
| 図2 テンプレートを使ってすべてのページを共通フォーマットにしているサイト例(拡大) |
これが、次のようなPerlプログラムで実装されているとする。
#!/usr/bin/perl |
| リスト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$/
|| |
| リスト2 決められた値以外を受け付けないようにする |
分かっていても多すぎてアプリケーションに書ききれなかったり、頻繁にコンテンツが更新されてそのたびにアプリケーションを修正していられないならば、若干セキュリティ強度は落ちるが、正規表現などである程度の範囲を指定すればよいだろう。英数字のみを許可する場合は、次のような正規表現で指定できる。
if($PARAMETER{file} =~ /^[0-9a-zA-Z]+$/){ |
| リスト3 英数字のみを許可する |
テンプレートを使ったアプリケーションに限らず、渡されたパラメータを基にファイルを開くアプリケーションは数多くある。十分に注意していただきたい。
◇
今回は、任意のファイルを読み出されてしまう危険性について紹介した。Path Traversalについて脆弱なプログラムをリスト1に載せたが、実は このプログラムはPath Traversalの問題だけでなくさらに危険なセキュリティホールを含んでいる(リスト2、3の対策をしていれば防げる)。次回はそれらについて説明するが、どのような危険があるかぜひ考えておいていただきたい。
| 「第2回」へ |
Webアプリケーションに潜むセキュリティホール バックナンバー
- 第1回 サーバのファイルが丸見え?!
- 第2回 顧客データがすべて盗まれる?!
- 第3回 気を付けたい貧弱なセッション管理
- 第4回 エラーメッセージの危険性
- 第5回 Webアプリケーションの検査テクニック
- 第6回 Webサイトのセッションまわりを調べる方法
- 第7回 攻撃されないためのセッション管理の検査方法
- 第8回 Webサイトの問い合わせ画面に含まれる脆弱性
- 第9回 オンラインショッピングにおける脆弱性の注意点
- 第10回 安全なWebアプリケーション開発のススメ
- 第11回 Webアプリケーションファイアウォールによる防御
- 第12回 mod_securityのXSS対策ルールを作成する
- 第13回 OSコマンドインジェクションを防ぐルールを作成する
- 最終回 Webアプリケーションの脆弱性を総括する
| Profile |
| 国分 裕(こくぶ ゆたか) 三井物産セキュアディレクション勤務。セキュリティコンサルタン トとして、不正アクセス監視やセキュリティ検査 などに従事している。金融機関、官公庁、大手製造業などへのセキュリティシ ステムの導入、セキュリティ 検査などの実績を持つ。 三井物産セキュアディレクション 主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サー ビスも実施中。 |
|
||||||||
| Security&Trust記事一覧 |
TechTargetジャパン
- 無料サービスなら通信内容を記録してもいいの? (2012/1/13)
無料の公衆無線LANサービスが、ユーザーに無断で通信履歴を記録していたことが判明し、話題に - 攻撃はまるでレーザービーム (2011/12/26)
2011年に話題となった標的型攻撃は「人」という弱点ををねらい打ちにしました。では、人に教育さえしておけば防げるものなのでしょうか? - 見せたくないなら「持たせない」が鉄則! (2011/12/15)
逆コンパイル対策で難読化したのに、大事なデータが解析されちゃった? Androidアプリのセキュリティの道は深い - イベントの秋と盛り上がったプライバシー問題 (2011/12/13)
イベントが各所で開催され、賑わう一方で、プライバシー関連の話題が引き続き議論の焦点に
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -




