セッションハイジャックについて勉強してみた 3

notoです。セッションハイジャック最終回です。

セッションハイジャック最終回はセッションID固定化についてです。

セッションID固定化

概要

セッションIDを外部から強制する方法

攻撃手法

セッションID固定化攻撃の手順

  1. セッションIDを入手する
  2. 被害者に対して入手したセッションIDを強制する
  3. 被害者は標的アプリケーションにログインする
  4. 攻撃者は被害者に強制したセッションIDを使用し標的アプリケーションにアクセスする

脆弱性が生まれる原因

  • セッションIDをURL埋め込みにしない
  • クッキーモンスター問題のあるブラウザを使わない(使わせない)
  • クッキーモンスター問題の発生しやすい地域型ドメインを使わない
  • クロスサイトスクリプティング脆弱性をなくす
  • HTTPヘッダインジェクション脆弱性をなくす
  • クッキーを書き換えられる脆弱性をなくす

これら全てを満たすことは困難。 IEには地域型ドメインに対するクッキーモンスター問題があり修正予定もない。しかしIEは広く利用されているブラウザなので使わないように強制することはできない。

セッションIDを固定化することは許容し、セッションID固定化攻撃が行われてもセッションハイジャックは防ぐように対策することが一般的。

対策

セッションID固定化攻撃は多様であり、ブラウザの脆弱性が悪用される場合もある。webアプリケーション側でセッションID固定化攻撃に対策する方法をとる

認証後にセッションIDを変更する

session_regenarate_id関数を利用する

1
session_regenarate_id(true);

セッションIDの変更ができない場合は、トークンにより対策する

ログイン時にトークンを生成し、クッキーとセッション変数の両方に記憶させる。認証確認時にクッキー上のトークンとセッション変数のトークンの値を比較し同一である場合認証されていると認識する。

トークンが外部に出力されるタイミングはログイン時のクッキー生成のみであるので、トークンは攻撃者にとって未知の情報であり知る手段がない。 そのため、セッションIDの固定化攻撃を防ぐことができる。

これから友人の結婚式なのですが、両親にチクチク小言を言われております。。。

参考文献

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

Comments