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

14,236 views

Published on

0 Comments
42 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,236
On SlideShare
0
From Embeds
0
Number of Embeds
4,696
Actions
Shares
0
Downloads
0
Comments
0
Likes
42
Embeds 0
No embeds

No notes for slide

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

×