Tips 3

Tips 3

～CGI のセキュリティについて～

巷のプロバイダが「セキュリティ上の問題により CGI 禁止」としていることがよくあるかと思います。
なぜだ！とお怒りになられる前に、それにはそれ相応の理由があると言うことを知っていただけたら幸いです。
（知った所でお怒りですって？まぁ、それはそうなんだけど・・・・笑）

また、許可しているプロバイダの場合は、こういった問題は潜んでおり基本的に回避が難しいです。
早い話が、CGI を置けたりシェルを開放してたりするプロバイダの場合は「セキュリティは確保できない」ということです。
（しかし、好奇心旺盛な方に実際にやられると困るので、その手法に関しては詳しくは触れません）


CGI・・・それは・・・

	まず、CGI の設置が出来る方には基本的なことですが、パーミッションの 644は「所有者は読み書きでき、同じグループのユーザとその他のユーザは読める」 755は「所有者は読み書き実行ができ、同じグループとその他のユーザは読んで実行できる」という意味です。データファイルの666では、「全てのユーザーが読み書きできる」という意味です。
	基本的なことを書きましたが、それがどういう意味かと言うと・・・・「ログインできるユーザなら、他人のファイルも自由に覗いたり書き換えたりできる」ということです。もちろん、FTP のアカウントで自由に他人のディレクトリに入れるというわけではありません。（FTP でログインしても他人のディレクトリに自由に入れるプロバイダもあるみたいですが・・・こんなのは論外）
	とりあえず、シェルが開放されている場合は別の要因があるので除外しますが、シェルが開放されていない場合でも「CGI にやらせる」ことにより他人のファイル読めてしまうことがあります。 CGI にやらせれば、FTP やシェルのようにパスワードを求めてくることもありません。（大半のサーバーでは、CGI は nobody（その他のユーザ）に属する Webサーバーの権限で動作します。　で、パーミッションの意味をもう一度見てください。その他のユーザの権限に注目）
	では、CGI がユーザの権限で動作するサーバー（Hi-HOもそうです）なら安心でしょうか？いえ、そうとも言いきれない面があります。絶対はないと思ってください。基本的に、「サーバーに上げた段階で、何をされてもおかしくない」と思う方が賢明です。（通常はありえないと思いますが、サーバー管理者に悪意があればそれで全て終わりです）
	防衛する手段としては、可能な限り必要のないパーミッションは削除しておきましょう。ユーザの権限で動作する CGI の場合、755→700、644→600に変更してみてください。これができない場合でも、755→705、644→604にするだけでも若干変わってきます。（しかし・・・通常のHTMLが600とかで見られるサーバはない・・・って考えたら、　隠しページなどを作った所でことごとく発見されてしまったり。ま、そんなもんです。）
	で、他人にファイルを危険性を考えたら、Linachatのconfigは暗号化して記録した方がいいのでしょうが、 configファイルが見られるような状態では、ログファイルも直接見られるはずなので、意味がないと判断して搭載しません。（ホントはそこまでのスキルがないだけ。笑）しかし、パーミッションをを700や600にすることで、そういった問題からは回避可能です。結局、設置者の操作、そしてサーバーの仕様にかかっているということでしょうか？
	そういう点で、CGI 設置は許可しているものの、サーバー管理者の手によって設置することが条件になってるプロバイダはセキュリティは強いかと思われます。（いくらなんでも未確認で設置なんてことはないでしょ・・・）また、プロバイダが用意したスクリプトのみ使用許可してる場合はさらに強いですが・・・たいていはカウンターぐらいのもので、掲示板などは提供されてても使い物になりません（笑）（本音では使って欲しくないからだろうね、こういったものは・・・）
