今更聞けないOAuth2.0

OAuth2.0ってなんだっけ？を自分なりにまとめてみました。
Slideshare はこちら
http://www.slideshare.net/ph1ph2sa25/oauth20-46144252

Transcript

1. 今更聞けない OAuth2.0 presented  by  @white_aspara25
2. 自己紹介   •  @white_aspara25   •  istyle.inc  エンジニア（自称）   •  ここ1年は ハノイ@ベトナム で  Bridgeエンジニ アとして働いてました
3. 話す内容 1.  OAuth  ってなに？   2.  OAuth2.0  システム仕様   3.  セキュリティ対策
4. 話さない内容 1.  OAuth1.0  の仕様   2.  XAuth  の仕様   3.  OpenID  Connect  
5. 話す内容 1.  OAuth  ってなに？   2.  システム仕様   3.  セキュリティ対策
6. OAuth ?
   おーす
7. OAuth  って？ ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル
8. OAuth  って？ ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル
9. ೝূ or  認可 ?
10. 認証？ •  英：AuthenFcaFon   「誰？」　を確認するのが目的 「認証（にんしょう）とは、何かによって、対象の正当性を確認する行為を 指す」   「相手認証とは、ある人が確かに本人であると納得させる事をいう」   by  Wikipedia
11. 認可？ •  英：AuthorizaFon   「リソースのアクセス権を指定する機能であり、（中略）特にアクセス制 御と関係性が深い」 by  Wikipedia 「何ができる？」　を確認するのが目的
12. OAuth  =  認可 のプロトコルです。   「誰か？」を確認する目的のものではありません。
13. OAuth  =  認可 のプロトコルです。   「誰か？」を確認する目的のものではありません。 ＝ OpenID  Connect  （今回は説明しません）
14. OAuth  って？ ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル
15. OAuth  って？ ※認証ではなく、認可です   HTTP  上で 何ができる？ を確認するためのプロトコル
16. 例 投稿サイトA SNS 投稿 自動投稿 スマホで撮影した愛猫の写真   サイトAに投稿したら、自動でSNSにも投稿したい！ として
17. 一番簡単な方法 投稿サイトA SNS ID/PW ログイン 投稿
18. 一番簡単な方法 投稿サイトA SNS ID/PW ログイン 投稿 の  ID/PW  を保持している
19. But...
20. それ、アカンやつや •  サイトA  はユーザの許可がなくても   SNS  の情報が見れてしまう •  SNS  のパスワードを変更   =>  サイトAのパスワードも変更が必要   •  ID/PW漏洩のリスク                      etc...   問題大有りです。
21. OAuth
    そこで
