FAPI Security について聞いてきた話（2017/08/18 社内勉強会）

Transcript

1. FAPI Security Yoko TAMADA @tmd45 2017/08/18 feedforce Inc. OpenID BizDay で金融 API に求められるセキュリティの話を聞いてきた話
2. Financial APIセキュリティの現状について @ OpenID BizDay 10 https://www.slideshare.net/secret/t4myNYsddpQX4k © 2017 by Nat Sakimura. CC-BY-SA 本スライドもこれに従い CC-BY-SA ライセンスとします。 所出、ライセンス
3. OAuth 2.0 おさらい ※用語は OpenID Connect と混ざってます
4. OAuth とは • リソースアクセスのしくみ（認可 , Authorization） • リソース（≒ 個人情報）へのアクセスを許可する／許可してもらう 【ソーシャルPLUS】各プロバイダの認証プロトコル #補足 https://feedforce.qiita.com/tmd45/items/2c7dc19854746096b330#%E8%A3%9C%E8%B6%B3
5. 例「Taro さん が キャンペーンサイト に Facebook ログイン を使ってログインする」 • IdP（Identity Provider） ◦ 認証結果と属性情報を 提供する 側 ＝Facebook ◦ 認証（認可）のサーバ側とか呼んだりする • RP（Relying Party） ◦ 認証結果と属性情報を 受け取る 側 ＝キャンペーンサイト ◦ 認証（認可）のクライアント側とか呼んだりする • その他 ◦ Entity（実体）＝Taro さん（エンドユーザー, 人間） ◦ Identity（属性）＝Taro さんの情報（ID, 個人情報, など） Role
6. • 認証とは「ブラウザの前にいる Entity が、サービス側が認識するどの Identiry と紐付いてい るのか確証を得ること」 • 認可を元に得られた情報（プロバイダ側のユーザ ID）→ お客様システムの会員 ID と紐づくこ とで、サービス側は「いまブラウザの前にいる人は Taro さんである」という確証を得る ◦ ソーシャルログインによる認証 認証と認可
7. 1. 認可要求（Authorization Request） 2. 認可応答（Authorization Response） 3. トークン要求（Access Token Request） 4. トークン応答（Access Token Response） 認可取得のフロー
8. キャンペーン サイト （RP） Facebook （IdP） エンド ユーザ 認可開始 （ログインボタン押下とか） 認可要求 ログイン／同意画面 認可応答 トークン要求 トークン応答 例: メアドの取得（API 利用） ⑤ じゃあください！ … あ、このメアドは 過去にご利用いただいた ゲ＊ラ様ですね！ マイページ表示 ① メアドが欲しいです ② メアドが欲しいって 言われてるんだけどいい？ ③ よかろう ④ いいってさ
9. • パスワード保存モデルは原理的※にセキュアではない • OAuth 2.0 を使わせるのは当然 API のセキュリティ
10. おさらいおわり
11. OAuth 2.0 のセキュリティ
12. • OAuth 2.0 を使わせるのは当然 API のセキュリティ（再）
13. • OAuth 2.0 を使わせるのは当然 ◦ OAuth 2.0 を使っていれば安全なのか？ API のセキュリティ（再）
14. • OAuth 2.0 はフレームワークである ◦ RFC6749 - The OAuth 2.0 Authorization Framework • "部品を正しく組み合わせることが重要。 OAuth を使えば良いというだけでは解決策にはなって いない。" ― Mark O'Neill, Gertner @APIDays Paris 2016 • さまざまなサービス環境に適切に対応するための、柔軟なオプションを提供している ただ OAuth を使うというだけではダメ
15. 個別の状況によってプロファイルが必要 Closed Circuit Factory Application Social Sharing Financial API - Read only Financial API - Read & Write 環境制御レベル 高 低 高 低 対 象 の 価 値 基本実装でも 充分 基本実装では ダメ インターネットのように 制御されていない環境下
16. 基本のプロファイル 送信者(sender), 受信者(receiver), メッセージ(message) の認証 送信者認証 受信者認証 メッセージ認証 認可要求 間接的 なし なし 認可応答 なし なし なし トークン要求 弱い GOOD GOOD トークン応答 GOOD GOOD GOOD
17. オプション機能とセキュリティレベル 認可要求/応答の種類とセキュリティレベル セキュリティレベル 機能セット 適用 高 JWS AuthZ Req. w/ Hybrid Flow 認可要求の保護 Hybrid Flow (confidential client) 認可応答の保護 Code Flow (confidential client) クライアント認証 低 Implicit Flow クライアント認証なし
18. オプション機能とセキュリティレベル トークンの種類とセキュリティレベル セキュリティレベル トークンの種類 適用 高 記名式トークン Sender Constrained Token 発行を受けた者しか 利用できない 低 持参人トークン Bearer Token 盗難されたトークン でも利用可能 飛行機のチケット 電車の切符
19. ※Hybrid Flow は OpenID Connect Core のなかで策定されている http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#HybridFlowAuth 金融 API 向けに策定中のプロファイル 送信者(sender), 受信者(receiver), メッセージ(message) の認証 送信者認証 受信者認証 メッセージ認証 認可要求 Request Object Request Object Request Object 認可応答 Hybrid Flow Hybrid Flow Hybrid Flow トークン要求 GOOD GOOD GOOD トークン応答 GOOD GOOD GOOD
20. • １クライアント１サーバの前提 • メッセージ認証（要求・応答） • 送信者認証 • 受信者認証 • 利用者認証 • メッセージ秘匿性 • トークンフィッシング、リプレイ 金融 API で解決必須の要因 "これらの多くはしばしば無視され、結果とし て非常に危ない OAuth 2.0 実装を産んで いる。" ― Nat Sakimura @OpenID BizDay
21. C 1 R • OAuth の重要な「セキュリティ上の前提」 ◦ 論理的な分離（認可サーバ毎に異なる redirection uri を設定）することが、認可サーバ Mix-up 攻撃などを回避するのに重要 １クライアント１サーバの前提 UA C 1 O C 1 R C 2 O C 2 R A 1 Z A 2 Z １クライアント１認可サーバ UA C 1 O C 1 R C 2 O A 1 Z A 2 Z １クライアント N 認可サーバ 違う認可サーバからの 応答を１つの redirection uri で受け 取る、とか
22. • 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 終端
23. • 認可要求・応答はブラウザを介するため、受信者は実際の送信者がだれかを確かめることが できない メッセージ 送信者 認証の問題 UA C 1 O C 1 R A 1 Z AZ は認可要求が CO から来たこ とを確認できない CR は認可応答が AZ から来たこ とを確認できない TLS 終端
24. • ネイティブアプリ（パブリッククライアント）上の「 code 横取り攻撃」などで顕著 ◦ 例: カスタムスキームをデバイス上のマルウェアなどによってハイジャック ◦ OAuth PKCE (RFC7636) はこの問題のために存在している メッセージ 受信者 認証の問題 UA GOOD APP BAD APP A 1 Z I am GOOD APP!!! redirect uri = goodapp://
25. • OAuth には利用者（ユーザ）の Identity の概念が無い • 利用者（ユーザ）認証については "Out of scope" 利用者認証 問題
26. • 認可要求はアプリケーション層では暗号化されていないので、 man-in-the-browser などによっ て読み取られる可能性がある • ブラウザ内マルウェアはかなり一般的 メッセージ秘匿性 問題 UA C 1 O C 1 R A 1 Z マルウェアはメッセージの内容を読 むことができる TLS 終端
27. • クライアントがトークン要求とリソース要求を「不正なサーバ」に送る。不正なサーバは今度は 「クライアント」として取得した要求を正規のサーバに送る ◦ クライアント開発者に、サーバのエンドポイントが変更されたとの偽メールを送る （２０人に１人程度はこのようなメール・フィッシングにひっかかることが知られている） ◦ 不正発行された TLS 証明書と DNS スプーフィングの組み合わせ トークン・フィッシング、トークン・リプレイ Attacker Client ABC Provider Hi! I am Provider API ♥ Hi! I am Client ABC ♪
28. どうする？FAPI セキュリティ
29. 1. Unique Source Identifier 2. Protocol + Version + Message Identifier 3. Full list of Actors/Roles ３つの要
30. OAuth 2.0 (RFC6749) の単純な実装の場合 Message Parameters ① Unique Source Identifier ② Protocol + Version Identifier ③ Fill list of Actors/Roles 認可要求 response type* client id* redirect uri scope state Client ID はグローバルに unique ではないため改ざ んが可能 識別子として params のリ ストがありますが、これは 完全な保証にはなりませ ん 存在しない 認可応答 code* state* other ext params Source Identifier にあた るものは存在しない 同上 存在しない トークン要求 grant type* code* redirect uri* client* credential / client id* Client ID はグローバルに unique ではない OK (OAuth 3.0 が存在し ないかぎり) 存在しない トークン応答 access token* token_type* expires_in refresh_token others Source Identifier にあた るものは存在しない 同上 存在しない
31. 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
32. 認可要求/応答の整合性を保護する • AuthZ※ Request/Response Integrity Protection ◦ Authorization の略記 • OAuth JAR (JWT Authorization Request) - IETF draft • ID Token (JWT による署名が施されている ) の利用 • ID Token に新しいパラメータ `s_hash` を含める
33. Message Original Parameters Modified Parameters Original Integrity Protection Modified Integrity Protection 認可要求 response type* client id* redirect uri scope state response type* client id* redirect uri* (unique) scope* state* / tbid* なし JWT Authorization Request (JAR) 認可応答 code* state* other ext params code* state* redirect uri* (unique) client id* state* / tbid* other ext params なし ID Token + s_hash トークン要求 grant type* code* redirect uri* client* credential / client id* grant type* code* redirect uri* (unique) client* credential / client id* state* / tbid* TLS TLS トークン応答 access token* token_type* expires_in refresh_token others + 上記 access token* token_type* expires_in refresh_token others TLS TLS
34. これらはまだ "Art" であり "Science" が必要 • ドイツのダルムシュタット工科大学のチームが学術的に標準化を試みている
35. これらの課題解決のための組織 • OpenID Foundation の Financial API WG https://openid.net/wg/fapi/ • なぜ OpenID Foundation でやるのか ◦ OAuth, JWT, JWS, OpenID Connect の全著者が所属している ◦ 無償、相互不主張提供とする知財ポリシーにより、だれでも自由に実装可能となる ◦ WG 加盟は無料（スポンサーは募集中とのこと） ◦ WTO TBT 協定※ 準拠プロセス ▪ 貿易の技術的障害に関する協定 云々
36. 所感: 金融って大変だな…
37. おまけ
38. 正しく実装できているかチェック • Self Certify 出来る（Docker Image の配布もある） • Self Certify を公開すると FTC法5条 が適用される • 公開せずにチェックツールとして使うのも良い
39. スマホアプリにおける認証時のベストプラクティス • OAuth 2.0 for Native Apps ◦ https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07 ◦ ネイティブアプリは OAuth認証リクエストを実行するために外部ユーザエージェントを使用しなければならない (MUST) ▪ 組み込み UA (WebView など) は使ってはいけない （！！！） ◦ 認証サーバは、以下の３つの redirect uri オプションをサポートしなければならない (MUST) ▪ App-declared Custom URI Scheme Redirection ▪ App-claimed HTTPS URI Redirection ▪ Loopback URI Redirection ◦ パブリックネイティブアプリクライアントは、 Proof Key for Code Exchange (PKCE, RFC7636) で認可リクエストを 保護しなければならない (MUST) ◦ ネイティブアプリクライアントのために shared secret が依然として必要な認証サーバーは、クライアントをパブ リッククライアントとして扱わなければならない (MUST)
40. これから想定される OAuth • ネットに繋いでいない（ブラウザを開くなどしていない）ユーザの認可 ◦ サーバからユーザのスマフォに push 通知で認可を求める
41. Closed Circuit Factory Application Social Sharing Financial API - Read only Financial API - Read & Write 環境制御レベル 高 低 高 低 対 象 の 価 値 終 ────── ⓣⓜⓓ