アカウント名:
パスワード:
同協会の web にある会員向のサービスでは、認証の際に、IDとパスワードがCookieに保存される。クロスサイトスクリプティング脆弱性を利用することで、ID、パスワードを奪取することが可能になっていた。 なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページは、基本的には公開しても構わない内容のもので、その前提でのレベルに設定しておりました。 しかし、協会の性格から、今後は世間から期待されているレベルを理解し、対処して参ります。」
なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページは、基本的には公開しても構わない内容のもので、その前提でのレベルに設定しておりました。 しかし、協会の性格から、今後は世間から期待されているレベルを理解し、対処して参ります。」
んーと、BASIC認証を使いたがらない状況があるから、かな?
というのもあるかと。
c)多くのブラウザで、BASIC認証では明示的なログアウトができない d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、cookieならルートディレクトリでcookie吐いておけば一回で済む e)BASIC認証だと、毎回生パスワードをBASE64したものが流れるので生理的に受け付けられない:-)
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がユーザエージェントとして目的サーバにパスワード付きでアクセスするのだから、そういうことができるのは当然のことで、
e)BASIC認証だと、毎回生パスワードをBASE64したものが流れるので生理的に受け付けられない:-)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
/.j的セキュリティニュース (スコア:2, おもしろおかしい)
足 [srad.jp] 元 [srad.jp]。
足元といえば (スコア:2, 参考になる)
Re:足元といえば (スコア:2, 興味深い)
Re:足元といえば (スコア:0)
> パスワードはブラウザに保存機能があるんだし。
> どうしてこうクッキーを使いたがるのかなあと。
んーと、BASIC認証を使いたがらない状況があるから、かな?
BASIC認証で良いよって言って貰うと楽なんだけどね。
Re:足元といえば (スコア:1)
a) セッション管理ができる
b) BASIC認証ダイアログの*見ため*を心配する人がいる
を思いつくんですが他になにかあったっけ。
BASIC認証って簡単 & 便利だと思うんだけど...。
a はともかく、 b は勘弁してほしい。
# そういえばユーザの認証に証明書を使ってるサイトってまだ見たことない気が。
Re:足元といえば (スコア:2, 参考になる)
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、cookieならルートディレクトリでcookie吐いておけば一回で済む
e)BASIC認証だと、毎回生パスワードをBASE64したものが流れるので生理的に受け付けられない:-)
というのもあるかと。
HTTP/1.1でもパスワード流れるんだ・・ (スコア:3, 参考になる)
HTTP/1.0 だと生で, HTTP/1.1 だとチャレンジ+パスワードのダイジェストかと勘違いしてました。
調べてみたら確かにパスワードの Base64 ですね。他人の情報を鵜呑みにした自分が馬鹿だった。反省。
# 鵜呑みにするなよ>自分
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 が有効なら、これを使うと盗めるのではないかと思いますが、たしかデフォルトでは無効だったような気がします。
鵜呑みにしてみる?
Re:足元といえば (スコア:0)
Re:足元といえば (スコア:1)
f) アプリケーションサーバ導入したら、「cookie認証 & 使えなかったら URL 埋め込み」な設定になってる(場合によっては基本認証だと機能制限される)製品だったから。