HTTPとHTTPSを併用しログイン後の画面遷移はHTTPSしか許可しないサイトでの安全なセッション管理その３

Security ASP.NET

HTTPとHTTPSを併用しログイン後の画面遷移はHTTPSしか許可しないサイトでの安全なセッション管理その２ - masaのメモ置き場
の続き

セッション管理に使用するCookieと認証状態の管理に使用するCookieが独立して存在するため、認証CookieにSecure属性を設定することで、認証後のセッションデータを保護することが出来るという概念です。
この仕組みが安全に動作するならば、ログイン時にSecure属性付きのセッションCookieを再発行することが難しくてもサイトの安全性を守ることが可能となります。

と書きましたが、この仕組みは、どちらかというと危険な動作をします。ASP.NETが使用するCookieは以下の2種類で構成されますが、それぞれが紐付けされた状態で管理されていないことが要因です。

  • 認証状態を管理するCookie - AuthCookie(名称は任意) ログインしたユーザIDを保持する
  • セッションを管理するCookie - ASP.NET_SessionID セッション変数へアクセスするためのキーとなる

この仕組みは、以下の攻撃に対し耐性がありませんので、セッション変数が漏えいする危険性があります。

  1. サイトへログインすることが可能な攻撃者が、攻撃者のアカウントでAuthCookieを取得
  2. 正規ユーザのSecure属性を持たないASP.NET_SessionIDを盗聴
  3. 攻撃者が持つAuthCookieと盗聴したASP.NET_SessionIDを組み合わせてサイトへアクセスする

従って、この実装ではHTTPとHTTPSの併用サイトで安全なセッション管理を行うことが出来ません。

1年程前マイクロソフトにこの問題について問い合わせてみましたが、

  • この仕組み単体を捉えて脆弱性であるとみなすことはない
  • ASP.NET_SessionIDに盗聴の危険がある場合、重要な情報をセッション変数に保持させるべきではない
  • 重要な情報をセッション変数に格納する場合、ASP.NET_SessionIDをSecure属性付きで発行すべきである

との見解のようです。

この攻撃が成功する要因は、「認証状態を管理するCookieとセッションを管理するCookieが紐付けされていない」ことにあります。紐付けすることにより問題が解決するならば、相応の実装を取ることでサイトの安全性を守ることが可能となります。