セッションの基本

セッションの基本は、下記の動画がわかりやすかった。

セッション固定攻撃

Rails のセキュリティガイドより引用：

セッション固定攻撃の概要図。

session_fixation

ref. Rails セキュリティガイド - Railsガイド

攻撃シナリオ

具体的な攻撃シナリオは下記の通り。

  1. 攻撃者は有効なセッションIDを生成します。攻撃者はWebアプリケーションのログインページ（つまりセッション固定攻撃の対象ページ）を開き、レスポンスに含まれるcookieからセッションIDを取り出します（図の1と2を参照）。
  2. 攻撃者はセッションが失効しないよう、定期的にWebアプリケーションにアクセスしてセッションを維持しておきます。
  3. ここで攻撃者は、標的ユーザーのブラウザでこのセッションIDを強制的に読み込ませます（図の3を参照）。通常は同一オリジン（same origin）ポリシー制限によって、外部ドメインから標的ユーザーのcookieを変更できないので、攻撃者はWebサーバーのドメインを経由してJavaScriptを標的ユーザーのブラウザに送り込んで読み込ませる必要があります。クロスサイトスクリプティング（XSS）によってJavaScriptコードの注入（インジェクション）に成功すれば、攻撃は完了です。セッションIDの例: <script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>。XSSとインジェクションの詳細については後述します。
  4. 攻撃者は、このJavaScriptが仕込まれたページに標的ユーザーを誘い込みます。標的ユーザーがブラウザでページを開くと、そのユーザーのセッションIDが攻撃者の仕込んだセッションIDと差し替えられます。
  5. 標的ユーザーのブラウザでは、仕込まれたセッションIDでのログインはまだ行われていないので、Webアプリケーションはユーザーに認証を要求します。
  6. 認証が完了すると、標的ユーザーと攻撃者は同じセッションを共有した状態になります。このセッションは有効なものとして扱われ、標的ユーザーは自分が攻撃されたことにも気付きません。

攻撃者は標的ユーザーのセッションを固定するために、XSSのJavaScriptを仕込むところがポイントっぽい。

対策

Railsの場合、ログイン後にreset_session すればいいだけ。

最も効果的な対応策は、ログイン成功後に古いセッションを無効にし、新しいセッションIDを発行することです。これなら、攻撃者が固定セッションIDを悪用する余地はありません。この対応策は、セッションハイジャックにも有効です。Railsでは以下の方法で新しいセッションを作成できます。

reset_session

ref. Rails セキュリティガイド - Railsガイド

See also