事例から学ぶWebサイトの脆弱点とその対応
連載：Webサイト運営者の
　 　　　　　　　　　　　　セキュリティ確保の心得

第3回
データベースサーバの構築、運用から発生する脆弱点とその対策

小倉秀敏
インターネットセキュリティシステムズ株式会社
テクニカルサポート部
2002/5/15

　前回の「Webアプリケーションサーバに存在するさまざまな脆弱点」では、Webサーバ、アプリケーションサーバなどに関する過去にあったさまざまな脆弱点について考察した。今回は、データベースサーバの運用、構築などから発生する脆弱点、およびその対策方法などを紹介する 。データベースはセキュリティ上の考慮が最もされにくいポイントとなっているのが現状だ。今後本記事を基にデータベースセキュリティに対する意識を高めてほしい。

Webサイトの運用、構築方法などから発生する脆弱性

　Webサイトにおいて、実はデータベースはセキュリティ上の考慮が最もされにくいポイントとなっている。通常のシステム管理の現場を考えてみよう。ネットワーク管理者はネットワークと各種OSの管理、データベース管理者はデータベースの管理と役割が明確に分かれていることだろう。ネットワーク管理者から見たデータベースはネットワーク上にぶら下がる複雑なサーバで、その管理はデータベース管理者任せである。一方データベース管理者からは、ネットワークは単なるインフラであり技術的に関与するものではないと見なされている。実際問題として、データベース管理者はデータの保全活動、要するにバックアップ作業とパフォーマンスの維持作業で手いっぱいであり、セキュリティなど二の次になっている。これではデータベースのセキュリティを技術的に見る人がいないことになる。

　では、そこにセキュリティ専門の技術者がいる場合はどうだろうか。残念ながら事態はそれほど変わらないのが現実である。世の中のセキュリティ関連技術者の多くは（ほとんどはといってもよいかもしれない）ネットワーク関連技術者であり、データベースをよく知らない人たちなのである。

　ここで少し視点を変えて、データベースを使用したシステム開発の過程でどのようなことが行われているのか、説明しよう。通常データベースを要するシステム開発を行う場合、データベースに対してはすべてDBA（Database Administrator）権限を持つユーザーを使用して開発が進められることが多い。これにより、やっかいな権限の問題に遭遇することがなくなるのである。そしてカットオーバー直前にセキュリティを意識し始め、適用してみる。その結果多くの場合、一部の機能が動作しないなどの問題に遭遇してしまう。すべての機能がDBA権限が前提で構成されてしまっているので、これは当然の結果といえる。そして動作させるためすべての設定を元に戻すのである。ここにすべてDBA権限で動作するシステムが出来上がる。そのようなデータベースでは、一度侵入を許すとすべての情報が漏えいしてしまう危険性がある。

●ほかのデータベースへの侵害

　ここではWebサイトの構成要素の1つとなっているデータベースについてのみ説明を進めているが、それだけではWebサイトの全要素とはいえない、例えば別の基幹系データベースには影響はないのだろうか。情報のやりとりが存在する限り、影響がないなどということはあり得ない。基幹系データベースが別途存在する場合、リアルタイムもしくはバッチジョブでWebサイト内のデータベースから情報のレプリケーションが行われる可能性が十分高い。そのレプリケーションに使用される接続形態により、Webサイト内データベースを踏み台にした直接侵入、Webサイト内データベースの保存情報を改ざんすることによる不正データのレプリケーションなど、いくつかのセキュリティ上考慮しなければならない点がある。

●データベース自体に存在する脆弱性

　過去多くのOSやネットワーク機器が、“単純なパスワードは拒否する”“パスワードの有効期限を設定する”などをして、パスワード管理の問題と戦ってきた。データベースのパスワード管理において、その戦いはまさに始まったばかりといえる。OracleではOracle8までは各種パスワード管理機能は存在していなかった。MicrosoftのSQL Serverの場合、SQL Server自体にはパスワード管理機能は存在せず、プラットフォームのWindowsにパスワード管理を任せるという道を選んだ。データベースにおける最大の脆弱点はパスワード管理にあるといっても過言ではない。パスワード管理の問題をついたワームもすでに発生している。「第1回 Webサイトセキュリティ侵害事件から見た脆弱点」で述べたCBLADワームがその一例である。CBLADワームはSQL Serverのデフォルトパスワードがセキュリティ上問題があることを悪用するものである。

