極楽せきゅあブログ

ときどきセキュリティ

論点の整理(今後改訂アリ)

前提としてofficeさんのやり方の一面的な記述。

officeさんはまず、ログファイルの在処を確認するためCGIソースにアクセスしなければならなかった。CGIソースはドキュメントルート外に存在し、Webサーバー的にはcgi-binという良くある場所の下に配置されていた。*1それを見て、ログファイル名や在処などを確認した上で、今度はログを閲覧した。
閲覧する方法詳細は省略。だってみんな知ってるじゃん(笑)。

判決(検察側の主張含む)ってこんな感じだったかな。

問題のログファイルを見るためには、ログファイルの名前や置き場所を確かめるために、まずCGIのソースを閲覧する必要がある。
CGIソースはドキュメントルート外にあった。従って、WebブラウザからURLを手操作でいろいろやったとしても見えないところにあったのだ。
他に見る手段としてはftpがあった。ここにはIDとパスワードが設定されていた。
不正アクセス禁止法におけるアクセス制御の基本単位は、あくまで電子計算機であり、その電子計算機に存在する特定のファイルを見る手段(今回はHTTPとFTP)の両方共にアクセス制御が成されていた(ドキュメントルート、IDとパスワード)ということになる。
一方、csvmail.cgiには欠陥が存在し、ダウンロードしたデータを書き換えてファイルを任意に指定してフォームを送信すればどのようなファイルでも見ることが出来た。この欠陥を利用するためには、ダウンロードしたデータを書き換える必要があり、これは不正アクセス禁止法で言う、あやしいデータを送り込む、ということに該当する。従ってこれは不正アクセスという形式が成立する。
一方、被告はあまりに態度が悪いし(苦笑)、従来通り行われていた手順を踏まずにいきなりプレゼンで公開などして、このサイトが攻撃される可能性を高めたりもしている。これは明らかに犯罪的な意図があったということだ。
とはいえ、その後危険の拡散防止に努めたり、社会的制裁も受けている。また、サイト管理側もすでにいろいろなところでCGIに関する一般的なリスクについて報道されていたのに知らなかった、という点も考慮すべきだ。

一方弁護側の主張はこんな感じ。

不正アクセス禁止法ってのはそもそも認証を回避することを咎めるための法律なのだから、認証の有無をもってアクセス制御されているかどうか、とすべき。法律の中では認証を回避するかどうか、という論点でしか語られていない。
しかし、今回の件でHTTP上でCGI経由でCGIのソースなどにアクセスしても、一度もIDもパスワードなどは出てこない。これはそもそも認証されていないのではないのか?
HTTPによるアクセスにおいて認証を設定する、ということは、例えばBasic認証を設定するなどして、ドキュメントルート内にファイルを配置する際も認証をかけるのが一般的である。設定された認証が効果を発揮するという前提があるから、各種の情報を安心して公開できるのであって、不正アクセス禁止法はそれを回避してズルするヤツらを取り締まりたいわけだ。認証が回避できて、しかもそれが罪に問われない、となると、誰も情報を公開しなくなってしまうだろう。従って、個別のプロトコルにおけるアクセス制御、つまり認証設定の有無が問題となるべきで、ネットワーク経由の特定利用というのはプロトコルベースでの利用を指す、と捉えるのが妥当であろう。
今回の件も、現実的にはFTPなどとは関係の無いところで管理側が見られたくないとするものへのアクセスが生じており、CGIも含めて一切の出来事はHTTP上の話に過ぎない。
となると、HTTP経由で一切の認証が設定されていない状態は、アクセス制御されている状態であるとは言えない。従って、あくまでHTTPプロトコルを伝ってアクセスした行為というのは、不正アクセスに当たらない。

ここから弁護側の主張に追記。まあここが今のところのあちきの意見かなあ。

技術者的な視点から言えば、HTTPによるサービスで、公開する相手を限定したい、という目的のためにまず最初に考えるのはBasic認証SSLなどの証明書認証、Webアプリケーションによる認証などの設定である。事実、どこのサービスを見ても、限定的なコンテンツ(ファイルなども含む)の公開にはIDとパスワード、もしくはそれに類する認証を追加で設定するのがほとんどだ。それ以外の方法も無いわけではないが、稀にしか見かけない。
そして、そうした追加認証の方法について想起すること自体、滅多にないことか、と言えばそんなことはなく、そこらじゅうの会員制サービスを見ればどこでもそういうこと(認証の追加)は普通に行われている。
逆に、ドキュメントルート内外にあるということでアクセス制御とするのは危険である。Webサーバーによる(デフォルトでは暗黙的な)設定と、Webサーバーの設定とは次元が異なるOS上のディレクトリ、ファイルアクセス許可設定によって、アクセス制御を行うことになるからだ。Webサーバーのプロセスが持つ権限と、OS上設定されたアクセス許可設定が微妙に絡み合い、意図した設定と効果の因果関係がわかりづらくなる。異なる次元、異なる考え方を混在させながら制御させようとするのは、どう考えても危険であろう。ミスも生じやすい。どうかすると暗黙的な設定のみで、一見見えないようになってるからOK、という安易な認識の管理が増えかねない。しかし、一見見えなくなっていたとしても、今回のようにCGIに素朴な欠陥が存在しただけでそれは超えられてしまう。
情報を預かるサイトの管理者に対しては、一定の管理責任を要求するべきだと考えるが、ドキュメントルートで良しとするならば、明示的、意識的に追加で設定をしなくてもOK、という論理になる。しかし、Basic認証をはじめとする追加での認証設定までやるべし、とするなら、現状にも合致するし、ドキュメントルートによる認証が「アクセス制御」である=無意識のうちにOSやサービスソフトウエアの暗黙的な機能によって、結果としてアクセス制御という形になっていたとしても、それが「アクセス制御」である、と認められる世界よりはるかに安全になるはずだ。
以上のように実務的な理由、および社会的なコンセンサスを適切なラインに設定するためにも、追加の認証設定まで行うことで初めてアクセス制御されているのである、そんなこともしてねーで見られても文句を言うな*2、とすべきではないだろうか。

残された論点。

  • CGIで認証を超える
  • レンタルサーバーなどで区画を分けてリソース提供する場合、見せたくないファイルをどこにどうやって置けばいいのか

*1:cgi-binというのは仮想的なディレクトリで、ドキュメントルート以下ではない場所を指すことが一般的だ。ただ、本当にその配置だったのかと言えばそれはわからない。その部分に関する証言は秘匿されとるからね。しかし、判決によるとドキュメントルートの内外にあるということがアクセス制御と同義に捉えられているため、Webサーバー上の構造は実際その通りであったと推測される…ってほら、やっぱくどくどわかりにくい説明を連ねないと正確に言い表せないじゃん(苦笑)

*2:ま、このフレーズは余計かな(笑)