- Salt Labsは、OAuth実装の脆弱性を通じて、数億人が利用する大規模サービスであるBooking.com、Grammarly、Vidio、Bukalapakと、モバイルフレームワークのExpoでアカウント乗っ取りが可能であることを発見。
- OAuthは本質的に安全なプロトコルだが、実装方法によっては致命的な脆弱性が生じうることを示している。
- Booking.com
- Facebook OAuth実装で、
redirect_uriを同一ホスト上の別パスに変更できる問題がある。
- booking.com内部には、base64形式のアドレスを渡すとそのアドレスへリダイレクトされるエンドポイントがある。
- この2つを組み合わせることで、OAuthのトークンが別のアドレスへ送られるように操作できる。
- Web版ではログイン処理時に
redirect_uriを検証していたため脆弱性はなかったが、モバイル版ではredirect_uriも改ざんできる問題があり、アカウント乗っ取りが可能だった。
- つまり、非常に正当なリンクに見えるものをユーザーがクリックして通常どおりOAuthを進めると、アカウントが乗っ取られる脆弱性。
- Expo
- モバイルフレームワークExpoの組み込みOAuth実装で見つかった脆弱性。
- この実装では
returnUrlにexp://~~というExpoアプリ専用リンクが入るが、ここにhTTps://~~のようなWebアドレスを入れられる問題がある。
https://は入力できないようにされているが、大文字小文字の変更だけで回避できる。
- こうすると
returnUrl情報がRUというクッキーに保存され、OAuth完了後にExpoのOAuthサーバーがそのクッキーを読んでリダイレクトする。
- ただし、ExpoからFacebookへ移動する前に「
https://~~ を信頼する場合...」という警告文が表示され、ユーザーがこれを承認する必要がある。
- 回避のため、2つのリンクを自動で開く方法を使用。
- 1つ目のリンクを開いてすぐ閉じ、
RUクッキーだけを設定。
- 2つ目のリンクではFacebook OAuthリンクを直接提示し、
RU警告メッセージを回避。
- この方法によりCodecademy.comのアカウント乗っ取りに成功。
- この脆弱性にはCVE-2023-28131が割り当てられ、Expoチームは最初の報告から数時間で問題を修正した。
- Grammarly、Vidio、Bukalapak
- この3サイトはいずれも同じ方式でアカウント乗っ取りが可能だった。
- まず正当なWebサイトを作成してFacebookログイントークンを収集。
- その後、VidioとBukalapakではFacebookが発行した（別のWebサイト向けに生成された）トークンを渡すと、そのままログインに成功した。
- FacebookトークンのApp IDを確認していないことで発生する脆弱性。（トークン再利用攻撃）
- Grammarlyは少し異なり、トークンではなくコードを使うため上記の脆弱性はなかった。
- しかし、コードを送信するAPIに
"code"の代わりに"access_token"という名前でトークンを渡すとログインできることが確認された。
- したがって、この3サイトはいずれも、正当な別サイトでFacebook連携を行うだけで直ちにアカウントを乗っ取られうる状態だった。
- OAuth実装時には、セキュリティ脆弱性が発生しうる箇所を確認し、脆弱性防止のためにすべての処理過程で細かく検証する必要がある。
3件のコメント
注意喚起になりますね。本当に気をつけなければなりません。
思っていた以上に、非常に大規模なサイトが多くの脆弱性を抱えていたんですね。
やはり慎重に扱うべき機能のようです。
認証ライブラリを使うべきかな……とも思いますが、
Expoの事例を見ると、これも独自に検証が必要だと感じますね.