アカウント名:
パスワード:
もしも攻撃者がクッキーを盗み出したとするならば、この時点で法の定める不正アクセスです。クッキーはユーザIDとパスワードの代替物でありそのことをもって個人を特定しているわけですから。不正に鍵を入手した段階でアウト。
不正アクセス行為の禁止等に関する法律 第三条(不正アクセス行為の禁止) 第一項 何人も、不正アクセス行為をしてはならない。 第二項 前項に規定する不正アクセス行為とは、次の各号の一に該当する行為をいう。 一 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為(当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。) 二 アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報(識別符号であるものを除く。)又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為(当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。) 三 電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為 第四条(不正アクセス行為を助長する行為の禁止) 何人も、アクセス制御機能に係る他人の識別符号を、その識別符号がどの特定電子計算機の特定利用に係るものであるかを明らかにして、又はこれを知っている者の求めに応じて、当該アクセス制御機能に係るアクセス管理者及び当該識別符号に係る利用権者以外の者に提供してはならない。ただし、当該アクセス管理者がする場合又は当該アクセス管理者若しくは当該利用権者の承諾を得てする場合は、この限りでない。
クッキーのやりとりの仕組みはアクセス制御機構の一部。 未知のXSS脆弱性によりやりとりの仕組みの穴をつき クッキーを盗んだら既にアウト。
XSS で cookie を盗むのはサーバからではなく、クライアントであるブラウザからであり、ブラウザに法が言うところのアクセス制御機能があるわけではないので、不正アクセス禁止法にはふれない。
さら
クライアントにアクセス制御機構がないなんて信じがたいですねぇ。
信じがたいも何も、どこにユーザ名とパスワードによるクッキーの保護があるのかと。
この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されて
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
主張の解読を試みる (スコア:1, 興味深い)
不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
#HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
> 「CGIというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
実装上の脆弱性は全て保護対象外という主
解説(Flamebait? -1) (スコア:3, 参考になる)
>不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
>#HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
全て保護対象外です。
原則、HTTPやSMTP、anonnymous FTPはアクセスを識別符号によって制限していないからです。
>> 「CGIというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
>実装上の脆弱性は全て保護対象外という主張のようですね。
Re:解説(Flamebait? -1) (スコア:2, 興味深い)
アクセス制御をしている「ツモリ」(主観)の
運営者、製造者がいたとします。
しばしば、SQLinjectionやXSSは【非常に単純な】
設計上もしくは実装上の漏れです。素人でも見つけられますね。
このような単純ミスの場合には、ディレクトリ丸裸と同様に
アクセス制御機構が働いていたとは見做しにくいものです。
CGIやWebアプリを作成した時に、未知のXSS脆弱性や
未知のSQLinjectionを作りこんでしまった、、ということは
考えられません。タネはとっくの昔に割れているものです。
設計者や製造者、運営者は、既知の基本的なセキュリティー上
の防止策を実装
| 慈愛こそ慈愛
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脆弱性によりやりとりの仕組みの穴をつき
クッキーを盗んだら既にアウト。
クッキーを使って、さらに個人情報を盗んだらもっとアウト。
ダブルプレー。
【。。。をし得る状態にさせる行為 】
というところがポイント。ここでワンナウト。
。。。をし得るだけでなく、したら、ツーアウト。
篠沢教授に10000点。
| 慈愛こそ慈愛
Re:解説(Flamebait? -1) (スコア:0)
Re:解説(Flamebait? -1) (スコア:0)
>> 違います。
> 違いません。
どっちが違ってるか知らないが、それぞれ根拠を示すがよい。
われらAC群体が見守ってあげよう。
Re:バカだけどIDで。 (スコア:0)
XSS で cookie を盗むのはサーバからではなく、クライアントであるブラウザからであり、ブラウザに法が言うところのアクセス制御機能があるわけではないので、不正アクセス禁止法にはふれない。
さら
Re:バカだけどIDで。 (スコア:1)
サーバとは異なる実装をしていますが、やはり「誰かが」「その権限で」
使っていると思われてなりません。
| 慈愛こそ慈愛
Re:バカだけどIDで。 (スコア:0)
信じがたいも何も、どこにユーザ名とパスワードによるクッキーの保護があるのかと。
この法律において「アクセス制御機能」とは、特定電子計算機の特定利用を自動的に制御するために当該特定利用に係るアクセス管理者によって当該特定電子計算機又は当該特定電子計算機に電気通信回線を介して接続された他の特定電子計算機に付加されて