よく、PHPでのセッションハイジャック対策として、認証後に「session_regenerate_id(true)」を行ったり、認証確認時にユーザ環境に依存する情報で簡易的なチェックを行う等の対策をよく拝見します。


そもそも認証済みセッションのセッションIDが盗聴された場合、「session_regenerate_id(true)」では、旧IDに紐付いた情報は破棄されることと、新しいセッションIDが発行される点はわかりますが、結局、そのタイミングが悪意をもったユーザの操作時点で再生成されない保証はできないような気がします。

その為その被害を軽減しそもそも発生確率を低減する対策として、ユーザ環境に依存する情報で定期的(操作毎?)にセッションIDの保有者と認証時点のユーザの同一性を確認しているという理解です。

そういった意味で、完全に防衛する仕組みは実現できないため、基本的には性悪説に則って考えて情報更新時には基本的にログイン状態を維持できる仕組みでも更新前や重要情報の表示前には再度パスワードによる認証を行うものだと認識しています。

いろいろなブログを拝見して考えていくと、結局自身が高じている悪意のあるユーザへの対策が完全では内容に思え、ちょっと悩んでおります。

回答の条件
  • 1人5回まで
  • 登録:2008/09/26 10:37:00
  • 終了:2008/10/03 10:40:02

回答(3件)

id:idetky No.1

idetky回答回数426ベストアンサー獲得回数202008/09/26 10:52:00

ポイント27pt

まあ、悩みますよね。。


で、質問はなんですか?

id:jyack

おっと、すみません。

500文字いないに納めるために、事例部分の削除とかしているうちに質問の部分も削除してしまっていました(笑)

質問としては、前述のような理解がそもそも正しいのかという点です。

セッションIDが盗聴された時点で、セッションIDを前提としての対策は仮に再生成をおこなっても

前述のように必ずしも正規のセッションに対して再生成するとは限らないので、努力はしても完全には防げない。

だから、最低限個人情報の類の表示や更新に関しては都度パスワードを求める必要があるという結論でよいのかなぁという事を

そのほかのPHPユーザの方の経験や実際の取り組みとしてご意見を伺いたかったのです。

2008/09/26 11:05:23
id:idetky No.2

idetky回答回数426ベストアンサー獲得回数202008/09/26 16:38:37

ポイント27pt

自分は、第三者の情報を扱うようなサイトを作る際には、必ずhttpsを利用しています。

この方法でも、スパイウェア、ウイルスなどでクライアントPC側に保存されているCookie情報は暗号化されていないので、Cookieの情報をインターネット上に流すような動作をするスパイウェアなどにクライアントPCが感染している場合にはどうしようもないですけどね。

id:jyack

ご回答ありがとうございます。

>自分は、第三者の情報を扱うようなサイトを作る際には、必ずhttpsを利用しています。

そうですね、私も認証や重要情報はHTTPS、閲覧時のセッションはHTTPSで認証を通過した後、セッション情報を共有しない形でHTTPSとは別なセッションIDを準備し管理をしています。

>この方法でも、スパイウェア、ウイルスなどでクライアントPC側に保存されているCookie情報は暗号化されていないので、Cookieの情報をインターネット上に流すような動作をするスパイウェアなどにクライアントPCが感染している場合にはどうしようもないですけどね。

そうなんですよね。

私が悩んでいるのも、そもそもWebアプリケーションの脆弱性については、開発者が十二分に対策を練るべきですが、

そのスコープとして利用者自身が追っているセキュリティリスクについて、どこまでWebアプリケーション側で考えるべきなのかという点で悩んでいます。

2008/09/26 17:45:52
id:nake No.3

nake回答回数87ベストアンサー獲得回数02008/09/26 17:22:01

ポイント26pt

>更新前や重要情報の表示前には再度パスワードによる認証を行うものだと認識しています。

これにSSLをかけるしかなさそうですね。

あと、IPアドレスとかリファーとか併用すれば強化できると思いますが、完璧にはならないでしょう。

考え方を逆にして、セッションIDがハックされたらどのようなことが可能かを考えてみては?

できることが、致命的でない限り容認するか、利用者に責任を求めるとかそういう感じが良いと思います。

id:jyack

ご回答ありがとうございます。

>考え方を逆にして、セッションIDがハックされたらどのようなことが可能かを考えてみては?

>できることが、致命的でない限り容認するか、利用者に責任を求めるとかそういう感じが良いと思います。

なるほど!それはその通りですね。

基本的にセッションIDは悪用される可能性がある、つまり性悪説的に考えることとして、

逆にセッションIDが漏洩し悪用された場合であっても、

重要な部分については必ず再度認証を行うように対策を講じる事で、

セッションIDが漏洩し悪用されても最後の一線は守れるますね。

そう考えると少し気持ちが楽になりますね。

2008/09/26 17:49:52
  • id:tukihatu
    クライアント側でどうしようもないのが、パスワードやセッションIDの弱さですよね…
    例えばPOSTで情報を引き継いでいくって言うのはどうなんでしょうか?
    いちいち書くのは面倒だけど、input名さえばれなければ硬いと思うんですが…同じですかね?
  • id:chibitomo
    アクセスごとにチケットやトークンを発行して複合的に防ぐくらいで
    おなかいっぱいです。
    PHP自身に深刻なセキュリティホールがあったり
    サーバのモジュールなどがアップデートされてなく
    そこでクラックされたら、いくらWEBアプ側でセキュリティ対策しても意味なくなる。
    携帯みたいにね固定識別番号あると楽なんだがそれも端末設定でOFFされてると
    取れないし。面倒だね。
    あとで客に大騒ぎされないようにあらゆる脆弱性対策を組み込んで免責事項。
    きっと完全に防ぐ方法あるんだぜ。そのサイトは最強に使いにくくなるけど。

  • id:tukihatu
    >いくらWEBアプ側でセキュリティ対策しても意味なくなる。
    かといって手をぬくと客に大騒ぎされるし…
    言われるままアプリで完璧近い対策しても、レンタルサーバな時点で…ねえ?

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません