最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1984   昨日: 2734

2006年05月07日

Greasemonkey利用者の感覚と不正指令電磁的記録作成罪立法者の感覚

JavaScriptでコードを書くことによりFirefoxの機能を手軽に拡張できるようにするという、Firefoxの機能拡張モジュール「Greasemonkey」がある。同様の機能が Operaでは標準搭載されているようだ。

これらは「User JavaScript」(ユーザスクリプト)という概念で、「ユーザスタイルシート」に似ている。ユーザスタイルシートとは、Webページの見た目のデザインをブラウザ側の設定で変更するものであるが、ユーザスクリプトではさらに進めて、ブラウザ側に設定したJavaScriptプログラムをページごとに動作させることによって、HTML内容などを改変して表示させるものだ。

自分で自分のブラウザに表示するHTMLを改変するという行為は、プロキシサーバ上での変換フィルタなどを用いるなどして古くから行われてきた。たとえばProxomitron*1はそうした用途に特化して作られたプロキシサーバの代表例である。

当然ながら、変換方法を第三者に勝手に決められてしまうと、致命的なセキュリティリスクを負うことになる。端的に言えば、「ワンタイムパスワードやバーチャルキーボードなどの厳重なスパイウェア対策のなされているインターネットバンキングのサイトであっても、知らないうちに不正送金されるなどの被害」が起こり得る。

元々これらは、自分用に自分のブラウザの動作を改変する行為なのであるから、その設定がどんな変換をするものであるかを自分で理解して使うものだった。

Greasemonkeyは変換フィルタに比べるとかなり強力になっている。第一に、JavaScriptでDOMを操作するという方法で変換するため、高度な変換ルールを容易に作成できること、第二に、「GM_xmlhttpRequest」というXMLHttpRequest*2に類似した機能*3があること、第三に、JavaScriptファイルへのリンクを右クリックメニューで選択するだけで簡単にルールを追加できることなどが、その理由である。

セキュリティ上のリスクは以前から報道されていたところだったが、先日ついに日本語圏でも、不正なスクリプトか?と疑いを持たれる騒動*4が起きた。

興味深いのは、次のような声が挙がった点だ。

そうすると、次のような反論がわらわらと出てきた。

  • Greasemonkeyだけじゃない、機能拡張だって、ツールバーだって、ActiveXコントロールだって、署名Javaアプレットだって、ダウンロードして実行する.exeファイルだって、同じように危険なのに、みんな使ってるじゃないか。
  • コードを読んだところで危険かどうかなんてわらない(わかりにくい)ように作ることだってできるじゃないか。
  • 「コードを読めないなら使うな」という理屈でいくと、「プログラマ以外はパソコンを使うな」ということになってしまうじゃないか。

たしかに、ユーザスクリプトも立派なプログラムであるという点で、ツールバーや.exeファイルなどと同様にリスクを考えるべきだということは言える。それを承知でもなお、「greasemonkeyというのはソースを読むのが前提なので」という感覚を抱く人は少なくなかったのではなかろうか。それがどのような気持ちから来るものかがポイントだ。

最近では日本語圏でもトロイの木馬による被害は深刻なものとなっており、いよいよ、「拡張子を見ないでファイルを開いてはいけない」といった基礎的なリテラシーが周知されようとしているところだ。そんな折、「成分解析」なる.exeファイルが人気を博したというが、そういうものを安易にダウンロードして実行する人たちが大量にいたということが恐ろしい。それをまた注意もせず広めたITmediaの記事はにわかには信じがたいものだった。こんな内容のプログラムは.exe形式で作成する必然性は全くなく、Web上で安全性が保証されたプログラム(JavaScriptや、Javaアプレットや、Flashコンテンツや、サーバサイドのプログラム)で実現できるのであり、できるだけそうした方法でプログラムを提供するというのが、近代的なソフトウェア配布のあるべき姿とされつつあるところ、それをITmediaがブチ壊した。

あるタイミングで不正なプログラムではないようだと思われている .exeファイルが、ある日突然、悪質なプログラムに差し替えられているとも限らないと考えると、得体のよくわからない一般Webサイトで提供されている .exeファイル(未署名の)を紹介することさえ憚られる。そういう時代になってきた。

プログラマにとってプログラムを配布することがある意味「肩身の狭い」ものになりつつある。そんな中Greasemonkeyは、ひさびさにプログラマたちを晴れやかにするものだった。「どんなスクリプトであれ、自由に気軽に公開させてくれ」という心の叫びを感じる。

プロキシの変換フィルタからの流れからすれば、変換方法を記述したファイルは「設定方法」のようなものだ。「プログラム」と「設定方法」に違いがあるのかないのか*5という話もあるが、Greasemonkeyで使われる「ユーザスクリプト」を、設定ファイルのようなものと感じる人も少なくないのではないか。

たとえば次のページを見てみる。

ここに掲載されているユーザスクリプトは、コードを読んでみると、AmazonのアソシエイトリンクのすべてのIDを、「ryosukecompute-22」に書き換えるスクリプトになっている。

これはblogとして書かれて一般公開状態になっているものの、おそらく、著者が自分で使うため専用のリンクなのだろう。Greasemonkeyの右クリックでインストールの機能を使うために、Webページにリンクを貼り付けているのだと思われる。

しかし、他人がこのリンクを右クリックしてインストールしてしまうとどうなるか。今回の騒動で指摘された「Amazonアソシエイトの規約違反」という事態が発生する。

ここで、3月の不正指令電磁的記録作成罪の議論を思い出す。

この議論でけったいな刑法学者さまより教えていただいたことは、不正指令電磁的記録の罪で、作成が罪とされていることの趣旨は、どんなプログラムでも安心して人々が利用できるように「プログラムの動作に対する信頼」を法律で保護するものなのだということである。

自分用に自分で書いたユーザスクリプトでも、公衆送信可能な状態に置くからには、それがどのように他人にクリックされるかを意識して書かないと、プログラムの動作に対する社会的信頼を侵害することになる……ということになるだろうか?

Greasemonkeyがなければ(簡単なインストールはできないので)、ユーザスクリプトはユーザスタイルシート同様に単なる「設定方法」のひとつにすぎないとも言える。設定方法の説明をWeb上にどう書こうが自由だろう。ところが、Greasemonkeyが存在すると、それは一般人にとって「プログラム」として目に映るものとなり、その社会的信頼の確保が求められるようになる……。

けったいな刑法学者さまは最後で次のようにおっしゃっていた。

ある程度リテラシーのあるひとから見れば、わかりそうなものであっても、そうではない人たちが実際にコンピュータを利用するようになってきたというのであれば、そのレベルが「コンピュータの利用に関心を持つべき社会の客観」ということになります。むしろ立法者は、そうだからこそ不正指令電磁的記録に関する罪を立法しなければならないと考えているようです。

