今更聞けないOAuth2.0
•
97 likes•69,104 views
OAuth2.0まとめ speakerdeck はこちら↓ https://speakerdeck.com/satot/jin-geng-wen-kenaioauth2-dot-0#
今更聞けないOAuth2.0
- 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 上で 何ができる？ を確認するためのプロトコル
- 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は知らなくても良い！
- 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 はコレ。
- 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アプリ
- 44. Implicit Grant
- 46. Implicit Grant 処理の流れ ネイティブアプリ 1. 認可要求 「 が から に投稿したいって 言ってるんだけど」
- 47. Implicit Grant 処理の流れ ネイティブアプリ 「問題ないっす！ 認めてやって！」 「 に確認するからちょい待って」
- 52. Implicit Grant 処理の流れ ネイティブアプリ そのため、redirect URI の事前登録は必須 ＝ 異なる redirect URI はエラーに
- 54. 話す内容 1. OAuth ってなに？ 2. OAuth2.0 システム仕様 3. セキュリティ対策
- 55. Case1. CSRF
- 56. CSRF 1) 攻撃者は通常の手順でSPの認可まで行う 2) 認可後のリダイレクト先の URI を取得し、被害者に アクセスさせる 手法 リスク ・ 第3者の アカウントと連携 ＝第3者がログイン可能 ＝ アカウントの乗っ取り ・ 第3者のアカウントとしてログインさせられる ー 個人情報やクレカ情報を登録したら、第3者に知られてしまう
- 58. CSRF Webアプリ 攻撃者 攻撃者は、入手した URI に他の人がアクセスするよう仕向ける （他者のブラウザで実行さえできれば良いので、ブログに貼るなど） 被害者
- 59. CSRF Webアプリ 攻撃者 被害者の アカウント から 攻撃者の アカウント に対する トークン 発行依頼 被害者
- 60. 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/