　このようなセキュリティの基礎であるパスワード管理の問題以外にも、もちろんデータベース特有の脆弱点も存在する。

●Oracleの場合

・Listener Connect Statements
　Oracle 7.3.4, 8.0.6および8.1.6において、攻撃者はListenerプログラム中のSET LOG_FILE（ログファイル）およびSET TRACE_FILE（トレースファイル）パラメータを変更することができてしまう。これにより、攻撃者は通常Oracleを実行しているoracleアカウントのコントロールを得て、データベースを構成するファイルの破壊などが可能となる。これを改善するにはOracleよりリリースされているpatch #1398259をインストールすればよい。これによりOracle実行時にはlistener.oraへの変更が禁止され、この脆弱点を解消することができる。

・Intelligent Agent Patch
　OracleのIntelligent Agentがrootによって所有され、かつsetuidビットがオンになっている場合、そのエージェントで使用される実行可能ファイルには脆弱点があることが確認されている。この脆弱点を放置しておくと、そのファイルを実行できるユーザーが、rootとしてシステムにアクセスしてくる恐れがある。詳しくはX-Forceの報告内容を参照するとよいだろう。Oracle 8.0.x の場合は8.0.6にバージョンアップするか、または8.0.5.1パッチを適応する必要がある。Oracle 8.1.5 の場合は8.1.6にバージョンアップするか、8.0.1.5パッチを適用する。いずれもOracleより入手できる。

●Microsoft SQL Serverの場合

・Malformed TDS Packet Header
　SQL Server 7.0にはTabular DataStream(TDS)パケットの処理に問題があるため、不正なTDSヘッダを持つパケットを受けるとDoS攻撃が成立してしまう。Microsoftよりパッチ（Microsoft Security Bulletin MS99-059）がリリースされているため、これを適用することで対応可能である。

・Buffer Overflow in Extended Stored Procedures
　SQL Serverの一部のバージョンには、拡張ストアドプロシージャが利用するsrv_paraminfo( )変数に対するチェックが十分ではないためバッファオーバーフローが発生する。この変数を使用しているのはxp_sqlinventory、xp_printstatements、xp_peekqueue、xp_proxiedmetadata、xp_SetSQLSecurity、xp_displayparamstmt、xp_enumresultset、xp_showcolv、xp_updatecolvbmであり、これらの拡張ストアドプロシージャに対して長いパラメータを与えるとバッファオーバーフローが発生する。拡張ストアドプロシージャの実体はDLL（Dynamic Link Library）であり、ここでバッファオーバーフローが発生することで、SQL Serverのクラッシュや任意のコードの実行の危険性がある。この問題もMicrosoft Security Bulletin MS00-092に記載されている適切なパッチを当てることで解消可能である。

　このようにありとあらゆる場所にさまざまな脆弱点が存在することが分かる。これは何もWebサイトを構築する際にだけ生じる問題ではなく、一般的にシステム構築の際には必ず遭遇することである。

データベースを狙った攻撃の実例

　MicrosoftのIISとSQL ServerもしくはOracleから構成されているようなWebサイトにおいて、IISのいくつかの脆弱点とデータベースにデフォルトのユーザー名とパスワードが残っているような場合、簡単に攻撃されてしまう。これを実現するツールも存在している。そのツールと若干の準備手順が行えれば、Oracleのデータディクショナリから全テーブル情報を得られる。また、SQL Serverからはmasterデータベースからたどることで、やはりデータベースに存在するすべてのオブジェクトの情報を得られてしまうのだ。

　ここではそのツールの名前や画面を掲載することはできないが、入手しようと思えば誰でも入手できるものである。決して対岸の火事と思ってはいけない状況がここにある。

●対策

　では対策について、どのようにすればよいのかを説明しよう。対策を行うに当たり一番大切なのは、“セキュリティを維持するのは、技術でもプロジェクトでもなく、プロセスである”という点である。

　セキュリティを維持するために何らかの技術、具体的にセキュリティ製品の導入やセキュリティエンジニアの採用を行っても、（少し悪いいい方だが）それは道具や方法論の1つにすぎず、現在の問題点の指摘とその解決方法の提案のみであり、セキュリティレベルを維持することはできない。

