事例から学ぶWebサイトの脆弱点とその対応
連載：Webサイト運営者のセキュリティ確保の心得
第2回
Webアプリケーションサーバに存在する
さまざまな脆弱点
小倉秀敏
インターネットセキュリティシステムズ株式会社
テクニカルサポート部
2002/4/12
前回の「Webサイトセキュリティ侵害事件から見た脆弱点」では、過去に発生したWebサイトのセキュリティ侵害事件から脆弱点を見てきた。今回は、預かり情報を死守するために、各サーバやWebアプリケーションに存在する脆弱点を取り上げ、それらを踏まえたうえでの必要なシステム構築の考え方や、その手法について説明する。
| 各種Webサーバにはそれぞれ脆弱点がある |
●Webサーバの脆弱点
Webサーバは、ファイアウォールにより構成されたDMZに配置されることが一般的である。DMZに配置されることで、だれしも“保護されている”と考えがちであるが、いまやDMZは“インターネットに直接接続されている”状況とまったく同じである。
ファイアウォールの役割は“認証されていない接続が、任意のサービスに接続することをブロック”することであり、Webサーバへの接続の場合は、“外部からのすべての接続がHTTPもしくはHTTPSサービスに接続することを許可”しないと意味がなく、HTTP、HTTPSに対してはファイアウォールは無条件で通すことが普通である。
URLフィルタリングが唯一HTTP、およびHTTPSの内容をチェックする機能であろう。しかもそれは特定のサイトからの接続をブロックするだけのものでしかない。現在の多くの攻撃は、このHTTP、HTTPSを使用し行われるため、ファイアウォールはこの攻撃をブロックすることができない。この意味でWebサーバは、もはやインターネットに直接接続されているのと同じ状況なのである。
さらに、Webサーバの脆弱点を攻撃する非常に多くのクラッキングツールが存在している。クラッキングツールを利用することで、スクリプト・キディ＊1レベルでも容易に攻撃できるのはよくご存じであろう。
Webサーバの脆弱点といえば、マイクロソフトのIISがよく引き合いに出される。一部にはApacheに変更すべきであるとの意見もある。しかしよく調べてみると、どのWebサーバが強固なセキュリティを持つかという議論は、あまり意味がないように思える現状が浮かび上がってくる。
|
●複数のWebサーバに存在する同様の問題
過去IISにはSource Disclosure問題、Unicode Decode問題など大きく取りざたされた問題がいくつかあった。しかしこれらの問題はIISだけに存在したものではなかった。IBMのWebSphereにも同様のSource
Disclosure問題やUnicode Decode問題が発生している。ただその問題の結果がIISとWebSphereでは異なるだけである。
Source Disclosure問題とは、URLに対して特定のパスや文字列を追加すると、Webアプリケーションのソースファイル自体がWebブラウザに送信され、許可されていないユーザーがプログラムを参照することができてしまうという問題である。IISの場合はASP、WebSphereではJSPファイルが該当する。
一方のUnicode Decode問題とは、URLに不正なUnicodeを含めることで、本来の動作とは異なる動作を起こさせる問題である。IISの場合は任意のプログラムを実行できてしまうという重大な脆弱性を引き起こす。またWebSphereの場合は、任意のファイルを参照できるという問題を引き起こす。
| 注意 いずれの問題もすでに解決済みである。適切なパッチもしくは最新版を使用することで、この問題は簡単に解決できる。 |
WebSphereとIISというまったく異なる2つの製品でよく似たセキュリティ上の問題が発生していることから、さまざまな機能を追加されたWebサーバにおいてセキュリティを維持することは、もともと困難なのではないかと危ぐされる。
Webサーバ自体の基本機能としてはHTTP経由での静的WebページのPublishだけであるが、現在の多くのWebサーバにはアプリケーションサーバとしての機能が加わっているうえに、アドオン機能により機能の追加などが容易に図れるようになっており、非常に複雑化している。このような複雑な機能構成が、結果的にセキュリティの維持を困難にするという結果をもたらしているのではないだろうか。
最近はApacheであれば大丈夫だという危険な考え方も一部にはあるように思える。しかしApacheにもmod_xxxxxという追加モジュールが存在し、それらにもセキュリティ上の問題が発生したことがある。つまりApacheも例外ではないのである。次に追加モジュールであるmod_auth_oracleに存在する脆弱点について説明しよう。
●mod_auth_oracleの脆弱点
mod_auth_oracle以外にもmod_auth_mysql、mod_auth_pgsqlなどの各データベース対応の同じ機能を実現するモジュールが存在している。これらはhttp://modules.apache.org/searchで容易に検索することができる。Apacheとmod_auth_oracleモジュールを併用すると、WebアプリケーションはOracle上に作成した任意のテーブルの情報を使用し、ユーザー認証を行うことができる。つまり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を参照するとよいだろう。
| 注意 これらmod_auth_xxxxの脆弱点もすでに解決され、新しいバージョンがリリースされている。 |
| Webサーバに対する基本的な考え方 |
いずれのWebサーバを使用していたとしても、“侵入されること”を想定してシステムを構築する必要がある。“xxxx Webサーバを使っているから安心”という考え方は捨て去らなければならない。
未知の侵入方法が予測範囲内であれば、侵入方法自体に対する対応を行うことである程度侵入を防御することが可能であるが、多くの場合、ソフトウェアのバグなどを悪用されるため、予想の範囲を超えてしまう。これが侵入されることを想定するということである。
● IISをセキュアにする
IISで発生するセキュリティ問題の多くを調べてみると、IUSR_<ホスト名>アカウントの実行権限に突き当たる。Unicode
Decode問題など、任意のプログラムを不正に実行可能な脆弱点の場合、実行されるプログラムはIUSR_<ホスト名>アカウントにより起動されている。IUSR_<ホスト名>アカウントの実行権限を縮小することで、ある程度不正なプログラム実行という問題を少なくすることができそうである。
%SystemRoot%\system32ディレクトリ、およびそこに含まれるファイルの実行権限はEveryoneに対して与えられている。つまりIUSR_<ホスト名>アカウントからの実行が可能になっている。Everyoneに対する実行権限を削除し、適切なアカウントもしくはグループに対してのみ実行権限を与えることで、IUSR_<ホスト名>アカウントを通じて不正にコマンドが実行されることを予防できる。
しかし注意点もある。ASP.DLLはこのディレクトリに存在するため、単純にディレクトリ、およびそこに含まれるファイルに対するEveryoneの実行権限を削除すると、ASPアプリケーションが動作しなくなってしまう。ASP.DLLに対してのみIUSR_<ホスト名>アカウントの実行権限を付加するように変更する。または、ASP.DLLをほかのディレクトリに移動するという方法も考えられるが、DLLはレジストリに登録されているGUIDというオブジェクト番号経由で利用される。そのためディレクトリを移動してしまうと、動作しなくなってしまう。そのため、regsvr32.exeでいったん登録を削除し、別ディレクトリに移動後regsvr32.exeにより再登録をする必要がある。
| Webアプリケーションサーバの問題 |
Webアプリケーションサーバとは、最近ではJavaVMを中心とした、ServletやEJB（Enterprise Java Beans）などの実行プラットフォームを指すことが多くなっている。何らかのWebアプリケーションを実行できるという意味では、IISやPHP、Perlを実行するホストもWebアプリケーションサーバといえるだろう。もちろん過去にはJavaVM自体にもセキュリティ上の脆弱点が存在した。最近ではPHPに脆弱点が発見され、大きな話題を呼んでいる。
ここではWebアプリケーションサーバ自体よりも、その上で動作するユーザーアプリケーションの構成に着目する。Webアプリケーションサーバ自体がいくらセキュアでもダメだということをご理解いただきたい。一口にWebアプリケーションといっても、単純なCookieの使い方からEJBの利用方法まで非常に多岐にわたる。ここではその中のいくつかを取り上げてみる。
●Cookieの処理
Webサイトの場合、セッション処理が非常に大切である。セッションを管理するうえで最もよく使用されるものがCookieである。
Cookieを使用するうえで注意しなければならない点は、WebサイトのクライアントソフトウェアであるWebブラウザが持つ脆弱点により、Cookieは容易に漏えいすることである。しかもWebブラウザのセキュリティ対策ほど当てにならないものはない。
セッション管理情報でさえ、漏えいした場合はかなりの危険性があるのに、それ以上の情報をCookieに持たせるのは命取りとなる。実際にそんなばかなと思わせるような事件が発生している。米バンクワン・オンラインは、Cookieにクレジットカード番号などの重要な情報を格納していたのだ。これではWebブラウザ側の脆弱点を利用され、クライアント側からクレジットカード情報が漏えいしてしまう危険性がある。
Cookie漏えい問題は基本的にはWebブラウザ、つまりWebサイトのクライアント側のセキュリティ問題である。しかし、ユーザーが気が付かなければWebサイトの問題とされてしまう危険性がある。状況を悪くしているのは、クライアント側のセキュリティはWebサイト側からは制御不可能であることである。つまりWebサイト側にとっては、セキュリティに無関心なユーザーの存在自体がセキュリティ上の脆弱点といえる。
●セッションハイジャックとクロスサイト・スクリプティング
クロスサイト・スクリプティングとは、IPA（情報処理振興事業協会）の「Webサイトにおけるクロスサイト
スクリプティング脆弱性に関する情報 」でも情報を公開している、セキュリティ上脆弱なWebアプリケーションに関する問題である。この問題はWebアプリケーションにおける入力文字列の評価、およびCookieの有効期限設定などにより、セキュリティ上の脅威として具現化する。
ではクロスサイト・スクリプティングによる攻撃はどのようにして実行されるのか、攻撃者の視点から見てみよう。筆者はクロスサイト・スクリプティングに関する多くのサイトの説明を読んでみたが、いまひとつ理解できなかった。攻撃者の視点に立って考えて初めて理解できたため、ここでもその視点で説明しよう。
- ターゲットWebサイトの決定
情報を盗み出したいWebサイトを決める。その際下記のような特徴を持つサイトを探す。
- Cookieの有効期限が長い。
- 入力フォームを持つ。
- 入力にJavaScriptを受け付けてしまう。
- 入力フォームに対して確認などのため動的ページ生成を行う。その際入力された情報をそのまま含めてしまう。
いずれも簡単に判断することができる。最後の項目を調べるには、入力フォームに
<script>document.write(document.cookie)</script>
のように簡単なスクリプトを入力し、送信した後、自分のブラウザがそのスクリプトを実行するかどうか、確認すればよいだけである。
- 攻撃用リンクの作成
脆弱なサイトの目的とする入力フォームのパラメータとして、例えば攻撃者のサイトにCookieを送信するようなJavaScriptを埋め込んだリンクを作成し、任意のWebに掲載するか、あるいはWeb形式の掲示板を持つBBSなどにポストする。
- 被害者がリンクをクリック
上記リンクをクリックした被害者のWebブラウザは、ターゲットWebサイトにJavaScriptを含んだHTTPリクエストを送信する。するとその入力に対してWebアプリケーションは動的にページを生成する。その際、攻撃用JavaScriptがそのまま動的ページに含まれてしまう。
- ターゲットWebサイトから被害者へJavaScriptを送信
動的に生成されたページには、攻撃者が仕込んだJavaScriptが含まれている。それが被害者のWebブラウザに送られる。
- JavaScriptの実行
被害者のWebブラウザ上でJavaScriptが実行される。Cookieを攻撃者のサイトに送信するようなJavaScriptの場合、Cookieを送信してしまう。これで攻撃者は被害者のCookieを取得することができる。
- Cookieをセットし、ターゲットWebサイト上でなりすまし
続いて攻撃者は得たCookieを自分のWebブラウザにセットし、ターゲットWebサイト上で被害者になりすます。この時点でCookieの有効期限が終了していなければ、Webサーバは読み込んだCookie情報からセッションが継続していると判断してしまう危険性がある。そうなれば攻撃者は被害者になりすまし、各種情報の取り出しや改変が可能になってしまう。これがセッションハイジャックである。つまりCookieにはセッションしか保存されていなくても、最悪Webサイト上でなりすましが可能になってしまうのである。もちろんこの攻撃は、被害者が攻撃対象のWebサイトのユーザーでなければ成り立たない。
| Webアプリケーションで使用する技術 |
サーバサイドで構築するWebアプリケーションを構成する技術によっても、新たなセキュリティ上の脆弱点を生み出す危険性がある。迅速にWebアプリケーションを構築できるものとして、ASP、JSP、PHPがよく利用されることと思う。統計情報を持っているわけではないが、これらを解説した書籍が数多く出版されていることから、大きく外していることはないだろう。
ではどのような点が問題となり得るのか、下記のコードを参照してもらいたい。
- ASP(ActiveServer Pages)の場合
|
Set oConn = Server.CreateObject("ADODB.Connection")
<- ここ |
- JSP(JavaServer Pages)の場合
|
<dbconnect id="connection_id" |
- PHPの場合
|
$conn = Ora_Logon("scott@orcl", "tiger"); <- ここ |
いずれもプログラム中に、データベースのユーザー名とパスワードがクリアテキストで含まれる。いったん何らかの形で侵入が成功すると、データベースにログオン可能なユーザー名とパスワードが直ちに漏えいし、データベースにまで被害が拡大してしまう危険性が高い。
◇
今回は、Webサーバ、アプリケーションサーバなどに関する過去にあったさまざまな脆弱点について考察した。現在それぞれ修正されているものであるが、今後本記事を基にセキュリティに対する意識を高めてほしい。次回は、データベースサーバの運用、構築などから発生する脆弱点、およびその対策方法などを紹介する。
 |
「連載 Webサイト運営者のセキュリティ確保の心得」 |
|
||||||||||||||
|
||||||||||||||
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
