公開日:2015/02/02
ログインする仕組を作るにあたってセッションハイジャックとセッションフィクセイションについて勉強したのでメモする。
セッションハイジャックと対策
既に開始しているセッションのセッションIDを攻撃者に盗まれ、アカウント等を乗っ取られること。
攻撃者は入手したセッションIDを自分のブラウザにセットすればログイン状態を実現したりショッピングカートを操作したり成りすましをすることができる。
クッキーファイルから盗む方法と通信データから盗む方法が考えられる。
クッキーファイルはクロスサイトスクリプティング(XSS)攻撃対策セッションクッキーを守る方法で守ること。
通信データはSSL通信で守ること。
セッションフィクセイションと対策
攻撃者によってセッションIDを埋め込まれ、アカウント等を乗っ取られること。
最終的に乗っ取られる点はセッションハイジャックと同じだが、攻撃方法が違う。
セッションフィクセイションの場合は攻撃者が用意したセッションIDを対象者のブラウザにセットすることで乗っ取りを実現する。
クロスサイトスクリプティングでセットする方法、リンクURLでセッションIDをセットする方法が考えられる。
クッキーモンスターバグや同ドメイン内の外部ページを使った方法もあるが条件が限られているので気にしない。
URLでセッションIDをセットできるかどうかはサーバの設定で制御できる。
確認すべきパラメータはsession.use_only_cookies。
これが無効だとURLに?PHPSESSID=と指定するとセッションIDをセットできてしまうので有効にする。
ドメインキングの場合、既に有効になっているので特に対処はしない。
ログイン時のセッションIDの更新と確定時のパスワード入力
上記対策をしていても何らかの方法でセッションIDを知られてしまったまたは盗まれてしまったとする。
攻撃者とセッションIDを共有している状態をどうにかしたい。
session_regenerate_id()関数でセッションIDを更新してしまうことで解決。
全ページで呼び出しちゃえばいいじゃん(∩´∀｀)∩
て思ったけどサーバ負荷が高く現実的ではないらしい(´・ω・｀)えー
ログイン時に一度だけ呼び出すものらしい。
じゃあログイン中のセッションID盗まれたらどうすんだ( ﾟдﾟ)
て思ったけどログイン中はSSL通信してるから盗まれないでしょ！てことなのかな。
ログインページだけSSL通信てこともありそうだけど…まあ常時SSLならいいか。
それでもログイン状態を乗っ取られた場合の対策として大事な場面ではパスワードを入力させるようにする。
お買い物の確定とかパスワードの変更の確定とか。
ほんとにwebセキュリティは考えないといけないことが多い。
webとかなくなればいいのに(:3_ヽ)_