　また「セキュリティ強化プロジェクト」を立ち上げることで、初期のセキュリティレベルを向上させることはできるが、やはり維持することはできない。プロジェクトはその目的を達成すれば解散される、一過性のものだからである。セキュリティレベルを向上し継続的に維持するには、セキュリティ対策を日常の業務プロセスの一部として組み込まなければならない。

　しかしながらこのような読み物でそのすべてを説明することはできない。ここではセキュリティレベルを維持するために使用できる「技術」について説明しよう（「技術」は道具なので、これをどのように利用するかという点は利用者に任すことになるが）。

●各構成要素の実装

　Webサーバ、アプリケーションサーバ、データベースサーバを物理的に同一のホスト上に実装できれば、ハードウェアコストを削減することができるため、そのような実装がなされることがよくある。分離したとしてもデータベースサーバくらいだろう。

　しかしセキュリティの観点からいえば、これらは物理的に異なるホスト上に実装すべきである。すべて同一ホスト上に配置してあると、Webサーバに侵入されることは、すべてのサーバ機能に侵入されるのと同じことになってしまい、攻撃者の手助けをしているようなものだ。物理的に別ホスト上に配置することで、少なくとも攻撃者は1つ1つのサーバに順番に侵入を試みる必要が出てくる。攻撃者が侵入に時間を要することを意味し、さらにどこかで検出できる可能性を高めることになる。それぞれにセキュリティを強化しておけば、データベースを高い確率で保護することができる。

　次に各構成要素ごとのセキュリティ対策について説明する。

はじめにOSに対するセキュリティ対策が必要

　各サーバに対するセキュリティ対策を施す前に、その土台となるOSに対するセキュリティ対策が必要となる。いくらアプリケーションレベルでセキュリティを強化しても、OSのセキュリティレベルが低いのでは何の意味もない。せっかくOracleのセキュリティを強化しても、OSの脆弱点から侵入されOracleのファイルを破壊されてしまっては意味がないのだ。

　OSレベルのセキュリティ脆弱点検査にはセキュリティ検査ツールを使用するとよいだろう。セキュリティ検査ツールにも、ネットワークベースのものとホストベースのものの2種類が存在する。もちろんセキュリティ検査自体にツールを使わなければならないということはなく、人手で行うことも不可能ではないかもしれない。しかし数百から数千に及ぶセキュリティの脆弱点を正確に把握し、検査漏れがないように行うことは非常に退屈であり、人間には困難な作業である。そのような作業はツールに任せるに限る（勉強目的である場合にのみ、人手でやってもよい程度だ）。

●ネットワークベース・セキュリティ検査ツール

　ホストやネットワーク装置に対して、ネットワーク上からリモート検査を行うツールで、検査対象にネットワークを介して利用可能な脆弱点が存在するかどうか検査を行う。主に不要なネットワークサービスが起動していないか、さらに起動しているネットワークサービスに既知の脆弱点が存在していないか、確認することができる。このときTCPフィンガープリントと呼ばれる、TCP/IPスタックの実装上の違いによりTCPパケット上に現れる特徴をチェックし、OSの違いやバージョンの違いをチェックできるものもある。また起動している各種サービスに対してログオンを試み、簡単なパスワードによるリモートログオンを許可していないかどうかの確認も併せて行うことができる。この関連のツールにはInternet Security Systems（ISS）の「Internet Scanner」、Symantecの「NetRecon」などの商用製品から、「SATAN」や「Nesus」などのフリーのプログラムまで多種多様である。検査ツールによって得手不得手などがあり、適宜使い分けるとよいだろう。

●ホストベース・セキュリティ検査ツール

　ホストベースのセキュリティ検査ツールの場合、検査対象ホストにインストールされたAgentと呼ばれるクライアント・ソフトウェアが検査を行う。Managerと呼ばれることが多い管理ソフトウェアがAgentと通信し、大量のホストに対して同時に検査を実行できるような構成をとるソフトウェアも多い。ネットワークベースのセキュリティ検査ツールは、ホストに対してリモートで監視するため、検査対象装置にログオンなどができなければ、詳しい情報を取り出すことができない。