# 通貨偽造では、真正なものと一般に誤認されうるものであることが必要とされます。この場合、普段からお金に接することが多い商売人やレジ担当者がすぐに偽造とわかるものであっても、そのへんの普通の人たちが誤認しやすいものであれば偽造通貨ということになります。社会的な信頼というとき、そのレベルはその道の専門家が思うほど高くはないように思います。

続々・作成罪はいらいない?, 続・けったいな刑法学者のメモ, 2006年3月18日

通貨は通貨としてしか機能しないものなので話はそのように単純なものでよいだろうが、プログラムは使う人によって、また使い方によって、様々な動作をするものである。さらに、一口に「プログラム」といっても、署名されたプログラムパッケージのような明らかに社会的信頼が確保されるべきものから、設定ファイルや設定の手順を記したものと違わないレベルのものまで幅広い概念を指している。不正指令電磁的記録作成等の罪は、いったいどういう範囲のものに対して適用されるのだろうか。

「実行の用に供する目的で」の「実行」とはどのような実行を指すのか?

ところで、けったいな刑法学者さまは、3月に挙げた「delall.vbs」の例について次のようにおっしゃっています。

甲についてどうなるのかということですが、事情にもよりますが、おそらく甲については作成罪は成立しないといえます。甲は、ハードディスクを消去するものとして「delall.vbs」というプログラムを書いたのであり、それは「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」不正な指令を与える電磁的記録とはいえないからです。また、たんに「format c:」のようなプログラムを紙に書いただけの場合、それだけでは、「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」不正な指令というのは困難ではないでしょうか。したがって、通常、なんらかのプログラムを紙に書いたとしても、その動作内容がそれ自体不確定な場合には、不正指令電磁的記録作成罪は成立しないと解されます。

続々・作成罪はいらいない?, 続・けったいな刑法学者のメモ, 2006年3月18日

犯罪成立のためには「人の電子計算機における実行の用に供する目的」でなければならないとされているので、「そのような心配はありませんよ」ということをよく耳にするのですが、次の点が気になります。

法案の文は、

人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる目的で、不正な指令に係る電磁的記録その他の記録を作成し、又は提供した者は、

と書かれているわけではありません。実際には、

人の電子計算機における実行の用に供する目的で、人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる不正な指令に係る電磁的記録その他の記録を作成し、又は提供した者は、

となっています。「目的」は、「意図に沿うべき動作をさせない」や「意図に反する動作をさせる」にはかかっていないように見えます。「実行の用に供する」にだけかかっているように見えます。つまり、どういう動作をさせるつもりだったかとは関係なく、単に他人のコンピュータで実行してもらう目的であれば、全部が該当するのではないでしょうか?

この「目的」による限定は、単に、他人に実行させる目的でないケース(研究目的のウイルス作成等、自分で使用する目的のケースなど)を除外しているだけではないでしょうか。

「その意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」というのは、作成者の意図(目的)を指しているのではなく、実行した人のコンピュータ上で起きる結果のことを指しているようにしか読めません。

ですから、「人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」ということが作成者の意図であることを要件とする目的犯となるように、法文を修正するべきではないでしょうか。法案作成者は、プログラムの動作というものについて、作成者の意図と実行結果が常に同じになるものだと想定していたように思えてなりません。

もしこの法案のままでいくとすると、作成罪の適用については、「不正な指令」の解釈を、「どのように使っても不正な動作にしかならないプログラム」に限定して運用しなければならないと思います。そうすると、作成者の目的が「意図に反する動作」という結果を招く意図のものであっても、作成者は「正当な目的の利用もできるようにプログラムを作っておく」という方法によって、作成罪を免れる抜け道ができてしまうのではないでしょうか。

「Remojin」は不正指令電磁的記録か?

という記事が出ていた。たしかに、「設定ファイルを書き換える」とか、「システムフォルダ内に自分自身をコピーし、レジストリを書き換える」というと、ウイルス臭い感じがしてくる。

しかし、シマンテックのテクニカルノートや、トレンドマイクロのウイルスデータベースの詳細情報で確認してみると、「レジストリを書き換える」というのは、Windowsの起動時にこのプログラムが自動起動するようにするレジストリ設定のことを言っているようだ。

他にも、レジストリ値の削除があるそうだが、それはよく読んでみると、「[仁義なきキンタマ]」のファイルを作成する不正プログラムの自動起動を止めるレジストリ設定のことを指しているようだし、ファイルの削除というのは、Antinny系トロイのファイルを削除することを指している。

Remojinが実行されると、システムフォルダ内に自分自身をコピーし、レジストリを書き換えることでWindowsが起動されるたびにRemojinが実行されるようにする。

Antinnyの亜種を削除しようとするトロイの木馬「Remojin」, INTERNET Watch, 2006年3月20日

「システムフォルダ内に自分自身をコピー」というが、よく考えてみれば、ごく普通のソフトウェアは皆そうやって自分をインストールするものだ。常駐型のソフトウェアであれば、レジストリを「改変」して自動起動の設定をするものだ。

そして、Remojinに自分自身を増殖する機能(他のコンピュータへ感染を広げる機能)があるわけではないらしい。

つまり、Remojinは、普通にAntinnyを駆除するツールプログラムとも言えるんじゃないの? と考えてみることができる*6

Remojinがどのようなファイル名でばら撒かれているのかは知らない。ファイル名が、この動作内容とかけ離れたものであれば、「人の使用する電子計算機についてその意図に反する動作をさせる不正な指令」と言えるかもしれないが、元のコードの作成者の目的は、単にAnntiny駆除ツールの提供だ――ということもあり得る。

あるいはこんなことも起き得るのではないか。

アンチウイルスベンダーが、Antinny駆除ツールを作り配布した。ツールは、駆除を実行するプログラム「disinfect_main.exe」とそれをインストールするGUIのインストーラ「Setup.exe」から構成されていたとする。通常はユーザはSetup.exeを起動し、仕様許諾条件の確認やインストール先の確認、「本当にインストールしますか?」などの確認を経て disinfect_main.exe が起動されるようになっているとする。しかし実は、直接 disinfect_main.exe をダブルクリックすれば確認なしにすべては完了してしまう作りになっていた。そこで、disinfect_main.exe だけを取り出して適当なファイル名を付けて .zip アーカイブするなどして、Winnyネットワークに放流する輩が現れた。

これもトロイの木馬として認定されてしまうのだろうか。

*1 作者が亡くなったためメンテナンスされていない。

*2 Ajaxを実現する要素機能として近年よく知られるようになった。

*3 XMLHttpRequestでは当該ページの供給元のサーバにしか接続を許さないというセキュリティ上の制約があるが、GreasemonkeyのGM_xmlhttpRequestは任意のサイトにアクセスできてしまう。

*4 作者によれば、プログラミングミスによるバグが原因であり、意図したものではなかったとのこと。

