Successfully reported this slideshow.

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

なんとなく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編もそのうち作る

×