　それに対しホストベースの検査ツールは、UNIXであればnobody、Windows系であればlocalsystemとしてAgentが動作するなどの技術を使用することで、基本的に取り出せない情報はなく、OSのセキュリティ上の問題点を徹底的に調査することができる。そのため検査結果も数千にもおよび脆弱点が発見されることも珍しくない（実際に目にすると嫌になるものだが）。このカテゴリの場合、ISSの「System Scanner」、Symantecの「Enterprise Security Manager」をはじめとするいくつかの商用製品や「cops」など、ネットワークベースのセキュリティ検査ツールに比べるとその数は少なくなってしまう。なおcops自体は非常に古いツールで、perl版とsh版の2種類存在している。sh、perlいずれもスキャン時には何らかの形でrootなどのユーザーでログオンしていることが必要とされるため、大規模スキャンには残念ながら向いているとはいえない。また筆者が確認した限り古いものしか確認できなかった。古ければ新しいセキュリティ上の脆弱点には対応できないため、現実的にはあまり役に立つとはいえない。

●検査ツールの限界：False Positive

　検査ツールにはFalse Positiveという現象が発生することが知られている。False Positiveとは簡単にいえば狂牛病検査の過程で起こる擬陽性と同じ意味で、完全には判断しきれず可能性があるものを脆弱点としてリストアップすることである。

　False Positiveの発生には、検査ツールの仕組みが関係している。よくできた検査ツールほど、検査対象には悪影響を与えないよう細心の注意を払いながら脆弱点の検査を行う。脆弱点を検査した揚げ句、検査対象に悪影響を与えてしまったのでは全く意味はないからだ（それは単に攻撃されたのと同じだ）。本当の攻撃は行わないため、よく疑似攻撃を行うといわれているが、実際には検査対象から得られる情報を詳細に調べているといったところだろう（その過程を疑似攻撃と呼ぶこともあるだろう）。

　筆者がある本で読んだ、非常に気に入っているセキュリティ検査の例えがある。それは、ガラス窓の脆弱性を調べることを考えてみるといった例である。具体的にはどの程度の衝撃で割れるのかということを調査するのである。一番簡単なのは実際に（石などを投げつけて）衝撃を加え割れるかどうか確認することであるが、それでガラスが割れてしまうのでは何の意味もない。これは脆弱点を検証するために本当の攻撃手法を使用し、検査対象に悪影響を与えてしまったことに相当する。ガラスを壊さないで確認するためには、手で軽くたたいてみる、メーカーと型番の調査、取り付け方の調査など、さまざまな情報を集め判断するしかない。セキュリティ検査ツールがやっていることはこういうことである。そのためどうしてもFalse Positiveが生ずることになる。

●Webサーバの脆弱点を検出する検査ツール

　Webサーバの脆弱点を検出するソフトウェアは数多く存在する。先のネットワークベースの検査ツールも、そのままWebサーバ用として使用できる。Microsoftのように、自社のWebサーバ専用のツールキットをリリースしている企業も存在するくらいだ。しかしWebサーバの脆弱点は依然として発見され続け、すべてのパッチをインストールし続けることは困難であるかのような状況だ。NimdaやCode Redが侵入に利用した脆弱点は決して最新のものではなく、発生時点ですでにパッチがリリース済みの「古い」ものであった。それにもかかわらず被害が甚大だったということは、いかに多くのサイトでパッチが適用されず放置されていたかが分かる。単に自社サイトに対する被害だけであればまだ“恥をかく”だけであるが、ワームの発信基地となることは許されないことである。

　ホストベースの不正侵入検知ソフト（HIDS）をWebサーバに実装することで、侵入の検知やブロックなどを行うことができる。Webページの改ざんが行われる際には、特定のファイルに変更が発生するため、特定ファイルに対するアクセスを監視できる機能が有用である。Linuxなどでは「Tripwire」をこの目的のために使用することができる。なおTripwireはファイルのチェックサムを比較することでファイル変更を検出しているため、CPUリソースをある程度必要とする。商用システムの場合、audit（監査）ログやイベントログを監視することで、比較的軽い負荷で特定ファイルへの書き込みだけではなく、読み込みアクセスも監視可能とするものも存在する（ISSの「RealSecure」、Symantecの「Intruder Alert」など）。

●データベースの脆弱点を検出する検査ツール

　データベースに対しても、やはりセキュリティ検査ツールが有効である。しかしOSやWebサーバに対するセキュリティ検査ツールとは異なり、その種類は非常に少なく、筆者が知る限り、ISSの「Database Scanner」（元はDBSecureという会社の製品だった）、Application Securityの「AppDetective」が利用できるのみである。Database ScannerやAppDetectiveはリモートからデータベースの脆弱性を検査する製品であり有効性は高い。もちろんツールなしでセキュリティ対策を行うことも、全く不可能というわけではない。しかし一般的にデータベースに関するセキュリティ情報は、OSなどの他の要素のセキュリティ情報よりもセキュリティ・アドバイザリーで目にすることも少ないため、ツールなしでは脆弱点を集めることさえ満足に行えなくなってしまう危険性が考えられる。

