Cacher is the code snippet organizer for pro developers

どういう問題があったか

説明するのめんどい http://vividcode.hatenablog.com/entry/twitter-oauth-vulnerability

どういう対策がされたか

• 第一段階: locationヘッダでの自動リダイレクトからmetaタグでのリダイレクトに変更(X-Frame-Optionsが効くので、iframe総当り攻撃が困難に)
• 第二段階: https://dev.twitter.com/blog/changes-to-sign-in-with-twitter

とりあえず即座に攻撃できるような状態ではなくなっています。

フィッシング？

ユーザーの自衛策として「怪しいリンクをクリックするな」というのは無茶なので、そういった対策が必要なものはバグです、セキュリティホールです。怪しいリンクをクリックできない世界のほうが間違っている。

フィッシングとか言ってしまうと「フィッシングサイトに気をつけましょう」になってしまいます。ユーザーに注意喚起して防ぐものなのか、Twitterやアプリ開発者が対応しなくてはいけないものなのか、区別が付きにくくなります。ハッキリ言うとノイズです。ユーザーが許可してないのにtoken取れるのだからそれはバグです。フィッシングじゃないです。

OAuthの認可ボタンを明示的に押した人であっても「怪しいリンクをクリックしただけだった」と言うでしょう。怪しいリンクもOAuthの認可ボタンも、結局ところ画面の要素クリックするだけなので、そんなものを判断しろというのが無茶なのかもしれません。パソコンに詳しい各位は「本当に怪しいリンクをクリックしただけ」なのか、それとも「よく分からずに重要な操作をしてしまった」のか見極める必要があります。

バグ報告の仕方

日本人が「なんじゃこりゃー、やばくねー、マズくねー」とか騒いでても全然伝わってないことがあるので、直らないです。バグ報告をしましょう。

セキュリティ上の問題だと判断したときは https://support.twitter.com/forms/security から送るといいです。通常のバグとか要望よりも優先的に対応してくれるはずです。英語とか適当でも通じます。攻撃コードや具体例があると良いです。

バグ報告すべきかどうかの判断基準とユーザー側での対策

Twitter社は既に問題を認識しているので、個別のアプリにバグ報告すべきかどうかの基準を示します。

• ウェブアプリなのにconsumer secretが漏れている → 問題です
• もしウェブアプリと配布するタイプのアプリ(デスクトップ/iOS/Android)があるなら、別アプリとして登録しましょう。
• 配布アプリでconsumer key/secretが漏れている → 想定範囲内です。問題ではないです。暗号化とか難読化とか言ってる奴は殴れ。
• consumer secretが漏れている + sign in with twitterが有効になっている → 問題です、開発者の人は直しましょう

個々のアプリ開発者が適切にsign in with twitterのオプションを設定する + X-Frame-Options対応ブラウザであれば、フル画面でOAuthの認可ボタンを押させない限りはtokenの取得は無理、という状態になっています。ただし、引き続きアプリ側の設定のCallback URLの指定よりも、oauth_callbackで指定したURLの方が優先されています。この仕様に依存しているアプリが多くあるのでいきなり変更は難しいでしょう(警告は出せるはず)

なので、まだユーザー側で以下のことに気を付ける必要があります。

• 正規のアプリ/サイト以外から、いきなりそのアプリのOAuthの認可画面が開かれたら怪しいと判断しましょう
• Twitterのサイトの画面が本物であっても、そこから別サイト or 別アプリにリダイレクトする可能性があります

既に攻撃をうけているかも知れない、判別方法は

攻撃を受けたかどうか判別するのは困難です。この説明は一般論としては正しいですが、セキュリティホールを突いた攻撃に対しては間違いです https://twitter.com/twedasuke/status/307138535528476672

「既存のアプリ」のためのアクセストークンを奪うものなので「身に覚えのないアプリ」は連携アプリのリストに増えません。twitter側で空気読んでピンポイントに無効化してくれてるかも知れないですが、不安な人は一旦すべてのアプリの連携を解除して、再度認証すればいいんじゃないでしょうか。