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

2. モデルのアプリケーション
入力画面
メールアドレス 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

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

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

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

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

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

8. ログイン前セッションフィクセイションの対象サイトは?
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

9. デモ
ワナサイト
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

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

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

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

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

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

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

16. Thank you
Copyright © 2013 HASH Consulting Corp.
16