TwitterのOAuth脆弱性 2013-03-01 Xtone Ltd. ピザ会 Aki / @nekoruri ---- SlideShare側でファイルが破損してしまったようで、 http://www.slideshare.net/nekoruri/20130301-twitter-oauthvulnerability を再アップロードしました。

1. TwitterのOAuth脆弱性
2013-03-01
Xtone Ltd. ピザ会
Aki / @nekoruri

2. なにがおきたの？
( ^o^) なんか友達からURL送られてきたお

3. なにがおきたの？
( ˘⊖˘) 。o(ID/Pass入力しなきゃ安全だよな……)

4. なにがおきたの？
|URL| ┗(☋｀ )┓三

5. なにがおきたの？
( ◠‿◠ )☛ アクセストークンは頂いた、抵抗は無意味だ

6. なにがおきたの？
▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ

7. なにがおきたの？
( ^o^)なんか友達からURL送られてきたお
( ˘⊖˘) 。O(ID/Pass入力しなきゃ安全だよな……)
|URL| ┗(☋｀ )┓三
( ◠‿◠ )☛アクセストークンは頂いた、抵抗は無意味だ
▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ
＿人人人人人人人人＿
＞ 大量のDM送信 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

8. おさらい
• URLを開くだけでアクセストークンが取られる
– 連携済みアプリの権限を悪者が丸ごと奪取
– デスクトップアプリ系なので、ほとんどDM込み全許可
– CSRF脆弱性の一種
• 現時点（2013/03/01 13時）で少しだけ改善
– 当初使われていた手法は無効化（未確認）
• その後（2013/03/01 15時）に対応
– クライアントアプリ提供者の設定変更が必要
– まだ脆弱なシナリオは残る（後述）

9. おきたこと
1. URLを開く
2. IFRAMEでTwitterの認証ページにリダイレクト
3. ログイン中かつ連携済みアプリがあれば、
ダイアログ無しでCallback URLにリダイレクト
4. Callback URLでアクセストークン取得完了

10. おきたこと
1. URLを開く
2. IFRAMEでTwitterの認証ページにリダイレクト
3. ログイン中かつ連携済みアプリがあれば、
ダイアログ無しでCallback URLにリダイレクト
4. Callback URLでアクセストークン取得完了
!?
IFRAME内である以外は、
通常のソーシャルログインそのものじゃね？

11. 取られていたはずの対策
• 必ずPINコードが表示
• Callback URLは指定不可
PINコード入力(OOB)モード
• フレーム内では表示されない
X-Frame-Optionsヘッダ

12. 問題点1
アプリ設定のCallback URL
• アプリ設定で入れたCallback URLは？
– 仕様変更により、実質空欄かどうかしか見ていない
• 空欄
– PINコード入力モードが必須になる
• なにかいれる
– 入力内容と無関係にrequest_token取得時にCallback
URLを指定できる
– request_token取得時にCallback URLを省略するとこ
れになるらしい（未確認）

13. 問題点2
PINコードなんて使わねーよ馬鹿
• 操作上の不利益
– 表示された8桁の数字をコピペさせる？はぁ？
• 技術的難しさ
– 表示された内容からスクレーピング？
– できない場合もある（標準ブラウザ等）
– 他の手段があるなら面倒だしそっちで……

14. 問題点2
PINコードなんて使わねーよ馬鹿
• PINコードは嫌だ派の回避策
– PINコードなんて使わない
（アプリ設定にはダミーURLを設定）
– どこかにリダイレクトさせてアプリで受け取る
• リダイレクト先ウェブサーバをlocalhostで起動
• 独自スキーマでインテント（Android）

15. 問題点2
PINコードなんて使わねーよ馬鹿
• PINコードは嫌だ派の回避策
– PINコードなんて使わない
（アプリ設定にはダミーURLを設定）
– どこかにリダイレクトさせてアプリで受け取る
• リダイレクト先ウェブサーバをlocalhostで起動
• 独自スキーマでインテント（Android）
認証開始時に任意のURLを
Callback URLに指定可能

