アカウント名:
パスワード:
同協会の web にある会員向のサービスでは、認証の際に、IDとパスワードがCookieに保存される。クロスサイトスクリプティング脆弱性を利用することで、ID、パスワードを奪取することが可能になっていた。 なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページ
同協会の web にある会員向のサービスでは、認証の際に、IDとパスワードがCookieに保存される。クロスサイトスクリプティング脆弱性を利用することで、ID、パスワードを奪取することが可能になっていた。
なお、同協会からは、下記のメッセージをいただいた。 「ご指摘いただいた点に関しては、早急に対処させていただきました。 会員専用のページ
んーと、BASIC認証を使いたがらない状況があるから、かな?
認証にクッキーを使おうとする理由は、眠い頭で考えて a) セッション管理ができる b) BASIC認証ダイアログの*見ため*を心配する人がいる を思いつくんですが他になにかあったっけ。
d)ルートディレクトリは認証なし。/protect/ディレクトリ以下と/cgi-bin/protect/ディレクトリ以下には認証が必要という場合、BASIC認証だと2回認証が必要だけど、
「2回認証が必要」というのはどういう意味ですか? ディレクトリが違っても、同じサーバの中で、しかも authorization の realm (正しい用語を知りません。 Apache でいう AuthName ディレクティブ [apache.org]で指定す
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回認証 が必要だけど、
「2回認証が必要」というのはどういう意味ですか?ディレクトリが違っても、 同じサーバの中で、しかも authorization の realm (正しい用語を知りません。 Apache でいう AuthName ディレクティブ [apache.org]で指定する文字列のこと) が同一なら、ブラウザは1度しかユーザ名とパスワードを聞かないと思うのですが。 www1.example.com と www2.example.com のようにサーバ名が違う状況でなら、 たぶんおっしゃるような違いがあるの
鵜呑みにしてみる?ふっふっふ。鵜呑みにしませぬぞ。
鵜呑みにしてみる?
ふっふっふ。鵜呑みにしませぬぞ。
それが安全です :) なお、シグニチャはいつ変えるかわからないのでご注意。
領域名(realm の値というのか..?)
おっしゃるように、日本語では「領域(名)」と呼ぶようですね。学びました。ありがとうございます。
もちろん、調べたクライアントのすべてがそのような挙動を示しただけで、 これが正しい挙動かどうかは判断しかねます。
仕様のほうを調べたので書いておきます。 ブラウザがどういう場合にユーザにユーザ名とパスワードの入力を求めるかについて、 RFC2617 [zvon.org] では、ページ A とページ B の「protection domain」が異なるならば、ページ A のユーザ名とパスワードをページ B にアクセス
この点は cookie だと有効範囲を domain と path で指定できるので安全でしょう。
プロバイダの Web サーバなどで http://www.example.com/~user1234/ のような URL になっているページで基本認証を使うと、他のユーザがユーザ名とパスワードを盗めることになると思います。
普通のCGIでは、CGIプログラム側に渡されるのはユーザ名だけなので、パスワードが盗まれることはありませんね。同様にアクセスログについてもそうです。
残念ながら、cookieのpathによる有効範囲の制限はJavaScriptの仕様によって破綻しているようです。
CGI設置とアクセスログの閲覧が許されていないサーバでは、Basic認証が有効ではないかと考えられます。
validate しようとしたページが基本認証でアクセス制限をしていても、ユーザ名とパスワードを Validator に対して入力すればちゃんと validate できるというのが
実物を確認できませんが、Validatorに対してパスワードを入力するのなら、その後はそのValidatorがユーザエージェントとして目的サーバにパスワード付きでアクセスするのだから、そういうことができるのは当然のことで、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
/.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)
「2回認証が必要」というのはどういう意味ですか? ディレクトリが違っても、同じサーバの中で、しかも authorization の realm (正しい用語を知りません。 Apache でいう AuthName ディレクティブ [apache.org]で指定す
鵜呑みにしてみる?
Re:足元といえば (スコア:1)
Re:足元といえば (スコア:1)
それが安全です :) なお、シグニチャはいつ変えるかわからないのでご注意。
おっしゃるように、日本語では「領域(名)」と呼ぶようですね。学びました。ありがとうございます。
仕様のほうを調べたので書いておきます。
ブラウザがどういう場合にユーザにユーザ名とパスワードの入力を求めるかについて、 RFC2617 [zvon.org] では、ページ A とページ B の「protection domain」が異なるならば、ページ A のユーザ名とパスワードをページ B にアクセス
鵜呑みにしてみる?
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 が有効なら、これを使うと盗めるのではないかと思いますが、たしかデフォルトでは無効だったような気がします。
鵜呑みにしてみる?