●Webアプリケーションの脆弱点を検出する検査ツール

　筆者の知る限り、残念ながら、Webアプリケーションプログラムを直接検査して、アプリケーション上の脆弱点を探してくれる便利なソフトウェアは、「Whisker」などフリーのCGI Scannerしか存在しない。しかし現実的には、CGIを商用Webサイトでフルに活用することはあまりないと思われる。残念ながら、CGI Scannerは解とはなり得ないのだ。

　Webアプリケーションはどんな技術を使っていても、ユーザーインターフェイスのために最終的には動的なWebページを構成する。この点に着目した商用システムが存在する。Sanctumの「AppScan」がそれである。AppScanはまるでIDS製品のように、Webアプリケーションが生成するページを監視し、その中にセキュリティ上脆弱なスクリプトなどが含まれている場合、それを発見することができる。しかしながら、直接Webアプリケーションを検査しているわけではないことに注意しなければならない。どの部分のコードが脆弱なのかは、膨大な知識データベースを参照する必要がある。

　つまり現時点では、どうしても人手によるWebアプリケーションのセキュリティ維持が必要なのである。

　人手でWebアプリケーションセキュリティを維持する場合、大切なのは「アプリケーション構築ポリシー」である。このポリシーの中で、Webアプリケーションに対してセキュリティ対策を施す場合、どのような技術を使用して構成すべきかなどのような、アプリケーション構築上根本的な点を決定する。ただ現実的にはポリシーでは網羅しきれない、日々発見される脆弱点に対する対応策も別途考慮しておく必要がある。

アプリケーション構築ポリシーに関係する事項

　ポリシーに関連する事項にはいくつかポイントがあるので、それを順番に説明しよう。

●データベースへのアプリケーションの実装

　通常データベース自体は単なるデータストアとして利用されることが多い。データベース上に何かを作り込むのはデータベース管理者であり、アプリケーションエンジニアは単にSELECT、INSERTなどの一部のSQLステートメントを発行するだけに止まることがほとんどである。しかしデータベース上に、Webアプリケーションと協調する仕組みを組み込むと、開発効率の面だけでなくセキュリティ面の向上にも役に立つ。

●ビューの利用

　一般ユーザーには実テーブルを参照する権限は与えず、仮想テーブルであるビュー経由でのみ参照を許可する。こうすることで、参照可能な情報をコントロールすることができる。もちろんデータが膨大になってもビュー経由の参照パフォーマンスに与える影響が少なくなるように、効率的なインデックスを使用するなど、テーブル設計を考慮しなければならない。またパフォーマンスへの影響が少ないのであれば、ビュー経由でUPDATEなどを行うことも可能である。

●ストアドプロシージャの利用

　一般ユーザーには実テーブルへの直接のINSERT、DELETE、UPDATEなどのテーブル操作に関する権限を許可せず、ストアドプロシージャ（Transact-SQLで作成したプログラムのうちのサブルーチン）の実行権限のみ与える。そしてストアドプロシージャ経由でのみテーブル操作が行えるようにする。こうすることで不用意にデータを操作される危険性を最小化することができる。

　併せてストアドプロシージャ内でトランザクションを完全にコントロールできるので、複数テーブル間のデータ不整合などから発生するアプリケーションの誤動作を未然に防止することができる。アプリケーションにトランザクション処理を任せた場合、ネットワーク切断などにより処理が中断した際のリカバリなどのイリーガル処理が複雑になる（以前筆者は、IISのASP上で使用できるトランザクショナルASPなる実装技術を見て絶句した経験がある）。複雑なイリーガル処理やアプリケーションの誤動作は、それ自体セキュリティ上の脆弱点を生み出しかねない危険性をはらんでいる。ただしストアドプロシージャ自体を読み出され改ざんされる危険性があるため、WITH ENCRYPTIONオプションで必ず暗号化しておく。その場合開発者自身もストアドプロシージャを読めなくなってしまうため、容易に保守できなくなってしまうことに注意しなければならない。

●トリガの利用

