Session管理してる？ (221ﾚｽ)
上下前次1-新
23(3): 名無しさん＠お腹いっぱい。 2001/06/11(月)11:59 ID:BchxEcFA(1) AAS
ちょっと質問。
よくユーザ登録のページで情報を入力しsubmitして
確認画面がでますよね。でソースを見ると入力内容をHidden
で渡してるものもあれば、Hiddenを使用していないものもあります。
Hiddenを使用せず渡すのは、s_id見たいなものを
をキーにして入力内容をDBに毎回insertしてページ間でデータが
渡っているのでしょうか？それとも別の方法があるんですかね？
疑問だったので・・・。
24(1): sage 2001/06/11(月)12:12 ID:??? AAS
>>23 cookie
25: sage 2001/06/11(月)12:11 ID:??? AAS
>>23 cookie
26: 名無しさん＠お腹いっぱい。 2001/06/11(月)12:44 ID:??? AAS
またはipを基に一時ファイル作成とか…。
まぁ普通はCookieだと思うが
27(1): 名無しさん＠お腹いっぱい。 [me] 2001/06/12(火)12:44 ID:??? AAS
cookieに依存すると、専用端末や携帯電話やcookie offに対応することに
なったときに面倒っすよ。趣味でPCだけ相手にしているときにはいいけど。
28: 名無しさん＠お腹いっぱい。 2001/06/12(火)13:16 ID:??? AAS
>>27
ソース見てhiddenがないのはどうなってるのかって聞いたから例としてcookie
と言ったまで。
そりゃ状況によって方法は変えますよ、わたしゃ。
29: 名無しさん＠お腹いっぱい。 2001/06/22(金)12:49 ID:yGqQ.0ks(1) AAS
age
30(3): 殿堂ナナシ [0] 2001/06/22(金)22:26 ID:??? AAS
>>23
Servlet ではセッションはサーバのメモリに保持する。
ファイルやDBはオーバーヘッドがあるのであまりないね〜。
PHP4 はファイルですよね（よく分からんけど）
>>24
クッキーに情報自体を保持するのは、一般的？に
セッション管理とは言いにくいような。。。
# セッションIDは別
31(1): 名無しさん＠お腹いっぱい。 2001/06/22(金)22:34 ID:??? AAS
>>30
セッション終了時に消えるクッキーをセッションクッキーって
言うの知らないの？
32(1): 殿堂ナナシ 2001/06/22(金)23:21 ID:??? AAS
>>31
怒ってる〜？
そうだね。レスポンスヘッダに設定する有効期限を無しに
すればセッションが続く限りクライアントが情報を保持するよね。
んで、そのセッションクッキーってのを使うと
セッション管理してるということになるの？
hidden と同じでクライアントに投げたら投げっぱなしなので
管理とは言いがたいような気がします〜。
毎回切断される HTTP で継続して情報を保持するために
サーバでランダムな ID を発行し、それをキーにクライアントと
やりとりを行う。
それをセッション管理と言う。
33: 名無しさん＠お腹いっぱい。 2001/06/23(土)03:44 ID:??? AAS
>>32
そのやり取りって、クッキー使ってんじゃないの?
34: 名無しさん＠お腹いっぱい。 2001/06/23(土)13:09 ID:??? AAS
どっちにしてもcookie使わない方法はないと思うが。
もちろん、擬似的なセッション維持だとは思うけど。
データをどこにもつかって事だと思うけど、
cokkieはドメイン毎に4Kまでの制限があるから、
ふつうサーバーでデータは保持する。
35: 殿堂ナナシ 2001/06/23(土)22:56 ID:??? AAS
クッキーだけでなく、サーバで発行したランダムなIDは次の
いづれかでやりとりされる。
・クッキー
・get リクエスト
・put リクエスト
このIDを普通はセッションIDっていうよね。
最近の Java や PHP では意識はしなくてもいいけど。
36: 名無しさん＠お腹いっぱい。 2001/06/24(日)08:45 ID:??? AAS
＞・クッキー
＞・get リクエスト
＞・put リクエスト
結局hidden以外はcookieじゃん。
37: 名無しさん＠おへそいっぱい。 2001/06/24(日)12:09 ID:??? AAS
URL Rewrite を忘れてる。<A HREF="/a/b/c;98A30x7"> みたい
なの。現行のステートマネージメントは
・Cookie の受け渡し
・HIDDEN フィールド
・URL Rewrite
で行われている (Servet の話だけど)。
ちなみにセッション ID がランダムに振られるシステムは設計が
おかしい。
38: 殿堂ナナシ 2001/06/24(日)21:36 ID:??? AAS
間違えた。。。 put は post です。。。
・クッキー <- Cookie の受け渡し
・post リクエスト <- HIDDEN フィールド
・get リクエスト <- URL Rewrite
私の表現がおかしい〜？
URL Rewrite は クッキーが使えないときにAP サーバが
セッションIDを URL に Rewrite するっていうものだよね。
最近、セキュリティ的に問題があるので使ってはいけないというのが
良く言われてるけど。
セッションIDがランダムに振られるのがおかしいというのはなぜ〜？
最近はAPサーバにセッション管理が実装されてるから
あまり意識してないもので。。。
一意性の問題？
39(2): 名無しさん＠おへそいっぱい。 2001/06/25(月)00:25 ID:??? AAS
そう、一意性の問題。普通はシーケンシャルに採番して一意性を
維持したままシャッフルすると思われる。ちょっと揚げ足を取っ
てみただけ。
現行のステートマネージメントメカニズムは、どの方法も SSL と
組み合わせないとセキュリティ的に問題ありだね。というか
そんなの Web の常識だったはずなのに、なぜ突然ひろみちゅが
騒ぎ始めたのか分からんよ。
URL Rewrite/HIDDEN フィールド
ソースを見れば一目瞭然。URL 欄にも表示される。ジャンプ先
サイトでは Referer ヘッダで参照可能 (ブラウザの種類と
バージョンにもよる)。自サイトを SSL 化しても Referer
ヘッダは漏れてしまうかも (なりすまし接続は無理だろうが)。
Cookie
丸見えでない分 URL Rewrite/HIDDEN フィールドよりまし
だが平文であることには変わりない。プロキシサーバなら
余裕で盗める。期限付きのはファイルで残る。
# 昔、クライアント側の IP アドレスを使ってセッション ID
# にハッシュかければセキュリティもバッチリでは? と発明
# しかけたが、程なくプロキシの存在を忘れているのに気づ
# いた。
40(1): 名無しさん＠お腹いっぱい。 [AGE] 2001/06/25(月)15:58 ID:??? AAS
>>30
クライアント側のクッキーにはIDのみで、
セッション情報はサーバ側に保存されるので
セキュリティ的には問題ない
と、どっかで読んだ覚えがあるんですが。
41: 40 2001/06/25(月)15:59 ID:??? AAS
>>30は>>39の間違いでした。
42: 名無しさん＠おへそいっぱい。 [mage] 2001/06/26(火)10:43 ID:??? AAS
セッション ID を盗まれると言うことは、意味的にサーバサイドの
セッション情報ごと盗まれるのと等しい。ただ、情報が丸見えでは
なく、どのような情報か想像しずらいという人間的な利点があるだけ。
ユーザ認証後のセッション ID を盗まれたら、アプリケーションを
乗っ取られたのと事実上同じ。セキュリティを確保したければ SSL
と併用せれ。
43(1): 名無しさん＠おへそいっぱい。 [mage] 2001/06/26(火)10:45 ID:??? AAS
セッション ID を盗まれると言うことは、意味的にサーバサイドの
セッション情報ごと盗まれるのと等しい。ただ、情報が丸見えでは
なく、どのような情報か想像しずらいという人間的な利点があるだけ。
ユーザ認証後のセッション ID を盗まれたら、アプリケーションを
乗っ取られたのと事実上同じ。セキュリティを確保したければ SSL
と併用せれ。
44(2): 名無しさん＠お腹いっぱい。 2001/06/26(火)15:40 ID:??? AAS
>43
ID+有効期限を暗号化して発行すれば、
多少マシになる。
45: 名無しさん＠おへそいっぱい。 2001/06/26(火)17:27 ID:??? AAS
>>44 その暗号化のキーは?
46(1): 名無しさん＠おへそいっぱい。 2001/06/26(火)17:28 ID:??? AAS
>>44 その暗号化のキーは?
47: 名無しさん＠お腹いっぱい。 2001/06/26(火)23:59 ID:DSIpbR1w(1) AAS
>46
なんでもいいじゃない？
暗号化も複合化もサーバーでやるんだから
実際にやってるけど、SIDとログインタイムをある形式にフォーマットして
BASE64で暗号化して発行。クライアントから返されるSIDは形式のチェックで先ずはじく。
仮に、クッキー盗まれても有効期限内しか使えないし、
まあ、解読も可能だろうけど、一定期間でキーやアルゴリズム変えれば、
それなりに実用的だと思う。
なんか間違ってる？
48: 名無しさん＠お腹いっぱい。 2001/06/27(水)00:07 ID:??? AAS
Crypt::Blowfishで暗号化でした
つくったのはおいらでないので間違ってるかも
49: 名無しさん＠おへそいっぱい。 2001/06/27(水)00:52 ID:DNFpNq1I(1) AAS
いくら強力な暗号化アルゴリズムを使っても、キーがサーバ側に
あったら意味ないでしょ。盗んだ側にとっては ID が暗号化され
ているかどうかなんて関係なく、盗んだ Cookie をそのまま送り
返せばよいのだから (だから >>39 でクライアント側の IP ア
ドレスをキーにハッシュかけようとした)。
あ、俺が考えてるのは中継サーバ等で Cookie が盗まれた場合ね。
総当りでのセッション ID 盗難防止という話だったら暗号化だけで
効果は高い。んーでも総当りなんて目立つ方法で盗もうとする莫迦
いるか? だから、わざわざセッション ID を暗号化してもたいした
効果がないと思っただけ。
50: 名無しさん＠おへそいっぱい。 2001/06/27(水)01:02 ID:??? AAS
すまん、ハッシュではなく可逆符号化だ…。
51: 名無しさん＠お腹いっぱい。 2001/06/27(水)02:33 ID:IVYsrfFE(1) AAS
間にProxyが入ろうがどうしようが
クライアント固有の識別ID(macアドレスとか)を
簡単に取れる手段があるといいんですがねえ。
プライバシー的には問題おおありですが。
そういうの、MSならやってくれ・・・ないか。さすがに。
52: 名無しさん＠お腹いっぱい。 [me] 2001/06/27(水)16:30 ID:??? AAS
proxyの問題を考えなければ簡単なんだけどね＞セッションID盗難対策
503iのような、固体識別番号取得タグをどのブラウザも実装してくれれば
話は簡単だけれども。
確認が入るのでプライバシー的な問題も無いと思うし、MSさん実装して
くれまいか。
上下前次1-新書関写板覧索設栞歴
あと 169 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.013s