Q&A
セッションハイジャック対策は十二分にされた上での話でしょうか。
何を想定し、どのように実施しようとしている試験なのか前提や背景を記載されたほうが良いかと思います
PHPでログインの保持を試験的に行なっていますが、このセッションIDが再度開いても「たまたま」同じになることは怒ると思うのですがそれに関する対策はみなさんされていますか？
またどのような対策をされていますか？
回答4件
0
このセッションIDが再度開いても「たまたま」同じになることは怒ると思うのですがそれに関する対策はみなさんされていますか？
セッションデータをデータベースなどに持たせている場合、新規作成のために生成した番号がすでに使われていれば、もう1回生成すれば済む程度の話です（セッションIDに十分な桁数があれば、そもそも重複すること自体が、現実的でない程度に稀な事象です）。
投稿2019/10/23 06:16
総合スコア146853
>もう1回生成すれば済む程度の話
私も実際はこれで済むと思います。それにログイン関係の試験で大事なのはセッション重複じゃないとおもう…
0
よほどアクセスが多いサイトでないと起こりそうにない問題ではありますが、セッションIDは任意の値で指定可能なので、例えばユーザーIDと日時タイムスタンプを含めた上で暗号化するとか、そういう対策になると思います。
フレームワークを利用している場合はそちらに管理を任せます。
投稿2019/10/23 06:13
総合スコア80890
a-z A-Z 0-9 , - の32桁だと約63恒河沙通りできてしまいますからね
文字化けかと思ってしまった。
漢字圏の単位のやつですね;
必要な場面で必ずregenerate_id()していたとしても早々重複は起きないでしょうし、別回答の通り作り直せば済む話と思います。
botでも使って試験しようとしてるんですかね…。重複確認できる前にサーバーが落ちそう
手元にあったシステムを見てみたら、セッションキーは128ビットだったのですが、この長さで誕生日攻撃を考えても、京（10**16）で数える程度のユーザーが集まらない限り、セッションキーの衝突が現実的な問題とはならなさそうです。
（マイクロソフトのGUIDも、122ビットをランダムに振っていますが、衝突して問題になったということは聞いたことがありません）
そうですよね。試験の目的や前提が今一つ見えません(追記依頼済み)
0
投稿2019/10/23 06:33
退会済みユーザー
総合スコア0
php の実装は時間とリモートアドレスが種っぽいので、複数サーバでロードバランサが IP での振り分けでない時に極稀に発生するって感じでしょうか。
サーバごとにプレフィックスつければ重ならない仕様っぽい気がします。
ぽいだらけｗ
0
どうしても気になるなら別途適当なクッキーを食わせておいて
適合を確認するとかやりようはありそうな気もしますが
「たまたま」の確率が極めて低いのであまり気にしなくても
大丈夫だとは思います
投稿2019/10/23 06:21
総合スコア118163
あなたの回答
tips
プレビュー
