ssig33.com

OAuth とか OpenID とかのフローを利用してフィッシングする話

はじめに。これは霊界に住む死者からの通信に基き書かれた記事です。しかし文責は私にあります。

OpenID はパスワードの授受なしに認証の伝達が出来る仕組みです。 OAuth はパスワードの授受なしでリソースへのアクセス権限を委譲出来る仕組みです。

こうした仕組みを用いて外部サイトと連携している限り、外部サイトへパスワードなどが流出する可能性は低いです。また外部サイトが所有する OAuth の token などが外部に流出たとしても、サイトの利用者や OAuth を提供するプロバイダーがその token を早期に無効にすることが出来ます。

しかしセキュリティへしっかり配慮されて作られた OpenID や OAuth をパスワードを抜く為のフィッシングに使用することが出来ます。以下のような具合です。

  1. OpenID 経由で外部サイトにログインしようとする/OAuth を使用して外部サイトに権限を委譲しようとする
  2. プロバイダーにログインしていなかった場合、プロバイダーによってはログインフォームが出る
  3. このログインフォームを捏造する
    • 利用者がプロバイダーにログインしてる状態なら「あれっセッション消えてたかな?」で終わる
    • 利用者がプロバイダーにログインしていない状態だとログインフォームが二度出る、が「あれっなんか調子悪いかな?」で済ます人多そう
  4. 捏造されたログインフォームから先は正規の UX に流す
  5. 上手くすれば利用者は気付かずパスワードを渡してくれる

またこの方法で特定の誰かのパスワードのみを抜きたいのであれば、最初のログインは普通にやって、既にログインしてる人がアクセスした時それがターゲットならフィッシングのフローに流せばよいです。対象に 2 回以上サービスを使わせる必要はあるがある程度は狙い撃ちできます。狙い撃ちすればバレる可能性もそれだけ下がるでしょう。

こうした攻撃を回避する為の方法は唯一つです。これまで全てのフィッシングと同じように「認証情報を入力する画面ではアドレスバーを必ず確認する」ということです。

ですが近年モバイルを中心にアドレスバーを確認することが困難または不可能なブラウジング環境が多々出てきています。こうした環境で認証情報を絶対に入力してはならないということを広く広報すべきでしょう。

しかしまあ現実にアドレスバーを確認出来ない環境が多い以上、プロバイダー側で対応(ログイン -> OAuth っていうフローを潰す)すべきでは、、、という気もしないでもない。

back to index of texts


Site Search

Update History of this content