16. 問題点3
X-Frame-Options
• そもそもなにそれ
– フレーム内での表示を「拒否」できる
– 対応するかはブラウザ次第
（サーバ側はフレーム内かどうかはわからない）
– 最近のブラウザではそれなりに実装
IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+
– TwitterではSAMEORIGINが設定
→ 同じドメイン上のサイトからのみ許可

17. 問題点3
X-Frame-Options
• そもそもなにそれ
– フレーム内での表示を「拒否」できる
– 対応するかはブラウザ次第
（サーバ側はフレーム内かどうかはわからない）
– 最近のブラウザではそれなりに実装
IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+
– TwitterではSAMEORIGINが設定
→ 同じドメイン上のサイトからのみ許可
……だったはずなのに……

18. 問題点3
X-Frame-Options
• Locationのリダイレクトは受け付けちゃう
– Firefox、Chromeで確認
– 意味ないじゃん！！！！
• ちなみに
– 一般的な設定では既に持ってるCookieも送信
– 3rd party Cookieの送信ポリシー次第
参考：http://d.hatena.ne.jp/mala/20111125/1322210819
＜2013-03-01 13時頃での対策＞
リダイレクトの方法を
Locationヘッダ→HTML refreshに変更

19. 問題点3
X-Frame-Options
• Locationのリダイレクトは受け付けちゃう
– Firefox、Chromeで確認
– 意味ないじゃん！！！！
• ちなみに
– 一般的な設定では既に持ってるCookieも送信
– 3rd party Cookieの送信ポリシー次第
参考：http://d.hatena.ne.jp/mala/20111125/1322210819
＜2013-03-01 13時頃での対策＞
リダイレクトの方法を
Locationヘッダ→HTML refreshに変更
この時点で、今回の大量のIFRAME
による総当たり攻撃には対応

20. 問題点4
「ソーシャルログイン」機能
• OAuth 1.0aの仕様外のTwitter独自機能
– GET oauth/authenticate
https://dev.twitter.com/docs/api/1/get/oauth/aut
henticate
– ログイン時かつ許可済みのアプリならば、
ダイアログ無しでリダイレクト
– （おそらく）ユーザの利便性のために提供
– この機能の存在自体が脆弱性……？

21. 本質的な問題では無いもの
consumer_secretの「流出」
• デスクトップアプリにおけるconsumer_secret
– OAuthで認証する時に使う
– アプリ毎に1つ
– 配布ファイル内に含めないといけない
– メモリ上で必ず一時的には平文で存在
設計上は「公開情報」とみなすべき
クライアントが本物かは信用できない
どうせ
漏れる

22. OAuth 1.0aのおさらい（超ざっくり）
クライアント Twitter
Callback URL + request_token + verifierにリダイレクトしろ
ブラウザ
（ユーザー）
request_token + Cookie
request_token
ログインしてクライアントに権限を渡す許可を出す
request_token
同上
Callback URL
CallbackURLを保存
request_token + verifier
access_token
※ 主要な情報の動きだけを書いたものです。

23. OAuth 1.0aのおさらい（超ざっくり）
クライアント Twitter
Callback URL + request_token + verifierにリダイレクトしろ
ブラウザ
（ユーザー）
request_token + Cookie
request_token
request_token
同上
Callback URL
CallbackURLを保存
request_token + verifier
access_token
※ 主要な情報の動きだけを書いたものです。
一度許可をしていると、
2度目以降は画面無しで
Callback URLにリダイレクト

24. OAuth 1.0aのおさらい（超ざっくり）
クライアント Twitter
Callback URL + request_token + verifierにリダイレクトしろ
ブラウザ
（ユーザー）
request_token
request_token
request_token
同上
Callback URL
CallbackURLを保存
request_token + verifier
access_token
※ 主要な情報の動きだけを書いたものです。
Callback URLにいるクライアントが
アクセストークンを取得できる

