TURNING POINT 
セッションIDの固定化とは
ブラウザの拡張機能などでセッションID名のCookieを作成後、そのCookieが存在する状態でログインし、ログイン後にCookieのセッションIDが変わっていない場合、セッションIDの固定化（セッション・フィクセーション）の脆弱性が存在します。
もし第3者によって固定化されたセッションIDを使用してしまった場合、当該第3者(攻撃者)はログインをバイパスすることができます。
原因
PHPには未初期化セッションIDを受け入れるセッションアダプションという特性があり、ユーザ側で勝手に作成したセッションIDでログインできるのはそれが理由です。
ただし、自分自身のCookieを編集してセッションIDを作成することは容易ですが、他人のCookieを操作するのは難易度が高い作業と言えます。
例えばIPAの図では「何らかの方法で自分が取得したセッションIDを利用者に送り込む」と記載されています。
つまり、他人のCookie内にセッションIDを設定したい場合、更に以下のような脆弱性を利用してCookieを操作する必要があります。
- クッキーモンスターバグ
- XSS
- HTTPヘッダインジェクション
対策
ログイン後にセッションIDを再発行することがセッションIDの固定化の対策になります。攻撃者は再発行後のセッションIDを知らないので、認証を突破することができなくなります。
セッションハイジャック
セッションIDに関する脆弱性としてはセッションハイジャックも有名です。
こちらは推測や盗聴に基づいて被害者のセッションIDを取得します。
セッションIDを推測が困難のものにする、セッションIDをURLパラメータに含めない、Cookieにsecurae属性を加えるといった、ある種当たり前のことがセッションハイジャック対策になります。
セッションIDの固定化の確認方法の注意点
セッションIDの固定化を確認する場合、POSTリクエストのCookieヘッダを編集するのではなく、Cookieそのものを作成してください。
そもそもセッションIDのCookieが既に作られている状態で固定化を確認する場合においては、POSTだけ変更しても当然次回以降のCookieヘッダは変更前のものが送信されるので確認になりません。
セッションIDのCookieが存在しない場合にPOSTだけ変更しても、次回以降のCookieヘッダには当然セッションIDは含まれません。