*5 たとえば、「やってはいけないセキュリティ設定指示 Top 15」にあるような危険なセキュリティ設定の指示をする行為が、「不正指令電磁的記録作成および供用」にあたるかといえば……あたらないだろう。「設定の指示」と「プログラム」の違いはどこにあるのか。

*6 もっとも、Remojinは、インストール先として「<Windowsシステムフォルダ>drivers」を選んでいるところが普通ではないし、おそらくアンインストーラも用意されていないのだろうから、トロイの木馬とみなす判断は正しいと思うが。

本日のリンク元 TrackBacks(100)

2006年05月10日

マイクロソフトから無差別メールが来たので晒す

To: blog@takagi-hiromitsu.jp
Date: Wed, 10 May 2006 18:12:38 +0900
Subject: 【Windows Live Sessions Tokyo へのご案内】

高木 浩光様

はじめまして。突然のご連絡、どうぞご容赦ください。 マイクロソフト株式会社MSN事業部にてWindows Liveの開発を統括しております、○○ ○○と申します。

高木さんが運営されているブログ「高木浩光@自宅の日記」にて、Webテクノロジーお よびマーケティングに関するエントリーを拝読させていただき、このメールを差しあ げました。

既にご存知のことと思いますが、現在、マイクロソフトでは、インターネット サービ スとソフトウェアで構成されるまったく新しい個人向けのサービスWindows Liveの開 発を進めております。

サービス正式リリースを控え、5月末にはマイクロソフト本社よりWindows Liveエバン ジェリストが来日予定です。

この機会を捉え、Webテクノロジーやマーケティングの動向に特に関心をお持ちの方々 を対象として、開発中のサービス群やWeb2.0時代のWindows Liveの戦略について、(略)

ご参加に対して謝礼やお礼を差し上げることが出来ず、大変恐縮ですが、高木さん運 営のブログにてWebテクノロジーおよびマーケティングに関する多くのエントリーを拝 見し、今回のWindows Liveセッションに是非ご参加いただきたく、このメール を差し あげた次第です。

(略)

マイクロソフト株式会社 ○○ ○○

この日記のどこに「Webテクノロジーおよびマーケティングに関する多くのエントリー」 があるんだ? 読んでもいないくせに嘘を言うなよ。

既にご存知のことと思いますが、現在、マイクロソフトでは、インターネット サービ スとソフトウェアで構成されるまったく新しい個人向けのサービスWindows Liveの開 発を進めております。

知るかよそんなもん。

本日のリンク元 TrackBacks(5)

2006年05月12日

「実行の用に供する目的で」の「実行」とは? その2

7日の「「実行の用に供する目的で」の「実行」とはどのような実行を指すのか?」に対して、引き続きけったいな刑法学者さまよりトラックバックを頂きました。

(略)を作成するということは、同時にその際、(略)を作成するという故意が必要です。

供用目的をもって、客観的に「人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」不正な指令を作成したけれども、そのような認識がなかった場合は処罰できないし、客観的に「人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる」不正な指令を作成していないときにも、犯罪は成立しない、というのでは、だめなのでしょうか。

また作成罪はいらない?, 続・けったいな刑法学者のメモ, 2006年5月12日

不正指令電磁的記録作成の件で、「故意がなければ処罰できない」の話は、「バグのあるソフトウェア」の話としてならば理解しています。情報処理学会の「 「ハイテク犯罪に対処するための刑事法の整備に関する要綱(骨子)」に関する意見書」の「1.攻撃を意図しない、ソフトウェアのバグや仕様の不完全性を処罰対象としないこと(要綱第一)」は、その典型的な杞憂の例で、その話をしているのではありません。

バグが故意によるものでないから処罰されないにしても、「人の使用する電子計算機についてその意図に沿うべき動作をさせず、又はその意図に反する動作をさせる不正な指令」をもたらすバグである限り、「一の不正な指令」である事実は揺ぎ無いのですよね。

つまり、処罰されないけれども、規範として、そのようなプログラムを作成してはならないということではないでしょうか?

つまり、日本の刑法に不正指令電磁的記録作成罪を新設することは、「そのような不正な指令を新たに存在するに至らしめることは、プログラムに対する社会の信頼を害することを意味する」という規範を、日本に作るということではないでしょうか。(処罰とは別に。)

バグについては、バグは誰も望んでいないものですから、避けるべきものとする規範が刑法に盛り込まれることについて、抵抗はないかもしれません。(もしくは、既に日本社会にそのような規範は存在していると言える。)

しかし、コンピュータプログラムというものは一般に、その一つが、環境や時刻やユーザや起動方法や他のデータの値などによって、複数の異なる動作をし得る「多態性」を持つわけです。文書偽造における文書が偽造された文書としてしか存在し得ないのとは違います。

あるプログラムについて、ある人たち(甲グループ)が実行したときはその意図通りに動作し、別の人たち(乙グループ)が実行したときはその意図に反する動作をしたというときに、乙グループの人たちはそれを不正指令電磁的記録と客観し得るでしょう。

乙グループの人たちにその意図に反する動作をさせる故意が作者になく、作者を処罰することはないにしても、乙グループが意図に反する動作をしたと客観するようなプログラムを「新たに存在するに至らしめる」ようなことは反規範的であるという規範が、この刑法改正案によって新たに作られるのではないでしょうか。

たとえば、あるプログラマが、.dll 形式でプログラムを作成し配布したとします。これはダブルクリックでは開きません。そしてこれについて詳細な説明書は付いていないとします。わかっている人だけが使ってくれればよいと考えて配布しています。ところが、その一方で、任意の .dll ファイルを右クリックメニューから実行できるシステムが乙グループの人たちのコンピュータに普及したとします。乙グループの人たちが、その .dll プログラムがどういう挙動をするものかよく知りもせず、右クリックメニューで実行したとします。その結果、乙グループの人たちに意図に反する動作をしました。

このような事態を招くことについて作者に故意がなければ、処罰されないのでしょう。

ですが、規範としては、こういうプログラムは作ってはいけないということになるのではないでしょうか。(刑法改正以後において。)

本日のリンク元 TrackBacks(100)

2006年05月13日

IE 7のセキュリティ改善を台無しにするIE 7 Beta2日本語版

