アカウント名:
パスワード:
もしも攻撃者がクッキーを盗み出したとするならば、この時点で法の定める不正アクセスです。クッキーはユーザIDとパスワードの代替物でありそのこと
不正アクセス行為の禁止等に関する法律 第三条（不正アクセス行為の禁止） 第一項 何人も、不正アクセス行為をしてはならない。 第二項 前項に規定する不正アクセス行為とは、次の各号の一に該当する行為をいう。 一 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。） 二 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報（識別符号であるものを除く。）又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。） 三 電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為 第四条（不正アクセス行為を助長する行為の禁止） 何人も、アクセス制御機能に係る他人の識別符号を、その識別符号がどの特定電子計算機の特定利用に係るものであるかを明らかにして、又はこれを知っている者の求めに応じて、当該アクセス制御機能に係るアクセス管理者及び当該識別符号に係る利用権者以外の者に提供してはならない。ただし、当該アクセス管理者がする場合又は当該アクセス管理者若しくは当該利用権者の承諾を得てする場合は、この限りでない。
クッキーのやりとりの仕組みはアクセス制御機構の一部。 未知のXSS脆弱性によりやりとりの仕組みの穴をつき クッキーを盗んだら既にアウト。
XSS で cookie を盗むのはサーバからではなく、クライアントであるブラウザからであり、ブラウザに法が言うところのアクセス制御機能があるわけではないので、不正アクセス禁止法にはふれない。
さら
クライアントにアクセス制御機構がないなんて信じがたいですねぇ。
信じがたいも何も、どこにユーザ名とパスワードによるクッキーの保護があるのかと。
この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されて
べき論ではたしかにそうだけど、どれが既知で知ってしかるべき、というのを裁判所で明らかにできるのでしょうか？
特許のように、ここの学会誌で載っているから公知だ、と いう具合にみんなが納得できる「既知」の定義が できますかね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
主張の解読を試みる (スコア:1, 興味深い)
不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
＃HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
> 「ＣＧＩというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
実装上の脆弱性は全て保護対象外という主
解説(Flamebait? -1) (スコア:3, 参考になる)
>不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
>＃HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
全て保護対象外です。
原則、HTTPやSMTP、anonnymous FTPはアクセスを識別符号によって制限していないからです。
>> 「ＣＧＩというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
>実装上の脆弱性は全て保護対象外という主張のようですね。
Re:解説(Flamebait? -1) (スコア:2, 興味深い)
アクセス制御をしている「ツモリ」（主観）の
運営者、製造者がいたとします。
しばしば、SQLinjectionやXSSは【非常に単純な】
設計上もしくは実装上の漏れです。素人でも見つけられますね。
このような単純ミスの場合には、ディレクトリ丸裸と同様に
アクセス制御機構が働いていたとは見做しにくいものです。
CGIやWebアプリを作成した時に、未知のXSS脆弱性や
未知のSQLinjectionを作りこんでしまった、、ということは
考えられません。タネはとっくの昔に割れているものです。
設計者や製造者、運営者は、既知の基本的なセキュリティー上
の防止策を実装すべきです。
＞XSSやSQL injectionはアクセス制御機構を無効化するような
情報を入力する行為
アクセス制御機構が働いていないように作ってしまっていながら
不正アクセス禁止法で守ってもらえると考えるようならば
そのようなサイトは個人情報を扱うべきではありません。
問題になっている森川氏のCGIもとっくの昔にネタばれしている
ような古典的な注意点を守っていない点で罪が重いものです。
なんでもかんでもhiddenな属性に格納して保護しているつもり
になっているなんて、あなたの目には見えないが機械には丸見え
ですよ？と森川氏に言いたいですね。
、「ＣＧＩというものは、設定者の主観の通りにではなく、
記述された指示の通りに動くものである」とは、このことです。
アクセス制御をしている「ツモリ」（主観）ではなく、アクセス
制御機構そのものが働かないような作りこみをワザワザしていた
のですから。
さて、一方において、Webアプリ構築時点では未知であった、
ブラウザの脆弱性によりXSS脆弱性が露呈し、攻撃者が悪用
したとしたらどうでしょう。もしも攻撃者がクッキーを盗み出し
たとするならば、この時点で法の定める不正アクセスです。
クッキーはユーザIDとパスワードの代替物でありそのことを
もって個人を特定しているわけですから。不正に鍵を入手した
段階でアウト。
もうひとつの別な角度からの観点を併せて書いておきます。
とあるサイトの馬鹿げた作りこみによるXSS脆弱性を悪用。
攻撃者は犠牲者のブラウザ上にてクッキーを盗み出さずに
ニセ画面を表示するだけのXSSによるHTMLインジェクション
を行ったらどうでしょう。
例えば、株式など経済的な問題のある風評を流す目的で
エセニュースページを犠牲者に見せる事が可能です。
この場合には、攻撃者は単純な防衛もしていないサイトの
XSS脆弱性を踏み台にし、被害者を騙すことになります。
肝心なことは、このケースではユーザIDやパスワードとは
無関係であることです。いかにも悪事なのですが、現行法の
定めるところの不正アクセスではありません。別な法の運用が
はかられるべきでしょう。適切な法があるかどうかは不明です。
事例もないですし。
| 慈愛こそ慈愛
自己レス追加 (スコア:1)
おおざっぱにいえば、URL（URI）はプロトコル別にRFCで定義されて
いますし、実はRFCで未定義であって別途定めるW3Cの規定により
定められるURLもあります。
このたび問題になったCGIのだらしない作り方を詳しく調べましたら
次のようなことがわかりました。すなわち、上で書いた標準的な書法
で記述されたURLの形式で、晒された個人情報に到達できてしまうの
です。言い換えますと、代表的なブラウザであれば、あなたがブラウ
ザを起動後、このURLをアドレスバーにいれてエンターキーを叩けば
問題の個人情報がブラウザの画面に表示されるのです。
このようなシステムが果して個人情報へのアクセス制御をしていたと
言えるでしょうか？まさしくディレクトリ丸見えの延長上にあるので
す。どこか不特定多数が訪問する掲示板やフォーラムなどで、この
URLを晒したり、あるいはリンクを作っておいたりしたら、不特定
多数がアクセス制御を侵犯したことに、、ならないですよねぇ。。。
そのぐらい今回の森川氏謹製のCGIはだらしないものなのです。
ちなみにこのCGIはmethod=POSTであることは上の論議に折込済みで
す。
あ、余談ながら、この際ですので言っておきましょう。Web画面から
メールを飛ばすFORMのCGIを良く見かけます。HTMLソース表示をして
みたら宛先がform内に書いてあることが極めて多いですよね。もう、
その瞬間スパム送り放題なのですがいいのですかねぇ。これなども
異常に古典的なものなのですが。もし皆さんがたまたま使おうとした
そのようなCGIが変な作りになっていたら、作成者に是非メールで
注意してあげてください。
office氏の場合には、メールの宛先ではなく、ファイル表示パスが
FORM内に書いてあっただけですが、ヨワヨワですねぇ。
| 慈愛こそ慈愛
Re:自己レス追加 (スコア:1)
ぜんぜん話が違うような。
Re:自己レス追加 (スコア:0)
>問題の個人情報がブラウザの画面に表示されるのです。
そういう嘘を平然と書けるってのはどういう神経してるんだろうなぁ。
Re:自己レス追加 (スコア:1)
＞＞あなたがブラウ ザを起動後、このURLを
＞＞アドレスバーにいれてエンターキーを叩けば
＞＞問題の個人情報がブラウザの画面に表示されるのです。
＞そういう嘘を平然と書けるってのはどういう神経してるんだろうなぁ。
あ、これは複数の人に確認をとってあってもらっているんで
大丈夫ですよ。私のバカな法律の解釈論とは異なりましてPoCですので。(^^)
Proof of ContentなURLが実在するんです。
＞そういう嘘
という名前の予想をくつがえす反例を作ることは
しばしば予想を証明することよりも簡単です。
かたや全面戦争ですし、かたや、運が良ければ一点突破でＯＫですので。
| 慈愛こそ慈愛
Re:自己レス追加 (スコア:0)
>大丈夫ですよ。私のバカな法律の解釈論とは異なりましてPoCですので。(^^)
>Proof of ContentなURLが実在するんです。
へ～、ほ～、ふ～ん。で
Re:自己レス追加 (スコア:0)
Proof of Content
なんですか？それ？
Re:解説(Flamebait? -1) (スコア:1)
法文からすると、アクセス制限をしているところに、
人のパスワードを使って入ったり、セッションハイジャック等のなりすまし行為をすることを言うのでしょう。
単純ミスによる脆弱性をもつソフトを使ったことによって、
パスワードがばれたり、クッキーを取られたりしても、
不正アクセス行為をされたら、不正アクセス禁止法で処罰されるべきです。
重要な他人の情報を持つものは、
少なくとも既知の脆弱性をもつソフトを使うべきでないというのは、
不正アクセス禁止法とは関係なく、また別の倫理上の話でしょう。
Re:解説(Flamebait? -1) (スコア:2)
>>単純ミスによる脆弱性をもつソフトを使ったことによって、
>>パスワードがばれたり、クッキーを取られたりしても、
>>不正アクセス行為をされたら、不正アクセス禁止法で処罰される
>>べきです。
そりゃそうでしょ。 だから？
論点は、公知の脆弱性をついて情報を閲覧する行為が不正アクセス
禁止法にひっかかるかどうかでしょ？
問題は、旧来のパソコン通信や専用線による通信等で想定されていた
不正アクセス行為という定義で、現在の状態をカバーできなくなった
ことにあるんだけど。
ただ、不正アクセス法を強化するんなら、管理者などへ対する
管理責任を明確に定義して、管理放棄や管理不行き届きを処罰対象
にしてほしいね。
Re:解説(Flamebait? -1) (スコア:1)
>禁止法にひっかかるかどうかでしょ？
裏技とセキュリティホールの境界を誰が決めるんだろう。という思いがずっと引っかかっています。
Re:解説(Flamebait? -1) (スコア:0)
Re:解説(Flamebait? -1) (スコア:1)
違います。
| 慈愛こそ慈愛
Re:解説(Flamebait? -1) (スコア:1)
といっても論拠だせないでしょうから、かわりに法律を引用しておきます。
つまり、
1. 他人が所有しているパスワードを使ってはならない
2. 他人にパスワードを知らせてはならない
という簡潔な結論が導き出せるはずなのですが、どうですか？
そんなわけで、両人とも微妙に間違っていて、#580587のACさんの
「使ったとき」というのは、それだけではないという話になります。
stwo さんの間違っている点は「不正に鍵を入手した段階でアウト。」で、
アウトなのは入手した側ではなく教えた側。
ただしこの法文から見るに、意図して教えた場合に限定されるでしょう。
これでも論拠を出さない「ちがいます」の応報をしたいのなら、
日記なりでどうぞ。
Re:解説(Flamebait? -1) (スコア:0)
＞
＞違います。
違いません。
バカ？
バカだけどIDで。 (スコア:1)
＝＝＝＝
三 電気通信回線を介して接続された他の特定電子計算機（ブラウザ）が有するアクセス制御機能（サーバとの間のクッキーのやりとり機構）によりその特定利用(クッキーにより本来ステートレスなHTTPを介して通信者の同一性を保証することで特定利用可。)を制限されている特定電子計算機（サーバ）に電気通信回線を通じてその制限を免れることができる情報又は指令を入力（あらかじめ防衛することが不可能であったブラウザの未知のXSS脆弱性を悪用）して当該特定電子計算機（サーバ）を作動させ、その制限されている特定利用（個人認証用の特定のクッキーを得る）をし得る状態にさせる行為
＝＝＝＝
クッキーのやりとりの仕組みはアクセス制御機構の一部。
未知のXSS脆弱性によりやりとりの仕組みの穴をつき
クッキーを盗んだら既にアウト。
クッキーを使って、さらに個人情報を盗んだらもっとアウト。
ダブルプレー。
【。。。をし得る状態にさせる行為 】
というところがポイント。ここでワンナウト。
。。。をし得るだけでなく、したら、ツーアウト。
篠沢教授に１００００点。
| 慈愛こそ慈愛
Re:解説(Flamebait? -1) (スコア:0)
Re:解説(Flamebait? -1) (スコア:0)
>> 違います。
> 違いません。
どっちが違ってるか知らないが、それぞれ根拠を示すがよい。
われらＡＣ群体が見守ってあげよう。
Re:バカだけどIDで。 (スコア:0)
XSS で cookie を盗むのはサーバからではなく、クライアントであるブラウザからであり、ブラウザに法が言うところのアクセス制御機能があるわけではないので、不正アクセス禁止法にはふれない。
さら
Re:バカだけどIDで。 (スコア:1)
サーバとは異なる実装をしていますが、やはり「誰かが」「その権限で」
使っていると思われてなりません。
| 慈愛こそ慈愛
Re:バカだけどIDで。 (スコア:0)
信じがたいも何も、どこにユーザ名とパスワードによるクッキーの保護があるのかと。
この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されて
Re:解説(Flamebait? -1) (スコア:0)
べき論ではたしかにそうだけど、どれが既知で知ってしかるべき、というのを裁判所で明らかにできるのでしょうか？
特許のように、ここの学会誌で載っているから公知だ、と いう具合にみんなが納得できる「既知」の定義が できますかね？