Cookieにはdomain属性が付きものだ
取りあえずの処置はできたが、同じ現象がまたすぐに起こらないとも限らない。星野君はCookieが2つ送信されていた原因を探ってみることにした。
しかし、自席に戻ってWeb管理ツールにアクセスしてみても、やっぱりCGISESSIDのCookieは1つしかない。新しくSet-Cookieされたら、当然新たなCookieが上書きされる。
星野君 「おかしいなぁ……」
そう星野君がつぶやくと、高橋さんが話し掛けてきた。
高橋さん 「どうしたの？何か悩んでるみたいだねぇ」
星野君 「町田さんにWeb管理ツールにログインできなくなったっていわれて見に行ったんですけど……。Cookieがなんか変なふうになってたんですよね」
高橋さん 「変なふうってどういうこと？」
星野君 「えっとですね……」
星野君は「malicious_cookie」という値のCookieがセットされていてセッション管理ができなくなってしまっていたことを説明した。
高橋さん 「へぇ〜〜、そんなことがあるんだね。そういうイタズラってあんまり聞いたことないなぁ」
星野君 「そうなんですよー。調べ方もよく分かんないし……」
高橋さん 「ま、でも、大体原因は想像つくけどな」
星野君 「え！ホントですか？？」
高橋さん 「うん。きっとCookieのdomain属性が違うから同じ名前で2つ送信されてるんだよ」
WebブラウザにCookieがセットされるとき、Cookieにはdomain属性というものが付けられる。特に指定がない場合はアクセスしているWebサーバのホスト名、指定がある場合はアクセスしているURLのドメイン名に後方一致していればそのdomain属性で保存される。
例えば、「www.example.com」であれば、「www.example.com」や「example.com」のドメインに対してcookieを指定できる（「.com」のような特別なトップレベルドメインには指定できない）。「www.example.com」にアクセスする際には、ドメイン属性が「www.example.com」になっているCookieを送信するが、「example.com」にアクセスする際には、ドメイン属性が「www.example.com」や「example.com」など後方一致するものが複数存在すれば、同じ名前のものであってもすべて送信する実装になっているようだ。
星野君 「あー、そうなんですか。あんまりそういうパターン見ないから気にしたことなかったですよ。なるほど……」
Cookie Monsterに襲われたFirefox
星野君は一瞬納得しかけたが、あることに気が付いた。
星野君 「けど、違うドメイン属性付けようと思ったら、うちの場合、.co.jpにCookieを指定することになると思うんですけど……。.co.jpドメインってCookie設定できないんじゃないですか？？」
高橋さん 「町田さんの使ってたWebブラウザ、もしかしてFirefoxじゃなかった？Firefoxなら.co.jpでもCookie指定ができるんだよ」
星野君 「え！？そうなんですか？？初めて知りましたよっっ！高橋さんって実は結構詳しいんですね！」
高橋さん 「あ……、うん、まあね」
星野君 「これって有効な対策あるんですかねぇ」
高橋さん 「う〜ん、対策かぁ……」
MozillaやFirefoxでは.co.jpなどの属性型ドメイン名に対してCookieを受け入れる仕様になっている。また、Internet Explorerでは.tokyo.jpなどの地域型ドメイン名に対してCookieを受け入れる仕様になっている。この仕様を悪用してCookieを操作する攻撃は、「クロスドメインクッキーインジェクション（Cross-Domain Cookie Injection）」または「Cookie Monster」などと呼ばれている。
例えば、example.co.jp上のWebアプリケーションにおいて、攻撃者がユーザーのWebブラウザに.co.jpのドメイン属性のCookieをセット【注1】したとしよう。
【注1】
攻撃者が.co.jpドメインのWebサイトを用意する必要はなく、Cookieを操作できるクロスサイトスクリプティングなどの脆弱性がある.co.jpドメインのWebサイトを踏み台にすることで攻撃が成立する
そのとき、ユーザーがexample.co.jp上にあるWebアプリケーションを利用しようとすると、Webブラウザは攻撃者によってセットされたセッションIDでログインを試みてしまう。もしもユーザーがログインに成功したならば、攻撃者はそのセッションIDを使ってWebアプリケーションにアクセス可能となり、なりすましを行うことができてしまう。
このような攻撃は一般的に「Session Fixation（セッション固定）」と呼ばれている。通常のセッション固定攻撃に対しては、ログイン時にWebアプリケーション側で以前のセッションIDを無効にし、新しいセッションIDに付け替えることで対策ができるが、クロスドメインクッキーインジェクションを利用したセッション固定の場合はそう簡単にはいかない。
攻撃者がセットしたCookieをCookieA（.co.jpドメイン）とし、WebアプリケーションがセットしたCookieをCookieB（www.example.co.jpドメイン）とする。ユーザーがWebアプリケーションにアクセスした際にCookieAが使われているとき、ログイン成功時にWebアプリケーション側でCookieをセットし直しても、明示的に.co.jpドメインを指定しない限りCookieBを付け替えるだけになる。この結果、CookieAとCookieBが共存する形となり、Webアプリケーションは引き続きCookieAを読み込もうとする（Webアプリケーション側のセッション管理の実装により、挙動は異なる場合がある）。
こうなってしまうと、WebアプリケーションがCookieAを受け付けてしまう場合はなりすましによる被害が発生し、CookieAを受け付けない場合はログインができないという被害のいずれかの影響を受けることとなってしまう。
Copyright © ITmedia, Inc. All Rights Reserved.