アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
「消費者は、クッキーがどのように働くのか理解してい (スコア:2, 興味深い)
以下ついでに、上記文章の背景の1つにあたる Servlet-MLでの一連のやりとり。高木さんが「Refererで漏れる」を連呼されていたのが印象深いです。
(「SSLでもRefererで(セッションIDが)漏れる!」という前提で延々議論が進んだ上で、数日後思い出したように「実は IE 4以降だと漏れない。でも(旧)Netscapeは漏れるのでやっぱり結論は変わらない」の訂正が入って、思わず“この議論はいったいナンダッタンダ”と呻いていた私)
[servlet-ml 2587] URL 認証 [archive.org]
[servlet-ml 2590] URL 認証 [archive.org]
[servlet-ml 2591] URL 認証 [archive.org]
[servlet-ml 2593] URL 認証 [archive.org]
[servlet-ml 2588] U [archive.org]
Re:「消費者は、クッキーがどのように働くのか理解し (スコア:3, 参考になる)
これを使うと、ほぼどんな環境でもセッションがつかえるようになり非常に便利が良いのですが、Cookieの使えない(無効にしている)環境化では非常に脆弱になり、Cooki
Re:「消費者は、クッキーがどのように働くのか理解し (スコア:0)
だから、私も基本的にはCookieは拒否、というよりも拒否リストを利用しています。拒否リストに無い新しいリンク先
Re:「消費者は、クッキーがどのように働くのか理解し (スコア:1)
乗っ取る気がなくても辿ったリンク先がRefererを集計して公開しているようなサイトだったりすると、意図せずセッションを乗っ取ってしまうような事態が容易に発生します。
任意のリンクをだれでもつけることができるような場合はさらに危険です。
また、当然ですが不用意なURLのコピー&ペーストも危険です。
Re:「消費者は、クッキーがどのように働くのか理解し (スコア:2, 参考になる)
も危険です。
たとえばMSNなんかでちょっと検索する [msn.co.jp]だけで、セッションキーが漏れているのがわかると思います。
こういったサーチエンジン向けに発行したセッションキー付きのURLからそのサイトに行くと、サーチエンジンから来た人全員でセッションを共有するような状態になってしまいます。