ん？セッションアダプテーションってそんな名前つけるほどのこと？

http://gihyo.jp/dev/serial/01/php-security/0025?page=1

ふと見て思った事。

いあ、そんな状況じゃオーソドックスなセッションフィクスネーションができちゃうかと。ぐぐる限り、セッションアダプテーションは任意のセッションIDをクラッカー側が指定できる。ってのが特徴らしいんだけど、一般的なアプリではクラッカーも正規のセッションID入手し放題なわけだから、正規発行済みのセッションIDを使えばいいだけだよね。

なんかもっと深い事あるのかなぁ？

アダプテーション対策の有無で差がでるとしたら、セッションの有効期限程度の話になるかと思う。

#ま、私もセッションキーが「a」一文字とかできちゃうのは気持ち悪いので嫌いな仕様なんだけど。

とおもって改めてしらべてて、やっぱりこんな程度の問題だよね。と見つけたので。メモ。

http://blog.ohgaki.net/session_regenerate_id_wo

ちなみに上のブログで心配しているのは。

Evil:セッション固定(No.1)してAliceに入力欄のURL送信

Alice:セッションNo.1に情報記入して、確認画面に移動。

Evil:セッションNo.1の確認画面をリロードしまくってAliceが情報記入するのを待つ。

というシチュエーションかな。メッセージダイジェストもいいかもしんないし。入力を受けて表示するまえにIDregenerateしてもいいかとは思う。ただ、regenerateするとブラウザの戻るボタンでセッションも消えちゃうのユーザビリティは落ちる。

もいっちょ、マイナーなやつだとこんなのもあり得る？

サイト仕様:クレジットカードを使った送金サイト。「送り先入力→金額入力→送り主情報入力→確認画面→完了」情報はセッションに入る

Evil:予めセッションNo.1で送り先,金額を入力。送り主情報入力のURLをセッションキーつきでAliceに送る。

送るときにメールなりニセサイトでBob（有名企業）への入金手順ですといって「送り主情報入力→確認画面→金額入力→送り先入力→完了」の手順ですよと掲示しておく

Alice:Bob宛だとおもいこんで、送り主情報を入力

Alice:確認画面を条件反射でOKにする→あぼーん。

ま、どちらかというとこれはフィッシングだけどね。