技術/HTTP/セッション固定化関連メモ(SessionFixation,SessionAdoption) (v1)

技術 / HTTP / セッション固定化関連メモ(SessionFixation,SessionAdoption) (v1)

id: 1009 所有者: msakamoto-sf 作成日: 2011-08-21 14:51:42
カテゴリ: HTTP ネットワーク

[ Prev ]
[ Next ]
[ 技術 ]

自分用メモ：

セッション識別子に重要情報を紐付ける時に、「格納前のセッション識別子を無効化＋新しいセッション識別子を発行」処理を行っていないとセッション固定化に脆弱。
「セッション識別子」は複数のCookieやFormPOSTパラメータの組み合わせの場合もある。セッションを引き継ぐパラメータのセットとして考え、どれか一つでもずれれば引き継げないとすれば、セットに含まれる全てのパラメータが変化しないのであれば脆弱、どれか一つでも格納前後で無効化＋更新されるのであれば問題とならない。
- 攻撃者はセットに含まれる全てのパラメータを被害者にセットし、重要情報がセッション識別子に紐付けられた後も、セットに含まれる全てのパラメータが同じでないと、被害者と同一のセッションを維持できないと考えられるため。（どれか一つでも不正であればログイン画面にリダイレクトされる、等）
「重要情報」の最たるものが「識別情報」なので、主に話題となるのが「認証前後のセッション固定化」となる。認証前の画面フローであっても、メールアドレスや住所など重要情報をセッション識別子に紐付ける場所があれば、セッション固定化問題の対象範囲となる。
- 金床本では「セッションの持つ価値が変化するすべての場面でセッションIDを変更する。」(p171)という解説をしている。

対策については参考資料を参照。

参考資料：

Session Fixation - OWASP
- https://www.owasp.org/index.php/Session_Fixation
Session Fixation - the Forgotten Vulnerability?
- https://www.owasp.org/images/7/7a/OWASP_AppSec_Research_2010_Session_Fixation_by_Schrank_Braun_Johns_and_Poehls.pdf
2011-06-06 - penultimate diary
- http://d.hatena.ne.jp/penult/20110606
2010-04-24 - T.Teradaの日記
- http://d.hatena.ne.jp/teracc/20100424
とくまるひろしのSession Fixation攻撃入門 - ockeghem(徳丸浩)の日記
- http://d.hatena.ne.jp/ockeghem/20090130/p1

Session Adoptionについて：

金床本、徳丸本ともにSession Adoptionはそれほど危険視していない。大垣氏のBlogでは随分と危険視されている。
- 金床本、徳丸本はあくまでもアプリケーションレイヤーだが、大垣氏はPHPという言語環境のレベルで捉えているための温度差もあるかもしれない。
- Session Adoptionがあるとしても、攻撃者がサーバから発行されたセッション識別子を取得するための一手間を減らすだけであり、Session Fixationに対する影響度は小さく、Session Fixation対策をしておくほうが優先度も高く、アプリケーションレイヤーで対策できるため、自分でPHPにパッチあてたりミドルウェアやフレームワークを修正するよりははるかに現実解として無難な落とし所と言える。

参考：

Session Adoption in Session Fixation
- http://www.ntt.com/icto/security/images/sr20100110.pdf
PHPのSession Adoptionは重大な脅威ではない - ockeghem(徳丸浩)の日記
- http://d.hatena.ne.jp/ockeghem/20090515/p1
PHP:既知のセキュリティ脆弱性 - Session Adoption
- http://blog.ohgaki.net/php-session-adoption

以下はあんまり考えがまとまりきっていない状態でのメモ：

どのような現象か？→認証前後でセッション識別子が変化しない。
「認証前後」がどのような意味を持つのか？→攻撃者が準備したセッション識別子を被害者が使い認証することで、攻撃者は同じセッション識別子を使い、被害者になりすますことが出来る。
「セッション識別子」とは何か？→サーバ側で同一の利用者であることを特定するための情報。
- "JSESSIONID"や"PHPSESSID"と同じか？→異なる。セッション識別子は必ずしもCookieで送信されるものである必要はなく、フォームに埋め込まれPOSTメソッドによりサーバに送信されたり、推奨できないがURLパラメータに埋め込まれサーバに送信される場合がありえる。
- さらに、セッション識別子は単一のKeyValueであるとは限らない。それは複数のKeyValueのセットの場合もある。
  - 例えばJSESSIONID + 独自のCookie + Formに埋め込んだToken がセットで「同一の利用者」を判断する場合もある。
  - この場合、上記3つの内どれか一つでも不正であれば利用者を特定できないような処理がなされていると想定できる。
なぜ「認証前後」なのか？例えば認証後の何かしらの更新系アクション完了部分は考慮しなくて良いのか？
- セッション固定化が脆弱性として意味を持つ本質は、攻撃者による情報の取得であると考えられる。
- どのような情報が攻撃者の目的になりうるか？
  - セッション識別子は利用者を識別する機能を持つ。
  - すなわち、識別情報の取得（なりすまし）が攻撃者の目的となりうる。
- 攻撃者がなりすましを目的としてセッション固定化を使うということは、攻撃者はまだ有効な被害者の識別情報を取得していない状態であることが前提となる。
- 認証前後にセッション固定化の脆弱性があるということは、攻撃者が所有する、まだ有効な識別情報に結びついていないセッション識別子を、被害者が認証処理を実行することで、有効な識別情報に結びつけることが出来ることを意味する。
- では、例えば攻撃者が自分の識別情報にすでに結び付けられているセッション識別子を、被害者に使用させることに意味はあるのか？
  - 意味が無い可能性が高い。例えば、Webページ上には認証済みの識別情報（ログイン名）を表示しているだろう。被害者が、攻撃者のセッション識別子をセットされた状態でアクセスすると、「誰か見知らぬ人がログインしている状態」に見えるだろう。そして恐らく、ログアウトをした後、自分のアカウントでログインし直すだろう。よほど画面設計に問題があり誰がログインしているのか分からない、という状態でない限り、他人のアカウントでログインされている状況で、「被害者が」、その後有意義なアクションを行うとは考えづらい。(その逆を行うのが攻撃者の目的となる)
さらに認証情報を広義の「重要情報」と考えれば、認証前の画面フローであっても、メールアドレスや住所などをセッション識別子に紐付けるような箇所があれば、そこはセッション固定化問題の対象範囲に含まれると考えられる。
もう少し考えると、セッション識別子は厳密には「識別情報」となり、認証前後で変化するのは識別情報(=セッション識別子)にひもづけられた「認証状態」という重要情報である、と考えることが出来る。