2009年5月14日木曜日

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



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にする→あぼーん。



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





0 件のコメント:

コメントを投稿