Cookie Monster Bugによる典型的な影響は、セッションIDの固定化攻撃を受けやすくなることです。
対策として、全てのサイトにおいて、Webアプリケーション側でセッションIDの固定化対策(後述)を実施することを推奨します。
調査結果
| 第1分類 | 第2分類 | 属性型JP ドメイン | 地域型JPドメイン | ||
| 第2レベル | 第3レベル | ||||
| モ バ イ ル | ケータイWeb | iモード | |||
| Ezweb | × | × | |||
| Softbank(1) | × | × | |||
| Softbank(2) | |||||
| PCサイト ビューア | docomo | ||||
| au | × | × | |||
| Softbank(1) | × | × | |||
| Softbank(2) | |||||
| Android | 標準 | × | × | ||
| Opera | × | × | × | ||
| Firefox | |||||
| iOS | 4.3.5 | ||||
| PC | IE | 6～9 | × | × | |
| Firefox | ～2.0.0.20 | × | × | × | |
| 3～ | |||||
| Google Chrome | 14.0.835.202 | ||||
| Safari | ～3.2.3 | × | × | × | |
| 4.0～ | |||||
| Opera | 5 | × | × | ||
| 6～11.0 | × | ||||
| 11.1～11.51 | × | × | × | ||
※凡例
- 地域型JPドメインの第2レベルとは、tokyo.jpなど第2レベルのドメイン名でCookieが発行できるもの
- 地域型JPドメインの第3レベルとは、chiyoda.tokyo.jpなど第3レベルのドメイン名でCookieが発行できるもの
- 背景が赤のセルは現バージョンでバグのあるもの。無色は旧バージョンの参考情報
- 携帯電話に関しては機種毎に仕様が異なる可能性が高く、全機種について調査したわけではないので、上記はあくまで抜き取りでの結果であることに注意されたし
※確認機種、バージョン等
- iモード:P-07A(iモードブラウザ2.0)で確認
- EZweb:W52T、biblioで確認（結果は同じ）。詳細は後述
- Softbank(1): 821N, 932SHで確認。これらは非公式JavaScript対応機
- Softbank(2): 944SH(公式JavaScript対応機)で確認
- Android:Xperia Arc(Android2.3.3)にて確認
- iOS:iPadで確認
- Google Chromeは最新版(14.0.835.202)でのみ確認
調査方法
携帯電話（俗に言うガラケー）は試験環境でのテストができないため、インターネット上に環境を作り、調査しました。具体的には、筆者およびHASHコンサルティング（株）の所有する地域型JPドメインtokumaru.bunkyo.tokyo.jpおよび属性型JPドメインhash-c.co.jp上で発行するCookieを用いて調査しました。Cookie Monster Bugが再現することを調査するためには、上記とは別のドメイン名で動作するサイトがあると確実です。このため、下記サイトの協力を得て調査を行いました。
- tricorder.co.jp : 株式会社トライコーダ上野宣氏にご協力いただいた
- otsuka.bunkyo.tokyo.jp : 左記サイト管理人の上田氏にご協力いただいた
EZwbbについての補足
現状のEZwebでは、HTTP通信の場合、ゲートウェイ（EZサーバー）上にてCookieが保管されます。今年の秋冬モデル以降の機種では、Cookieは常に端末に保存されるようになるようです（下記参照）。このゲートウェイのdomain属性の挙動を調査した結果、独特の仕様であることが分かりました。以下、例示により説明します。
Webサイト http://www.example.co.jp/ において、以下をdomain属性としてCookieを発行する場合。
domain=co.jp
domain=.co.jp
domain=example.co.jp
domain=.example.co.jp
domain=www.example.co.jp
この際、有効となるCookieは、domain属性が .example.co.jp と www.example.co.jpのもののみです。また、このCookieは、example.co.jpドメインのサブドメインのうち、4レベルのサブドメイン（Cookieを発行したホストと同じレベルのドメイン）のみが受け取れます。すなわち、受け取れるホストを例示すると以下の通りです。
Cookieを受け取れるホスト
www.example.co.jp
home.example.co.jp (domain=.example.co.jp のCookieのみ)
a.example.co.jp (domain=.example.co.jp のCookieのみ)
Cookieを受け取れないホスト
example.co.jp
hohe.www.example.co.jp
ここまでであれば、EZwebのCookieの仕様が独自というだけで、Cookie Monster Bugではありません。しかし、以下の例はCookie Monster Bugです。
例1: example.co.jpで発行された domain=.co.jp のCookieは、hash-c.co.jpにも tricorder.co.jp にも送信される。www.hash-c.co.jpやwww.tricorder.co.jpには送信されない。
例2:tokumaru.bunkyo.tokyo.jpで発行されたdomain=.bunkyo.tokyo.jpのCookieは city.bunkyo.tokyo.jpやotsuka.bunkyo.tokyo.jpには送信される。www.city.bunkyo.tokyo.jpやwww.otsuka.bunkyo.tokyo.jpには送信されない。
結果として、EZwebのゲートウェイのCookie処理にはCookie Monster Bugがありますが、ドメイン名そのものをホスト名とするサイトのみが影響を受けます。サブドメイン（www.example.co.jpなど）をホスト名として運用していれば、影響は受けません。
また、第1レベルのドメイン(TLD)について、domain指定することはできません。例えば、domain=.jpと指定したCookieは無効となります。
Operaについての補足
Operaは独自の方法でCookie Monster Bugに対応していると言われていました（参考：金床著「ウェブアプリケーションセキュリティ」）が、調査してみると、全てのバージョン（バージョン5以降）でCookie Monster Bugがあることがわかりました。不思議なことに、Operaバージョン6～11.0では、ごく限定的なパターン(3レベルの地域型JPドメイン)のみCookie Monster Bugがあったのに、バージョン11.10～11.51（本稿執筆時点の最新版）では、属性型JPドメインと、2レベルの地域型JPドメインのCookie Monster Bugが追加されてしまっています。しかも、Opera11以降で導入されたアドレスバー上のドメイン強調表示を見ると、属性型JPドメイン、地域型JPドメインとも正しいドメイン名を強調表示しています。それにもかかわらず、Cookie Monster Bugがある原因は不明です。
現在、属性型JPドメインでCookie Monster Bugがあるブラウザは、EZwebのゲートウェイをのぞくと、全てOperaです。auのPCサイトビューアもOperaでした。
影響
Cookie Monster Bugによる典型的な影響はセッションIDの固定化攻撃(Session Fixation Attack, CWE-384)の影響を受けやすくなることです。WebアプリケーションにセッションID固定化の脆弱性がある場合、「なりすまし」の結果、以下の影響があります。- 利用者の重要情報（個人情報、メールなど）の閲覧
- 利用者の持つ権限での操作（送金、物品購入など）
- 利用者のID によるメール、ブログなどへの投稿、設定の変更など
サイト側対策
全てのサイト（Cookie Monster Bugの有無に関わらず）に対して以下を推奨します。- セッションIDとトークン以外をCookieとして保存しない
- ログイン成功後にセッションIDを変更する、あるいはトークンによる対策を行う
- セッションID以外をCookieに保持している場合、外部サイトから値をセットされた場合の影響を分析し、必要な対処を行う*1
*1:「体系的に学ぶ 安全なWebアプリケーションの作り方」では、セッションID以外にCookieに保存する例として、セッションID固定化対策、Cookieのセキュア属性不備対策に用いるトークンがありますが、これらのトークン(Cookie)に関してはCookie Monster Bugのセキュリティ上の影響はありません。
詳しくは以下を参照ください。
想定問答集
Q1:Cookie Monster Bugはブラウザの脆弱性なのか
A1:判断の分かれるところですが筆者はブラウザの脆弱性であると考えます
ブラウザ等インターネット対応のソフトウェアの処理内容は、RFCの規定に従うことになっています。Cookieの規定は、元々はNetscape社の仕様（archive.orgで参照、有限会社futomiによる参考訳）があり、その後RFC2109（1997年）、RFC2965（2000年）が発行されましたが、実際にはこれらのRFCは普及せず、Netscape社のオリジナル仕様が広く使われていました。このため、現在広く使われているCookieの利用形態を文書化するような形で、RFC6265が今年の4月に発行されました。このRFC6265には、Cookie Monster Bugに関連する記述として、4.1.2.3. The Domain Attribute と 5.3. Storage Model があります。このうち、4.1.2.3の末尾を以下に引用します。
NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes". For example, some user agents will reject Domain attributes of "com" or "co.uk".参考訳：
セキュリティ上の理由から、多くのユーザエージェント（注:ブラウザのこと）は、public suffixと一致するDomain属性を拒否するように構成されます。 たとえば、いくつかのユーザエージェントは、「com」または「co.uk」のDomain属性を拒否します。public suffix（effective top level domain; eTLD）については、高木浩光氏のエントリ「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」の中に説明があります。上記の記述にあるように、Cookie Monster Bugへの対処はRFC6265上のmustやshouldの規定ではなく、参考情報のような扱いになっています。したがって、RFC6265を根拠として、Cookie Monster Bugが脆弱性であると判定することはできません。
しかしながら、Cookie Monster BugによるセッションID固定化の主要因は、Cookie Monster Bugそのものにあると考えられ、ブラウザ側で対処しないので、やむを得ずWebアプリケーション側で対処している状況と筆者は理解しています。
すなわち、Cookie Monser Bugはブラウザの脆弱性ではあるが、歴史的には、Netscape/Firefox、Safriに当該問題があり、現在でもIEでは完全に対処していないことは広く知られており、やむを得ずWebアプリケーション側で対応している、というのが筆者の理解です。
Q2:セッションIDの固定化以外の脅威はないの?
A2:セッションIDの固定化以外にも若干の問題があります
最近のブラウザには、URL中のドメイン名を強調表示する機能があります。これはフィッシング詐欺に対する保護機能として提供されるものです。IE9の該当機能の説明を引用します（ドメインの強調表示 - Microsoft Windowsより）。
詐欺的な Web サイトを回避する方法の 1 つに、アクセスしようとしている Web サイトのアドレスを正しく理解することが挙げられます。 Internet Explorer 9 にはドメインの強調表示機能があり、アドレス バーでドメイン名を強調表示することで正しい URL かどうかがひとめでわかります。 これにより、偽の URL でユーザーをだまそうとする詐欺的なサイトを注意でき、個人情報が漏えいする可能性を減らすことができます。
しかし、地域型JPドメインの場合、この機能は誤動作します。以下は大田区のホームページと筆者の所有する地域型JPドメインのIE9でのアドレスバーの表示です。
大田区ホームページのアドレスバー表示
tokumaru.bunkyo.tokyo.jpのアドレスバー表示
どちらもtokyo.jpが強調表示されていますが、これは誤りで、4レベルを強調表示するべきです。以下にOpera11.51での表示例を示します。
大田区ホームページのアドレスバー表示
tokumaru.bunkyo.tokyo.jpのアドレスバー表示
前述のように、Opera11.51には属性型JPドメインと地域型JPドメインのCookie Monster Bugがありますが、アドレスバーの強調表示は正しく行われています。なぜそうなっているかは不明です。
IEのケースに戻ると、ドメイン名の強調表示が誤っているため、フィッシング詐欺対策としてはかえって逆効果になると考えられます。意図的に、city.xxxx.xxxx.jpと紛らわしいドメイン名（例えば、cify.xxxx.xxxx.jp）を取得することで、地方公共団体のホームページと紛らわしいサイトを運営することができます。
さらに、今後JPRSが提供を予定している都道府県型JPドメインであれば、実在しない市名により、city.xxxx.xxxx.jp（xxxx.xxxxは市名と紛らわしいドメイン名）の運用が可能になると考えられます。アドレスバーのドメイン名強調表示は、このような詐欺行為に対して有効なはずですが、以下の理由により、有効に機能しないと予想されます。
- 長年地域型JPドメインに対応していないIEが、さらに複雑なルールの都道府県型JPドメインに直ちに対応するとは考えにくい
- 対応ブラウザであっても、ドメイン名のルールがややこしすぎて一般市民には理解困難
同一生成元ポリシーの解説は、「体系的に学ぶ 安全なWebアプリケーションの作り方」を参照ください。
Q3:属性型JPドメインは使わない方がよいのか
A3:どのタイプのドメイン名を利用するかは、Cookie Monster Bugの有無だけではなく総合的に判断する必要があり、下記理由から属性型JPドメインの利用を推奨します
産総研が公表している「産総研 RCIS: 安全なWebサイト利用の鉄則」には、利用者をフィッシングの手口から守るためのドメイン名に対する要件として、以下を挙げています。
- サービス提供者が保有するドメイン名を使う
- まぎらわしくないドメイン名を使う
- ドメイン名を利用者に周知する
従って、属性型JPドメインに対するCookie Monster Bugが一部のブラウザに存在するというだけの理由から属性型JPドメインを避けることはバランスに欠いた判断であり、属性型JPドメインを選択した上で、セッションID固定化対策をするのがよいと考えます。
Q4:地域型JPドメインは使わない方がよいのか
A4:Webサイトを運用するドメイン名としては、特別な理由がない限り地域型JPドメインは使わない方がよいと考えます
Cookie Monster Bugの対処はWebアプリケーション側で可能とはいえ、セッションIDの固定化脆弱性はまだあまり知られていない脆弱性であり、未対処のサイトが多いと予想されます。そのような状況下で、地域型JPドメインを積極的に利用する理由は見あたりません。属性型JPドメインのように、組織を識別しやすい特性があるわけでもないし、Cookie Monster Bugのあるブラウザの種類も増えてしまいます。また、前述のように、IEではドメイン名の強調表示が誤動作します。
このような状況下では、地域型JPドメインでのWebサイトの運用は避けた方が賢明であると考えます。
Q5:都道府県型JPドメインについての所見は?
A5:地域型JPドメインと同じ理由から、Webサイトのドメイン名としては避けた方がよいと考えます
現状のブラウザの実装状況から判断して、都道府県型JPドメインの登場は、現在の状況をさらに混乱させると予想します。そのような状況下で、Webサイトを運営するドメイン名として都道府県型JPドメインを選択することは当面避けるべきと考えます。
Q6:Cookie Monster Bugはドメインの問題ではなくて、Cookie仕様やブラウザの実装の問題ではないのか?
A6:その通りです
Cookie Monster Bugは前述のようにブラウザのバグであり、Cookieの仕様（RFC6265）に起因するものです。長期的には、これらが改善されるべきであると筆者は考えます。
しかしながらRFC6265は、RFC2965の発行から10年以上経ってようやく発行されたこと、長い間IEの地域型JPドメインのCookie Monster Bugが改善されていない実績などから、今後すぐにCookieの仕様やブラウザのCookie実装が改善される見通しに関しては悲観的に考えざるを得ません。
筆者はWebアプリケーションのセキュリティを専門とするコンサルタントであり、現在のWebの仕様や関連ソフトウェア（Webサーバー、開発言語、ブラウザ等）の状況を受け入れた上で、Webアプリケーションを安全にする方法を示すことが使命と考えます。この文書は、そのような立場で書いています。
地域型JPドメインや（将来の）都道府県型JPドメインを避けた方が良いというのは、あくまでも現状のブラウザにおけるCookieの実装を是認するという想定での話です。例えば、メールサーバーのドメイン名としてこれらドメイン名を用いる場合や、WebやCookieにとらわれない新しいテクノロジーを用いる場合は、上記は該当しません。
Q7:ケータイWebではCookieを使わない方が良いのか
A7:Cookie Monster Bugの存在に関わらず、今後はケータイサイトもCookieによるセッション管理に移行すべきと考えます。
Cookie以外のセッションIDの埋め込み場所としては、URLやケータイIDがありますが、いずれもセキュリティ上の課題があり、その解決は容易ではありません。これに対して、Cookie Monster Bugの対応は比較的容易です。
また、従来Cookieの使えないiモードブラウザ1.0の存在がCookie対応を難しくしていましたが、最近になって状況が変わってきました。最近のiモードブラウザ1.0のシェアを「モバイルサイトの3キャリア共通CSSと最新コーディング事情 - livedoor ディレクターブログ」から、調べてみます。
このエントリによると、ケータイWebのアクセスシェアでiモードは46.4%、そのうちiモードブラウザ1.0のシェアは30.9%ということです。これにより、ケータイWeb中のiモードブラウザ1.0のアクセスシェァは、約14%となります。ケータイの世界でも、そろそろCookie対応機種にのみ対応することを検討してもよい状況になってきたと言えます。
14%を切り捨てるのが忍びない場合でも、Cookieの使えない場合のみURLにセッションIDを埋め込むこともできます。詳しくは以下を参考にしてください。
Q8:Cookie Monster BugによりCookieの盗聴はできるの?
A8:できません
Q9:余計なCookieの削除はしなくてよいの?
A9:余計なCookieの削除は必須ではありません
Cookie Monster Bugを用いた攻撃の結果、攻撃者から注入されたCookieとアプリケーションが発行するCookieが同じ名前で複数登録された状態になります。これに対して、余計なCookieを削除するべきかどうかという質問です。
セッションIDの固定化攻撃への対策としては、余計なCookieを削除は必須ではありません。しかし、同名Cookieがブラウザから送られることにより、アプリケーションが誤動作する可能性はあります。詳しくは以下の参考サイトをご覧ください。
この対処としては、余計なCookieの削除の他に、複数のCookie（セッションIDなど）を検知して、もし複数の同名Cookieがあれば、エラーとして処理を停止する実装も考えられらます。すなわち、同名Cookieについては以下の3種類の実装が可能です。
- 何もしない（セッションIDの振り直は行う）
- 認証成功時に余計なCookieを削除する
- 同名Cookieを検知してエラーとする
これら実装には一長一短があるため、サイト運営者の判断により仕様を決定することになります。
Q10:私の管理するサイトにセッションIDの固定化脆弱性があるかどうすれば分かりますか?
A10:ログイン前後でセッションIDが変化するかどうかで判定できます
この問題を含めてWebアプリケーションの簡易的な脆弱性検査の目的に「ウェブ健康診断仕様」が利用できます。仕様書は財団法人地方自治情報センターのサイトからダウンロードできます。セッションIDの固定化は、同仕様書K-1に記述されています。
Q11:色々ややこしくてよく分からないんだけど、私のサイトが問題ないか調べてもらえませんか?
A11:未承諾広告※個別サイトの問題についてはHASHコンサルティング株式会社のサービスがご利用いただけます
HASHコンサルティング株式会社では、上記のような調査結果をブログや寄稿記事、勉強会における講演等の形で広く公開しております。これらの情報は無料でご利用頂けます。
一方、サイト個別の特性に応じた調査が必要な場合や、セキュリティ担当者がいないなど、公開した情報だけでは個別の問題に対して判断ができない場合は、HASHコンサルティング株式会社の有償サービスがご利用頂けます。問い合わせはこちらの問い合わせフォームからお願い致します。
0 件のコメント:
コメントを投稿