Upgrade to Pro — share decks privately, control downloads, hide ads and more …

今更聞けないOAuth2.0

satot
March 22, 2015

 今更聞けないOAuth2.0

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

satot

March 22, 2015
Tweet

Other Decks in Technology

Transcript

  1. 自己紹介   •  @white_aspara25   •  istyle.inc  エンジニア(自称)   • 

    ここ1年は ハノイ@ベトナム で  Bridgeエンジニ アとして働いてました
  2. それ、アカンやつや •  サイトA  はユーザの許可がなくても   SNS  の情報が見れてしまう •  SNS  のパスワードを変更

      =>  サイトAのパスワードも変更が必要   •  ID/PW漏洩のリスク                      etc...   問題大有りです。
  3. OAuth  を使った方法 投稿サイトA SNS 投稿 1.  ユーザはSNSにサイトAからの投稿を許可(=認可)   2.  ユーザの許可を受けてSNSはトークンを発行

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

      3.  投稿サイトAはトークンを使ってSNSに投稿   サイトAからの投稿許可 投稿 トークンを発行 No  more  ID/Password SNS  の  ID/PW  をサイトAは知らなくても良い!
  5. OAuth2.0 •  AuthorizaFon  Code  Grant   •  Implicit  Grant  

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

    •  Resource  Owner  Password  CredenFals  Grant   •  Client  CredenFals  Grant   4種類のトークン   発行フロー 今回は取り扱いません
  7. AuthorizaFon  Code  Grant •  認可コードグラント、とも   •  サーバ間通信のような、トークンを秘密保持できる場合 に使われる  

    •  一般的な  web  アプリはコレ Implicit  Grant •  トークンを秘密保持できない場合に。   •  スマホアプリや Javascript  はコレ。  
  8. CSRF 1)  攻撃者は通常の手順でSPの認可まで行う   2)  認可後のリダイレクト先の  URI  を取得し、被害者に アクセスさせる  

    手法 リスク ・ 第3者の  アカウントと連携    =第3者がログイン可能    =  アカウントの乗っ取り   ・ 第3者のアカウントとしてログインさせられる   ー 個人情報やクレカ情報を登録したら、第3者に知られてしまう  
  9. CSRF  対策 Webアプリ 攻撃者   は被害者のセッションに基づく    state    値を発行  

    被害者 state state 認可リクエスト時の    state    値が引き回される state
  10. CSRF  対策 Webアプリ 攻撃者 最初に発行した    state    と被害者の  

     state    値と比較   ⇒  検証に失敗! 被害者 state state state
  11. redirect  URI  の改ざん 「ユーザー認可リクエスト」と「アクセストークンリクエスト」で   異なる  redirect  URI  を指定  

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

        SP  に  redirect  URI  の事前登録をしない場合に発生 ※Implicit  Grant  はSP  への  redirect  URI  の事前登録が必須なので、AuthorizaFon   Code  Grant  に限られる 手法 条件
  13. 対策(SP) 1)  redirect  URI  の事前登録をしておき、登録の あるURIと同じかチェック   2)  「ユーザー認可リクエスト」と  

      「アクセストークンリクエスト」で       redirect  URI  が一緒かチェック  
  14. redirect  URI  の改ざん 対策 Webアプリ 攻撃者  Consumer 被害者 「ユーザ認可リクエスト」の時と異なる  redirect

     URI  が   「アクセストークンリクエスト」で設定されている   ⇒  検証失敗!
  15. 攻撃例 •  Consumer  のなりすまし   •  オープンリダイレクタ   •  Implicit

     Grant  におけるトークン置き換え   などなど・・・(説明は逐次追記します)  
  16. まとめ •  OAuth  とは認可のプロトコル   •  トークンはあくまで「何ができるか」を証明する もの。「誰か」を証明するものではない   • 

    トークンは第三者でも使用可能。漏れないよ うに充分に配慮する   •  セキュリティ上の配慮する点が多数。 Consumer  としても  SP  としても対策を怠らない こと  
  17. 参考 •  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/