C 1 R ● OAuth の重要な「セキュリティ上の前提」 ○ 論理的な分離(認可サーバ毎に異なる redirection uri を設定)することが、認可サーバ Mix-up 攻撃などを回避するのに重要 1クライアント1サーバの前提 UA C 1 O C 1 R C 2 O C 2 R A 1 Z A 2 Z 1クライアント1認可サーバ UA C 1 O C 1 R C 2 O A 1 Z A 2 Z 1クライアント N 認可サーバ 違う認可サーバからの 応答を1つの redirection uri で受け 取る、とか
● UA(ブラウザなど)を介した通信は、 UA 内で TLS が終端するため保護されない。メッセージは 認証されず、変更される恐れがある ● 例えば code や state も汚染チェックせずに使われることが多い メッセージ認証の問題 UA C 1 O C 1 R A 1 Z メッセージ認証されていない (response_type, client_id, redirect_uri, scope, state) メッセージ認証されていない (code, state) TLS 終端
● ネイティブアプリ(パブリッククライアント)上の「 code 横取り攻撃」などで顕著 ○ 例: カスタムスキームをデバイス上のマルウェアなどによってハイジャック ○ OAuth PKCE (RFC7636) はこの問題のために存在している メッセージ 受信者 認証の問題 UA GOOD APP BAD APP A 1 Z I am GOOD APP!!! redirect uri = goodapp://
● 認可要求はアプリケーション層では暗号化されていないので、 man-in-the-browser などによっ て読み取られる可能性がある ● ブラウザ内マルウェアはかなり一般的 メッセージ秘匿性 問題 UA C 1 O C 1 R A 1 Z マルウェアはメッセージの内容を読 むことができる TLS 終端
● クライアントがトークン要求とリソース要求を「不正なサーバ」に送る。不正なサーバは今度は 「クライアント」として取得した要求を正規のサーバに送る ○ クライアント開発者に、サーバのエンドポイントが変更されたとの偽メールを送る (20人に1人程度はこのようなメール・フィッシングにひっかかることが知られている) ○ 不正発行された TLS 証明書と DNS スプーフィングの組み合わせ トークン・フィッシング、トークン・リプレイ Attacker Client ABC Provider Hi! I am Provider API ♥ Hi! I am Client ABC ♪
FAPI WG で考案中の実装 Message Parameters ① Unique Source Identifier ② Protocol + Version Identifier ③ Fill list of Actors/Roles 認可要求 response type* client id* redirect uri scope state Unique redirect URI & Client ID 要求署名 ① + UA 識別子としての state あるいは TBID 認可応答 code* state* other ext params Unique redirect URI 応答署名 ① + Client ID + UA 識別子 としての state あるいは TBID トークン要求 grant type* code* redirect uri* client* credential / client id* Unique redirect URI & Client ID OK (OAuth 3.0 が存在し ないかぎり) ① + UA 識別子としての state あるいは TBID トークン応答 access token* token_type* expires_in refresh_token others Unique redirect URI 同上 ① + Client ID + UA 識別子 としての state あるいは TBID