「セキュリティで保護された」というと何を思い浮かべるだろうか。Windows用語のような気がするが、普通は、SSLによる接続( https:// ページへのアクセス)のことを連想するだろう。(「セキュリティ(暗号化処理)で保護された接続」など。)

それはともかく、Internet Explorer 7 がさまざまなセキュリティ上の改良を施していることは既に報道等で伝えられているところだ*1が、報道されていないところとして、「インターネットゾーン」のセキュリティ設定の画面の改善がある。

凶悪設定3兄弟の改善

図1の「Download signed ActiveX controls」の部分は、日本語版で言うところの「署名済み ActiveX コントロールのダウンロード」という、悪名高い設定項目で、アホな業者がしばしばこれを「『有効にする』にせよ」と誤った設定を指示して人々を危険にさらしてきたものだ。

これら凶悪設定トップ3は、そもそもそんな設定は不必要なのだから設定不可能なようにしてしまうべきだが、IE 7では一応の改善があった。図1のように、「Enable」(有効にする)の項目には「(not secure)」(安全でない)と補足が書かれており、「Prompt」(ダイアログを表示)の項目に「(recommended)」(推奨)と書かれている。

図1: IE 7 Beta 2のインターネットゾーンのセキュリティ設定画面(英語版)

そして、同図右のように、「(not secure)」な項目を選択すると、その設定項目部分の背景色が赤っぽくなり、項目タイトルの「Download signed ActiveX controls」の右の部分に、「(not secure)」と表示され、この項目が「安全でない」設定になっていることを警告するようになった。

今後ユーザは、ここが「赤くなるような設定で使ってはいけない」ということになる。

そして、IE 7 Beta 2の日本語版が先日リリースされた。この画面がどうなっているかを確認したところ、図2のようになっていた。

図2: 図1の日本語版での翻訳

なんだこの「(セキュリティで保護されていない)」というのは。SSLが使われていないとでも言いたいのか?

マイクロソフトの日本語化係の人は、「安全でない (not secure)」という言葉をどうしても使いたくないのだろうか。*2

クリップボード盗聴機能の改善

次に、IE 7では、クリップボード盗聴の問題がやや改善された。

IEはデフォルト設定(「スクリプトによる貼り付け処理の許可」を「有効にする」の設定)のまま使うと、悪意あるサイトを訪れたときに、クリップボードの内容(コピーペーストして入力したパスワードや、会社の機密文書の編集内容など)を盗まれてしまう問題があった。これは1999年から指摘されていたのに一向に改善される様子がなかった。

それが、IE 7 Beta2では、この「スクリプトによる貼り付け処理の許可」のデフォルト設定が、図3のように「ダイアログを表示する」に変更された。

図3: クリップボードアクセス機能の設定(日本語版)

この設定で、クリップボードにアクセスするJavaScriptを含むページを表示すると、図4の確認ダイアログが出る。

図4: クリップボードにアクセスする際の確認ダイアログ(IE 7 Beta2の場合)

IE 6での確認ダイアログのメッセージ(図5)と違って、意味がわかるようになった。

図5: クリップボードにアクセスする際の確認ダイアログ(IE 6の場合)

ただし、IE 6 のインストールされた Windowsに IE 7 を上書きインストールした場合、IE 6の設定が引き継がれるようなので、何も知らない人は(IE 7をインストールしても)この設定は「有効にする」のままとなるおそれがある。「IE 7をインストールしたらインターネットゾーンのセキュリティ設定をリセットしよう」と推奨するのがよいかもしれない。リセットは図6のように「既定のレベル」ボタンを押せばよい。

図6: 「既定のレベル」ボタンを押してインターネットゾーンのセキュリティ設定をリセットする

ところで、その「スクリプトによる貼り付け処理の許可」という設定項目は、いかにも意味不明なタイトルだった。「貼り付け」とうのがコピーペーストのペーストのことであることがまずわからないうえ、「スクリプトによるペースト」と言われてもなんのことだかわかるわけがない。

それが、英語版のIE 7 Beta2 では改善された。図7のように、「Allow Programmatic clipboard access」というタイトルに変更されたのだ。日本語訳すれば、「プログラムによるクリップボードへのアクセスの許可」といったところか。

図7: クリップボードアクセス機能の設定(英語版)

この改善がなぜか、同じバージョンの日本語版ではスキップされている。

*1 アドレスバーの常時表示、オレオレ証明書の拒否、アドレスバーの色分け表示、錠前アイコンの位置と内容表示方法の改善など

*2 どうやら、マイクロソフトの全社的翻訳方針として、「secure」という英単語はすべて「セキュリティで保護された」と機械的に置き換えているようだ。マイクロソフトのサイトには以前から「セキュリティ保護された .NET Web アプリケーションの構築」というコンテンツがあった。表題からは「IISで SSLを使う方法の解説かな?」という印象を受けるが、中身は安全なWebアプリケーション開発の解説になっていて、違和感を覚えていた。調べてみるとこのコンテンツの英語版は「Building Secure ASP.NET Applications」というタイトルだった。ここでも「Secure」が「セキュリティ保護された」に置き換えられているようだ。safe と secure を区別したいということなのだろうが、もうちょっとどうにかならないものか。

本日のリンク元 TrackBacks(4)

2006年05月16日

アンチウイルスベンダーがWinnyのCacheフォルダ内のウイルスを駆除しない理由

という記事が出ていた。たしかに普通のウイルス(ワームおよびトロイの木馬を含む)の場合、発生直後に大流行した後に急速に衰えていく性質がある。それはウイルス対策ソフト(パターンマッチング方式によるウイルス削除システム)の普及が効果を挙げている結果であろう。それに対しこの記事は、Winnyを媒介するウイルスの場合は、あまり衰えずに継続して感染者が出続けること、さらには、後になって大きなピークが現れる現象が見られることをデータで示している。後になってピークが出る原因について、著者の新井さんは、

幾つもの推論はできるが、筆者はその中から1つを挙げておきたい。それは、一連のニュースを見て新たにWinnyを使い始めた利用者がおり、彼らが暴露ウイルスに感染し始めているのではないか、ということだ。歴史は繰り返されるのか。

Winny経由の漏えいは止まるか? データに見る暴露ウイルスの感染推移, 新井悠/ITmedia, 2006年5月16日

と考察している。

それもあるとして、全体的にあまり衰えない原因として、次があると思われる。

まず、Winny利用者をターゲットとしたトロイの木馬を原因とする情報漏洩事故が、従来の事故と比べて被害が甚大である原因は、次の3つに分けられる。

  1. 人々がトロイを踏みやすい: 出所不明なファイルでもそれを開きたいという強い欲求が利用者にあるため。(WANでのファイル共有利用時に一般的に問題となる性質)

  2. トロイのファイルが流通し続ける: 削除する方法がなく、人々の意思と無関係に自動運転でファイルが拡散していくため。(Winny型のP2Pファイル共有/放流システム固有の性質)

  3. 事故で流出した被害ファイルが流通し続ける: 削除する方法がなく、人々の意思と無関係に自動運転でファイルが拡散していくため。(Winny型のP2Pファイル共有/放流システム固有の性質)

このうち、2.の性質が、普通のウイルスと違ってWinnyを媒介するウイルスが沈静化しにくい最大の要因であろう。

トロイの木馬による攻撃で被害者数が多くなるのは、トロイが自分自身を複製して他へ被害を広げる増殖機能(ワームないし狭義のウイルスが持つ性質)を持つ場合である。したがって、アンチウイルスソフトにより感染端末でそのトロイを駆除すれば、増殖も止まるため、被害規模は沈静化する。

それに対しWinny媒介型の場合、増殖機能はWinny本体が受け持っている*1ため、端末のトロイを駆除してもトロイの流通は止まらない。これが原因である。

ここでひとつ疑問がある。なぜ、アンチウイルスベンダーは、WinnyのCacheフォルダ内のウイルスファイルを駆除しないのだろうか?*2 これを駆除すれば、上の2.の要因は消滅し、普通のウイルスと同程度の沈静化を達成できるかもしれないのにだ。

一般にアンチウイルスソフトは、圧縮・アーカイブファイル内のウイルスファイルも検出して削除する。多重に圧縮・アーカイブされたファイルでも検知できるとされている。

(18日修正:セキュリティホールmemo 2006.05.18のご指摘に従い参考参照先を変更。)

それと同様に、WinnyのCacheフォルダ内のファイルも(圧縮を解除するのと同様に)デコード*3して、さらに多重に処理された圧縮・アーカイブも展開して検査することは、技術的に可能であるはずだ。そして、検出されたウイルスを含むCacheファイルは、単純に削除してしまって差し支えないはずだ。

それが行われていない理由として、次などの可能性が考えられる。

  • Winnyの用途の大半が専ら違法行為目的のものと考えられているところ、Winny自身の機能部分にまで介入してウイルス駆除を行うことは、Winnyの機能を改善サポートすることを意味する*4ため、そのような違法行為蔓延の継続を促すようなことは反社会的であると考えられている可能性。

  • WinnyのCacheフォルダ内の特定ファイルをアンチウイルスで削除できるようになると、ウイルスだけでなく、事故で流出した悲惨なプライバシー侵害ファイルや、著作権侵害ファイルも削除してほしいという要望が出るようになると考えられ、何を削除するべきかの判断をアンチウイルスベンダーが迫られることになりかねない。そのような厄介な事態には巻き込まれたくないので、そのような機能を提供することに消極的になっている可能性。

  • 対応する圧縮・アーカイブ方式の追加(WinnyのCacheファイルという新方式の)は、アンチウイルスソフトのエンジン中枢の改良が必要であり、アンチウイルスベンダーの本社での決断が必要となるところ、日本に本社のあるアンチウイルスベンダーはもはや存在せず、日本固有の被害状況に対処してそのような新機能を導入することが億劫になっている可能性。

  • アンチウイルスソフトの目的は、それを購入してくれた顧客を保護することであり、その目的のためには、Downフォルダに展開されたファイルを駆除対象とするだけで十分であり、Cacheフォルダ内のものまで駆除する理由がない*5と考えられている可能性。

*1 メール媒介ウイルスの場合におけるSMTPサーバが、複製はするけれども増殖機能を持つわけではないのと違って。

*2 今のところこれを駆除するアンチウイルスはないと理解していますが、あるようでしたら教えてください。

*3 その方法は既に公知である。WinnyがCacheフォルダ内のファイルをエンコードしている目的は、違法な公衆送信行為をしている事実を利用者が自覚しにくくする(認識しているのに認識していないと嘘をつけるようにする)ためであるが、仮にそれが、著作権法2条1項20号の「技術的保護手段」とみなされるとすると、それをアンチウイルスソフトがデコードすることが、「技術的保護手段の回避」(同法30条2項)にあたり120条の2 1項に抵触する……などと考えてみるのはおもしろいが、WinnyのCacheフォルダ内のファイルのエンコードが著作権法の技術的保護手段にあたるわけがない。

著作権法 2条1項20号

技術的保護手段 電子的方法、磁気的方法その他の人の知覚によつて認識することができない方法(次号において「電磁的方法」という。)により、第十七条第一項に規定する著作者人格権若しくは著作権又は第八十九条第一項に規定する実演家人格権若しくは同条第六項に規定する著作隣接権(以下この号において「著作権等」という。)を侵害する行為の防止又は抑止(著作権等を侵害する行為の結果に著しい障害を生じさせることによる当該行為の抑止をいう。第三十条第一項第二号において同じ。)をする手段(著作権等を有する者の意思に基づくことなく用いられているものを除く。)であつて、著作物、実演、レコード、放送又は有線放送(次号において「著作物等」という。)の利用(著作者又は実演家の同意を得ないで行つたとしたならば著作者人格権又は実演家人格権の侵害となるべき行為を含む。)に際しこれに用いられる機器が特定の反応をする信号を著作物、実演、レコード又は放送若しくは有線放送に係る音若しくは影像とともに記録媒体に記録し、又は送信する方式によるものをいう。

*4 メール媒介ウイルスを駆除するアンチウイルスシステムは、インターネットメールの機能を改善サポートするものである。

*5 Cacheフォルダ内も駆除対象とすることの意義は、アンチウイルスを使用していない他のWinny利用者を保護することにあるから。ただし、メール媒介ウイルスの場合のように、メール送信時にウイルスフィルタリングが行われている理由が、他人に迷惑がかからないようにすることであるのと対比すれば、Cacheフォルダ内のウイルスを駆除することもアンチウイルスの本来の目的に合致しているという見かたもできる。しかし、WinnyのCacheフォルダ内のファイルは、利用者にとって「公衆送信している」という自覚を持たないようにWinnyが作られているため、その部分に対してウイルス駆除が必要だという考え方が出てこないのかもしれない。

本日のリンク元 TrackBacks(4)

2006年05月20日

セッションハイジャック攻撃は1号不正アクセス行為か、それとも2号ないし3号か

情報ネットワーク法学会の学会誌「情報ネットワーク・ローレビュー」に論文を投稿していたところ、第5巻1号に掲載していただくことができた*1

  • 高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, pp.30-43 (2006年5月).

この論文は、昨年11月に開かれた同学会の研究大会での個別発表(発表時スライド, 関連報道)の際に予稿集に掲載された発表要旨に大幅に加筆したもの*2である。

追記した論点のうち次の部分について、説明が足りていないと思うので、詳細な検討を日記に書き留めておくことにする。

セッションIDは、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)には当たらない場合が多いが、「制限を免れることができる情報」(同法3条2項2号および3号)に該当するであろう。警察庁の不正アクセス禁止法の解説資料22では、他人の識別符号を無断で使用する行為以外の不正アクセス行為として、「セキュリティホールを攻撃してコンピュータに侵入する行為」しか挙げていないが、セッションハイジャック攻撃のように、セキュリティホールのない(瑕疵のない)Webサイトに対して「制限を免れることができる情報」(セッションID)を入力する行為も、不正アクセス行為に該当すると解するべきである。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.37

