セッションフィクセイション脆弱性の影響を受けやすいサイトとは

最近、セッションフィクセイション脆弱性に対する関心がなぜか高まっています。同脆弱性は割合地味な脆弱性であり、話題になることはあまりありません。そこで、関心の高いこの時期に、セッションフィクセイション脆弱性の影響を受けやすいサイトについて説明し、注意を喚起したいと思います。

セッションフィクセイション脆弱性とは

セッションフィクセイション（セッションIDの固定化）脆弱性は、なんらかの方法で利用者（被害者）のブラウザ上でセッションIDを強制的に指定して、その後利用者がログインしたタイミングで、攻撃者が「ログイン済みのセッションID」を知ることができるという脆弱性です。「安全なウェブサイトの作り方(改訂第五版)」P17から図を引用します。

図の「2.何らかの方法で自分が取得したセッションIDを利用者に送り込む」手法は、安全なウェブサイトの作り方では説明されていません。そこで、以下に「セッションIDを利用者に送り込む」手法について説明します。

セッションIDを送り込む方法(1) URL埋め込みのセッションID

携帯電話向けコンテンツなどで、セッションIDをURLに埋め込んでいるサイトがあります。この場合は、セッションIDを埋め込んだURLをリンクとして用意しておき、利用者に閲覧させるだけでセッションIDを送り込むことができます。
しかし、この場合、利用者が罠のリンクを踏んだ後、他のサイトに遷移する前に攻撃対象サイトにログインしないと、セッションフィクセイション攻撃は成立しません。

セッションIDを送り込む方法(2) Cookieに保存したセッションID

多くのWebサイトでは、セッションIDをCookieに保存しています。この場合、ブラウザかWebアプリケーションに脆弱性があれば、セッションIDを利用者のCookieに送り込むことができます。

(1)ブラウザのバグ（Cookie Monster Bug）
IEには、地域型JPドメイン名および都道府県型JPドメイン名に対して、Cookie Monster Bugというバグ（脆弱性）があります。たとえば、domain=tokyo.jpという属性のCookieをIEは受け入れてしまいます。
都道府県型JPドメイン名は、日本に住所を持つ個人・法人なら誰でも取得できるため、攻撃者がexample.tokyo.jpを取得して、そこに domain=tokyo.jp 属性のCookieをセットする罠を仕掛け、例えばwww.metro.tokyo.jp（東京都のホームページ）にも有効なセッションIDを利用者に「送り込む」ことが可能です（東京都のホームページはあくまで一例です）。

(2)CookieをセットできるWebアプリケーション脆弱性
攻撃対象のサイトにXSS脆弱性や、HTTPヘッダインジェクション脆弱性があると、そのサイトの利用者にCookieを送り込むことができる場合があります。
XSSやHTTPヘッダインジェクション脆弱性は単独でもなりすまし攻撃可能な場合が多いのですが、例えばリダイレクト処理にHTTPヘッダインジェクション脆弱性がある場合、「HTTPボディにJavaScriptは埋め込めないが、Cookieのセットならでき」ます。この場合、HTTPヘッダインジェクション攻撃とセッションフィクセイション攻撃の合わせ技で、なりすましができることになります。

(3)サブドメインを踏み台にした攻撃
当該サイトに脆弱性がなくても、同じドメイン上の別ホストに脆弱性がある場合、脆弱性のあるホスト上でセットしたCookieによりセッションフィクセイション攻撃ができます。これはブログ記事「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」で攻撃例として示した方法です。

また、地域型JPドメイン名や都道府県型JPドメイン名の上のサイトにXSSやHTTPヘッダインジェクション脆弱性がある場合、同じ都道府県に有効なCookieをセットして、同じ都道府県の地域型JPドメイン名や都道府県型JPドメイン名のサイトにセッションフィクセイション攻撃を仕掛けることができます。たとえば、サイトexample.tokyo.jpにXSS脆弱性がある場合、これを悪用して domain=tokyo.jpのCookieを指定することにより、例えばwww.metro.tokyo.jp（東京都のホームページ）にも有効なセッションIDを「送り込む」ことが可能です。

影響を受けやすいサイト

ここまで、セッションフィクセイション攻撃の経路を示しました。上記から、セッションフィクセイション攻撃の影響を受けやすいサイトは下記に示す性質のものです。

• URLにセッションIDを埋め込んでいるサイト
• 地域型JPドメイン名または都道府県型JPドメイン名を用いているサイト
• サブドメイン形式のレンタルサーバー
• サブディレクトリ形式のレンタルサーバー
• 同じドメイン上に脆弱なサイトがある（可能性の高い）サイト
• HTTPヘッダインジェクション（などCookie設定可能な）脆弱性のあるサイト

対策

ここまで「セッションIDを送り込む」方法と、それが可能な条件を示しましたが、条件に該当するサイトが直ちに危険という訳ではありません。一般的に、「セッションIDが送り込まれてしまう」ことを防ぐことは困難な場合があるため、これを受け入れ、「セッションIDが送り込まれてもセッションハイジャックはされない」ように対策することが一般的です。
その方法は、「安全なウェブサイトの作り方」(P19)に下記のように書かれています。

ログインが成功した時点から新いセッションを開始する（新しいセッションIDでセッション管理をする）ようにします。また、新しいセッションを開始する際には、既存のセッションIDを無効化します。

PHPでこれを実現するには、ログイン成功直後に下記を実行します。

session_regenerate_id(true);

これは容易に実現できるため、セッションフィクセイション攻撃を受けやすいか否かに関わらず、かならず上記を実施するようにしましょう。影響の受けやすさを検討しなければならないケースとしては、既存サイトが上記対策を実施しておらず、かつ対策がすぐにできない場合です。その場合は、セキュリティの専門家にチェックをしてもらうとよいと思いますが、セッションフィクセイション脆弱性に関してはとっとと直してしまった方が安い気がします。


[PR]Webサイトのセキュリティ施策はHASHコンサルティング株式会社まで