OAuthの認可フローにおけるエラーレスポンス等を用いたフィッシングリスクについて
ritouです。
せっかくなのでアドカレ8日目の記事にします。
なんだか最近騒がしいなと思ってたらこんな記事が出てました。
３行で
- OAuthの認可リクエストでパラメータ間違ってた時にClientに戻すASがある
- 仕様的にはredirect_uriが間違ってる場合は誰でもオープンリダイレクタできちゃうのでアンチパターンになってるんだけど、正規のredirect_uriで他のが間違ってる場合は戻しても良いし(例ではMicrosoft)、間違ってるぞって正規のredirect_uriに戻すところもある(例ではGitHub)
- 悪意のある開発者がredirect_uriにエラーレスポンスが返される認可リクエストやそれに向けたログインURLを作った場合、ドメインはASのものになって実際はredirect_uriにリダイレクトされるので、フィッシングに使われる可能性がある
っていう話で、手法自体は新しい話ではないでしょう。
あとはこれと同様で何らかのエラー応答を任意のURLに戻す機能があったら同じ話になりますよということです。
試してみる
一番再現が簡単そうなGitHubでこんな設定をしてみます。
redirect_uriにはいつも使ってるQiitaパトロール用のURLを設定しました。
試したらこのアプリケーション消します。
で、こんなURLを作るわけですね。
https://github.com/login/oauth/authorize?client_id=ff682c5da73f5aa8d2e9&redirect_uri=hogehoge
アクセスしてみましょう。
変なパラメータつけたせいでエラーレスポンスが正規のredirect_uriに戻されました。
ちなみに未ログイン状態だと一回ログイン画面が挟まります。
認可リクエストの前にログインさせるか、させないかはASのキメではありますが、ログイン前に判定してエラーレスポンスをリダイレクトで返す場合はよりフィッシングに使われる可能性が高くなりますね。
対策
今回の話は、いわゆる性悪説というか、
悪意のある開発者がフィッシングサイトのURLをredirect_uriに設定する場合がありますよ
ってところに注意が必要ってことです。
例えばOAuthが出てきた当初は redirect_uriに設定できるURLをファイルの存在確認とかを使って厳密に検証する とかやってたところもありました。しかし、フィッシングサイトを管理下に置いている開発者はそんなことしてもフィッシングサイトのURLを設定できるので効果は薄いですね。
記事には
- なるべくエラー応答をClientに戻さない
- 戻すときはURL遷移をユーザーに伝えたり、時間をかけたり、リンクをクリックさせたりする
とか書いてあります。
今回のような「まぁ、そりゃそうよ」みたいな話が出て騒がれると、これまでよりもこのあたりのベストプラクティスが変わっていくかもしれません。
OAuth 2.1とかに影響が出るかに注目ですね！
ではまた。
追記。詳しい人に対策教えてもらいました。
むかーしむかし、OpenID 2.0の実装してるときに戻り先URLとフィッシングサイト(どこからもらったか忘れた)のドメイン突き合わせて検知しようみたいな話があったのを思い出しました。
どこまで審査するかはあると思いますがそういう仕組みは使えるかもしれませんね。
Discussion