Slide 1

Slide 1 text

今更聞けない OAuth2.0 presented  by  @white_aspara25

Slide 2

Slide 2 text

自己紹介   •  @white_aspara25   •  istyle.inc  エンジニア(自称)   •  ここ1年は ハノイ@ベトナム で  Bridgeエンジニ アとして働いてました

Slide 3

Slide 3 text

話す内容 1.  OAuth  ってなに?   2.  OAuth2.0  システム仕様   3.  セキュリティ対策

Slide 4

Slide 4 text

話さない内容 1.  OAuth1.0  の仕様   2.  XAuth  の仕様   3.  OpenID  Connect  

Slide 5

Slide 5 text

話す内容 1.  OAuth  ってなに?   2.  システム仕様   3.  セキュリティ対策

Slide 6

Slide 6 text

OAuth ? おーす

Slide 7

Slide 7 text

OAuth  って? ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル

Slide 8

Slide 8 text

OAuth  って? ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル

Slide 9

Slide 9 text

ೝূ or  認可 ?

Slide 10

Slide 10 text

認証? •  英:AuthenFcaFon   「誰?」 を確認するのが目的 「認証(にんしょう)とは、何かによって、対象の正当性を確認する行為を 指す」   「相手認証とは、ある人が確かに本人であると納得させる事をいう」   by  Wikipedia

Slide 11

Slide 11 text

認可? •  英:AuthorizaFon   「リソースのアクセス権を指定する機能であり、(中略)特にアクセス制 御と関係性が深い」 by  Wikipedia 「何ができる?」 を確認するのが目的

Slide 12

Slide 12 text

OAuth  =  認可 のプロトコルです。   「誰か?」を確認する目的のものではありません。

Slide 13

Slide 13 text

OAuth  =  認可 のプロトコルです。   「誰か?」を確認する目的のものではありません。 = OpenID  Connect  (今回は説明しません)

Slide 14

Slide 14 text

OAuth  って? ※認証ではなく、認可です   HTTP  上で 認可 を行うためのプロトコル

Slide 15

Slide 15 text

OAuth  って? ※認証ではなく、認可です   HTTP  上で 何ができる? を確認するためのプロトコル

Slide 16

Slide 16 text

例 投稿サイトA SNS 投稿 自動投稿 スマホで撮影した愛猫の写真   サイトAに投稿したら、自動でSNSにも投稿したい! として

Slide 17

Slide 17 text

一番簡単な方法 投稿サイトA SNS ID/PW ログイン 投稿

Slide 18

Slide 18 text

一番簡単な方法 投稿サイトA SNS ID/PW ログイン 投稿 の  ID/PW  を保持している

Slide 19

Slide 19 text

But...

Slide 20

Slide 20 text

それ、アカンやつや •  サイトA  はユーザの許可がなくても   SNS  の情報が見れてしまう •  SNS  のパスワードを変更   =>  サイトAのパスワードも変更が必要   •  ID/PW漏洩のリスク                      etc...   問題大有りです。

Slide 21

Slide 21 text

OAuth そこで

Slide 22

Slide 22 text

OAuth  を使った方法 投稿サイトA SNS 1.  ユーザはSNSにサイトAからの投稿を許可(=認可)   サイトAからの投稿許可

Slide 23

Slide 23 text

OAuth  を使った方法 投稿サイトA SNS 1.  ユーザはSNSにサイトAからの投稿を許可(=認可)   2.  ユーザの許可を受けてSNSはトークンを発行   サイトAからの投稿許可 トークンを発行

Slide 24

Slide 24 text

OAuth  を使った方法 投稿サイトA SNS 投稿 1.  ユーザはSNSにサイトAからの投稿を許可(=認可)   2.  ユーザの許可を受けてSNSはトークンを発行   3.  投稿サイトAはトークンを使ってSNSに投稿   サイトAからの投稿許可 投稿 トークンを発行

Slide 25

Slide 25 text

OAuth  を使った方法 投稿サイトA SNS 投稿 1.  ユーザはSNSにサイトAからの投稿を許可(=認可)   2.  ユーザの許可を受けてSNSはトークンを発行   3.  投稿サイトAはトークンを使ってSNSに投稿   サイトAからの投稿許可 投稿 トークンを発行 No  more  ID/Password SNS  の  ID/PW  をサイトAは知らなくても良い!

Slide 26

Slide 26 text

○○ができる を証明するもの トークン = ○○ = ××のサービス上で △△の代わりに 投稿(メッセージ、写真、、) 閲覧(個人情報、友達、、) 注意点

Slide 27

Slide 27 text

○○ができる を証明するもの トークン = ○○ = ××のサービス上で △△の代わりに 投稿(メッセージ、写真、、) 閲覧(個人情報、友達、、) 注意点 ただのチケット   =本人じゃなくても使える   =本人証明にならない

Slide 28

Slide 28 text

○○ができる を証明するもの トークン = ○○ = ××のサービス上で △△の代わりに 投稿(メッセージ、写真、、) 閲覧(個人情報、友達、、) 注意点 用法用量を守って   正しくお使いください

Slide 29

Slide 29 text

