アカウント名:
パスワード:
漏れる漏れないの話と、ローカルで改竄される話は、別です。
HIDDENに埋め込んだセッションIDは、FORMで渡さないと いけないんですよね。 でも、それだと全部SUBMITボタンでページを移動しないといけなくなっちゃう気がするんですが。
PHPとかでセッション管理をすると、FORMなしでセッションIDが渡せるcookieは便利です。 いちいちSUBMITボタンによる遷移をしなくても、ただ表示するだけのページでもセッション確認できますから。 なりすましや漏洩が心配なら「セッションの切断」のページを用意して、そこでcookieを消すとかすればいいんじゃないでしょうか。 もちろん、セッションcookieの有効期限は過去の時間にしてブラウザが終了した時点で消えるように。
cookieに代わるセッション管理の手法があれば(もちろんJavaScriptを除く)R-MSもいいと思いますが、今のところ思いつきません。 原文を書いた人は、代替案も書いてくれるともっと説得力があって支持してくれる、採用してくれる人も多かったと思います。
「cookieでなくhiddenで」という発言の意味は、cookieだとクロスサイトスクリプティング脆弱性を確実に排除せねばならないがそれに自信を持てないという点と、ブラウザのMS01-055のような欠陥の影響を受けて危険だから、hiddenでという話なのでしょう。
詳しくは例えばここの資料の一つ目と五つ目が参考になるかもしれません。 http://www.shoeisha.com/event/sec/session/index.html [shoeisha.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
スクリプト(javascript)とクッキー使わずにECサイトは (スコア:2)
Re:スクリプト(javascript)とクッキー使わずにECサイ (スコア:1)
欧州議会がcookie禁止法案を来週採決 [srad.jp]
のコメントで色々議論されてます。
最近、Cookieへの風当たりが強くて、Web系技術者としては頭の痛い限りで
Re:スクリプト(javascript)とクッキー使わずにECサイ? (スコア:0)
情報なので、ローカルに保存して改変し、それを
ブラウザで読み込んで処理を継続する事でなんらかの
行為も可能ですよね。
それを防止するためには HTTP_REFERER を参照し
サーバから正しく送り出されたコンテンツに
基づいているか確認するという手はありますが
HTTP_REFERER は必ず得られるものと
Re:スクリプト(javascript)とクッキー使わずにECサイ? (スコア:1)
漏れる漏れないの話と、ローカルで改竄される話は、別です。
Re:スクリプト(javascript)とクッキー使わずにECサイ? (スコア:1)
HIDDENに埋め込んだセッションIDは、FORMで渡さないと いけないんですよね。
でも、それだと全部SUBMITボタンでページを移動しないといけなくなっちゃう気がするんですが。
PHPとかでセッション管理をすると、FORMなしでセッションIDが渡せるcookieは便利です。
いちいちSUBMITボタンによる遷移をしなくても、ただ表示するだけのページでもセッション確認できますから。
なりすましや漏洩が心配なら「セッションの切断」のページを用意して、そこでcookieを消すとかすればいいんじゃないでしょうか。
もちろん、セッションcookieの有効期限は過去の時間にしてブラウザが終了した時点で消えるように。
cookieに代わるセッション管理の手法があれば(もちろんJavaScriptを除く)R-MSもいいと思いますが、今のところ思いつきません。
原文を書いた人は、代替案も書いてくれるともっと説得力があって支持してくれる、採用してくれる人も多かったと思います。
Re:スクリプト(javascript)とクッキー使わずにECサイ? (スコア:0)
なくて、改変して(何らかの手段でうまく)偽装できれば
他人に覗き見されてしまうという可能性を言っているの
かも。(そんなことが可能なのかどうか分かりませんけど)
でもそれは cookieも同じような... 永続保存では
なくセッションのみの cookieなら大丈夫なのかな。
ほへ、よー分からん ^^;
Re:スクリプト(javascript)とクッキー使わずにECサイ? (スコア:3, 参考になる)
「cookieでなくhiddenで」という発言の意味は、cookieだとクロスサイトスクリプティング脆弱性を確実に排除せねばならないがそれに自信を持てないという点と、ブラウザのMS01-055のような欠陥の影響を受けて危険だから、hiddenでという話なのでしょう。
詳しくは例えばここの資料の一つ目と五つ目が参考になるかもしれません。 http://www.shoeisha.com/event/sec/session/index.html [shoeisha.com]