gistfile1.md

DM踏んだだけでアレな件はTwitterのOAuth実装がク○だと思う

これの話です。 http://togetter.com/li/463503

(追記 : この考察ではiframeでTwitterの認可URL指定してもX-Frame-Options設定されてるやんけ問題が未解決と思ったらなにやら更新されてたのでもう様子見)

前提条件

あくまでこれ前提で考えてます。間違ってたらごめんなさいね。

• モバイルアプリの通信盗聴や某市長の手違いみたいな感じでConsumer Key/Secretを入手したやつがいる

DMのリンク先で行われているらしいこと

• 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経由かな？

Twitterがoauth_callbackに意図しないURLを設定できる
=> Native Appにはまず必要ない。過去の履歴見れば自動的にそれらしきWhitelistは作れるはず。

って感じで、穏便に既存アプリ壊さず解決できるかなぁ。

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さんなので、今回はしれっと対応していただきたいですね。