#idcon 17thで発表した内容に２つの内容が含まれていましたが、これはOAuth 2.0のCSRF対策の部分だけを抜き出したものです。

1. OAuth2.0のCSRF対策拡張を
考えて導入した話
Ryo Ito(@ritou)
2013/11/29
#idcon Vol.17
#idcon vol.17
1

2. 本発表の内容
• “OAuthのセキュリティ強化を目的とする拡
張仕様を導入しました”
– http://alpha.mixi.co.jp/2013/12020/
#idcon vol.17
2

3. CSRF
（Cross Site Request Forgeries）
#idcon vol.17
3

4. CSRF脆弱性を持つ
日記投稿サービス
• ユーザー認証機能あり
• 投稿フォームからPOSTリクエストにより日記
コンテンツをWebサーバーに送信
• Webサーバーは受け取ったコンテンツをログ
イン中のユーザーの日記として保存、公開
#idcon vol.17
4

5. 日記投稿サービス
に対するCSRF例
3. 日記投稿サービスは、悪意のある
サービスからのリクエストをユーザーAの
投稿として処理
ユーザーA
日記投稿サービス
2. 悪意のあるサービスが
日記投稿サービスにリクエストを送る
1. 悪意のあるサービスに誘導される
（spamメール、メッセージ、攻撃者が
投稿した日記の中のリンクなどから）
#idcon vol.17
悪意のあるサービス
5

6. リスク
• ユーザーが意図しない投稿をされるおそれ
• 投稿された日記に悪意のあるサービスへの
誘導用リンクが入っていたら、次から次へと...
#idcon vol.17
6

7. 日記投稿サービスがとるべき
CSRF対策
• セッションIDを投稿フォームのhiddenパラメー
タに含む
– 攻撃者は第3者のセッションIDを知らない
• リクエストを受け取ったら、セッションIDの値を
検証する
#idcon vol.17
7

8. 日記投稿サービスがとるべき
CSRF対策
3. 日記投稿サービスは、リクエスト中の
セッションIDとユーザーAのセッションを
検証し、不正なリクエストをブロック！
ユーザーA
日記投稿サービス
2. 悪意のあるサービスが
日記投稿サービスにリクエストを送る
1. 悪意のあるサービスに誘導される
（spamメール、メッセージ、攻撃者が
投稿した日記の中のリンクなどから）
#idcon vol.17
悪意のあるサービス
8

9. CSRF脆弱性を持つ
ログインサーバー
• ログインフォームからPOSTリクエストにより
ID/パスワードをWebサーバーに送信
• Webサーバーは受け取ったID/パスワードを
検証し、有効な組み合わせであればログイン
処理を行う
#idcon vol.17
9

10. ログインサーバー
に対するCSRF例
3. ログインサーバーは、
悪意のあるサービスからのリクエストを
ユーザーAのログイン試行として処理
ログインサーバー
2. 悪意のあるサービスが
ログインサーバーに攻撃者の
ID/PWを送る
ユーザーA
1. 悪意のあるサービスに誘導
#idcon vol.17
悪意のあるサービス
10

11. リスク
• 攻撃者のアカウントとしてログインさせられて
しまう
• その後、気付かずに保存したデータなどに攻
撃者からアクセスされる可能性
– プライベートな画像
– 住所情報
– クレジットカード情報など
#idcon vol.17
11

12. ログインサーバーがとるべき
CSRF対策も同じ
• セッションIDをログインフォームのhiddenパラ
メータに含む
– 攻撃者は第3者のセッションIDを知らない
• リクエストを受け取ったら、セッションIDの値を
検証する
#idcon vol.17
12

13. ここまでは一般的な話
• Web Application Frameworkで対策されてい
るものもある
#idcon vol.17
13

14. OAuth 2.0とCSRF
• 認可フローにおけるCSRFのリスクとは
• まずは認可フローの復習から
#idcon vol.17
14

15. Client
ユーザーA
Server
0. 認可処理開始
1. 認可要求
2. リソースアクセスを許可
3. 認可応答
認可コード
ユーザーAの
セッションに
紐付く
OAuth 2.0の認可フロー
4.アクセストークン
取得
認可コード
アクセストークン
15

16. OAuth 2.0におけるCSRF
• 第3者(もしくは第3者のセッション)に攻撃者の
アクセストークンを紐づけさせようとする攻撃
• 標的となるユーザーのセッション上で自らの
認可応答をClientに渡す
#idcon vol.17
16

17. 標的
攻撃者
ユーザーB
ユーザーA
Client
Server
0. 認可処理開始
1. 認可要求
認可応答を
ユーザーBの
セッションで
処理させる
2. リソースアクセスを許可
3. 認可応答
認可コード
ユーザーAの
アクセストークンが
ユーザーBの
セッションに紐付く
4.アクセストークン
取得
認可コード
アクセストークン
OAuth 2.0の認可フローにおけるCSRF
17