サイトA まとめると サイトB ○○する 発行 として この一連のフローを仕様に落としたのが OAuth サイトAを認可 の代わりに 「サイトB」上で ○○  ができる証明書

Slide 30

Slide 30 text

話す内容 1.  OAuth  ってなに?   2.  OAuth2.0  システム仕様   3.  セキュリティ対策

Slide 31

Slide 31 text

OAuth2.0 •  AuthorizaFon  Code  Grant   •  Implicit  Grant   •  Resource  Owner  Password  CredenFals  Grant   •  Client  CredenFals  Grant   4種類のトークン   発行フロー

Slide 32

Slide 32 text

OAuth2.0 •  AuthorizaFon  Code  Grant   •  Implicit  Grant   •  Resource  Owner  Password  CredenFals  Grant   •  Client  CredenFals  Grant   4種類のトークン   発行フロー 今回は取り扱いません

Slide 33

Slide 33 text

AuthorizaFon  Code  Grant •  認可コードグラント、とも   •  サーバ間通信のような、トークンを秘密保持できる場合 に使われる   •  一般的な  web  アプリはコレ Implicit  Grant •  トークンを秘密保持できない場合に。   •  スマホアプリや Javascript  はコレ。  

Slide 34

Slide 34 text

AuthorizaFon  Code  Grant

Slide 35

Slide 35 text

AuthorizaFon  Code  Grant  処理の流れ Webアプリ

Slide 36

Slide 36 text

AuthorizaFon  Code  Grant  処理の流れ 1.  ユーザー認可リクエスト 「  が   から   に投稿したいって 言ってるんだけど」 Webアプリ

Slide 37

Slide 37 text

AuthorizaFon  Code  Grant  処理の流れ 「問題ないっす!   認めてやって!」 「  に確認するからちょい待って」 Webアプリ

Slide 38

Slide 38 text

AuthorizaFon  Code  Grant  処理の流れ 認可コードの発行&送付 「@  :  の確認取れたわ。 発行するから  に取りにきて。   トークンの引換券はこれな:      」 認可コード 認可コード

Slide 39

Slide 39 text

AuthorizaFon  Code  Grant  処理の流れ 「つ   のトークン  おくれ。」 認可コード 「   ね。はいよ  」 Webアプリ 2.  アクセストークンリクエスト

Slide 40

Slide 40 text

AuthorizaFon  Code  Grant  処理の流れ 「つ  として   を投稿しておくれ」 「OK.  したよ 」 Webアプリ

Slide 41

Slide 41 text

AuthorizaFon  Code  Grant ポイント

Slide 42

Slide 42 text

ポイント   は      と引き換えに   を発行 認可コード Webアプリ   はリクエストしてきた   の認証チェック

Slide 43

Slide 43 text

ポイント   は  には渡らない 側で管理 = 秘密保持可 Webアプリ

Slide 44

Slide 44 text

Implicit  Grant

Slide 45

Slide 45 text

Implicit  Grant  処理の流れ ネイティブアプリ

Slide 46

Slide 46 text

Implicit  Grant  処理の流れ ネイティブアプリ 1.  認可要求 「  が   から   に投稿したいって 言ってるんだけど」

Slide 47

Slide 47 text

Implicit  Grant  処理の流れ ネイティブアプリ 「問題ないっす!   認めてやって!」 「  に確認するからちょい待って」

Slide 48

Slide 48 text

Implicit  Grant  処理の流れ ネイティブアプリ トークンの発行&送付 「@  :  の確認取れたわ。 はい、これ使って   。」

Slide 49

Slide 49 text

Implicit  Grant  処理の流れ ネイティブアプリ 「つ  として   を投稿しておくれ」 「OK.  したよ 」

Slide 50

Slide 50 text

Implicit  Grant ポイント

Slide 51

Slide 51 text

Implicit  Grant  処理の流れ ネイティブアプリ は  の確認が取れたらすぐ  を発行 の認証をしない分、簡単

Slide 52

Slide 52 text

Implicit  Grant  処理の流れ ネイティブアプリ そのため、redirect  URI  の事前登録は必須 = 異なる  redirect  URI  はエラーに  

Slide 53

Slide 53 text

Implicit  Grant  処理の流れ ネイティブアプリ   は  に渡るため、漏れる可能性がある = 秘密保持不可

Slide 54

Slide 54 text

話す内容 1.  OAuth  ってなに?   2.  OAuth2.0  システム仕様   3.  セキュリティ対策

Slide 55

Slide 55 text

Case1.  CSRF

Slide 56

Slide 56 text

CSRF 1)  攻撃者は通常の手順でSPの認可まで行う   2)  認可後のリダイレクト先の  URI  を取得し、被害者に アクセスさせる   手法 リスク ・ 第3者の  アカウントと連携    =第3者がログイン可能    =  アカウントの乗っ取り   ・ 第3者のアカウントとしてログインさせられる   ー 個人情報やクレカ情報を登録したら、第3者に知られてしまう  

Slide 57

Slide 57 text

CSRF Webアプリ 攻撃者 攻撃者は正規の方法で認可コードの発行まで行い   のリダイレクト先のURIを取得

