Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
なんとなくOAuth怖いって思ってる奴ちょっと来い~ OAuth 1.0編   2013/3               RITOU
読んでもらいたい人   よくわからんけどOAuthは怖い!   よくわからんけどやっぱりOAuthは信    用できない!   オレが難読化だ!
つのる想い   Twitterの騒ぎ、問題の本質が見えなく    なってる気がする   Twitterが対応した場所?違うよね     Serverの対応は既存のClientへの影     響も考えた応急処置   Client Cred...
このスライドの内容   OAuthの前提   OAuth 1.0 実装のポイント
このスライドの目的   ぼくがかんがえるおーおーすのかんど    ころを知ってもらいたい   特に、仕様がアレな部分をどう実装す    るかを紹介したい   まぁ、OAuth 1.0の時代はもう終わっ    てるけどな
OAuth 1.0(2007-2012)Obsoleted by OAuth 2.0
OAuth1.0の前提突っ込みどころはあるにしても、とりあえずこんな前提で仕様は書かれてる   TLS(HTTPSなリクエスト)は信用できる   HTTPなAPIもあるよね。署名つけよう     2007年とか2008年とかだからね
Client Credentialの扱い クライアントアプリケーションが信頼性の低い組織の管 理下に置かれるケースは少なくない。例えばクライアン トがデスクトップアプリケーションで、ソースコードや 実行形式のバイナリが公開されている場合、攻撃者...
OAuth1.0の前提突っ込みどころはあるにしても、とりあえずこんな前提で仕様は書かれてる   TLS(HTTPSなリクエスト)は信用できる   HTTPなAPIもあるよね。署名つけよう   モバイル/デスクトップアプリのClient  ...
初めにユーザーが絡む   フローの話をしよういわゆる3-legged OAuth, ユーザーのアクセス許可が入るフロー(2-leggedについては最後に)
OAuth 1.0のポイント   Access Token( / Secret)の管理   アクセス許可結果の受け渡し   Client Credentialの管理
ちょっと余計なの  ついてるけどフローは  まぁこんな感じhttp://developer.yahoo.co.jp/other/oauth/flow.html
実装の  ポイントを  後ろから  見ていくhttp://developer.yahoo.co.jp/other/oauth/flow.html
APIアクセスに必要な情報   2組のCredentialで署名する必要あり     Access   Token/Secret     Consumer   Key / Secret
http://developer.yahoo.co.jp/other/oauth/flow.html
Access Token / Secretを取得するためには    これまたいろいろ必要      Request   Token / Secet       ユーザーの同意を求めるために必        要なやつ      OAuth...
http://developer.yahoo.co.jp/other/oauth/flow.html
OAuth Verifierを取得するためには    ユーザーが許可した後にServerから     Clientへのリダイレクトなどによる受     け渡しが必要
OAuth Verifierを正しく渡してもらうには   ClientからServerへの戻り先の指定が    必要     OAuth   Callback      Request   Token取得時に指定      Server...
http://developer.yahoo.co.jp/other/oauth/flow.html
Request Tokenを取得するためには   Client Credentialsが必要     Consumer   Key / Secret
Request Tokenを取得するためには   Client Credentialsが必要     Consumer   Key / Secret      Webアプリケーションでここが        守られていればALL Secure
Request Tokenを取得するためには   Client Credentialsが必要     Consumer   Key / Secret      Webアプリケーションでここが        守られていればALL Secur...
?     Client      Credential      +      渡されたパラ      メータ      を投げるとこ      ろが信頼でき      なくなる    http://developer.yahoo.co.  ...
?     Client      Credential      +      渡されたパラ      メータ      を投げるとこ      ろが信頼でき      なくなる    http://developer.yahoo.co.  ...
OAuth Callbackの指定にはServerの検証が入る。ここで不正な値を指定されないように守るしかない。http://developer.yahoo.co.jp/other/oauth/flow.html
3legged OAuthで重要なこと   Client Credentialが悪意のある誰かに    取得されても、OAuth Verifierが取得    されなければ、第3者にToken    Credentialが渡ることを防げる
Server/Clientがやらないといけないこと ServerはOAuth         Verifierが悪意のあ る第3者に渡らないように実装 ClientはServerが提供する安全な方 法を利用する(しかない)
以上の観点からTwitterの実装を考える OAuth    Verifierが悪意のある第3者 に渡るケースがある   戻り先のURLが事前に指定してある   場合、Request Token取得時に任意   のURLを指定できる
Client Credentialを安全に管理できないClient    第3者が Request Tokenを取得できる      戻り先のURLが事前に指定してある      場合、Request Token取得時に自分      のサ...
それに加えて   ユーザーのアクセス許可画面をスキッ    プできるオプションがある     302でリダイレクトしてた     iframe内で画面表示なしで      OAuth Verifierを取得できた
Twitterの件のまとめ   アクセス許可画面の省略がキモ!ではない     ノークリックを実現でとどめをさされた     のは事実     しかし、画面表示をしたところでユー     ザーが見逃したらやられるだろう感   Clien...
2legged OAuth    Server-Clientの2者なので2legged    アプリケーションに紐づくデータにア     クセスする用途に利用されている    Client Credentialのみで署名生成 モバイル/デ...
Server/Clientがやらないといけないこと   Serverは2legged OAuthの利用をWebア    プリのみに制限する     Client登録時に指定させる      Webアプリかどうか      利用するAPI...
ここまでをまとめるとOAuth 1.0の(というか2.0もなんだけど)実装の良し悪しはServerのClient管理にかかってる
ServerのClient管理の話    1プロジェクト、1Client Credentialは     よくない      Webアプリとネイティブアプリで      Client Credential共有
ServerのClient管理の話    1プロジェクト、n Client Credentials     の形式が良さそう      Webアプリとネイティブアプリで      Client Credentialを分ける      それ...
ServerのClient管理の話    OAuth Callbackの適切な制限が必要      HTTPSなURLのフルパス(個人的に      はパラメータも固定)      複数指定はできていいと思う
ServerのClient管理の話    気を付ける部分      リダイレクタ対策      パラメータ無視や前方一致      ドメイン単位の制限      カスタムURIスキーム      重複、先勝ちなどの特性      ...
特にOAuthのServerを実装する人たちは正しい知識を得たうえで、ユーザーとClientが安全にリソースアクセスできるような手段を提供するように努力しましょう
今回はこれぐらいにしとく   OAuth 2.0編もそのうち作る
Upcoming SlideShare
Loading in …5
×