この部分は、セッションハイジャック攻撃*3は、不正アクセス禁止法3条2項1号の不正アクセス行為には当たらず(当たらない場合が多く)、同2号ないし3号の不正アクセス行為に当たると解するべきであると主張している。

「当たらない場合が多いが」と書いたのは、サイト管理者がサイト利用者に対して「セッションIDを他人に知らせないでください」と利用規約等に明記していることがあるかといえば、あり得ないことではないがほとんどないであろうという背景に基づいて述べたものである。

しかし、セッションIDが「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)に当たらないからといって、セッションIDが「識別符号」に当たらないとまで言えるかというと、実はもう少し検討が必要である。

まず、同法2条2項は「識別符号」を次のように定義している。

この法律において「識別符号」とは、特定電子計算機の特定利用をすることについて当該特定利用に係るアクセス管理者の許諾を得た者(以下「利用権者」という。)及び当該アクセス管理者(以下この項において「利用権者等」という。)に、当該アクセス管理者において当該利用権者等を他の利用権者等と区別して識別することができるように付される符号であって、次のいずれかに該当するもの又は次のいずれかに該当する符号とその他の符号を組み合わせたものをいう。

不正アクセス行為の禁止等に関する法律 2条2項

ここで「その他の符号」が登場するので、セッションIDが「その他の符号」に該当することを検討してみる必要がある。しかし、「次のいずれかに該当する符号とその他の符号と組み合わせたもの」とあるので、仮にセッションIDが「その他の符号」であるとしても、それ単独では2条2項の「識別符号」にはならない。

