そもそも認証済みセッションのセッションIDが盗聴された場合、「session_regenerate_id(true)」では、旧IDに紐付いた情報は破棄されることと、新しいセッションIDが発行される点はわかりますが、結局、そのタイミングが悪意をもったユーザの操作時点で再生成されない保証はできないような気がします。
その為その被害を軽減しそもそも発生確率を低減する対策として、ユーザ環境に依存する情報で定期的（操作毎？）にセッションIDの保有者と認証時点のユーザの同一性を確認しているという理解です。
そういった意味で、完全に防衛する仕組みは実現できないため、基本的には性悪説に則って考えて情報更新時には基本的にログイン状態を維持できる仕組みでも更新前や重要情報の表示前には再度パスワードによる認証を行うものだと認識しています。
いろいろなブログを拝見して考えていくと、結局自身が高じている悪意のあるユーザへの対策が完全では内容に思え、ちょっと悩んでおります。
No.2
426
20
27pt
自分は、第三者の情報を扱うようなサイトを作る際には、必ずhttpsを利用しています。
この方法でも、スパイウェア、ウイルスなどでクライアントPC側に保存されているCookie情報は暗号化されていないので、Cookieの情報をインターネット上に流すような動作をするスパイウェアなどにクライアントPCが感染している場合にはどうしようもないですけどね。
ご回答ありがとうございます。
＞自分は、第三者の情報を扱うようなサイトを作る際には、必ずhttpsを利用しています。
そうですね、私も認証や重要情報はHTTPS、閲覧時のセッションはHTTPSで認証を通過した後、セッション情報を共有しない形でHTTPSとは別なセッションIDを準備し管理をしています。
＞この方法でも、スパイウェア、ウイルスなどでクライアントPC側に保存されているCookie情報は暗号化されていないので、Cookieの情報をインターネット上に流すような動作をするスパイウェアなどにクライアントPCが感染している場合にはどうしようもないですけどね。
そうなんですよね。
私が悩んでいるのも、そもそもWebアプリケーションの脆弱性については、開発者が十二分に対策を練るべきですが、
そのスコープとして利用者自身が追っているセキュリティリスクについて、どこまでWebアプリケーション側で考えるべきなのかという点で悩んでいます。
No.3
870
26pt
＞更新前や重要情報の表示前には再度パスワードによる認証を行うものだと認識しています。
これにSSLをかけるしかなさそうですね。
あと、ＩＰアドレスとかリファーとか併用すれば強化できると思いますが、完璧にはならないでしょう。
考え方を逆にして、セッションＩＤがハックされたらどのようなことが可能かを考えてみては？
できることが、致命的でない限り容認するか、利用者に責任を求めるとかそういう感じが良いと思います。
ご回答ありがとうございます。
＞考え方を逆にして、セッションＩＤがハックされたらどのようなことが可能かを考えてみては？
＞できることが、致命的でない限り容認するか、利用者に責任を求めるとかそういう感じが良いと思います。
なるほど！それはその通りですね。
基本的にセッションIDは悪用される可能性がある、つまり性悪説的に考えることとして、
逆にセッションIDが漏洩し悪用された場合であっても、
重要な部分については必ず再度認証を行うように対策を講じる事で、
セッションIDが漏洩し悪用されても最後の一線は守れるますね。
そう考えると少し気持ちが楽になりますね。
牛乳先生(tukihatu)
2008/09/26 19:10:24
2
2
chibitomo
1
2
1
おっと、すみません。
５００文字いないに納めるために、事例部分の削除とかしているうちに質問の部分も削除してしまっていました（笑）
質問としては、前述のような理解がそもそも正しいのかという点です。
セッションIDが盗聴された時点で、セッションIDを前提としての対策は仮に再生成をおこなっても
前述のように必ずしも正規のセッションに対して再生成するとは限らないので、努力はしても完全には防げない。
だから、最低限個人情報の類の表示や更新に関しては都度パスワードを求める必要があるという結論でよいのかなぁという事を
そのほかのPHPユーザの方の経験や実際の取り組みとしてご意見を伺いたかったのです。