25. OAuth 1.0aのおさらい（超ざっくり）
クライアント Twitter
Callback URL + request_token + verifierにリダイレクトしろ
ブラウザ
（ユーザー）
request_token
request_token
request_token
同上
Callback URL
CallbackURLを保存
request_token + verifier
access_token
※ 主要な情報の動きだけを書いたものです。
Callback URLを誰が渡すかが重要
Callback URLにいるクライアントが
アクセストークンを取得できる

26. 問題点4
「ソーシャルログイン」機能
• ウェブアプリの場合
– consumer_secretを知っている
→ 正しいクライアントと言い切れる（普通は）
– 正しいクライアントの主張するCallback URLは信
用できる
– そのままリダイレクトしてCallback URLの先のペー
ジにアクセストークンを渡しても良い

27. 問題点4
「ソーシャルログイン」機能
• デスクトップアプリの場合
– consumer_secretを知っている
→ 正しいクライアントとは限らない
– そのクライアントが主張しているCallback URLは信
用できない
– 登録されたアプリ情報を見せて、ユーザーの判断
を仰がなくてはいけない。
（2013-03-01 15時頃?）
アプリ設定でダイアログ強制表示を選べるように変更

28. （参考）PINコードを入力する場合
クライアント Twitter
PINコード
ブラウザ
（ユーザー）
request_token + Cookie
request_token
ログインしてクライアントに権限を渡す許可を出す
request_token
PINコード
PINで認証したい
request_token + verifier
access_token
※ 主要な情報の動きだけを書いたものです。
Twitterサイト上に
表示されたPINコードは
自動では取得できない
PINコード
コピペ

29. アプリ側の対策案
1. PIN入力モードだけを使う（確実）
– アプリ設定のCallback URLは空欄にする
2. PIN入力の手間を減らす（非推奨）
– ブラウザに表示されたPINを自動取得
– スマホ系での対策案
• Androidのブラウザでスクレイピング
http://www.slideshare.net/maimuzo/android-3170284
• iPhoneでOAuth認証するぜの巻
http://hidden.vis.ne.jp/blog/?p=570
– ただし：本来は標準ブラウザに飛ばすべき
• OAuthの認証にWebViewを使うのはやめよう
http://shogo82148.github.com/blog/2012/11/24/no-more-
webview/

30. アプリ側の対策案
3. デスクトップアプリはダイアログを強制表示（確実）
– アプリ設定の「Sign in with Twitter」を無効化
– oauth/authenticateでもリダイレクトしない
（必ず確認ダイアログが表示される）
– これがTwitter側からの最終的な対策と思われる
– 作者が気付かず「Sign in with Twitter」が有効なままのデスク
トップアプリは対策されない
→ 窓から投げ捨てろ、アプリへの許可を取り消せ
– 悪意のあるアプリが他のアプリのconsumer_{token,secret}を
利用する場合
→ 必ずダイアログ出るので無意味
アプリの名前も確認せず[許可]押した奴が悪い

31. 主な情報源
1. [Twitter公式] Changes to the 'Sign in with Twitter' flow
https://dev.twitter.com/blog/changes-to-sign-in-with-twitter
2. TwitterのOAuthの問題まとめ
https://gist.github.com/mala/5062931
3. 怪しいクライアントを許可していないのに勝手に twitter で DM が
送信されていた
http://vividcode.hatenablog.com/entry/twitter-oauth-
vulnerability
4. DM踏んだだけでアレな件はTwitterのOAuth実装がク○だと思う
https://gist.github.com/ritou/5053810
5. 【拡散希望】twitterの新型ウイルスがヤバい URL踏んだだけでア
ウト
http://uinyan.com/twitter_oauth_vulnerability/
6. フィッシング？ - Togetter
http://togetter.com/li/463503

32. 今回の名言
（malaさんのgist:5062931より）
ユーザーの自衛策として「怪しいリンクをク
リックするな」というのは無茶なので、そういっ
た対策が必要なものはバグです、セキュリ
ティホールです。怪しいリンクをクリックできな
い世界のほうが間違っている。

33. Twitterさん迅速な対応おつかれさまでした。