ところが、2条3項に次の記述がある。

この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されている機能であって、当該特定利用をしようとする者により当該機能を有する特定電子計算機に入力された符号が当該特定利用に係る識別符号(識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号を含む。次条第二項第一号及び第二号において同じ。)であることを確認して、当該特定利用の制限の全部又は一部を解除するものをいう。

不正アクセス行為の禁止等に関する法律 2条3項

つまり、「識別符号」の定義は2条2項で与えられているものの、2条3項では、その定義を拡張し、括弧書き部分が示す符号も含むものとしている。しかも、「次条第二項第一号及び第二号において同じ」とあるので、これは3条2項(つまり、不正アクセス行為の定義)においても、その拡張された「識別符号」で解釈しなければならない。したがって、「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」として何が該当し得るかを検討する必要がある。

Webアプリケーションは、その構成によっては、ログイン後にセッションIDを発行する場合がある*4。その場合、セッションIDは「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」であると言うことができるかもしれない*5

しかし、この括弧書きには「により作成される符号と当該識別符号の一部を組み合わせた符号」とあるので、「当該識別符号の一部を組み合わせた」ものでなくてはならない。一般的なセッションIDでは、それに2条2項の「識別符号」の一部が組み合わされていることはないはずである。

ただし、次の2つの屁理屈が考えられる。

まず、「当該識別符号の一部を組み合わせた」というときの「一部」という文言について、空の場合も含むという解釈があり得るかもしれない。つまり、長さゼロの部分文字列を組み合わせているという見なし方である。これは、理数系的発想ではよくある物の見方であるが、法解釈上はどうだろうか。何も組み合わせていないのに「組み合わせたもの」と解釈することは普通ではないのではなかろうか。

次に、2条2項の「識別符号」の定義で「次のいずれかに該当する符号とその他の符号を組み合わせたもの」とあることから、2条3項の「当該識別符号の一部を組み合わせた」における「識別符号の一部」は、2項の「その他の符号」の部分だけから構成される一部であってもかまわないと言える。そうすると、セッションIDには、たしかに、パスワードなどの「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」は含まれていないけれども、「その他の符号」(つまり何でもよい)は含まれているじゃないか、と見なすこともできるかもしれない。ただ、それなら、初めから「その他の符号を組み合わせた」と書けばよいのであって、わざわざ「当該識別符号の一部を組み合わせた」としている趣旨は、2号2項の1号〜3号に何らかの形で係る符号であることを想定していると解すべきだろう。

つまり、このように、ログイン後に発行されるセッションIDについて、それを「識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号」と見なすことは、不可能ではないがやや無理があるといえる。

また、いずれにしても、ログイン前に発行されるセッションIDを用いてセッション追跡するWebアプリケーション構成も存在するのであり、そのセッションIDが「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」でないことは明らかであるから、セッションハイジャック攻撃が1号不正アクセス行為に当たらない場合があるとする論旨は否定されない。

ちなみに、ではなぜ、2条3項で「識別符号を用いて当該アクセス管理者の定める方法により作成される符号と当該識別符号の一部を組み合わせた符号を含む」と括弧書きされているのか。それは、立法担当者らによる逐条解説書で次のように説明されている。

(略)本項括弧書きでは「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」である場合を既定している。これは、公開鍵暗号方式における秘密鍵が識別符号の一部(第二条二項一号)として用いられる場合のように、アクセス制御機能によっては、識別符号そのものを入力(送信)せず、識別符号を作用させて作り出される別の符号を当該識別符号の一部であるID等とともに入力する例があるために、このように既定しているものである(略)。この場合の別の符号としては電子署名が、ID等としては電子証明書(略)が挙げられる。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.54

公開鍵暗号方式を用いた識別は、利用権者等が自分の秘密鍵により作成した電子書名を識別を行う特定電子計算機に入力することにより行われる。(中略)この場合、利用権者等の秘密鍵が識別符号(の一部)となるが、特定電子計算機に入力されるものは当該秘密鍵で作成された電子署名となる(図参照)。

これを第二条第三項括弧書きに当てはめれば、「識別符号」は秘密鍵と電子署名の組み合わせであり、このうち別の符号を作成するために「用い」られるのは秘密鍵、「作成される符号」は電子署名、これと組み合わせられる「当該識別符号の一部」は電子証明書ということになる。「アクセス管理者の定める方法」とは、識別符号を用いてどのように符号を作成するか、その作成方法を指し、具体的には、RSA、楕円暗号等暗号化の方式を指す。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.57

つまり、3条2項1号の不正アクセス行為の定義で、「識別符号を入力して当該特定電子計算機を作動させ」ることを要件としているが、この「入力」というのは利用者側コンピュータへの入力のことではなく、サーバ側コンピュータへの入力(電気通信回線を通じた、つまり、利用者コンピュータから見れば「送信」)のことを指しているので、パスワードなど利用者が直接使用する秘密情報(2条2項1号)をサーバへ送信しないタイプのアクセス制御機能の場合、2条2項の「識別符号」の定義ではこの要件を満たさないことになってしまう。そのため、2条3項の括弧書きにより「識別符号」の定義は拡張され、3条でも同様とされているのである*6

