[servlet-ml 2598] URL 認証

["TAKAGI, Hiromitsu" <takagi@etl.go.jp>]

On Wed, 18 Oct 2000 15:32:44 +0900
"Yasuda,Tetsu" <tetsu@ktb.netwk.ntt-at.co.jp> wrote:
> 
> > 盗聴されなくても、Refererで漏れます。
> > HTTPS（SSL）を使っていても、Refererで漏れます。
> > この点でもその方法はダメです。
> 
> SSLを使っていて、Refererがもれる、というのはどう言う意味でしょうか。
> SSLはHTTP Requestのすべてを暗号化してしまうので漏れることは無いと思います
> が。

「Refererが漏れる」ではなく、「Refererで漏れる」です。
Refererが何であるかはご存知でしょうか？

> > Cookie機能を持たない端末（i-modeなど）は、「セキュリティ上の問題がある
> > ため当サイトでは対応していません」とお断りすべきです。
> 
> Cookieを使ったとしても、SSLを使用しない場合、その値はもれてしまうわけです
> から、Cookieの値そのものをなりすまし防止に防ぐ、というのは中途半端だと思
> います。

私が言っているのは、「Cookieが果たしている役割をCookie以外（BASIC認証
を除く）で代用することは危険だ」ということだけで、その他の観点において
「それで安全だ」とは言っていません。

盗聴による危険性と、安易な写像関数方式の危険性は、レベルが違います。
これらは分けて考える必要があります。

「盗聴されたらどうせだめなんだから、安易な写像関数方式でも十分」
という論理は間違っています。

盗聴はないものと仮定しても満足されるサービスも世の中にはあります。
それに比べると、Refererによる漏洩や、安易な写像関数方式の危険性は
極めて現実的なものです。

> あくまでも、Cookieはセッションの概念の無いHTTPに擬似的にセッションを維持
> するための機構であって、

そのとおりです。

>                         それがセキュリティを高めていると考えるのは危険で
> はないでしょうか。

誰もそのようなことを言っていません。

私が言ったことは、「セキュリティを低めずにすむ」ということだけです。

違いはおわかりいただけるでしょうか？

> もちろん、Basic認証を用いたとしても、それが平文で流れれば、セキュリティは
> それほど高いとは言えないでしょう。
> #やらないよりまし、ぐらい。

私はアプリケーションによってはそれで十分な場合があると思います。
また、そのことは今の議論とは関係がありません。


高木 浩光＠電子技術総合研究所
http://www.etl.go.jp/~takagi/