　複数ステップのデータ操作を行う場合、最初の操作のみWebアプリケーションが直接行い、以降の動作はトリガを使用して処理を進めるようにすることで、特定のデータベースアカウントがデータ操作に介在することを排除できる。これにより、アプリケーションが使用するデータベースアカウントの権限をさらに縮小し、侵入された際の被害をさらに小さくすることが可能となる。

●Webサーバもしくはアプリケーションサーバからデータベースへの接続

　脆弱点の説明において、ASP、JSP、PHPなどはアプリケーションソースにデータベースのユーザー名とパスワードがクリアテキストで含まれるため問題であることは説明した。それ以外にもいくつか、問題が発生するケースが考えられる。

　例えばOracle iASの場合、HTTP Listener（実体はApacheである）から直接Oracleに対してSQLステートメントを投げることができる。その際に使用されるのがmod_plsqlモジュールである。しかしmod_plsqlとて、一度はOracleに接続しなければならない。そのための接続情報、ユーザー名とパスワードをDatabase Access Descriptor(DAD)と呼ばれるファイルに保存しておく。これがクリアテキスト形式である。これではASPやJSP、PHPを使った場合の危険性と何ら変わりはない。つまりmod_plsqlを使用した直接的なOracleへの接続は避けなければならない。

注意 最新版のOracle iASでは該当のDAD中の部分は暗号化されており、クリアテキストにはなっていない。詳細およびパッチ情報は以下のURLを参照してほしい。http://www.oracle.co.jp/news/security/index.html

●サーバサイドオブジェクト技術の利用

　やはり現時点ではデータベースへの接続は、サーバサイドオブジェクト技術を利用する方法が最も妥当だと考えられる。具体的にはEnterprise JavaBeans（EJB）やサーバサイドActiveX技術である。ここではEJBを使った場合を考えてみる。

　まずデータベースへの接続はEJBのみで行い、JSPやServletからは接続しないようにする。これによりデータベースへのログオン情報が分散して保存されることを防ぎ、仮に定期的にログオン情報の変更を行う必要が生じても、手間を最小限に押さえ込むことができる。セキュリティの視点からいえば、定期的なログオン情報の変更は重要である。さらにログオン情報が分散していると、侵入された際の漏えいのリスクが高くなる。またデータベースに接続するEJBは、データベースと物理的に同一ホスト上で動作させることで、EJBからのログオン情報がネットワーク上を流れなくなるので、万が一データベース以外のホストに侵入され、スニッフィング（データの盗聴）されたとしてもログオン情報が漏えいすることがない。さらにデータベースへのログオンをJavaBeansではなくEJBコンテナに管理させるようにすることで、Javaコード自体からユーザー名、パスワードを排除することができるようになる。これにより万が一root権限を奪取されJavaコード自体が漏えいしても、データベースへの接続情報がそのまま漏えいすることはなくなる。

　しかしEJB技術を採用した場合、往々にしてWebアプリケーション自体の実行速度の問題に突き当たる。つまり“セキュリティレベルは高いが動作スピードが遅い”ということになる。この場合、セキュリティレベルと動作スピードをトレードオフしなければならない。将来的には問題なく両立できるであろうが、現時点での技術で両立しないのであれば、どちらかを優先した実装を行う必要がある。それはケース・バイ・ケースであるため、絶対的な解答はない。

特定の脆弱点に対応する事項

　ここでは特に最近話題となった、クロスサイト・スクリプティング対策について、いくつかポイントを挙げてみよう。

●クロスサイト・スクリプティング対策

　クロスサイト・スクリプティング対策において最も大切な点は、ユーザー入力をきちんと評価し、本来入力されるべきではない“<”などの文字が入力された場合、無効な入力として処理を行う前に「はじく」ことである。これにより問題はほとんど解消することができる。さらに、

・Cookieの有効期限をセッションのみにする
・Cookieの有効ドメインを最小化する

などの方法を併せて利用することで、リスクを少なくすることができる。ただしCookieに対して制限を加えることで、ユーザビリティが損なわれることも考えられる。有効期限をセッションに限定することで、一度ログアウトしてしまうと、直後に接続しても再度ログオンする必要が出て、再接続の際の手間が省けない。有効ドメインを最小化した場合、構成にもよるがサブドメインに属する別ページに移動した際にもログオンする必要が発生してしまうかもしれない。いずれもユーザーの使い勝手という問題が発生する。しかしながらこのような処置を行っても、Cookie自体の漏えい問題への対処は依然としてユーザーに影響されるという、重大な問題を解決することはできない。

