アカウント名:
パスワード:
青柳裁判長は「問題のファイルには、FTPサーバからIDとパスワードを入力してアクセスするのが通常。CGI経由のアクセスは、FTP上のアクセス制御を回避した不正アクセス行為にあたる」と認定した。
最近のサーバーは未知のプロトコルと話できるのか
もし明示の必要なく「通常のアクセス手段」を後出しできるなら、適当なデータをHTTPサーバで公開しておいて、閲覧に来た人を片っ端から「キミキミ、このファイルはFTPでアクセスしないと不正アクセスだよ」と脅す事も可能?
文面を見る限りそうとしか見えませんが。 過去にチート関連裁判で製作側の意図どおりプレイしなきゃ違法って言ってのける人たちですから、この判決を見てもさもありなんとしか思えないけど。 そうなると、と
有罪かどうかはともかく、判決文がどっかおかしいのは間違いないと思いますけどね。
2 この法律において「識別符号」とは、特定電子計算機の特定利用をすることについて当該特定利用に係るアクセス管理者の許諾を得た者(以下「利用権者」という。)及び当該アクセス管理者(以下この項において「利用権者等」という。)に、当該アクセス管理者において当該利用権者等を他の利用権者等と区別して識別することができるように付される符号であって、次のいずれかに該当するもの又は次のいずれかに該当する符号とその他の符号を組み合わせたものを
枝葉であまり意味の無いの話だけど >1.不用意なアクセスからデータを保護する >2.アクセス権を持つ人物を特定する 適切に管理されたURLにもいえることですね。
ちなみにどのブラウザーですか? そしてそれって仕様として正しいの?
ちなみに、それが正しい動作なら使いしてURL使えばよいことやん。
バグで漏れるならパスワードでも一緒でしょう。
S/使いしてURL/使い捨てURL/ 外部に漏れるならもれると言う前提で管理すればよいだけでしょう。
>>>ちなみにどのブラウザーですか? >>>そしてそれって仕様として正しいの? に答えられないから、相手を貶めて誤魔化す手段への変更ですね
仕様かどうか聞かれて慌てふためき
remote exploitをつついてサーバ乗っ取るのはsshdかtelnetdの認証回避だから不正アクセス禁止法違反ともいえる...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
別のデーモンで認証していればいいらしい (スコア:2, おもしろおかしい)
すごいな~,remote exploitをつついてサーバ乗っ取るのはsshdかtelnetdの認証回避だから不正アクセス禁止法違反ともいえるわけだ.
サイバーノーガード強し…
Re:別のデーモンで認証していればいいらしい (スコア:5, すばらしい洞察)
件のデータは、「通常のアクセス方法は、FTPを使用するものとする」とどこかに明示されていたんでしょうか?
もし明示の必要なく「通常のアクセス手段」を後出しできるなら、適当なデータをHTTPサーバで公開しておいて、閲覧に来た人を片っ端から「キミキミ、このファイルはFTPでアクセスしないと不正アクセスだよ」と脅す事も可能?
# 誰か完膚なきまでに否定してくれませんか…
Re:別のデーモンで認証していればいいらしい (スコア:1)
最近のサーバーは未知のプロトコルと話できるのか
Re:別のデーモンで認証していればいいらしい (スコア:2, すばらしい洞察)
ただ、あの文面だと確かに、管理者の想定外アクセスは不正アクセスだとか、FTPで認証しとけばHTTPで認証しなくてもOK、ノーガードにお墨付き、という意味に見えるので、裁判所ももう少し判決文の文面を練りこむべきではなかったかと。
そうしないと、日本のIT系技術はどんどん萎縮するばかりではないかと。
Re:別のデーモンで認証していればいいらしい (スコア:1)
ただこの場合判断するのは、送り込んだ時点の行為で既に不正アクセスだと思うんですけどねぇ
送り込んだだけだと犯罪にならないのかな?
Re:別のデーモンで認証していればいいらしい (スコア:1)
>送り込んだ時点の行為で既に不正アクセスだと思うんですけどねぇ
これだと思うから
Re:別のデーモンで認証していればいいらしい (スコア:1)
今回のは管理者がアクセスを許可したプログラムに対して実施されているのだから、上記の行為をふまえて判断するのはどうかなぁ~って感じだと思います
Re:別のデーモンで認証していればいいらしい (スコア:1)
それだと、ウィルスを送り込んだ人だけが対象になり、便乗してバックドアを使いに来た人たちが考慮されていません。
でもそこは「管理者の想定しないアクセス」と認めて欲しいワケで…むむ、なんかややこしくなってきた
Re:別のデーモンで認証していればいいらしい (スコア:0)
Re:別のデーモンで認証していればいいらしい (スコア:0)
Re:別のデーモンで認証していればいいらしい (スコア:0)
文面を見る限りそうとしか見えませんが。
過去にチート関連裁判で製作側の意図どおりプレイしなきゃ違法って言ってのける人たちですから、この判決を見てもさもありなんとしか思えないけど。
そうなると、と
Re:別のデーモンで認証していればいいらしい (スコア:0)
おお、これぞ夢にまで見た情報家電による情報家電のためのユビキタス社会だ!
と。
Re:別のデーモンで認証していればいいらしい (スコア:0)
話を一般化し過ぎ。
Re:別のデーモンで認証していればいいらしい (スコア:1)
仮にCGIバグが存在しなかったとしても、個人情報の記録されたファイルが認証機構のないhttpプロトコルでアクセス可能な場所に格納されていたことに変わりはないわけで、アクセスされたこと自体に違法性を認める判決はおかしいというのが元コメントの主張なのでは?
有罪かどうかはともかく、判決文がどっかおかしいのは間違いないと思いますけどね。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:別のデーモンで認証していればいいらしい (スコア:0)
/virtual/cgi-data
/virtual/www
/virtual/www/cgi-bin
/virtual/www/cgi-bin/csvmail
ぶっこ抜かれたデータは/virtual/cgi-data の中な。
Re:別のデーモンで認証していればいいらしい (スコア:0)
何を今更。しっかりと”httpプロトコル
Re:別のデーモンで認証していればいいらしい (スコア:0)
#都合が悪いからに決まってるんだろうけどさ
Re:別のデーモンで認証していればいいらしい (スコア:0)
ちがうでしょ (スコア:0)
「CGIが介在しないとhttpプロトコルではアクセスできない場所」の誤りですね。
Re:別のデーモンで認証していればいいらしい (スコア:0)
CGIが認証機構なんじゃないの?
そこのバグを利用したということで。
あとは推測しやすかったpasswordだったってこと。
#CGIを使った認証は認めないという立場もあるかもしれんが
Re:別のデーモンで認証していればいいらしい (スコア:1)
#Botもすべてまずいんだよね・・・今回の判決は
#CGIはアプリ鯖のひと機能でしかないんだが
Re:別のデーモンで認証していればいいらしい (スコア:0)
別に無視してもしなくても同じだからだよ。
実際「認証機構のないhttpプロトコルでアクセス可能」だったでしょ?
Re:別のデーモンで認証していればいいらしい (スコア:0)
>>「個人情報の記録されたファイルが認証機構のないhttpプロトコルでアクセス可能な場所に格納されていた」わけではないよ
この場合の「認証機構のない」がかかるのは「場所」だ。
Re:別のデーモンで認証していればいいらしい (スコア:0)
>この場合の「認証機構のない」がかかるのは「場所」だ。
それじゃ余計変だ(笑
そのあとの
>/virtual/cgi-data
>/virtual/www
>/virtual/www/cgi-bin
>/virtual/
Re:ちがうでしょ (スコア:0)
それが何? いずれにしても httpプロトコルでアクセスできる場所ですね。
Re:ちがうでしょ (スコア:0)
・認証があると考えるなら、何が(どういったことをすれば)認証機構?
Re:ちがうでしょ (スコア:0)
ちなみに不正アクセス禁止法の上での「アクセス制御機能」だったら
Re:ちがうでしょ (スコア:0)
一 当該アクセス管理者によってその内容をみだりに第三者に知らせ
てはならないものとされている符号
によるアクセスではあるでしょうね。
#推測されやすく、且つ、通ってしまったってだけのことで。
Re:ちがうでしょ (スコア:0)
> 一 当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号
これに則るのであれば「第三者に対して非公開であり、アクセス管理者により通知されなければわからないURL」は、「識別符号」と解釈できます。
一方、
> 3 この法律において
Re:ちがうでしょ (スコア:0)
「符号」は単に秘密の情報ではなく、何かを確認するための情報です。
秘密にする必要のある場合もあれば、公開してよい物もあります。
CRCは情報が正しいかどうかを確認するための符号です。これは公開さ
Re:ちがうでしょ (スコア:0)
URLの一部にもなりうるCGIパラメータなんかはまんま符号ともみなせるでしょう。
そもそも、その文字列(符号)がどんな役割を持つか、どういった扱いで処理すれば、
運用すれば符号である/ないのきちんとした条件が明記されているんでしょうか?
Re:ちがうでしょ (スコア:0)
問題は「秘密のURL」によるアクセスが
> 当該特定利用の制限の全部又は一部を解除するもの
という「アクセス制御機能」になるのかどうかじゃないですかね。
Re:ちがうでしょ (スコア:0)
> という「アクセス制御機能」になるのかどうかじゃないですかね。
これはなり得るんじゃないでしょうか。ある特定のURLを知っている人であればそのページを「表示」することが可能であり、そのURLを知らない人であればページを表示することはできません。従って、秘密のURLというのは、ページを表示するという機能に対する制限機能を持つ識別符号と考えることができます。
たとえば
1. URL中にユーザーIDとパスワードを含めるタイプの認証方式(http://username:password@server/resource)
2.
Re:ちがうでしょ (スコア:0)
秘密のURLがあって、そこへREQUESTが来たとします。
しかし、URLを打ち込んだ何者かを特定することは
これだけではできません。従って、「何者」かがURLを
知っていてもよい人物なのか知る手立てはありません。
これだけでは「符号」と呼ぶことはできません。
CGIパラメータは符号になり
Re:ちがうでしょ (スコア:0)
そもそも知っていて良い人物かどうかどうやって確認するんですか?
Re:ちがうでしょ (スコア:0)
Passwordが符号から外れるというのは、考えにくい事態です。
特定個人だけが知っているべきなのに第三者に知られてしまったとか
PasswordがPasswordの機能を果たせ
Re:ちがうでしょ (スコア:0)
>これだけではできません。従って、「何者」かがURLを
>知っていてもよい人物なのか知る手立てはありません。
URLではなくPasswordでも同じことは言えますよね?
その上で、
>そもそも知っていて良い人物かどうかどう
Re:ちがうでしょ (スコア:0)
>URLではなくPasswordでも同じことは言えますよね?
認証なしのURLが存在すると言うことは、
WWWで公開されていると言うことです。
公開されている情報にアクセスしてくる人物を
特定する手段はありません。
特定するためには、管理手段
Re:ちがうでしょ (スコア:0)
わかりますよ。Passwordが適切に管理されていることが前提です。
これは、URLに関しても、特定の人にしかURLを教えないように「適切に管理」すれば同じことではないでしょうか?
どこからもリンクされて
Re:ちがうでしょ (スコア:0)
可能でしょうね。
しかし、同時に、不特定からのアクセスを制限することもできませんし
不特定からのアクセスがないことを保証するものでもありません。
このような状態は「適切に管理」されているとは言えません。
>「推測」してURLを入力すれば表示できる、ということなら、パスワードについてもまったく同
Re:ちがうでしょ (スコア:1)
管理するという意味だとしたら、ソフトウェアの仕様上の制約から
そのような管理は実現が難しいと言わざるを得ません。
まず HTTP リクエストヘッダの referer 行の問題があります。
ブラウザに新しい URL をタイプした場合でも、その直前に表示した
ページの URL を referer として送ってしまうブラウザは珍しくありません。
そのようにして、関係のないサーバの管理者が「秘密の」URL を知ってしまう
リスクがあります。それに対してパスワードは、このように安易には漏れない
ように一応考慮されています。
またプロクシサーバのログ保存に際しても、常識的な実装ではパスワードが
見えるようにすることはありませんが、URL はそれほどには秘密扱いして
いません。従って、パスワードと URL を同一視することには無理があります。
Re:ちがうでしょ (スコア:1)
まず、パスワードと URL という、ソフトウェアによって明らかに区別して
扱われている二者を無理矢理同一視すると何が嬉しいのか、説明してもらわ
ないとね。 日本語として意味不明です。
Re:ちがうでしょ (スコア:1)
やっぱり何かが嬉しいんだろうか? と首をひねる以外にありませんな。 この部分も同様。「使い捨てURL」と書くだけなら簡単ですが、
実際にはどの契機で URL を無効化すれば良いのか、また、無効
化した場合には新しい URL をユーザに知らせないと不都合が出
そうだがその通知手段をどうするか。という問題があります。
さらに言わせてもらえば、そこまでやるのは HTTP over SSL み
たいな一般的な代替手段と比べて費用対効果が期待出来るのか、
という疑問すらあります。
どうも、HTTP や HTML を深く理解している人ならば出てくる筈の
ない論理、のように見えてしまって仕方ありません。
Re:ちがうでしょ (スコア:1)
とりあえず ftp://ftp.netscape.com/pub/ 以下のブラウザを
全部調べなさい。ただし、英語と日本語以外は免除してあげよう。
大きな口を叩くのはそれからにしなさい。
Re:ちがうでしょ (スコア:1)
いい加減な前提が崩された、どこぞの AC 君ではありますまいか。
断っておくと、referer を漏らすブラウザの存在は、ウェブサーバ
のログを調べていて掴みました。けっこう狭い範囲に存在する事は
分かりましたが、関心がないのでバージョン等は確認していません。
そもそも、URL がパスワード代わりに使える場合がある、などという
作り話を広めたり維持することには関心がありませんので。
ブラウザが URL を漏らすというリスクは、実は将来リリースされる
ブラウザに関しても存在します。パスワードを漏らすのとは違って、
第一級の「バグ」とは認識してもらえないかも知れません。漏らさない
のが「仕様」だと言い切るだけの文書の裏付けがなく、パスワードのよ
うに、社会通念による保護が期待出来る訳でもありません。
これらの事情を認識せず、URL とパスワードを同一視出来る場合がある、
などという愚か者がもし居るとしたら、プロフェショナルとしてのおつ
きあいは避けるに越したことはないでしょう。
Re:別のデーモンで認証していればいいらしい (スコア:1)
なのにHTTPで取れたんだろうね?認証なしで?
それならこの裁判自体意味がないと?
被告が実はFTPで接続したって言いたいのか?
#GCIはHTTP鯖上で動いてます、プロトコルとプログラムの違いわからんのかな?
Re:別のデーモンで認証していればいいらしい (スコア:0)
通用門からの入場は正面ゲートの入場料支払いを回避した不正入場行為にあたる」
なら理解できるのに…
Re:別のデーモンで認証していればいいらしい (スコア:1)
「問題の博覧会場には正面ゲートから料金を払って入場するのが通常。
業者が勝手に作り運営者が気づかなかった別の見つかりづらい正面ゲートを見つけてはいると不正入場行為にあたる」
になると思うんだけど?HTTPっちゃ正面ゲートだよ
まぁ意味不明だなこの文章じゃ(w
Re:別のデーモンで認証していればいいらしい (スコア:0)
まあ、例えること自体、あまりいいこっちゃないでしょうけど、
・「鍵がかかっているとこに勝手に入ってはいけません」という法律があるとする。
・博覧会場の
Re:別のデーモンで認証していればいいらしい (スコア:1, すばらしい洞察)