そのようなアクセス制御方式として、逐条解説書は公開鍵認証の場合だけを挙げているが、他にも、HTTPのダイジェスト認証(RFC 2617)や、POP3のAPOP(RFC 1939)も該当するであろう。これらはいずれも、パスワードを元にしたハッシュ値(「当該アクセス管理者の定める方法により作成される符号」)とユーザID(「当該識別符号の一部」)の組(「組み合わせたもの」)を電気通信回線を通じて当該特定電子計算機に入力するものだからである。

このように、2条3項の括弧書きの意図は、ダイジェストを用いた認証方式等が該当しなくなるのを避けるために追加されたものであり、セッションIDを送信することによるセッションハイジャックを1号不正アクセス行為に含めるために追加したわけではないと考えるのが自然であろう。

おそらく、立法関係者らは法案立案時に、認証機能の実現手法については技術的に検討したものの、認証後の認証状態(セッション)の維持手法については検討する必要性を認識しなかったのではなかろうか。逐条解説書においても、後者に関する記述が何ら見当たらない。もっとも、セッションハイジャック行為は2号又は3号の不正アクセス行為に該当すると見なすことは、自然に可能であるから、運用上問題となることはないという結果になっている。

警察庁の不正アクセス行為類型の分類方法には不備がある

さて、上の論文では次のように書いた。

セッションIDは、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないとされている符号」(同法2条2項1号)には当たらない場合が多いが、「制限を免れることができる情報」(同法3条2項2号および3号)に該当するであろう。警察庁の不正アクセス禁止法の解説資料22では、他人の識別符号を無断で使用する行為以外の不正アクセス行為として、「セキュリティホールを攻撃してコンピュータに侵入する行為」しか挙げていないが、セッションハイジャック攻撃のように、セキュリティホールのない(瑕疵のない)Webサイトに対して「制限を免れることができる情報」(セッションID)を入力する行為も、不正アクセス行為に該当すると解するべきである。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.37

脚注22の警察庁の解説資料とは、次のページのことを指す。

この解説では、不正アクセス行為の例は「その1」と「その2」で説明されており、前者は「他人のID・パスワードなどを無断で使用する行為」、後者は「セキュリティ・ホールを攻撃してコンピュータに侵入する行為」と説明されている。

もう少し調べてみると、やはり警察庁の認識では、不正アクセス行為は2種類の様態から成り、それは「識別符号窃用型」と「セキュリティホール攻撃型」であるとされていることがわかる。

まず、逐条解説書に次の記述が見られる。

(3) 不正アクセス行為の類型

不正アクセス行為は、一言でいえば、アクセス制御機能による特定電子計算機の特定利用の制限を免れて、その制限されている特定利用をし得る状態にさせる行為である。

不正アクセス行為の類型は、大別すると、他人の識別符号を無断で入力する行為と、アクセス制御機能による特定利用の制限を免れる情報(識別符号を除く)又は指令を入力する行為、いわゆるセキュリティ・ホール攻撃に分類することができる(注三、注四)。

(略)

本条第二項は、第一号で他人の識別符号を無断で入力するという前者の類型を、第二号及び第三号でアクセス制御機能による特定利用の制限を免れることができる情報又は指令の入力という後者の類型を規定している。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.69

そして、警察庁が毎年発表している「不正アクセス行為の発生状況等について」という統計資料において、「不正アクセス行為の手口別年別推移」の統計のなかで、手口を「識別符号窃用型」と「 セキュリティ・ホール攻撃型」に分類している(図1)。

セッションハイジャック攻撃は、先に述べたように、1号不正アクセス行為に当たると解釈するのは無理があるので、「識別符号窃用型」に分類することはできないだろう。そうすると、セッションハイジャック攻撃がはたして「セキュリティホール攻撃型」といえるかどうかが問題となる。

では、「セキュリティホール」とは何だろうか。逐条解説書には次の記述がある。

(注四) セキュリティ・ホール攻撃は、コンピュータのプログラムの瑕疵等により、アクセス管理者の意に反してアクセス制御機能により制限された特定利用をし得る状態にすることができる一定の情報又は指令を入力する行為であり、実際にも相当数のものが知られている。

不正アクセス対策法制研究会編著, 逐条 不正アクセス行為の禁止等に関する法律, 立花書房, p.72

セッションハイジャック攻撃はセッションIDの値が何らかの原因で攻撃者に知られてしまうことによって可能となるものであるが、その原因は、セキュリティホールが原因である場合(XSS脆弱性など)も存在するものの、パケット盗聴による方法のようにセキュリティホールが原因ではないものもある。SSLによる保護を謳っていないサイトにおいては、パケット盗聴によりパスワードなどを盗み見られる可能性があることは、サイトの仕様であり、それをセキュリティホールと呼ぶことは通常ない。

また、何らかの原因で攻撃者に知られてしまったセッションIDで攻撃者にアクセスされたときに、なりすましアクセスを許すことになるのは、システムにセキュリティホールがあるからではない。それは正常な動作であり、システムに瑕疵があるということにはならない*7

セッションハイジャックという概念は、Webアプリケーション固有のものというわけでもない。たとえば、TCP接続を直接乗っ取る TCP session hijacking という攻撃手法も古くから知られており、パケットの盗聴・改竄が可能な状況では、システムにセキュリティホールがなくても、そのような攻撃が可能である。一般に、様々な通信プロトコルにおいて、このようなハイジャック系の攻撃はあり得るのであり、不正アクセス禁止法の趣旨からすれば、そのような攻撃も不正アクセス行為に該当すると解されるべきである。

セッションハイジャック攻撃を「セキュリティホール攻撃型」と呼ぶのが不適切であることは、小さなことかもしれないが、そこにこだわる必要性がある。それについては論文で述べている。関連する部分を少しだけ引用しておく。

ACCS事件の判決文には、不正アクセスに当たらない場合の例として、「当該顧客の公開領域へのアクセスは、当該顧客の承諾(同法3条2項各号)があるか、当該特定利用を誰にでも認めていることによりアクセス制御機能による制限のない特定利用であるから(略)、もとより不可罰であって、この点で不都合が生じることはない」とする記述がある17*8。しかし、2002年の一連の事件では、管理者はそのようなアクセスを承諾していなかったであろうし、管理者の主観ではアクセス制御機能(FTPアカウント)により制限されていると理解されていたものであろう。2002年の事件が不正アクセス行為に当たらないと判断される何らかの理由(管理者の主観によらない条件)が存在するはずであるが、ACCS事件の判決には記されていない。

2.3 アクセス制御機能による制限の優劣

そこで次に、あるアクセスがアクセス制御機能によって制限されたものといえるかという点について検討する。

ACCS事件の判決では、この点について次の検討がある18

(略)

「本件の各特定利用ができたのは、プログラムのないし設定上の瑕疵があったためにすぎないのであり、アクセス管理者が本件アクセス行為のような形で特定利用をすることを誰にでも認めていたとはいえない。よって、本件においても、本件CGI及び本件ログファイルの各閲覧は、アクセス制御機能による特定利用の制限にかかっていたものということができる。」とある。