●そのほかの特定の対策

　簡単なことであるが、ユーザーが入力パラメータを得る際、GETメソッドではなくPOSTメソッドを使用する。GETメソッドではURL上に直接パラメータが現れてしまうため、情報漏えいの危険性が発生する。もちろんこれ以外にも細かい点はいくつも存在するので、各自注意しなければならない。

注意事項 Webアプリケーションのセキュリティ上の問題の場合、Webアプリケーションの構成方法以外に、Webサーバ自体のセキュリティ上の脆弱点が関与している場合がある。そのような場合、WebサーバとWebアプリケーションの両方の脆弱点に対応しなければならない。クロスサイト・スクリプティング問題はそのような問題の1つである。Webサーバベンダからはクロスサイト・スクリプティングに対応したパッチなどがリリースされているが、先の説明でも分かるように、クロスサイト・スクリプティングの問題の本質はWebアプリケーションであるため、ベンダからのパッチを当てただけでは対応できないのである。

利用者の使用方法の規定

　今までWebサイトを構築する際の留意点について説明してきたが、Webサイト側ではコントロールできないという点では最大の脅威になり得る脆弱点である、利用者のブラウザの問題について触れてみたい。問題はブラウザから何かセキュリティ上、影響を与える情報が漏れるかどうかという点だ。

　残念ながらCookieの漏えいに関してはいくつかのブラウザで実際に発生している。しかもブラウザやメール経由のウイルスやワームの広がりを見れば、セキュリティパッチの適用はあまり期待できないということになってしまう。ある程度利用方法規定を掲げ、それを順守してもらうほか方法はないのではないかと思われる。例えば、

・各種スクリプトやアプレットの実行許可設定の指定
・ウイルス対策ソフトの導入とウイルス定義ファイルの定期的な更新
・Webサイトを訪れた後は必ずいったんブラウザを終了する

などの項目が必要だろう。一部のアプリケーションは、インターネット経由でのアップデート機能を提供するために、無制限にアプレットなどを実行させる設定に変更を促している様なものもある。しかしこれではさらなる脆弱点を設けているようなものである。ウイルス対策ソフトによるバックドアの検出や、ブラウザを終了することで確実にCookieの有効期限を終了させるなどが大切である。

最後に

　このように、セキュリティ上安全なWebサイトを構成し、安全な状態で運用するには非常に多くの技術的な、さらに運用上のハードルが存在する。しかも対策を行えば、ユーザービリティやアプリケーションの動作に影響を与える可能性も高く、そのトレードオフには高度な判断が必要とされる。しかし、世の中はますますインターネット経由での商取引が盛んになってくると考えられている。XMLを使用した直接的な情報の交換技術、RosettaNet（ロゼッタネット）などに見られるインターネット経由でのサプライチェーンの実現など、今後さらにセキュリティ上安全なサイトの構築は重要になってくるだろう。いまそのポイントをつかんでおくことは非常に大切なことのように思われる。

◇

　今回の記事「Webサイト運営者のセキュリティ確保の心得」は、Webサーバ、アプリケーションサーバ、データベースサーバなどに関するさまざまな脆弱点について考察した。この記事をご参考にしていただき、運用管理面での脆弱点を少しでも軽減するために活用していただければ幸いである。

「連載 Webサイト運営者のセキュリティ確保の心得」

Index 第1回 Webサイトセキュリティ侵害事件から見た脆弱点

Webサイトのセキュリティ侵害に関連した事件 “クレジットカード情報盗難事件”から見る脆弱点 ワームを使用したWeb改ざん事件から見る攻撃 ワームによるSQL Serverへの攻撃 Webサイトにおけるリスクの存在 第2回 Webアプリケーションサーバに存在するさまざまな脆弱点 　 各種Webサーバにはそれぞれ脆弱点がある Webサーバに対する基本的な考え方 Webアプリケーションサーバの問題 Webアプリケーションで使用する技術 第3回 データベースサーバの構築、運用から発生する脆弱点とその対策 　 Webサイトの運用、構築方法などから発生する脆弱性 データベースを狙った攻撃の実例 はじめにOSに対するセキュリティ対策が必要 アプリケーション構築ポリシーに関係する事項 特定の脆弱点に対応する事項 利用者の使用方法の規定 最後に

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）