• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
なんとなくOAuth怖いって思ってるやつちょっと来い
 

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

on

  • 8,920 views

 

Statistics

Views

Total Views
8,920
Views on SlideShare
4,649
Embed Views
4,271

Actions

Likes
29
Downloads
0
Comments
0

11 Embeds 4,271

http://d.hatena.ne.jp 3941
https://bozuman.cybozu.com 220
http://bikkuri.me 59
https://twitter.com 23
http://http401.tumblr.com 15
https://bozuman.s.cybozu.com 7
http://reader.aol.com 2
http://131.253.14.98 1
http://hatenatunnel.appspot.com 1
http://digg.com 1
http://feedly.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • なんとなくOAuth怖いって思ってる奴ちょっと来い~ OAuth 1.0編 2013/3 RITOU
    • 読んでもらいたい人 よくわからんけどOAuthは怖い! よくわからんけどやっぱりOAuthは信 用できない! オレが難読化だ!
    • つのる想い Twitterの騒ぎ、問題の本質が見えなく なってる気がする Twitterが対応した場所?違うよね  Serverの対応は既存のClientへの影 響も考えた応急処置 Client Credentialの難読化?んなわけ ない  盛り上がるのは良いけど・・・
    • このスライドの内容 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の扱い クライアントアプリケーションが信頼性の低い組織の管 理下に置かれるケースは少なくない。例えばクライアン トがデスクトップアプリケーションで、ソースコードや 実行形式のバイナリが公開されている場合、攻撃者が分 析のためにコピーをダウンロードし、クライアントクレ デンシャルを見付けてしまう可能性がある。 そういった場合、サーバーはクライアントのアイデン ティティを検証する際、クライアントクレデンシャルの みを使うべきではない。可能であれば、IP アドレスのよ うな他の要素も用いるべきである。 http://openid-foundation-japan.github.com/draft- hammer-oauth-10.html#client_cred_sec
    • OAuth1.0の前提突っ込みどころはあるにしても、とりあえずこんな前提で仕様は書かれてる TLS(HTTPSなリクエスト)は信用できる HTTPなAPIもあるよね。署名つけよう モバイル/デスクトップアプリのClient Credentialは取得される可能性がある  難読化の話はもういらん
    • 初めにユーザーが絡む フローの話をしよういわゆる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 Verifier ユーザーが許可したあとに発行さ れるやつ
    • 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 Secure モバイル/デスクトップアプリで は第3者に取得される可能性が どうなるか?
    • ? Client Credential + 渡されたパラ メータ を投げるとこ ろが信頼でき なくなる http://developer.yahoo.co. jp/other/oauth/flow.html
    • ? Client Credential + 渡されたパラ メータ を投げるとこ ろが信頼でき なくなる http://developer.yahoo.co. jp/other/oauth/flow.html
    • 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取得時に自分 のサーバーのURLを指定できる OAuth Verifier取得できる AccessToken/Secret取得できる Write権限でDM送れる
    • それに加えて ユーザーのアクセス許可画面をスキッ プできるオプションがある  302でリダイレクトしてた iframe内で画面表示なしで OAuth Verifierを取得できた
    • Twitterの件のまとめ アクセス許可画面の省略がキモ!ではない  ノークリックを実現でとどめをさされた のは事実  しかし、画面表示をしたところでユー ザーが見逃したらやられるだろう感 Client Credentialの秘匿も本質じゃない 本質はやはりOAuth Callbackの扱い
    • 2legged OAuth  Server-Clientの2者なので2legged  アプリケーションに紐づくデータにア クセスする用途に利用されている  Client Credentialのみで署名生成 モバイル/デスクトップアプリは… ┐(´~`;)┌
    • Server/Clientがやらないといけないこと Serverは2legged OAuthの利用をWebア プリのみに制限する  Client登録時に指定させる Webアプリかどうか 利用するAPIの指定でもいい Clientはモバイル/デスクトップアプリか ら直接2legged OAuthを使わない  どうしてもな場合はバックエンドのサー バーを経由するなど(工夫が必要)
    • ここまでをまとめるとOAuth 1.0の(というか2.0もなんだけど)実装の良し悪しはServerのClient管理にかかってる
    • ServerのClient管理の話  1プロジェクト、1Client Credentialは よくない  Webアプリとネイティブアプリで Client Credential共有
    • ServerのClient管理の話  1プロジェクト、n Client Credentials の形式が良さそう  Webアプリとネイティブアプリで Client Credentialを分ける  それぞれに利用させるAPIを制限  プロジェクト内のユーザー識別子は 統一
    • ServerのClient管理の話  OAuth Callbackの適切な制限が必要  HTTPSなURLのフルパス(個人的に はパラメータも固定)  複数指定はできていいと思う
    • ServerのClient管理の話  気を付ける部分  リダイレクタ対策 パラメータ無視や前方一致 ドメイン単位の制限  カスタムURIスキーム 重複、先勝ちなどの特性 “oob”使ってユーザーに手動で渡し てもらうほうが良いかも
    • 特にOAuthのServerを実装する人たちは正しい知識を得たうえで、ユーザーとClientが安全にリソースアクセスできるような手段を提供するように努力しましょう
    • 今回はこれぐらいにしとく OAuth 2.0編もそのうち作る