22. OAuth  を使った方法 投稿サイトA SNS 1.  ユーザはSNSにサイトAからの投稿を許可（＝認可）   サイトAからの投稿許可
23. OAuth  を使った方法 投稿サイトA SNS 1.  ユーザはSNSにサイトAからの投稿を許可（＝認可）   2.  ユーザの許可を受けてSNSはトークンを発行   サイトAからの投稿許可 トークンを発行
24. OAuth  を使った方法 投稿サイトA SNS 投稿 1.  ユーザはSNSにサイトAからの投稿を許可（＝認可）   2.  ユーザの許可を受けてSNSはトークンを発行   3.  投稿サイトAはトークンを使ってSNSに投稿   サイトAからの投稿許可 投稿 トークンを発行
25. OAuth  を使った方法 投稿サイトA SNS 投稿 1.  ユーザはSNSにサイトAからの投稿を許可（＝認可）   2.  ユーザの許可を受けてSNSはトークンを発行   3.  投稿サイトAはトークンを使ってSNSに投稿   サイトAからの投稿許可 投稿 トークンを発行 No  more  ID/Password SNS  の  ID/PW  をサイトAは知らなくても良い！
26. ◦◦ができる を証明するもの トークン ＝ ◦◦ ＝ ××のサービス上で △△の代わりに 投稿（メッセージ、写真、、） 閲覧（個人情報、友達、、） 注意点
27. ◦◦ができる を証明するもの トークン ＝ ◦◦ ＝ ××のサービス上で △△の代わりに 投稿（メッセージ、写真、、） 閲覧（個人情報、友達、、） 注意点 ただのチケット   ＝本人じゃなくても使える   ＝本人証明にならない
28. ◦◦ができる を証明するもの トークン ＝ ◦◦ ＝ ××のサービス上で △△の代わりに 投稿（メッセージ、写真、、） 閲覧（個人情報、友達、、） 注意点 用法用量を守って   正しくお使いください
29. サイトA まとめると サイトB ◦◦する 発行 として この一連のフローを仕様に落としたのが OAuth サイトAを認可 の代わりに 「サイトB」上で ◦◦  ができる証明書
30. 話す内容 1.  OAuth  ってなに？   2.  OAuth2.0  システム仕様   3.  セキュリティ対策
31. OAuth2.0 •  AuthorizaFon  Code  Grant   •  Implicit  Grant   •  Resource  Owner  Password  CredenFals  Grant   •  Client  CredenFals  Grant   ４種類のトークン　　 発行フロー
32. OAuth2.0 •  AuthorizaFon  Code  Grant   •  Implicit  Grant   •  Resource  Owner  Password  CredenFals  Grant   •  Client  CredenFals  Grant   ４種類のトークン　　 発行フロー 今回は取り扱いません
33. AuthorizaFon  Code  Grant •  認可コードグラント、とも   •  サーバ間通信のような、トークンを秘密保持できる場合 に使われる   •  一般的な  web  アプリはコレ Implicit  Grant •  トークンを秘密保持できない場合に。   •  スマホアプリや Javascript  はコレ。  
34. AuthorizaFon  Code  Grant
35. AuthorizaFon  Code  Grant  処理の流れ Webアプリ
36. AuthorizaFon  Code  Grant  処理の流れ 1.  ユーザー認可リクエスト 「　　が　　　から　　　に投稿したいって 言ってるんだけど」 Webアプリ
37. AuthorizaFon  Code  Grant  処理の流れ 「問題ないっす！　　 認めてやって！」 「　　に確認するからちょい待って」 Webアプリ
38. AuthorizaFon  Code  Grant  処理の流れ 認可コードの発行＆送付 「@　　：　　の確認取れたわ。 発行するから　　に取りにきて。   トークンの引換券はこれな：　　　　　　」 認可コード 認可コード
39. AuthorizaFon  Code  Grant  処理の流れ 「つ 　　のトークン　　おくれ。」 認可コード 「　　 ね。はいよ　　」 Webアプリ 2.  アクセストークンリクエスト
40. AuthorizaFon  Code  Grant  処理の流れ 「つ 　として　　　を投稿しておくれ」 「OK.  したよ 」 Webアプリ
41. AuthorizaFon  Code  Grant ポイント
42. ポイント 　　は　　　　　　と引き換えに　　 を発行 認可コード Webアプリ 　　はリクエストしてきた　　　の認証チェック
43. ポイント 　　は　　には渡らない 側で管理 ＝ 秘密保持可 Webアプリ
44. Implicit  Grant
45. Implicit  Grant  処理の流れ ネイティブアプリ
46. Implicit  Grant  処理の流れ ネイティブアプリ 1.  認可要求 「　　が　　　から　　　に投稿したいって 言ってるんだけど」
47. Implicit  Grant  処理の流れ ネイティブアプリ 「問題ないっす！　　 認めてやって！」 「　　に確認するからちょい待って」
48. Implicit  Grant  処理の流れ ネイティブアプリ トークンの発行＆送付 「@　　：　　の確認取れたわ。 はい、これ使って　　　。」
49. Implicit  Grant  処理の流れ ネイティブアプリ 「つ 　として　　　を投稿しておくれ」 「OK.  したよ 」
50. Implicit  Grant ポイント
51. Implicit  Grant  処理の流れ ネイティブアプリ は　　の確認が取れたらすぐ　　を発行 の認証をしない分、簡単
52. Implicit  Grant  処理の流れ ネイティブアプリ そのため、redirect  URI  の事前登録は必須 ＝ 異なる  redirect  URI  はエラーに  
53. Implicit  Grant  処理の流れ ネイティブアプリ 　　は　　に渡るため、漏れる可能性がある ＝ 秘密保持不可
54. 話す内容 1.  OAuth  ってなに？   2.  OAuth2.0  システム仕様   3.  セキュリティ対策
55. Case1.  CSRF
56. CSRF 1)  攻撃者は通常の手順でSPの認可まで行う   2)  認可後のリダイレクト先の  URI  を取得し、被害者に アクセスさせる   手法 リスク ・ 第3者の　　アカウントと連携   　＝第3者がログイン可能   　＝　　アカウントの乗っ取り   ・ 第3者のアカウントとしてログインさせられる   ー 個人情報やクレカ情報を登録したら、第3者に知られてしまう  
57. CSRF Webアプリ 攻撃者 攻撃者は正規の方法で認可コードの発行まで行い   のリダイレクト先のURIを取得
58. CSRF Webアプリ 攻撃者 攻撃者は、入手した  URI  に他の人がアクセスするよう仕向ける   （他者のブラウザで実行さえできれば良いので、ブログに貼るなど） 被害者
59. CSRF Webアプリ 攻撃者 被害者の　　　アカウント から 攻撃者の　　　アカウント に対する   トークン　　　発行依頼   被害者
60. CSRF Webアプリ 攻撃者 　　は 攻撃者の　　　アカウント に対するトークン　　を発行   ⇒    被害者の　　　アカウント と 攻撃者の　　　アカウント が紐付く   被害者
61. CSRF Webアプリ 攻撃者 攻撃者は自分の　　　アカウントでログイン   被害者の　　　上の情報を取得   被害者
62. 対策（Consumer） 「ユーザー認可リクエスト」   「アクセストークンリクエスト」   この2つが同じセッションかをチェック   state  パラメータを使う  
63. CSRF  対策 Webアプリ 攻撃者 state    値を含めて「ユーザ認可リクエスト」を投げる 被害者 state 　　は攻撃者のセッションに基づいて    state    値を発行  
64. CSRF  対策 Webアプリ 攻撃者 　　は被害者のセッションに基づく    state    値を発行   被害者 state state 認可リクエスト時の    state    値が引き回される state
65. CSRF  対策 Webアプリ 攻撃者 最初に発行した    state    と被害者の    state    値と比較   ⇒  検証に失敗！ 被害者 state state state
66. Case2.  redirect  URI  の改ざん
67. redirect  URI  の改ざん 「ユーザー認可リクエスト」と「アクセストークンリクエスト」で   異なる  redirect  URI  を指定       攻撃者にアクセストークンを抜き取られ、被害者の個人情報に アクセスされる、など   手法 リスク
68. redirect  URI  の改ざん 「ユーザー認可リクエスト」と「アクセストークンリクエスト」で   異なる  redirect  URI  を指定       SP  に  redirect  URI  の事前登録をしない場合に発生 ※Implicit  Grant  はSP  への  redirect  URI  の事前登録が必須なので、AuthorizaFon   Code  Grant  に限られる 手法 条件
69. redirect  URI  の改ざん Webアプリ 攻撃者 攻撃者は予め、正規の　　　を使って 「ユーザ認可リクエスト」 を発行   （　　　 が設定している 「ユーザ認可リクエスト」 の  URI  を取得）
70. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者 被害者を先ほど入手した  URI  にアクセスさせる    ただし、redirect  URI  は攻撃者のConsumer  のものに差し替える  
71. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer redirect  URI  の事前登録がないので   チェックをスルー 被害者
72. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer redirect  URI  に指定されたように   攻撃者の  Consumer  に到達 被害者
73. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 攻撃者は、最初に入手した   正しい  redirect  URI  に差し替えてリクエスト 被害者
74. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者 　　の本来のリクエストと同じなのでチェックを通過   　　は攻撃者の  Consumer  を　　　と誤認し、トークンを発行
75. redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者 攻撃者がトークンを取得   SP  上の被害者の情報にアクセスが可能
76. 対策（SP） 1)  redirect  URI  の事前登録をしておき、登録の あるURIと同じかチェック   2)  「ユーザー認可リクエスト」と   　　「アクセストークンリクエスト」で     　　redirect  URI  が一緒かチェック  
77. redirect  URI  の改ざん 対策 Webアプリ 攻撃者  Consumer 予め登録のある  redirect  URI  ではない   ⇒  検証失敗！ 被害者
78. redirect  URI  の改ざん 対策 Webアプリ 攻撃者  Consumer 被害者 「ユーザ認可リクエスト」の時と異なる  redirect  URI  が   「アクセストークンリクエスト」で設定されている   ⇒  検証失敗！
79. 他にも・・・
80. 攻撃例 •  Consumer  のなりすまし   •  オープンリダイレクタ   •  Implicit  Grant  におけるトークン置き換え   などなど・・・（説明は逐次追記します）  
81. まとめ
82. まとめ •  OAuth  とは認可のプロトコル   •  トークンはあくまで「何ができるか」を証明する もの。「誰か」を証明するものではない   •  トークンは第三者でも使用可能。漏れないよ うに充分に配慮する   •  セキュリティ上の配慮する点が多数。 Consumer  としても  SP  としても対策を怠らない こと  
83. 参考 •  hZp://openid-­‐foundaFon-­‐japan.github.io/ rfc6749.ja.html   •  hZp://www.slideshare.net/charlier-­‐shoe/ oauth-­‐20-­‐29540466   •  hZp://www.atmarkit.co.jp/ait/arFcles/1209/10/ news105.html   •  hZp://www.slideshare.net/ritou/idcon17-­‐oauth2-­‐ csrfprotecFonritou   •  hZps://speakerdeck.com/ritou/openid-­‐ connectwoyong-­‐iteidlian-­‐xi-­‐woshi-­‐zhuang-­‐surutokiniqi-­‐ wofu-­‐kerukoto-­‐number-­‐yapcasia   •  hZp://developer.yahoo.co.jp/yconnect/client_app/