SSIのセキュリティ/SSI入門

Home | SSI目次 | Prev | SSIのセキュリティ

◆ SSIに伴うセキュリティの問題

多くのプロバイダでは、SSIはおろか、独自の CGIさえも許可しない場合が常識化しています。その最大の理由がセキュリティに関係しています。

プロバイダ側は、表向きサーバの負担を挙げています。確かに SSIや CGIは、サーバに負担をかけます。しかし、実際には不用意なプログラムによるサーバのダウンや情報の漏洩です。

また、SSIでは、UNIXのコマンド処理が可能なため、セキュリティの見地から、使わせたくないことに多少は理解できます。

■ サーバ側における SSIのセキュリティ

SSIを使うことで、サーバのセキュリティにはどのような影響があるのでしょうか？

結論から言うと、サーバに CGIプログラムを許可するかどうかという基本的に同じ問題に過ぎません。CGIプログラムに対して設けているのと同じ制約を置くとすれば、特に新たなリスクが発生してくるということはありません。

SSIを許可しても、execコマンドは使えないようにしているサーバも少なくありません。そのような制約をするのは、execコマンドが CGIプログラムよりも多くのことができると判断しているからですが、実際はそんなことはありません。

execコマンドよりも、Perlで書く CGIプログラムの中でできてしまうことは、かなりたくさんあり、SSIよりもはるかに多いのです。

SSIによってできることは、ユーザがボタンをクリックしなくてもプログラムを起動できるようにすることだけです。

しかし、CGIプログラムのリンクを貼るだけでも、CGIプログラムを起動できるわけですから、それとたいして違うわけではありません。その意味では、サーバ側で execコマンドが使えないというのは、矛盾があります。

この章の SSIの設定で述べたとおり、confファイルの設定さえしっかりとしておけば、セキュリティホールが開くわけではありません。それができないのは、何よりもサーバ管理者のスキル不足であると言わざるを得ません。

私個人の考え方では、SSIは、CGIプログラムと同じ程度のリスクしか与えていないことです。ですから、サーバに対して CGIプログラムを許可するのなら、SSIのすべての機能を使わせるべきと考えます。ただし、サーバの負荷が過大になるとするのなら、１つの手段として SSIを使えないようにしておくほうが安心ともいえるでしょう。

今後は、現在利用している Webサーバの稼動状態を把握しながら、SSI解析の負担が生じたときに、どのような対策を講じるべきかを考えなければならないでしょう。

■ ユーザが考えるべき SSIのセキュリティ

最近言われている「スパイウェア」とは、一体どこから忍び込んでくるのでしょうか？

実は、Webサイトを閲覧中に、勝手にインストールされてしまうのです。私たちはそのことになかなか気づきません。知らぬ間のことなのですから。

裏で仕掛けられた CGIプログラムを見抜くことは至難のことです。私は頻繁に外国のサイトを閲覧します。特に、企業サイトではスパイウェアをインストールしようとしています。それを裏で行っているのが SSIです。

そのサイトの HTMLソースを見ても、SSIが動いているのは分からないのです。SSIは、プログラムの結果を表示させるため、ソースには現れない性質を持っています。唯一、Webブラウザの URL欄に表示されるファイルの拡張子が「.shtml」だけが、SSIの動作を裏付けています。

ただし、最近では識別子子を .shtml にしなくても、SSIを実行できるサーバもあります。

私たちユーザができることは限られています。しかし、インターネットのセキュリティに関しては、ユーザ自らが行うのが常識です。ファイヤーウォールの設定や、スパイウェア防止のソフトをインストールすることは、自衛のための最低限の防御策でしょう。「君子怪しきに近寄らず」の例えのように、信頼できないサイトには近寄らない方が賢明でしょう。

最新更新日 2003年11月9日最新更新日 2004年4月8日