ログイン前セッションフィクセイション攻撃の脅威と対策

ログイン前セッションフィクセイション 攻撃の脅威と対策 HASHコンサルティング株式会社 徳丸 浩 twitter id: @ockeghem Copyright © 2013 HASH Consulting Corp.

モデルのアプリケーション 入力画面 メールアドレス foo@pexample.jp セッション変数にメールアドレスがあれば、 修正のため入力欄にフィルする 確認 POST <input name=”mail” value=”foo@example.jp”> 確認画面 メールアドレス:foo@example.jp 戻る メールアドレスをセッション変数に保存 $_SESSION[’mail’]=$_POST[’mail’]; 登録 確認画面から登録画面にはセッションで受け渡し 登録画面 メールアドレスを登録しました セッション変数空メールアドレスを取り出し $mail=$_SESSION[’mail’]; Copyright © 2013 HASH Consulting Corp. 2

セッションIDを強制できると秘密情報が漏えい 攻撃者のPC 攻撃者がセッションIDを取得 何らかの方法で セッションをセット 正規サイト 攻撃者用セッションID 攻撃者のセッションID のまま個人情報を入力 被害者 攻撃者のセッション 被害者の 個人情報 あらかじめ取得した セッションIDでアクセス 被害者の個人情報閲覧 Copyright © 2013 HASH Consulting Corp. 3

なんらかの方法って何? • よく言われるのは以下のいずれかの場合 – セッションIDがURL埋め込みになっているサイト（ケータイサイト等） – セッションIDがPOSTパラメータの場合（あまり見ない） – 地域型JPドメイン名、都道府県型JPドメイン名のサイト • CookieにセッションIDがあり、汎用JPドメイン名や、.COM等 の場合は気にしなくていいのでは? Copyright © 2013 HASH Consulting Corp. 4

No! SSLを使っているサイトの場合は駄目 Copyright © 2013 HASH Consulting Corp. 5

通信路上に攻撃者がいる光景 通信路上の攻撃者 正規サイト 攻撃者がセッションIDを取得 ワナでHTTP ページに誘導 被害者 攻撃者用セッションID http://example.jp 攻撃者のセッション Set-Cooki: …. https://example.jp HTTPSは盗聴・ 改ざんできない evil … Copyright © 2013 HASH Consulting Corp. 被害者の 個人情報 example.jp 6

なぜSSLの場合だけ? • SSL使う場合だけ脆弱となるのは違和感があるが… • SSL使わない場合、通信路上に攻撃者がいると、 セッションフィクセイション脆弱性がなくても、 セッションIDを盗聴することで、なりすましは可能 • SSLを採用しないサイトは、通信路上の攻撃者はいないもの と見なしている（安全な回線で使ってね。ﾆｺｯ） • SSLを使用しているサイトは通信路から攻撃に対処しているこ とが想定される（お・も・て・な・し♡）ので、通信路からの攻撃で 盗聴・改ざん等ができてはいけない • そうでないと…当サイトはSSLを使用してお客様の通信を安 全に暗号化しています。ただし、通信路上に攻撃者がいる場 合には、その限りではありません …となってしまう Copyright © 2013 HASH Consulting Corp. 7

ログイン前セッションフィクセイションの対象サイトは? 1. 未ログインの状態でセッション変数に秘密情報を保持 かつ 2. セッションIDを外部から強制できる（以下は例） – – – – URLにセッションIDを埋め込んでいるサイト 地域型JPドメイン名、都道府県型JPドメイン名上のサイト SSLを使用しているサイト Cookie書き換えできる脆弱性(XSS、HTTPヘッダインジェクション 等)を持つサイト – 同じドメインのサブドメイン上にCookie書き換えできる脆弱性があ るサイトがある場合 例: sub.example.jp にXSS脆弱性やHTTPヘッダインジェクション 脆弱性があると、www.example.jp もCookieをセット可能 – … • 2.はきりがないので、1.が該当するならば、ログイン前セッショ ンフィクセイション脆弱性対策するのが良い Copyright © 2013 HASH Consulting Corp. 8

デモ ワナサイト kawaguchi.tokyo.jp IEはdomain=tokyo.jpの ドメインを受け入れる (Cookie Monster Bug) 被害者 ワナを閲覧 攻撃者用 セッションID 正規サイト urayasu.tokyo.jp 被害者の 個人情報 PHP 5.5.6 session.use_strict_mode=1 Copyright © 2013 HASH Consulting Corp. 9

対策案(1) 入力ページの前の「入り口ページ」でセッションIDを振り直す 被害者 入口 入力画面 登録を始めます 入力 foo@pexample.jp 確認 確認画面 foo@pexample.jp 登録画面 登録しました 登録 セッションID を振り直す Copyright © 2013 HASH Consulting Corp. 10

対策案(1)の対抗策 ワナサイトから入力画面にショートカットして誘導する 被害者 ワナサイト 入力画面はこちら 誘導 入口 入力画面 登録を始めます 入力 foo@pexample.jp 確認 確認画面 foo@pexample.jp 登録画面 登録しました 登録 セッションID を振り直す Copyright © 2013 HASH Consulting Corp. 11

対策案(2) 対策案(1)に加え、トークンにより画面遷移を制限する ワナサイト 被害者 入力画面はこちら 誘導 入口 入力画面 登録を始めます 入力 確認画面 foo@pexample.jp foo@pexample.jp token 確認 登録画面 token 登録 登録しました token セッションID再生成 トークン生成 Copyright © 2013 HASH Consulting Corp. 12

対策案(2)の対抗策 クッキーとトークンを正規サイトから取得して、入力画面に強制 被害者 ワナサイト 入力画面はこちら token Cookie 誘導 入口 入力画面 登録を始めます 入力 確認画面 foo@pexample.jp foo@pexample.jp token 確認 登録画面 token 登録 登録しました token セッションID再生成 トークン生成 Copyright © 2013 HASH Consulting Corp. 13

ではどうすれば良いか? • リクエスト毎に毎回セッションIDを振り直すというアイデア – 安全だが、1回でもレスポンスを取りこぼすと、セッションが無効に なってしまう – 過去のセッションを有効なまま残せば、前画面の状態までは戻れる – 過去のセッションを残すことの妥当性に関する議論 • 実は、リクエスト毎にセッションIDを振り直す必要はない • セッション変数に秘密情報をセットする場合のみ、セッションID を振り直せばよい – 秘密情報をセットする前のセッションは、攻撃者のセッションを引き 継いでいるだけなので、漏れても害はない • あるいは、ログイン前にはセッションを開始しないで、hidden パラメータでデータを引き回す【推奨】 Copyright © 2013 HASH Consulting Corp. 14

まとめ • ログイン前セッションフィクセイション脆弱性は、意外に多くの サイトが対象となる • ログイン前セッションフィクセイションの脅威は、セッションに格 納された秘密情報の漏洩など • 「外部からCookieをセットする攻撃経路」は多様であり、もれ なくつぶすことが困難 • ログイン前にはセッションを開始しないことを推奨 • やむを得ずログイン前にセッションを開始する場合は、 セッション変数に秘密情報をセットするページで、 セッションIDを振り直す Copyright © 2013 HASH Consulting Corp. 15

Thank you Copyright © 2013 HASH Consulting Corp. 16