雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|
2024|06|
2025|01|

2009-11-13 [長年日記]

[Firefox]Firefoxのセッション管理とSingle Sign-On

[11/15] 他のブラウザの挙動について追記

OpenIDやSAMLなどのSSOシステムは対応するサービスも出揃い、一般化しているというほどではありませんが、あちこちで見かけるようになってきました。しかしこれらのSSOサービスをFirefoxで利用する場合には注意する必要があります。というのは、Firefoxには3年以上前にバグとして指摘されているにもかかわらず、放置され続けているセッションに関する仕様があるためです。

Session Restore remembers logins from session cookies

この仕様、当初はクラッシュ時のセッションリカバリの話ということで、べつにそれでいいんじゃない?という方向でいったん落ち着いたようです。

ところがその後、セッションリカバリ機能はこの仕様を残したまま、通常の終了・起動時における「前回終了時のウィンドウとタブを表示する」というオプションへと昇格してしまいました。

セッションリカバリ

これはまずいと感じた人により、再びバグとして昨年7月に登録されていますが、セッションのリカバリ機能はそもそもそういうものだという意見もあり、修正されないまま今日に至っています。

"Save and Quit" tabs should not save session cookies of to-be-restored tabs

どういう問題か?

Firefoxの起動オプションとして「前回終了時のウィンドウとタブを表示する」を選択していると、ブラウザの終了時に破棄されるべき Max-Age(Expire)が省略されたクッキーが保存されてしまい、次回起動時にそうしたクッキーを使っているログインセッションが復活してしまうというものです。

例えば、適当なWebサービスで以下のような手順を踏むことで確認できます。

  1. 起動オプションを「前回終了時のウィンドウとタブを表示する」にする
  2. Webサービスにログインする(この時、次回以降の自動ログイン機能がWebサービス側にある場合、オフにします)
  3. Firefoxを終了する(コンピュータを再起動する)
  4. Firefoxを再起動して先ほどのWebサービスにアクセスすると、認証手続きなしでログインできてしまう

SSOでは何が起きるか。

上記の例は、あくまで1つのサービスの中で起きる話でしたが、SSOが絡むと複数のサービスに認証無しでログインできてしまうようになります。

  1. SSO認証に対応しているサイトにログインする
  2. 上記認証サービスに対応しているWebサービスを使う
  3. Firefoxを終了する(コンピュータを再起動する)
  4. Firefoxを再起動する
  5. SSOに対応している任意のサービスにログインし、1.でログイン済みのサイトを認証サービスとして指定すると、認証手続き無しでログインできてしまう

Firefoxのセッション管理機能は、ブラウザを閉じたときに開いていたサイトだけでなく、閉じる瞬間に開いていたウィンドウ、タブの履歴に含まれる全てのサイトについてもクッキーを保存するため、このような問題が生じます。

ちなみに、SSOに限らずいったん認証に成功した後、ログアウトせずにまったく関係の無い他のページに移った場合でもセッション情報は残るため、1つのウィンドウ(タブ)であちこち巡回すると、どこのサイトのセッション情報が残っているのか非常に分かりにくい仕様になっています。

SSOサービス側の事情

この問題については、認証機能を含む1つのサービスであれば、サーバ側のセッションタイムアウトを適当な長さに設定することによりある程度は回避できます。ところが、SSOの認証サービスではそうは行かない事情があります。

SSOの利用シーンは、だいたい次のような手続きで進みます。

  1. ユーザーがアプリケーションサービスにアクセスする。
  2. アプリケーションサービスから認証サービスにリダイレクトする。
  3. 認証サービスで認証に成功すると、アプリケーションサービスに再びリダイレクトされる。
  4. アプリケーションサービスを利用する。
  5. 別のアプリケーションサービスを利用する場合、最初からの手順を繰り返す。

この時、ユーザーは大半の時間を4.のアプリケーション上で過ごすため、認証サービスから見た場合、ユーザーのアクセス間隔は極端に長くなります。このため、認証サービスではタイムアウトの設定が難しいのです。というより、SSOサービスはそもそも1度認証すれば対応する全てのサービスを使えるというのが売りのひとつなので、むしろタイムアウトを設けずに、ブラウザの終了時に認証セッションも終了するというのがいちばん理にかなった姿のように思います。

SSLのばあい

認証サービスのクッキーにsecure属性が付いてていれば、デフォルトの状態では問題ありません。ただ、私が調べたOpenID対応認証サービスではsecure属性が付いていないものがありました。

上で「デフォルトの状態では」と書きましたが、Firefoxではsecure属性の付いたクッキーも保存するオプションがあります。

  1. about:configを開く
  2. browser.sessionstore.privacy_levelを0にする

上記設定でsecure属性がセットされているクッキーも保存されるようになり、SSLのログインセッションも保持されます。これはSSOに限らない話なので、非常に危険な設定です。

こんな設定をわざわざする人はいないだろうと思っていたのですが、この設定、クッキーだけでなくフォームの入力内容の保存オプションも兼ねており、某有名blog他で、blogの編集途中でもブラウザを閉じられる便利な設定例の一部として紹介されているため、そうとは知らずに設定してしまっている人が結構いるのではないかと心配しています。

設定変更が容易

仮にOS自体もオートログインの設定になっていると、こうした危険な設定の変更を防ぐ方法が無いというのも問題です。職場や学校などで、ちょっと席を外している間に設定を変えておき、ターゲットが帰った後にマシンを再起動して、じっくりと操作するといったことも可能になります。

ネットカフェやホテル等の設置端末はほとんど触ったことが無いのですが、Firefoxがインストールされていて、起動時に前回終了時っぽい画面が出てきたらかなり危険でしょう。

他のブラウザとの挙動の比較

比較のため、IE(8.0.6001.18702)、Opera(10.01)、Safari(4.0.4)でセッションの復元がどうなっているか確認しました。まず、それぞれのブラウザでのセッションの復元設定については、以下のようになっています。

IE8
起動後、[ツール]→[最終閲覧セッションを再度開く(S)]で前回終了時に開いていたタブを復元することができます
Opera
デフォルトの設定が「前回終了時の状態を復元する」になっています
Safari
セッションの復元機能は標準では無いようです

次にセッションの復元機能があるブラウザで、以下の手順によりセッションの復元がどのようになるか確認しました。

  1. ブラウザを起動してはてなにログインする
  2. ブラウザを終了させる
  3. ブラウザを再起動して、前回のセッションを復元させる
  4. はてなのページをリロードして、ログイン状態を確認する

結果、ログインセッションが復元されたのはFirefoxだけでした。

まとめ

ということで、Firefoxではログアウトせずにブラウザを閉じるような使い方をしていると危険です。SSOではログインしていなかったサービスにまで影響が及ぶため、この仕様が変更されるまでは注意する必要があるでしょう。

ユーザー側でできる対処として、以下が考えられます。

  • ブラウザの終了前にきちんとログアウト手続きを踏む
  • SSOの場合、認証サービス側でもログアウトする
  • 1つのタブ(ウィンドウ)では1つのサービスだけ使うという方法を徹底する

あとは

  • SSOサービスは使わない
  • Firefoxは使わない

などでしょうか(^^;