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