「OAuth 2.0 (Implicit Flow) でログイン」の被害例

Author: Nov Matake
Date:

。登場人物

  • OAuth 2.0対応してる某ゲームプラットフォーム
  • 某ゲームプラットフォーム上で占いゲームを運営してる攻撃者
  • 某ゲームプラットフォーム上で運営されてる農園ゲーム（= 被害アプリ）
  • 某ゲームプラットフォーム上で無邪気に遊んでる被害ユーザ

※ 念のため、今回の話は特にゲームに限った話ではない。

前提

某ゲームプラットフォーム、農園ゲーム共に、XSS とか CSRF とかセッションハイジャックされるような脆弱性はない。

農園ゲームはプラットフォームが発行するAccess TokenをOAuth 2.0のImplicit Flowを使って受け取り、同じくプラットフォームが提供するProfile API (GET /me とか) にアクセスして、レスポンスに含まれる user_id をもとにユーザを認証している。

攻撃者は占いゲームのDBから任意のAccess Tokenを取得可能。

シナリオ

  1. 被害ユーザが占いゲームに登録 (= 占いゲームに対するAccess Tokenが発行される)
  2. 攻撃者が農園ゲームにアクセス、Authorization Flow開始
  3. 攻撃者が某ゲームプラットフォーム -> 農園ゲームへのRedirect Responseを中断させる
  4. 攻撃者がFragment中のAccess Tokenを占いゲームのDBから持ってきた被害者のAccess Tokenに置き換え
  5. 農園ゲームは受け取ったAccess Tokenをもとに、攻撃者を被害ユーザとして認証
  6. 攻撃者が被害ユーザとして農園ゲームで遊ぶ

対策方法

農園ゲームの開発者は、受け取ったAccess Tokenが農園ゲームに対して発行されたものであることを確認すること。占いゲームに対して発行されたAccess Tokenを受け入れないこと。

プラットフォームがFacebookの場合なら、以下のリクエストを行うことで、Access Tokenがどのクライアントに発行されたものかを検証可能。

GET /app
Authorization: OAuth replace_with_your_access_token

急募 : 他のプラットフォームの場合の対応策

参考文献