| ＠IT > Security&Trust > 事例から学ぶWebサイトの脆弱点とその対応 |
 特集 小倉秀敏
ファイアウォールの役割は“認証されていない接続が、任意のサービスに接続することをブロック”することであり、Webサーバへの接続の場合は、“外部からのすべての接続がHTTPもしくはHTTPSサービスに接続することを許可”しないと意味がなく、HTTP、HTTPSに対してはファイアウォールは無条件で通すことが普通である。 URLフィルタリングが唯一HTTP、およびHTTPSの内容をチェックする機能であろう。しかもそれは特定のサイトへの接続をブロックするだけのものでしかない。現在の多くの攻撃は、このHTTP、HTTPSを使用し行われるため、ファイアウォールはこの攻撃をブロックすることができない。この意味でWebサーバは、もはやインターネットに直接接続されているのと同じ状況なのである。 さらに、Webサーバの脆弱点を攻撃する非常に多くのクラッキングツールが存在している。クラッキングツールを利用することで、スクリプト・キディレベルでも容易に攻撃できるのはよくご存じであろう。 Webサーバの脆弱点といえば、マイクロソフトのIISがよく引き合いに出される。一部にはApacheに変更すべきであるとの意見もある。しかしよく調べてみると、どのWebサーバが強固なセキュリティを持つかという議論はあまり意味がないように思える現状が浮かび上がってくる。 ●複数のWebサーバに存在する同様の問題 一方のUnicode Decode問題とは、URLに不正なUnicodeを含めることで、本来の動作とは異なる動作を起こさせる問題である。IISの場合は任意のプログラムを実行できてしまうという重大な脆弱性を引き起こす。またWebSphereの場合は、任意のファイルを参照できるという問題を引き起こす。
WebSphereとIISというまったく異なる2つの製品でよく似たセキュリティ上の問題が発生していることから、さまざまな機能を追加されたWebサーバにおいてセキュリティを維持することは、もともと困難なのではないかと危ぐされる。 最近はApacheであれば大丈夫だという危険な考え方も一部にはあるように思える。しかしApacheにもmod_xxxxxという追加モジュールが存在し、それらにもセキュリティ上の問題が発生したことがある。つまりApacheも例外ではないのである。追加モジュールであるmod_auth_oracleに存在する脆弱点について説明しよう。 ●mod_auth_oracleの脆弱点 このモジュールの脆弱点とは、mod_auth_oracleモジュールがOracleに対して送信するSQLクエリーに、HTTPリクエストを通じて任意のSQLコードを挿入できてしまうというものである。つまりSQLクエリー中のデータが改変される可能性が生まれる。またこの脆弱点によりSQLクエリーを改変し、ストアドプロシージャの実行も可能になってしまう。 mod_auth_oracleは、認証プロセスの際SELECTステートメントを構成し、Oracleに送信する。この脆弱点を利用すると、Oracleに対して送信するSELECTステートメントに任意の文字列、例えば「;SELECT 'xxxxxxx、」を追加することができてしまうのである。するとパスワードルックアップのSELECTステートメントの後に、;（セミコロン）で別のSELECTステートメントを接続し、データベースに送信することができる。 Oracle以外のデータベースの場合、1回のクエリー中で複数のSQLステートメントの実行が可能であるが、Oracleの場合はそのようなSQLステートメントの実施は認められていない。しかしUNION句を使用することで、SQLステートメントの連結が可能である。しかもストアドプロシージャの実行さえ可能になってしまう。 詳しくはhttp://cert.uni-stuttgart.de/advisories/apache_auth.phpを参照するとよいだろう。
いずれのWebサーバを使用していたとしても、“侵入されること”を想定してシステムを構築する必要がある。“xxxx Webサーバを使っているから安心”という考え方は捨て去らなければならない。 未知の侵入方法が予測範囲内であれば、侵入方法自体に対する対応を行うことである程度侵入を防御することが可能であるが、多くの場合、ソフトウェアのバグなどを悪用されるため、予想の範囲を超えてしまう。これが侵入されることを想定するということである。 ● IISをセキュアにする %SystemRoot%\system32ディレクトリ、およびそこに含まれるファイルの実行権限はEveryoneに対して与えられている。つまりIUSR_<ホスト名>アカウントからの実行が可能になっている。Everyoneに対する実行権限を削除し、適切なアカウントもしくはグループに対してのみ実行権限を与えることで、IUSR_<ホスト名>アカウントを通じて不正にコマンドが実行されることを予防できる。 しかし注意点もある。ASP.DLLはこのディレクトリに存在するため、単純にディレクトリ、およびそこに含まれるファイルに対するEveryoneの実行権限を削除すると、ASPアプリケーションが動作しなくなってしまう。ASP.DLLに対してのみIUSR_<ホスト名>アカウントの実行権限を付加するように変更する。ASP.DLLをほかのディレクトリに移動するという方法も考えられるが、DLLはレジストリに登録されているGUIDというオブジェクト番号経由で利用される。そのためディレクトリを移動してしまうと、動作しなくなってしまう。regsvr32.exeでいったん登録を削除し、別ディレクトリに移動後regsvr32.exeにより再登録をする必要がある。
Webアプリケーションサーバとは、最近ではJavaVMを中心とした、ServletやEJB（Enterprise Java Beans）などの実行プラットフォームを指すことが多くなっている。何らかのWebアプリケーションを実行できるという意味では、IISやPHP、Perlを実行するホストもWebアプリケーションサーバといえるだろう。もちろん過去にはJavaVM自体にもセキュリティ上の脆弱点が存在した。最近ではPHPに脆弱点が発見され、大きな話題を呼んでいる。 ここではWebアプリケーションサーバ自体よりも、その上で動作するユーザーアプリケーションの構成に着目する。Webアプリケーションサーバ自体がいくらセキュアでもダメだということをご理解いただきたい。一口にWebアプリケーションといっても、単純なCookieの使い方からEJBの利用方法まで非常に多岐にわたる。ここではいくつかを取り上げてみる。 ●Cookieの処理 Cookieを使用するうえで注意しなければならない点は、WebサイトのクライアントソフトウェアであるWebブラウザが持つ脆弱点により、Cookieは容易に漏えいすることである。しかもWebブラウザのセキュリティ対策ほど当てにならないものはない。 セッション管理情報でさえ漏えいした場合は、かなりの危険性があるのに、それ以上の情報をCookieに持たせるのは命取りとなる。実際にそんなばかなと思わせるような事件が発生している。米バンクワン・オンラインは、Cookieにクレジットカード番号などの重要な情報を格納していたのだ。これではブラウザ側の脆弱点を利用され、クライアント側からクレジットカード情報が漏えいしてしまう危険性がある。 Cookie漏えい問題は基本的にはWebブラウザ、つまりWebサイトのクライアント側のセキュリティ問題である。しかし、ユーザーが気が付かなければWebサイトの問題とされてしまう危険性がある。状況を悪くしているのは、クライアント側のセキュリティはWebサイト側からは制御不可能であることである。つまりWebサイト側にとっては、セキュリティに無関心なユーザーの存在自体がセキュリティ上の脆弱点といえる。 ●セッションハイジャックとクロスサイト・スクリプティング ではクロスサイト・スクリプティングによる攻撃はどのようにして実行されるのか、攻撃者の視点から見てみよう。筆者はクロスサイト・スクリプティングに関する多くのサイトの説明を読んでみたが、いまひとつ理解できなかった。攻撃者の視点に立って考えて初めて理解できたため、ここでもその視点で説明しよう。
サーバサイドで構築するWebアプリケーションを構成する技術によっても、新たなセキュリティ上の脆弱点を生み出す危険性がある。迅速にWebアプリケーションを構築できるものとして、ASP、JSP、PHPがよく利用されることと思う。統計情報を持っているわけではないが、これらを解説した書籍が数多く出版されていることから、大きく外していることはないだろう。 ではどのような点が問題となり得るのか、下記のコードを参照してもらいたい。
いずれもプログラム中に、データベースのユーザー名とパスワードがクリアテキストで含まれる。いったん何らかの形で侵入が成功すると、データベースにログオン可能なユーザー名とパスワードが直ちに漏えいし、データベースにまで被害が拡大してしまう危険性が高い。 ◇ 今回は、Webサーバ、アプリケーションサーバなどに関するさまざまな脆弱点について考察した。次回は、データベースサーバの運用、構築などから発生する脆弱点、およびその対策方法などを紹介する。
|
 |
||||||||||||||||||||||||||||