18. リスクはログインのCSRFと同等
• その後のAPIアクセスで取り扱われるデータ
はServerにとっては攻撃者のものとなる
• OAuthを認証に使っている場合は攻撃者に
アカウントを乗っ取られる可能性もある
• 攻撃者としては認可応答のURLを他人のブ
ラウザで実行されるだけでよい
#idcon vol.17
18

19. stateパラメータによる対策
• Clientがセッションに紐づくstateパラメータを
生成
• Clientがstateパラメータを認可要求に指定
• Serverが認可応答にstateパラメータを指定
• Clientがstateパラメータとセッションの整合性
を検証してからトークンを取得する
#idcon vol.17
19

20. Client
ユーザーA
0. 認可処理開始
1. 認可要求
Server
ユーザーAの
セッションに
紐付くstateを
払い出す
state
2. リソースアクセスを許可
3. 認可応答
認可要求に
含まれるstateを
そのまま指定
認可コード state
stateがユーザーAの
セッションに紐づくことを
検証 -> 成功
4.アクセストークン
取得
認可コード
アクセストークン
OAuth 2.0の認可フロー(stateパラメータあり)
20

21. 標的
攻撃者
ユーザーB
ユーザーA
Client
0. 認可処理開始
1. 認可要求
Server
ユーザーAの
セッションに
紐付くstateを
払い出す
state
認可応答を
ユーザーBの
セッションで
処理させる
2. リソースアクセスを許可
3. 認可応答
認可コード state
stateが
ユーザーBの
セッションに
紐づくことを
検証 -> 失敗
OAuth 2.0の認可フローにおけるCSRF (stateパラメータあり)
21

22. Clientの実装に依存
• Clientがセッションに紐づくstateパラメータを
生成
• Clientがstateパラメータを認可要求に指定
• Serverが認可応答にstateパラメータを指定
• Clientがstateパラメータとセッションの整合性
を検証してからトークンを取得する
#idcon vol.17
22

23. Clientの実装をどう信用するか
• 認可要求にstateパラメータつけないかも
• 認可要求にstateパラメータがついてきても、
セッションに関係しない値を利用してるかも
• 認可要求にstateパラメータがついてきても、
認可応答の値を検証してないかも
これらをServer側で動的に確認することは困難
#idcon vol.17
23

24. Server側で対策をとれる拡張
• Serverがserver_stateパラメータを生成
• Clientがserver_stateパラメータをセッション
に紐づけ、認可要求に指定
• Serverが認可コードにserver_stateパラメー
タを紐付け、認可応答には含まない
• Clientはセッションに紐づくserver_stateを認
可コードとともに送り、トークンを要求する
• Serverは認可コードとserver_stateを検証
#idcon vol.17
24

25. Client
ユーザーA
0. 認可処理開始
セッションと
server_stateを
紐付け
Server
1. server_state取得
server_state
2. 認可要求
server_state
3. リソースアクセスを許可
4. 認可応答
認可コード
セッションと紐づく
server_state
を指定
5.アクセストークン
取得
認可コード
認可コードと
server_stateを
紐付け
認可コードと
server_stateの
検証に成功
server_state
アクセストークン
OAuth 2.0の認可フロー(server_stateパラメータあり)
25

26. 標的
攻撃者
ユーザーB
ユーザーA
Client
0. 認可処理開始
セッションと
server_stateを
紐付け
Server
1. server_state取得
server_state
2. 認可要求
認可応答を
ユーザーBの
セッションで
処理させる
server_state
3. リソースアクセスを許可
4. 認可応答
認可コード
ユーザーBの
セッションと紐づく
5.アクセストークン
取得
認可コード
server_state
server_state
を指定
OAuth 2.0の認可フローにおけるCSRF (server_stateパラメータあり)
認可コードと
server_stateの
検証に失敗
26

27. ポイント
• Clientが実装を省略できない
– server_stateをセッションと紐付けて管理しなけ
ればアクセストークンを取得できない
#idcon vol.17
27

28. ネイティブアプリへの適用
• Client Credentialが安全に管理できない状況
における”認可応答の奪取”の問題
割愛
– redirect_uriを被せて認可応答を受け取る手口
• Authorization Code Grant + server_stateを
利用することで、認可要求を作成したClient
のみがトークンを取得できる
– Client Secretは空でよい
#idcon vol.17
28

29. 導入状況
• OAuth 2.0の認可を利用するしくみに導入
– mixi Graph API/mixiアプリ/mixiページアプリ
• 既存のClientへの影響から、server_stateパ
ラメータの利用は任意
• API(scope)単位で必須化を検討中
– お金や大事な情報を扱うAPIへの認可
– 認証連携のためのAPIへの認可
#idcon vol.17
29

30. まとめ
• 既存のstateパラメータによる対策に課題を感
じていた
• server_stateを用いた拡張を導入した
• この拡張の利用はOpenID Connect用の
scopeなどで必須化したい
#idcon vol.17
30

31. 終わり
•
•
•
•
•
Ryo Ito (@ritou)
株式会社ミクシィ
OIDF-J エヴァンジェリスト : http://openid.or.jp/
Blog : http://d.hatena.ne.jp/ritou/
Gihthub : https://github.com/ritou
#idcon vol.17
31