「ちょっとこれみてくれない」とurlを送るスパムDMの解析と解説

まとめ

けっこう巧妙に仕掛けられたものでした。
入力されたIDやパスワードがどのように処理されているかはわかりませんでしたが、ページを開いただけでアクセストークンを抜かれるように細工されていました。

また、cookieを使用しているようなのでこれを無効化してみるとかじゃないと今回のケースは厳しそう。
DMなどでURLが来た時に、一度、ブラウザのプライベートブラウジングモードなどを使用してみるとか。
特に短縮されたままのリンクは要注意だと思います。
今後、似たようなことがおこるようになるとおもいますので、くれぐれもご注意を。

Twitterもこれは盲点だったのかもしれないですね。

怪しいURLはだいたい、短縮されているものが多いです。
わからない場合は開かないことが一番でしょう。
とにかく、怪しいURLは開かないことが一番です。
また、パスワードを打ち込まなかったらも大丈夫だろうと思いがちですが、今回のケースは、「パスワードを打ち込まなくてもページを自動的に乗っ取られる」ものでした。
パスワード打ち込まなかったからいいや、ではありません。興味本位で開いてみるのは危険なのでやめるべきです。

次に、アカウントが乗っ取られたときは、「パスワードが盗まれた」と思いがちですが、Twitterの場合はこれが当てはまらないことが多いです。
確かに、パスワードが盗まれるケースもあるのですが、Twitterの場合はパスワードを盗まずともDMを送ることができます。これはTwitterの仕様です。今回はこの仕様が悪用されたものです。
じゃあどうすれば良いかということですが、パソコン版TwitterのWeb版からアプリ連携を解除する、ということです。これ以外にありません。

最後にですが、もし乗っ取られたとみられる人がいたら、教えてあげましょう。そのときにこのページのURLを貼るなどあるかもしれませんが、スパムと見分けがつかなくなるかもしれないので控えたほうが良いと思います。

[追記]iframeに関する対策がでたっぽい

リダイレクトが302によるものではなくなった様子。
とりあえずiframeによる対策はできたっぽい。

[追記]最終的に

問題を挙げて、一応整理してみました。

• なぜiframeで認証が通った
  → Twitterのoauth/authenticateの認証が通った時に302が返っていたため、X-Frame-Optionsが無視されていた。
  → 現在はmetaタグでリダイレクトされるため、iframeによる対策はできている

• Locationがないものがあったけど
  → おそらく認証していないのクライアントだったのだろう。1度でも認証済みのものは2回目以降はLocationでアクセストークンを返してくる仕様だった。

• CK/CSが漏れたのはなんで
  → クライアントサイドにあるものなので完全に隠すのは不可能。OAuth2.0に期待といったところでは。