Server OS が Windows の場合
	UNIXの場合のセキュリティ問題を書きましたが、ＮＴサーバーの場合はさらに深刻です。私がＮＴサーバーをおもちゃに出来る環境にあるがために、ＮＴの粗が見えてるだけかもしれませんが、検証（遊んだとも言う）した結果を基に書いてみます。あくまでも IIS の事例ですが、ファイルシステムの問題もあるので他のサーバーでも十分ありえます。
	Internet Information Server では、CGI も含めて Webサーバは「Domain User」の権限で動作します。この「Domain User」とは、パスワード付でログオンした一般ユーザと同じ権限を持っています。（匿名ログオン用にするにはあまりにも大きな権限と思いますが・・・どうなんでしょ？）という理由により、ユーザーマネージャで「Domain Guest」の権限に変更しておいた方がいいでしょう。
	これで万事解決のように思われますが、実際はそんなに甘くありません。 NTFSには「everyone」という「全てのユーザ」のグループがあって、重要なファイルなども「everyone」がフルコントロール可能だったりします。（フルコントロールの権限はないまでも、たいていの場合は「読取」の権限を持っています）
	「everyone」は、その名の如く全てのユーザの意味です。「Domain Guest」ももちろん含みます。そして、「everyone」が「C:\InetPub\wwwroot\」ごと削除してしまったらどうなるでしょう？「C:\InetPub\wwwroot\」は、ＩＩＳが自動で設定するインターネット公開用のディレクトリのルートです。通常は、「everyone」がフルコントロール可能で、このディレクトリの下に公開するコンテンツを全て入れます。で・・・悪意に満ちたスクリプトにここを削除されてしまうと、一発で・・・・・・・
	では、everyone には InetPub 以下での権限を「読取」しか与えなかったらいいかと言うと、そうでもありません。ＣＧＩ動作をさせるには、最低限でもＷｅｂサーバーに「変更」の権限を与える必要があります。ですが、「変更」の権限は、削除する権限も持っています。（笑）まさにお手上げ・・・たとえ、「読取」だけだとしても、隠しページを作るには困るでしょ？　　余談ですが、「C:\Program Files\」にも「everyone」はフルアクセス権を持っています。　　ここを勝手に触られるとシャレにならない事態だということはWindowsユーザなら誰でも知ってますね（笑）
	ということで、重要なファイルの部分からは明示的にGuestの権限は奪っておく・・・というので対処してもいいのですが、膨大な数のファイルのアクセス権を確認しながら行うのは非現実的です。（本当はそうするべきでしょうが）たとえそうした所で Webサーバを「DomainGuest」の権限で動作させることにする以上、Guestの権限は Webサーバが読んだり書いたりする領域からは削れません。
	では、解決法・・・・・・・・・「Windowsのサーバーでは、CGI を自由に設置させない」ということしか思い付きません。仕様の特徴を考えても、サーバー所有者のチェックを経て設置されるべきでしょう。実行権のあるディレクトリを自由に開放するのは、私には自殺行為にしか見えません・・・・（って、言い過ぎね、これは（笑））
余談
	IIS4.0 では、「実行権」が、「スクリプト」と「バイナリも含めた実行権」の２段階になっています。が、なんとデフォルトで全てのディレクトリに「スクリプト」の権限が与えられているのです。「スクリプト」に属する実行ファイルは、asp、shtmlなどがデフォルトで、perlも登録すればスクリプトです。（設定次第でスクリプトを「実行ファイルを起動するバイナリ」扱いにもできますが、通常はそんなことしません）ですが、悪さができるのは何もバイナリだけではないのです。 asp は知りませんが、Perl でもファイルを消したり上書きしたりという極悪レベルのイタズラも十分可能なので、そこらへんも冷静に検証する必要があると思います。

いろいろと書きましたが、「悪意のあるユーザ」がいなければこんな問題は発生しません。
悪いことはやめようね。（誰でもやるようなことやっても虚しいだけよ～）

そして、「CGI禁止」の理由はこういったセキュリティの問題です。
が、本音はセキュリティよりサーバー負荷をかけられるのが嫌という所でしょうか？
（だって、「用意したスクリプト」だけを許可してるプロバイダってさー、カウンターだけとか
　極端に使いにくい掲示板くらいしか提供しなかったり・・・・(>_<)）

ご感想やご指摘などいただけると幸いです。

戻る

written by Lina


CGI・・・それは・・・

	まず、CGI の設置が出来る方には基本的なことですが、パーミッションの 644は「所有者は読み書きでき、同じグループのユーザとその他のユーザは読める」 755は「所有者は読み書き実行ができ、同じグループとその他のユーザは読んで実行できる」という意味です。データファイルの666では、「全てのユーザーが読み書きできる」という意味です。
	基本的なことを書きましたが、それがどういう意味かと言うと・・・・「ログインできるユーザなら、他人のファイルも自由に覗いたり書き換えたりできる」ということです。もちろん、FTP のアカウントで自由に他人のディレクトリに入れるというわけではありません。（FTP でログインしても他人のディレクトリに自由に入れるプロバイダもあるみたいですが・・・こんなのは論外）
	とりあえず、シェルが開放されている場合は別の要因があるので除外しますが、シェルが開放されていない場合でも「CGI にやらせる」ことにより他人のファイル読めてしまうことがあります。 CGI にやらせれば、FTP やシェルのようにパスワードを求めてくることもありません。（大半のサーバーでは、CGI は nobody（その他のユーザ）に属する Webサーバーの権限で動作します。　で、パーミッションの意味をもう一度見てください。その他のユーザの権限に注目）
	では、CGI がユーザの権限で動作するサーバー（Hi-HOもそうです）なら安心でしょうか？いえ、そうとも言いきれない面があります。絶対はないと思ってください。基本的に、「サーバーに上げた段階で、何をされてもおかしくない」と思う方が賢明です。（通常はありえないと思いますが、サーバー管理者に悪意があればそれで全て終わりです）
	防衛する手段としては、可能な限り必要のないパーミッションは削除しておきましょう。ユーザの権限で動作する CGI の場合、755→700、644→600に変更してみてください。これができない場合でも、755→705、644→604にするだけでも若干変わってきます。（しかし・・・通常のHTMLが600とかで見られるサーバはない・・・って考えたら、　隠しページなどを作った所でことごとく発見されてしまったり。ま、そんなもんです。）
	で、他人にファイルを危険性を考えたら、Linachatのconfigは暗号化して記録した方がいいのでしょうが、 configファイルが見られるような状態では、ログファイルも直接見られるはずなので、意味がないと判断して搭載しません。（ホントはそこまでのスキルがないだけ。笑）しかし、パーミッションをを700や600にすることで、そういった問題からは回避可能です。結局、設置者の操作、そしてサーバーの仕様にかかっているということでしょうか？
	そういう点で、CGI 設置は許可しているものの、サーバー管理者の手によって設置することが条件になってるプロバイダはセキュリティは強いかと思われます。（いくらなんでも未確認で設置なんてことはないでしょ・・・）また、プロバイダが用意したスクリプトのみ使用許可してる場合はさらに強いですが・・・たいていはカウンターぐらいのもので、掲示板などは提供されてても使い物になりません（笑）（本音では使って欲しくないからだろうね、こういったものは・・・）