なんとなくOAuth怖いって思ってるやつちょっと来い

15,570 views

Published on

  • Be the first to comment

なんとなくOAuth怖いって思ってるやつちょっと来い

  1. 1. なんとなくOAuth怖いって思ってる奴ちょっと来い~ OAuth 1.0編 2013/3 RITOU
  2. 2. 読んでもらいたい人 よくわからんけどOAuthは怖い! よくわからんけどやっぱりOAuthは信 用できない! オレが難読化だ!
  3. 3. つのる想い Twitterの騒ぎ、問題の本質が見えなく なってる気がする Twitterが対応した場所?違うよね  Serverの対応は既存のClientへの影 響も考えた応急処置 Client Credentialの難読化?んなわけ ない  盛り上がるのは良いけど・・・
  4. 4. このスライドの内容 OAuthの前提 OAuth 1.0 実装のポイント
  5. 5. このスライドの目的 ぼくがかんがえるおーおーすのかんど ころを知ってもらいたい 特に、仕様がアレな部分をどう実装す るかを紹介したい まぁ、OAuth 1.0の時代はもう終わっ てるけどな
  6. 6. OAuth 1.0(2007-2012)Obsoleted by OAuth 2.0
  7. 7. OAuth1.0の前提突っ込みどころはあるにしても、とりあえずこんな前提で仕様は書かれてる TLS(HTTPSなリクエスト)は信用できる HTTPなAPIもあるよね。署名つけよう  2007年とか2008年とかだからね
  8. 8. Client Credentialの扱い クライアントアプリケーションが信頼性の低い組織の管 理下に置かれるケースは少なくない。例えばクライアン トがデスクトップアプリケーションで、ソースコードや 実行形式のバイナリが公開されている場合、攻撃者が分 析のためにコピーをダウンロードし、クライアントクレ デンシャルを見付けてしまう可能性がある。 そういった場合、サーバーはクライアントのアイデン ティティを検証する際、クライアントクレデンシャルの みを使うべきではない。可能であれば、IP アドレスのよ うな他の要素も用いるべきである。 http://openid-foundation-japan.github.com/draft- hammer-oauth-10.html#client_cred_sec
  9. 9. OAuth1.0の前提突っ込みどころはあるにしても、とりあえずこんな前提で仕様は書かれてる TLS(HTTPSなリクエスト)は信用できる HTTPなAPIもあるよね。署名つけよう モバイル/デスクトップアプリのClient Credentialは取得される可能性がある  難読化の話はもういらん
  10. 10. 初めにユーザーが絡む フローの話をしよういわゆる3-legged OAuth, ユーザーのアクセス許可が入るフロー(2-leggedについては最後に)
  11. 11. OAuth 1.0のポイント Access Token( / Secret)の管理 アクセス許可結果の受け渡し Client Credentialの管理
  12. 12. ちょっと余計なの ついてるけどフローは まぁこんな感じhttp://developer.yahoo.co.jp/other/oauth/flow.html
  13. 13. 実装の ポイントを 後ろから 見ていくhttp://developer.yahoo.co.jp/other/oauth/flow.html
  14. 14. APIアクセスに必要な情報 2組のCredentialで署名する必要あり  Access Token/Secret  Consumer Key / Secret
  15. 15. http://developer.yahoo.co.jp/other/oauth/flow.html
  16. 16. Access Token / Secretを取得するためには  これまたいろいろ必要  Request Token / Secet ユーザーの同意を求めるために必 要なやつ  OAuth Verifier ユーザーが許可したあとに発行さ れるやつ
  17. 17. http://developer.yahoo.co.jp/other/oauth/flow.html
  18. 18. OAuth Verifierを取得するためには  ユーザーが許可した後にServerから Clientへのリダイレクトなどによる受 け渡しが必要
  19. 19. OAuth Verifierを正しく渡してもらうには ClientからServerへの戻り先の指定が 必要  OAuth Callback Request Token取得時に指定 Serverは事前登録されているもの と一致するか検証
  20. 20. http://developer.yahoo.co.jp/other/oauth/flow.html
  21. 21. Request Tokenを取得するためには Client Credentialsが必要  Consumer Key / Secret
  22. 22. Request Tokenを取得するためには Client Credentialsが必要  Consumer Key / Secret Webアプリケーションでここが 守られていればALL Secure
  23. 23. Request Tokenを取得するためには Client Credentialsが必要  Consumer Key / Secret Webアプリケーションでここが 守られていればALL Secure モバイル/デスクトップアプリで は第3者に取得される可能性が どうなるか?
  24. 24. ? Client Credential + 渡されたパラ メータ を投げるとこ ろが信頼でき なくなる http://developer.yahoo.co. jp/other/oauth/flow.html
  25. 25. ? Client Credential + 渡されたパラ メータ を投げるとこ ろが信頼でき なくなる http://developer.yahoo.co. jp/other/oauth/flow.html
  26. 26. OAuth Callbackの指定にはServerの検証が入る。ここで不正な値を指定されないように守るしかない。http://developer.yahoo.co.jp/other/oauth/flow.html
  27. 27. 3legged OAuthで重要なこと Client Credentialが悪意のある誰かに 取得されても、OAuth Verifierが取得 されなければ、第3者にToken Credentialが渡ることを防げる
  28. 28. Server/Clientがやらないといけないこと ServerはOAuth Verifierが悪意のあ る第3者に渡らないように実装 ClientはServerが提供する安全な方 法を利用する(しかない)
  29. 29. 以上の観点からTwitterの実装を考える OAuth Verifierが悪意のある第3者 に渡るケースがある  戻り先のURLが事前に指定してある 場合、Request Token取得時に任意 のURLを指定できる
  30. 30. Client Credentialを安全に管理できないClient  第3者が Request Tokenを取得できる  戻り先のURLが事前に指定してある 場合、Request Token取得時に自分 のサーバーのURLを指定できる OAuth Verifier取得できる AccessToken/Secret取得できる Write権限でDM送れる
  31. 31. それに加えて ユーザーのアクセス許可画面をスキッ プできるオプションがある  302でリダイレクトしてた iframe内で画面表示なしで OAuth Verifierを取得できた
  32. 32. Twitterの件のまとめ アクセス許可画面の省略がキモ!ではない  ノークリックを実現でとどめをさされた のは事実  しかし、画面表示をしたところでユー ザーが見逃したらやられるだろう感 Client Credentialの秘匿も本質じゃない 本質はやはりOAuth Callbackの扱い
  33. 33. 2legged OAuth  Server-Clientの2者なので2legged  アプリケーションに紐づくデータにア クセスする用途に利用されている  Client Credentialのみで署名生成 モバイル/デスクトップアプリは… ┐(´~`;)┌
  34. 34. Server/Clientがやらないといけないこと Serverは2legged OAuthの利用をWebア プリのみに制限する  Client登録時に指定させる Webアプリかどうか 利用するAPIの指定でもいい Clientはモバイル/デスクトップアプリか ら直接2legged OAuthを使わない  どうしてもな場合はバックエンドのサー バーを経由するなど(工夫が必要)
  35. 35. ここまでをまとめるとOAuth 1.0の(というか2.0もなんだけど)実装の良し悪しはServerのClient管理にかかってる
  36. 36. ServerのClient管理の話  1プロジェクト、1Client Credentialは よくない  Webアプリとネイティブアプリで Client Credential共有
  37. 37. ServerのClient管理の話  1プロジェクト、n Client Credentials の形式が良さそう  Webアプリとネイティブアプリで Client Credentialを分ける  それぞれに利用させるAPIを制限  プロジェクト内のユーザー識別子は 統一
  38. 38. ServerのClient管理の話  OAuth Callbackの適切な制限が必要  HTTPSなURLのフルパス(個人的に はパラメータも固定)  複数指定はできていいと思う
  39. 39. ServerのClient管理の話  気を付ける部分  リダイレクタ対策 パラメータ無視や前方一致 ドメイン単位の制限  カスタムURIスキーム 重複、先勝ちなどの特性 “oob”使ってユーザーに手動で渡し てもらうほうが良いかも
  40. 40. 特にOAuthのServerを実装する人たちは正しい知識を得たうえで、ユーザーとClientが安全にリソースアクセスできるような手段を提供するように努力しましょう
  41. 41. 今回はこれぐらいにしとく OAuth 2.0編もそのうち作る

×