アカウント名:
パスワード:
同協会の web にある会員向のサービスでは、認証の際に、IDとパスワードがCookieに保存される。クロスサイトスクリプティング脆弱性を利用することで、ID、パスワードを奪取することが可能になっていた。 なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページ
同協会の web にある会員向のサービスでは、認証の際に、IDとパスワードがCookieに保存される。クロスサイトスクリプティング脆弱性を利用することで、ID、パスワードを奪取することが可能になっていた。
なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページ
んーと、BASIC認証を使いたがらない状況があるから、かな?
認証にクッキーを使おうとする理由は、眠い頭で考えて a) セッション管理ができる b) BASIC認証ダイアログの*見ため*を心配する人がいる を思いつくんですが他になにかあったっけ。
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/ protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証 が必要だけど、 「2回認証が必要」というのはどういう意味ですか?ディレクトリが違っても、 同じサーバの中で、しかも authorization の realm (正しい用語を知りません。 Apache でいう AuthName ディレクティブ [apache.org]で指定する文字列のこと) が同一なら、ブラウザは1度しかユーザ名とパスワードを聞かないと思うのですが。 www1.example.com と www2.example.com のようにサーバ名が違う状況でなら、 たぶんおっしゃるような違いがあるのだろうと思います。 鵜呑みにしてみる?
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/ protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証 が必要だけど、
鵜呑みにしてみる?ふっふっふ。鵜呑みにしませぬぞ。
鵜呑みにしてみる?
領域名(realm の値というのか..?)
もちろん、調べたクライアントのすべてがそのような挙動を示しただけで、 これが正しい挙動かどうかは判断しかねます。
この点は cookie だと有効範囲を domain と path で指定できるので安全でしょう。
プロバイダの Web サーバなどで http://www.example.com/~user1234/ のような URL になっているページで基本認証を使うと、他のユーザがユーザ名とパスワードを盗めることになると思います。
普通のCGIでは、CGIプログラム側に渡されるのはユーザ名だけなので、パスワードが盗まれることはありませんね。同様にアクセスログについてもそうです。
残念ながら、cookieのpathによる有効範囲の制限はJavaScriptの仕様によって破綻しているようです。
CGI設置とアクセスログの閲覧が許されていないサーバでは、Basic認証が有効ではないかと考えられます。
validate しようとしたページが基本認証でアクセス制限をしていても、ユーザ名とパスワードを Validator に対して入力すればちゃんと validate できるというのが
実物を確認できませんが、Validatorに対してパスワードを入力するのなら、その後はそのValidatorがユーザエージェントとして目的サーバにパスワード付きでアクセスするのだから、そういうことができるのは当然のことで、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
/.j的セキュリティニュース (スコア:2, おもしろおかしい)
足 [srad.jp] 元 [srad.jp]。
足元といえば (スコア:2, 参考になる)
Re:足元といえば (スコア:0)
> パスワードはブラウザに保存機能があるんだし。
> どうしてこうクッキーを使いたがるのかなあと。
んーと、BASIC認証を使いたがらない状況があるから、かな?
BASIC認証で良いよって言って貰うと楽なんだけどね。
Re:足元といえば (スコア:1)
認証にクッキーを使おうとする理由は、眠い頭で考えて
a) セッション管理ができる
b) BASIC認証ダイアログの*見ため*を心配する人がいる
を思いつくんですが他になにかあったっけ。
Re:足元といえば (スコア:2, 参考になる)
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、cookieならルートディレク
Re:足元といえば (スコア:1)
www1.example.com と www2.example.com のようにサーバ名が違う状況でなら、たぶんおっしゃるような違いがあるのだろうと思います。
鵜呑みにしてみる?
Re:足元といえば (スコア:1)
試したら確かに 領域名(realm の値というのか..?)が同一であれば
一度の入力で、それ以後は入力の必要はありませんでした。
サーバが違うとどうなるかっていうのはやってません。めんどくさくて。^^;
..とか、書こうとしたがやっぱ実験しました。
192.168.1.x と www14.cds.ne.jp でやってみたら同じ領域名でも2回入力が
必要ですね。
w3m on Linux, mozilla 1.1b on win2k, IE5.5 on win2k で実験しました。
もちろん、調べたクライアントのすべてがそのような挙動を示しただけで、
これが正しい挙動かどうかは判断しかねます。
# 仕様書見れや>自分
# # 見たんだがわからなかったのは秘密
Re:足元といえば (スコア:1)
ブラウザがどういう場合にユーザにユーザ名とパスワードの入力を求めるかについて、 RFC2617 [zvon.org] では、ページ A とページ B の「protection domain」が異なるならば、ページ A のユーザ名とパスワードをページ B にアクセスするときに自動的に使ってはいけない、とだけ規定しています(1.2 節 [zvon.org])。
基本認証の場合、サーバ名が同じで領域名も同じ場合だけ、同じ protection domain に属すると見なされます(正確には、「サーバ名が同じ」ではなく「root URL が同じ」と定められています。言い換えれば、プロトコルやポート番号も同じでないといけません)。
よって、プロバイダの Web サーバなどで http://www.example.com/~user1234/ のような URL になっているページで基本認証を使うと、他のユーザがユーザ名とパスワードを盗めることになると思います。この点は cookie だと有効範囲を domain と path で指定できるので安全でしょう。基本認証と cookie で cookie のほうがよい点の一つということになります。
(と書いておきながら、ぼくはそんなこと今まで知らなかったので、まったく自信がありません。知っている人は知っていることなのでしょうか。それとも、ぼくは何か間違えている??)
ダイジェスト認証はブラウザの対応状況が問題ですが、 cookie のように protection domain をより細かく指定できるようです。基本認証とダイジェスト認証の違いはパスワードを平文で送るかどうかだけだと思っていたので、そうではないと知って少し驚きました。
鵜呑みにしてみる?
Re:足元といえば (スコア:1)
Re:足元といえば (スコア:1)
普通のCGIでは、CGIプログラム側に渡されるのはユーザ名だけなので、パスワードが盗まれることはありませんね。同様にアクセスログについてもそうです。
Re:足元といえば (スコア:1)
せっかく cookie には有効範囲を設定できるようになっているのに、 Javascript のほうは「身内ページ」の判定をサーバ名(だかサーバ名+スキーム名+ポート名)で行っているので、危険だという理解で合っているでしょうか。
そう考えると、今のところ「管理者が違うところは(name-based virtual host を使うなどして)違うサーバ名にする」という方針にしたほうが安全なのでしょうか。 CGI プログラムを他のユーザが設置できなければ安全というのはそうだと思います。
調べている時間がないのですが、 CGI プログラムを置いたら、パスワードまで取れると思いますよ。 CGI プログラムで基本認証の delegation をしている例は実際に世の中にありますし。
「基本認証の delegation」という言葉は合ってないかもしれないのですが、適切な表現が見つからない上、説明している時間がありません。ごめんなさい。 W3C HTML Validator [w3.org] で validate しようとしたページが基本認証でアクセス制限をしていても、ユーザ名とパスワードを Validator に対して入力すればちゃんと validate できるというのが、ぼくが「基本認証の delegation」という言葉で表現したい動作ですが、これでご理解いただけますか?(しかも validator.w3.org は今落ちているみたいだ……。)
鵜呑みにしてみる?
Re:足元といえば (スコア:1)
Re:足元といえば (スコア:1)
以下では Apache に限定します。調べてみたら、 Apache では普通 Authorization ヘッダの内容を CGI プログラムに渡さないようになっているそうです。なので、ぼくが危惧していたような問題は起きないみたいです。
ぼくが見たケースでは、このあたり(つながらないので Google のキャッシュ) [google.com]に書かれている工夫が使われていたようです。もし mod_rewrite が有効なら、これを使うと盗めるのではないかと思いますが、たしかデフォルトでは無効だったような気がします。
鵜呑みにしてみる?