Server OS が Windows の場合
	UNIXの場合のセキュリティ問題を書きましたが、ＮＴサーバーの場合はさらに深刻です。私がＮＴサーバーをおもちゃに出来る環境にあるがために、ＮＴの粗が見えてるだけかもしれませんが、検証（遊んだとも言う）した結果を基に書いてみます。あくまでも IIS の事例ですが、ファイルシステムの問題もあるので他のサーバーでも十分ありえます。
	Internet Information Server では、CGI も含めて Webサーバは「Domain User」の権限で動作します。この「Domain User」とは、パスワード付でログオンした一般ユーザと同じ権限を持っています。（匿名ログオン用にするにはあまりにも大きな権限と思いますが・・・どうなんでしょ？）という理由により、ユーザーマネージャで「Domain Guest」の権限に変更しておいた方がいいでしょう。
	これで万事解決のように思われますが、実際はそんなに甘くありません。 NTFSには「everyone」という「全てのユーザ」のグループがあって、重要なファイルなども「everyone」がフルコントロール可能だったりします。（フルコントロールの権限はないまでも、たいていの場合は「読取」の権限を持っています）
	「everyone」は、その名の如く全てのユーザの意味です。「Domain Guest」ももちろん含みます。そして、「everyone」が「C:\InetPub\wwwroot\」ごと削除してしまったらどうなるでしょう？「C:\InetPub\wwwroot\」は、ＩＩＳが自動で設定するインターネット公開用のディレクトリのルートです。通常は、「everyone」がフルコントロール可能で、このディレクトリの下に公開するコンテンツを全て入れます。で・・・悪意に満ちたスクリプトにここを削除されてしまうと、一発で・・・・・・・
	では、everyone には InetPub 以下での権限を「読取」しか与えなかったらいいかと言うと、そうでもありません。ＣＧＩ動作をさせるには、最低限でもＷｅｂサーバーに「変更」の権限を与える必要があります。ですが、「変更」の権限は、削除する権限も持っています。（笑）まさにお手上げ・・・たとえ、「読取」だけだとしても、隠しページを作るには困るでしょ？　　余談ですが、「C:\Program Files\」にも「everyone」はフルアクセス権を持っています。　　ここを勝手に触られるとシャレにならない事態だということはWindowsユーザなら誰でも知ってますね（笑）
	ということで、重要なファイルの部分からは明示的にGuestの権限は奪っておく・・・というので対処してもいいのですが、膨大な数のファイルのアクセス権を確認しながら行うのは非現実的です。（本当はそうするべきでしょうが）たとえそうした所で Webサーバを「DomainGuest」の権限で動作させることにする以上、Guestの権限は Webサーバが読んだり書いたりする領域からは削れません。
	では、解決法・・・・・・・・・「Windowsのサーバーでは、CGI を自由に設置させない」ということしか思い付きません。仕様の特徴を考えても、サーバー所有者のチェックを経て設置されるべきでしょう。実行権のあるディレクトリを自由に開放するのは、私には自殺行為にしか見えません・・・・（って、言い過ぎね、これは（笑））
余談
	IIS4.0 では、「実行権」が、「スクリプト」と「バイナリも含めた実行権」の２段階になっています。が、なんとデフォルトで全てのディレクトリに「スクリプト」の権限が与えられているのです。「スクリプト」に属する実行ファイルは、asp、shtmlなどがデフォルトで、perlも登録すればスクリプトです。（設定次第でスクリプトを「実行ファイルを起動するバイナリ」扱いにもできますが、通常はそんなことしません）ですが、悪さができるのは何もバイナリだけではないのです。 asp は知りませんが、Perl でもファイルを消したり上書きしたりという極悪レベルのイタズラも十分可能なので、そこらへんも冷静に検証する必要があると思います。