Slide 58

Slide 58 text

CSRF Webアプリ 攻撃者 攻撃者は、入手した  URI  に他の人がアクセスするよう仕向ける   (他者のブラウザで実行さえできれば良いので、ブログに貼るなど) 被害者

Slide 59

Slide 59 text

CSRF Webアプリ 攻撃者 被害者の   アカウント から 攻撃者の   アカウント に対する   トークン   発行依頼   被害者

Slide 60

Slide 60 text

CSRF Webアプリ 攻撃者   は 攻撃者の   アカウント に対するトークン  を発行   ⇒    被害者の   アカウント と 攻撃者の   アカウント が紐付く   被害者

Slide 61

Slide 61 text

CSRF Webアプリ 攻撃者 攻撃者は自分の   アカウントでログイン   被害者の   上の情報を取得   被害者

Slide 62

Slide 62 text

対策(Consumer) 「ユーザー認可リクエスト」   「アクセストークンリクエスト」   この2つが同じセッションかをチェック   state  パラメータを使う  

Slide 63

Slide 63 text

CSRF  対策 Webアプリ 攻撃者 state    値を含めて「ユーザ認可リクエスト」を投げる 被害者 state   は攻撃者のセッションに基づいて    state    値を発行  

Slide 64

Slide 64 text

CSRF  対策 Webアプリ 攻撃者   は被害者のセッションに基づく    state    値を発行   被害者 state state 認可リクエスト時の    state    値が引き回される state

Slide 65

Slide 65 text

CSRF  対策 Webアプリ 攻撃者 最初に発行した    state    と被害者の    state    値と比較   ⇒  検証に失敗! 被害者 state state state

Slide 66

Slide 66 text

Case2.  redirect  URI  の改ざん

Slide 67

Slide 67 text

redirect  URI  の改ざん 「ユーザー認可リクエスト」と「アクセストークンリクエスト」で   異なる  redirect  URI  を指定       攻撃者にアクセストークンを抜き取られ、被害者の個人情報に アクセスされる、など   手法 リスク

Slide 68

Slide 68 text

redirect  URI  の改ざん 「ユーザー認可リクエスト」と「アクセストークンリクエスト」で   異なる  redirect  URI  を指定       SP  に  redirect  URI  の事前登録をしない場合に発生 ※Implicit  Grant  はSP  への  redirect  URI  の事前登録が必須なので、AuthorizaFon   Code  Grant  に限られる 手法 条件

Slide 69

Slide 69 text

redirect  URI  の改ざん Webアプリ 攻撃者 攻撃者は予め、正規の   を使って 「ユーザ認可リクエスト」 を発行   (    が設定している 「ユーザ認可リクエスト」 の  URI  を取得)

Slide 70

Slide 70 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者 被害者を先ほど入手した  URI  にアクセスさせる    ただし、redirect  URI  は攻撃者のConsumer  のものに差し替える  

Slide 71

Slide 71 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer redirect  URI  の事前登録がないので   チェックをスルー 被害者

Slide 72

Slide 72 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer redirect  URI  に指定されたように   攻撃者の  Consumer  に到達 被害者

Slide 73

Slide 73 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 攻撃者は、最初に入手した   正しい  redirect  URI  に差し替えてリクエスト 被害者

Slide 74

Slide 74 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者   の本来のリクエストと同じなのでチェックを通過     は攻撃者の  Consumer  を   と誤認し、トークンを発行

Slide 75

Slide 75 text

redirect  URI  の改ざん Webアプリ 攻撃者  Consumer 被害者 攻撃者がトークンを取得   SP  上の被害者の情報にアクセスが可能

Slide 76

Slide 76 text

対策(SP) 1)  redirect  URI  の事前登録をしておき、登録の あるURIと同じかチェック   2)  「ユーザー認可リクエスト」と     「アクセストークンリクエスト」で       redirect  URI  が一緒かチェック  

Slide 77

Slide 77 text

redirect  URI  の改ざん 対策 Webアプリ 攻撃者  Consumer 予め登録のある  redirect  URI  ではない   ⇒  検証失敗! 被害者

Slide 78

Slide 78 text

redirect  URI  の改ざん 対策 Webアプリ 攻撃者  Consumer 被害者 「ユーザ認可リクエスト」の時と異なる  redirect  URI  が   「アクセストークンリクエスト」で設定されている   ⇒  検証失敗!

Slide 79

Slide 79 text

他にも・・・

Slide 80

Slide 80 text

攻撃例 •  Consumer  のなりすまし   •  オープンリダイレクタ   •  Implicit  Grant  におけるトークン置き換え   などなど・・・(説明は逐次追記します)  

Slide 81

Slide 81 text

まとめ

Slide 82

Slide 82 text

まとめ •  OAuth  とは認可のプロトコル   •  トークンはあくまで「何ができるか」を証明する もの。「誰か」を証明するものではない   •  トークンは第三者でも使用可能。漏れないよ うに充分に配慮する   •  セキュリティ上の配慮する点が多数。 Consumer  としても  SP  としても対策を怠らない こと  

Slide 83

Slide 83 text

参考 •  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/