しかしながらこの根拠だけでは、前述の2002年の事件での警視庁の判断と矛盾する。2002年の事件は設定上の瑕疵が原因であった。

この矛盾について大橋7は、「アクセス制御機能が極めて拙劣であり、もはや利用者にとってアクセス制御機能の存在を認識し得ない場合に至れば、たとえ行為の外形として『アクセス制御機能による特定利用の制限を免れることができる情報又は指令』が入力されたとしても、犯罪構成要件としての故意が認められず、不正アクセス行為は成立しないのであるから、不当な結論は生じないであろう。」と主張している*9

2.4 2005年の連続サイバー攻撃事件との対比

確かに2002年の事件においては、アクセスした者たちに、「アクセス制御機能により制限されている利用をしている」との認識はなかったかもしれない。ところが、2005年に対照的な事件が起きた。(略)

2005年の事件では、アクセス管理者の主観では利用を制限していたつもりであったであろうし、アクセス者の行為は犯意を持ったものであったと推察できる。また、詳細は明らかにされていないものの、プログラムの瑕疵が原因だったと推察できる。それでもなお不正アクセス行為に当たらないと判断される場合があることを、この事件は意味しており、不正アクセス行為の構成要件として、行為の外形に関する何らかの客観的条件が存在すると推察される。しかしながら、その条件は公表されていない。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.34

3. さらなる議論の必要性

以上のように整理すると、警視庁は「GETメソッドによるアクセスならば不正アクセス行為に当たらない」との判断基準を持っているのではないかとの推定が可能である。しかしながら、それは、現在のWebアプリケーション構築技術の標準を鑑みるに、受け入れ難い条件設定である。その理由を次に述べる。

3.1 セッションハイジャック攻撃の可罰性

ブラウザの画面上にユーザ名とパスワードを入力してログインするタイプのアクセス制御機能を有するWebサイトにおいて、しばしば次のようなURLを目にすることがある。

http://example.com/foo.cgi?sessionid=c62ae61b35b70c8c

「sessionid=」以降に書かれた文字列は、「セッションID」と呼ばれ、

(略)

そのような攻撃が可能となる原因は、セッションIDが漏洩したことにあるのであって、サーバー側にプログラムや設定上の瑕疵があるわけではない21し、ましてや、「拙劣な」アクセス制御方式だということにもならない。(略)

脚注21: URLにセッションIDを含める構成方式は、Webブラウザが「Referer:」機能によって第三者サーバーへIDを漏らしてしまう場合があるという点で、適切でない構成であるということもできるが、サイトの全体構成次第で、適切といえる場合もある*10ので、それ自体に瑕疵があるとはいえない。

(略)

もし、単純に「GETメソッドによるアクセスならば不正アクセス行為に当たらない」とする判断基準を採用すると、プログラムに瑕疵のないアクセス制御機能さえ、同法の保護対象とならない場合がある(URLにセッションIDを載せるWebサイトに対するセッションハイジャック攻撃が処罰されない)ことになってしまうのであり、この基準は不適切である。

高木浩光, “不正アクセス行為の2つの文理解釈について”, 情報ネットワーク・ローレビュー, 第5巻1号, p.36

つまり、一方で、「プログラムないし設定上の瑕疵があった」という前提状況が、不正アクセス行為と見なす根拠のひとつとされているところ、他方で、「GETメソッドによるアクセスならば不正アクセス行為に当たらない」との基準で判断するのは、それは逆に、瑕疵のないシステムに対してさえ、セッションハイジャック攻撃が不正アクセス行為に当たらないということになってしまうのであるから、そのような基準は不適切であり、つまり要するに、瑕疵の有無で不正アクセスか否かを切り分けられるものではない――ということを主張している。

そのため、セッションハイジャック攻撃がセキュリティホール(プログラムないし設定上の瑕疵)攻撃型ではないことを示すのが重要となっている。

なお、この論文の本題は、そこではなく、何が2号および3号不正アクセス行為に当たるかの既存の判断の矛盾を示すことと、それを回避する解釈ついての検討となっている。

*1 編集委員の先生方にはご迷惑をおかけし、たいへんお世話になりました。

*2 予稿集の原稿では上限ページ数の都合から短縮版としていたところ、この論文は元原稿から書き起こした。(発表時スライドは元原稿の文脈に沿っている。)今回の論文は、発表時の質疑応答で気づかされた点など、いくつかの論点を元原稿に追加したもの。

*3 ここで言う「セッションハイジャック攻撃」とは、利用権者がログイン中の状態のときに、攻撃者がその状態を「乗っ取って」利用する攻撃を指す。利用権者がログインしていなくても直接になりすましアクセスができてしまう欠陥(たとえば、ユーザIDを送信するだけでそのユーザになりすましてアクセスできるなどの欠陥)のあるサイトにおける、そのようななりすましアクセスはセッションハイジャックとは呼ばない。典型的には、ログイン時にサーバにより発行されるセッションID(ログインごとに生成される予測困難な受付番号)を何らかの方法で知得して、それを窃用して当該サーバになりすましアクセスする手法(Webアプリケーションの場合)がこれに該当する。その他、FTPの利用における control connectionに対する TCP session hijackingなども該当する。

*4 Session Fixationの問題を避けるために、セッションIDの発行はログイン後に行った方がよいが、ログイン前から発行されたセッションIDをログイン後にも継続して使用する(セッション追跡のために)という構成の場合もある。

*5 実際には、実装上は、ログイン後であれ、単にランダムにセッションIDを作成して、それをユーザIDと関連付けるだけであるから、「識別符号を用いて」作成しているわけではないが、識別符号が入力されなければ作成されなかった符号であるといった理屈から、法解釈上の観念的な見方として、「識別符号を用いて当該アクセス管理者の定める方法により作成される符号」と解釈されることもあり得るかもしれない。

*6 ではなぜ、初めから2条2項でそのように定義しなかったかという疑問が生ずるが、それは、4条(他人の識別符号を無断で第三者に提供する行為)で、2条2項の定義を必要としているからであろう。

*7 何らかの原因で攻撃者に知られてしまった識別符号で攻撃者にアクセスされたときに、なりすましアクセスを許すことになるのが正常であるのと同様に。

*8 東京地裁平16特(わ)752号 平成17年3月25日刑事10部判決、判例時報1899号, pp.155-161

*9 大橋充直, “検証 ハイテク犯罪の捜査 情報漏えい犯罪の新判例(ACCS事件)”, 捜査研究647号 pp.67-81 および 同648号 pp.67-74

*10 外部サイトへのリンクが一切存在しないサイトで、かつ、SSLを使用していないサイトなど。

本日のリンク元 TrackBack(0)

最新 追記

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
最新 追記