ついでなのでドキュメントルートってのを掘り下げてみようっと。CGIのナニがどうだからどうよ、という話も。あーあ、これでまた仕事が…
apacheなどのデフォルトhttpd.confって、例えばこんな感じになりますね。
DocumentRoot "/export/home/sonodam/apache_1.3.29/htdocs" ScriptAlias /cgi-bin/ "/export/home/sonodam/apache_1.3.29/cgi-bin/"
もちろんこのまんまにしなくてもいいんだけどねえ。ただまあデフォルトでは両者は別のディレクトリっすね。
Webブラウザでふつーに見ることができるのはhtdocsディレクトリ配下のファイルで、cgi-binディレクトリ配下のブツは見ることができない。
実際上記のような設定で動いているWebサーバーに対し、WebブラウザのURL欄に、
http://サーバー名（IPアドレスでも可）/../cgi-bin/test.cgi
ってなURLを入れたとしても、Forbiddenな403エラーになるか、他の設定がデフォルトのまんまならば/cgi-bin/のあたりが置き換えられて、CGIの実行結果しか見えない。ブツはどうあがいても直に見えないわけだ。
判決（および検察）は、これが「アクセス制御」の一部だ、ということを主張している。cgi-binというディレクトリの下にあったcsvmail/csvmail.cgiというファイルを見るための手段は、他にはftpによるアクセスしかない。ftpはftpでIDとパスが設定されていたため、アクセス制御されている状態であったわけで、それとドキュメントルートを合わせると合わせ技で電子計算機（の中身のcsvmail.cgi）は保護されていた＝アクセス制御されていた、と言える。
これが判決で言う「アクセス制御」の要旨すかね。
一方、CGIに欠陥があったため、CGIが作り出すフォームを細工すれば、csvmail.cgiというファイルの中身をおがむことはできたのだ。ドキュメントルートなんて関係なく。CGIというのはそもそもWebサーバーにとっては鬼っ子のようなもので、Webサーバーの設定などとは関係無く自由に振る舞うことができたりする。ドキュメントルート外にあろうが、利用者がCGIプログラムに「これ見せろ」と指令することができれば、見せてもらえるのだ。そして、内容や仕様、実際のプログラムに欠陥があれば今回のように指令することができちゃったりする。
こういうことになった背景は以下のように想定できる。
- （暗黙的な）ドキュメントルートによる「アクセス制御」に、無自覚に頼り切っていた
- CGIプログラムの仕組みそのものに内包されているリスクにあまりに無頓着であった
こんなもんかな。
これに対し、認証を機能追加していたとしたらどうか？
認証を追加する、ということは、見せたくないモノをはっきりと意識する、ということだ。少なくとも、会員限定にしたいモノはどれとどれなのか、それを明確にしなければ、どこに認証を追加するのか定義できないわけで、少なくともそれだけで暗黙的な機能に無自覚に頼り切るよりは安全になる可能性が高い。
だが、CGIに今回のような欠陥があった場合にはどうか？
Basic認証はドキュメントルート外にはそもそも設定しないものだ。しかし、レンタルサーバーのサービスに於いては、CGIのソースを見るためにはBasic認証が必要、ということは可能性として無いとは言えないが非常に稀だろう。認証方式が異なったとしてもディレクトリ単位で認証設定をするものは同じだ。
というより、ここにもう一つ論点があるけど、それは、ドキュメントルートに頼り切るのと、Basic認証などのWebサーバーが提供する認証の仕組みとはあまり違いが無い、という点だ。両方ともディレクトリ単位であり、違いと言えば明示的にIDとパスワードを入れさせるかどうか、ということである。欠陥があるCGIを使っていない場合などには、その違いで会員向けサービスなどのアクセス制御を行うことができる。しかし、欠陥があるCGIが存在すると違いは意味が無くなる。
では、CGIによって作られるフォームに認証を付けたらどうか？認証を通らなければ今回の質問フォームにたどりつけないのだとしたら？
あらかじめ認められた人以外はフォームにたどりつけない、ということはつまり、欠陥へたどりつくハードルが一つ増える、ということでもある。また、仮に欠陥に気づき、利用しようとしたときでも、「誰が」その欠陥を悪用したのか記録がはっきりと残ってしまう。それもハードルになるだろう。
いろいろ考えると、やはり認証マンセーであるほうが世の中安全に近くなると言えるだろう。
（つづく）
