これの話です。 http://togetter.com/li/463503
(追記 : この考察ではiframeでTwitterの認可URL指定してもX-Frame-Options設定されてるやんけ問題が未解決と思ったらなにやら更新されてたのでもう様子見)
あくまでこれ前提で考えてます。間違ってたらごめんなさいね。
- モバイルアプリの通信盗聴や某市長の手違いみたいな感じでConsumer Key/Secretを入手したやつがいる
- iframeがいっぱい開かれた
- 有名なTwitter Clientの認可画面だ : (本家の認可URLもしくはCunsumer Key/Secretを知っててRequest Token取得できた?)
- 画面を開くだけで自動認証だ : (oauth_callbackを自分のサーバーのURLに?)
- DM送信はあとからしれっとやるらしい?
- 有名Twitter ClientとかのConsumer Key/Secretを持ってる
- Request Tokenを取得。このとき、設定でcallbackを指定してるアプリケーションはそれ以外のoauth_callbackに任意のドメインを指定できちゃう(←アカン) POST oauth/request_token
- 認可画面を開く。キャプチャ画像にあったとおり、oauth/authenticateを使う GET oauth/authenticate
- 一度でも認可したことがあればスキップしてoauth_callbackにoauth_verifierが戻る。あとはどこまででも行ける
- ところでiframeあたりはどうやった?
ってことですね。
- 有名どころを並べればまぁどれかは認可してる的発想
- ○○だとDM読めないじゃんってTweetがあったけど、READ/WRITEならDM送れる
- Consumer Key/Secretは漏れる
- Twitterがoauth_callbackに意図しないURLを設定できるのが原因。世の中の実装を見て、アプリケーション単位でホワイトリスト的な制限をすべき
- ちなみにOAuth 1.0はオワコンなのでTwitterさんはOAuth 2.0頑張って
Consumer Key/Secretは漏れる
=> Native (Mobile / Desktop) Apps経由かな?
=> TweetDeck Tweetbot for iOS HootSuite ShootingStar iOS ShootingStarPro ってあるけど、これらはデスクトップ/モバイル版ありそうですね
Twitterがoauth_callbackに意図しないURLを設定できる
=> Native Appにはまず必要ない。過去の履歴見れば自動的にそれらしきWhitelistは作れるはず。
=> ちなみに、WebとNative両方使ってるところってある?
今までもしれっと設定の部分とか変えてきたTwitterさんなので、今回はしれっと対応していただきたいですね。