今回はセッションに関連する代表的なぜい弱性の一つである「セッション・フィクセーション」について解説しよう。
セッション・フィクセーションとは，セッションIDを詐取するのではなく，攻撃者が知っているセッションIDをユーザーに使わせて，後からユーザーになりすます攻撃のことである（図1）。クッキーとして有効なセッションIDを攻撃者によりセットされ，そのセッションIDがユーザー情報とひも付けられてしまう。
 |
| 図1●セッション・フィクセーションのぜい弱性を突く攻撃の例 [画像のクリックで拡大表示] |
図1の例では，http://example9.co.jp上の攻撃者が，ユーザーのブラウザに任意のクッキーをセットしている。このセッションIDは，攻撃者があらかじめターゲット・サイトにアクセスし，取得したものである。問題は，攻撃者がこのクッキーを，ユーザーのブラウザにセットできてしまうことだ。この攻撃が成立する大きな要因はクッキーがセットされるメカニズムにある。このメカニズムはCookieMonsterという呼び方で説明されることが多い。
第1回で，クッキーがセットされる条件の一つとして，domain属性に関する制限を解説した。
「ブラウザがアクセスするURL内のドメイン名がこれに後方一致（一部制限がある）する場合のみクッキーが送信される。これに後方一致しない場合は，不正なクッキーであると判断されブラウザにセットされない」
ここで言う制限とは，指定可能なドメイン名のことである。例えば，“.jp”というドメインが指定され，これをブラウザが受け付けてしまうと，example0.jp，example1.jpなど，“.jp”（後方）が一致する別のドメイン上でも同一のクッキーが使用されてしまうことになる。これを受け入れてしまうと，管轄の異なるWebサイト間で，クッキーが共有されてしまう問題が発生するため，このような指定が制限されている。
ただ，ネットスケープ仕様ではこの制限について触れてはいるものの，（1）仕様があいまい，（2）仕様が策定されてから時間が経過し，使用され得るドメイン名が変化してきている，（3）そもそも正しい規則が何であるかを定めることが難しい，といった状況にあり，ブラウザによって実装が違っている。例えば，トップ・レベル・ドメインを指定したクッキーはどのブラウザでも受け入れられないが，セカンド・レベル・ドメイン以降を指定したクッキーは，受け入れるブラウザとそうでないものがある。比較的メジャーと思われる.co.jpドメインでも，次のように実装のばらつきがある。どの実装が正しいという定義がないことが致命的な問題になっているのであろう。
例：.co.jp指定時の各ブラウザの挙動
| IE6.0 | 受け入れない |
| FireFox 2.0.0.11 | 受け入れる |
| Opera 9.24 | 受け入れない |
ここで，もう一度問題を整理してみよう。図1の例では，http://example9.co.jp上の攻撃者が，http://example.co.jpのサイトに送信されるクッキーを，ユーザーのブラウザにセットしている。これは望ましい挙動ではないが，仕様上は可能である。.co.jpドメインを利用するサイトでは，管轄の異なるサイト上でセットされたクッキーが送信されてくる可能性を考慮する必要があるわけだ。.co.jp ドメインを攻撃者が取得することはないだろうから，「問題ないのではないか」と思うかもしれない。ただ，ぜい弱性を持つ.co.jpドメイン上のサイトを踏み台としたクッキーのセットが可能であることを軽視するわけにはいかない。
実は，この問題の解決策は，RFC2965 のセクション7.2「Cookie Spoofing」で提案されている（関連RFC2964）。これは，新しいクッキー・フォーマットであるSet-Cookie2について記載されたドキュメントである。ここで推奨されているアプローチは，ブラウザが
Cookie: $Version="1"; sid="1jk3fas31"; $Domain=".co.jp "
というフォーマットでクッキーを送信し，サーバーは送られてきたドメイン属性が意図したものであるかを確認するというものである。ネットスケープ仕様のフォーマット
Cookie: sid=1jk3fas31;
と比べてみると，欠落していた情報であるドメイン属性が，送り返されていることが分かるだろう。
この実装では，example0.co.jpのサーバーは，example0.co.jpをドメイン属性としてクッキーを発行する。送られてきたクッキーのドメイン属性が別サイト上で発行された.co.jpである場合，受け入れを拒否することができる。このアプローチを採用すれば，問題の大半を根本的に解決することができるはずだ。ただ現状では，Set-Cookie2をサポートしているメジャーなブラウザはOperaだけ。これを持って解決とする訳にはいかないのが実情である。
こうした現状を踏まえた上で，セッション・フィクセーションの問題に対する解決策を挙げておこう。対策は，ログイン成功時に古いセッションIDを無効化し，セッションIDを再発行することである。
ログイン機能だけを意識すればいいなら，これが正統な対策と言えるだろう。この対策により，ログイン情報を保持した新しいクッキーはユーザーのブラウザにだけ通知され，攻撃者には未知の値となる。このため，なりすましは成立しない。ただ，セッション・フィクセーションの問題は，ログイン機能だけでは完結しないケースがある。この問題については，次回解説する。
|
