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

Transcript

1. FAPI Security
   Yoko TAMADA @tmd45
   2017/08/18 feedforce Inc.
   OpenID BizDay で金融 API に求められるセキュリティの話を聞いてきた話
   

   View Slide

2. Financial APIセキュリティの現状について @ OpenID BizDay 10
   https://www.slideshare.net/secret/t4myNYsddpQX4k
   © 2017 by Nat Sakimura. CC-BY-SA
   本スライドもこれに従い CC-BY-SA ライセンスとします。
   所出、ライセンス
   

   View Slide

3. OAuth 2.0 おさらい
   ※用語は OpenID Connect と混ざってます
   

   View Slide

4. OAuth とは
   ● リソースアクセスのしくみ（認可 , Authorization）
   ● リソース（≒ 個人情報）へのアクセスを許可する／許可してもらう
   【ソーシャルPLUS】各プロバイダの認証プロトコル #補足
   https://feedforce.qiita.com/tmd45/items/2c7dc19854746096b330#%E8%A3%9C%E8%B6%B3
   

   View Slide

5. 例「Taro さん が キャンペーンサイト に Facebook ログイン を使ってログインする」
   ● IdP（Identity Provider）
   ○ 認証結果と属性情報を 提供する 側 ＝Facebook
   ○ 認証（認可）のサーバ側とか呼んだりする
   ● RP（Relying Party）
   ○ 認証結果と属性情報を 受け取る 側 ＝キャンペーンサイト
   ○ 認証（認可）のクライアント側とか呼んだりする
   ● その他
   ○ Entity（実体）＝Taro さん（エンドユーザー, 人間）
   ○ Identity（属性）＝Taro さんの情報（ID, 個人情報, など）
   Role
   

   View Slide

6. ● 認証とは「ブラウザの前にいる Entity が、サービス側が認識するどの Identiry と紐付いてい
   るのか確証を得ること」
   ● 認可を元に得られた情報（プロバイダ側のユーザ ID）→ お客様システムの会員 ID と紐づくこ
   とで、サービス側は「いまブラウザの前にいる人は Taro さんである」という確証を得る
   ○ ソーシャルログインによる認証
   認証と認可
   

   View Slide

7. 1. 認可要求（Authorization Request）
   2. 認可応答（Authorization Response）
   3. トークン要求（Access Token Request）
   4. トークン応答（Access Token Response）
   認可取得のフロー
   

   View Slide

8. キャンペーン
   サイト
   （RP）
   Facebook
   （IdP）
   エンド
   ユーザ
   認可開始
   （ログインボタン押下とか）
   認可要求
   ログイン／同意画面
   認可応答
   トークン要求
   トークン応答
   例: メアドの取得（API 利用）
   ⑤ じゃあください！
   … あ、このメアドは
   過去にご利用いただいた
   ゲ＊ラ様ですね！
   マイページ表示
   ① メアドが欲しいです
   ② メアドが欲しいって
   言われてるんだけどいい？
   ③ よかろう
   ④ いいってさ
   

   View Slide

9. ● パスワード保存モデルは原理的※にセキュアではない
   ● OAuth 2.0 を使わせるのは当然
   API のセキュリティ
   

   View Slide

10. おさらいおわり
    

    View Slide

11. OAuth 2.0 のセキュリティ
    

    View Slide

12. ● OAuth 2.0 を使わせるのは当然
    API のセキュリティ（再）
    

    View Slide

13. ● OAuth 2.0 を使わせるのは当然
    ○ OAuth 2.0 を使っていれば安全なのか？
    API のセキュリティ（再）
    

    View Slide

14. ● OAuth 2.0 はフレームワークである
    ○ RFC6749 - The OAuth 2.0 Authorization Framework
    ● "部品を正しく組み合わせることが重要。 OAuth を使えば良いというだけでは解決策にはなって
    いない。" ― Mark O'Neill, Gertner @APIDays Paris 2016
    ● さまざまなサービス環境に適切に対応するための、柔軟なオプションを提供している
    ただ OAuth を使うというだけではダメ
    

    View Slide

15. 個別の状況によってプロファイルが必要
    Closed Circuit
    Factory
    Application
    Social Sharing
    Financial API
    - Read only
    Financial API
    - Read & Write
    環境制御レベル
    高 低
    高
    低
    対
    象
    の
    価
    値
    基本実装でも
    充分
    基本実装では
    ダメ
    インターネットのように
    制御されていない環境下
    

    View Slide

16. 基本のプロファイル
    送信者(sender), 受信者(receiver), メッセージ(message) の認証
    送信者認証 受信者認証 メッセージ認証
    認可要求 間接的 なし なし
    認可応答 なし なし なし
    トークン要求 弱い GOOD GOOD
    トークン応答 GOOD GOOD GOOD
    

    View Slide

17. オプション機能とセキュリティレベル
    認可要求/応答の種類とセキュリティレベル
    セキュリティレベル 機能セット 適用
    高
    JWS AuthZ Req.
    w/ Hybrid Flow
    認可要求の保護
    Hybrid Flow
    (confidential client)
    認可応答の保護
    Code Flow
    (confidential client)
    クライアント認証
    低
    Implicit Flow クライアント認証なし
    

    View Slide

18. オプション機能とセキュリティレベル
    トークンの種類とセキュリティレベル
    セキュリティレベル トークンの種類 適用
    高
    記名式トークン
    Sender Constrained
    Token
    発行を受けた者しか
    利用できない
    低
    持参人トークン
    Bearer Token
    盗難されたトークン
    でも利用可能
    飛行機のチケット
    電車の切符
    

    View Slide

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
    

    View Slide

20. ● １クライアント１サーバの前提
    ● メッセージ認証（要求・応答）
    ● 送信者認証
    ● 受信者認証
    ● 利用者認証
    ● メッセージ秘匿性
    ● トークンフィッシング、リプレイ
    金融 API で解決必須の要因
    "これらの多くはしばしば無視され、結果とし
    て非常に危ない OAuth 2.0 実装を産んで
    いる。"
    ― Nat Sakimura @OpenID BizDay
    

    View Slide

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 で受け
    取る、とか
    

    View Slide

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 終端
    

    View Slide

23. ● 認可要求・応答はブラウザを介するため、受信者は実際の送信者がだれかを確かめることが
    できない
    メッセージ 送信者 認証の問題
    UA
    C
    1
    O
    C
    1
    R
    A
    1
    Z
    AZ は認可要求が CO から来たこ
    とを確認できない
    CR は認可応答が AZ から来たこ
    とを確認できない
    TLS 終端
    

    View Slide

24. ● ネイティブアプリ（パブリッククライアント）上の「 code 横取り攻撃」などで顕著
    ○ 例: カスタムスキームをデバイス上のマルウェアなどによってハイジャック
    ○ OAuth PKCE (RFC7636) はこの問題のために存在している
    メッセージ 受信者 認証の問題
    UA
    GOOD
    APP
    BAD
    APP
    A
    1
    Z
    I am GOOD APP!!!
    redirect uri = goodapp://
    

    View Slide

25. ● OAuth には利用者（ユーザ）の Identity の概念が無い
    ● 利用者（ユーザ）認証については "Out of scope"
    利用者認証 問題
    

    View Slide

26. ● 認可要求はアプリケーション層では暗号化されていないので、 man-in-the-browser などによっ
    て読み取られる可能性がある
    ● ブラウザ内マルウェアはかなり一般的
    メッセージ秘匿性 問題
    UA
    C
    1
    O
    C
    1
    R
    A
    1
    Z
    マルウェアはメッセージの内容を読
    むことができる
    TLS 終端
    

    View Slide

27. ● クライアントがトークン要求とリソース要求を「不正なサーバ」に送る。不正なサーバは今度は
    「クライアント」として取得した要求を正規のサーバに送る
    ○ クライアント開発者に、サーバのエンドポイントが変更されたとの偽メールを送る
    （２０人に１人程度はこのようなメール・フィッシングにひっかかることが知られている）
    ○ 不正発行された TLS 証明書と DNS スプーフィングの組み合わせ
    トークン・フィッシング、トークン・リプレイ
    Attacker
    Client
    ABC
    Provider
    Hi! I am Provider API ♥
    Hi! I am Client ABC ♪
    

    View Slide

28. どうする？FAPI セキュリティ
    

    View Slide

29. 1. Unique Source Identifier
    2. Protocol + Version + Message Identifier
    3. Full list of Actors/Roles
    ３つの要
    

    View Slide

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 にあた
    るものは存在しない
    同上 存在しない
    

    View Slide

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
    

    View Slide

32. 認可要求/応答の整合性を保護する
    ● AuthZ※ Request/Response Integrity Protection
    ○ Authorization の略記
    ● OAuth JAR (JWT Authorization Request) - IETF draft
    ● ID Token (JWT による署名が施されている ) の利用
    ● ID Token に新しいパラメータ `s_hash` を含める
    

    View Slide

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
    

    View Slide

34. これらはまだ "Art" であり "Science" が必要
    ● ドイツのダルムシュタット工科大学のチームが学術的に標準化を試みている
    

    View Slide

35. これらの課題解決のための組織
    ● OpenID Foundation の Financial API WG https://openid.net/wg/fapi/
    ● なぜ OpenID Foundation でやるのか
    ○ OAuth, JWT, JWS, OpenID Connect の全著者が所属している
    ○ 無償、相互不主張提供とする知財ポリシーにより、だれでも自由に実装可能となる
    ○ WG 加盟は無料（スポンサーは募集中とのこと）
    ○ WTO TBT 協定※ 準拠プロセス
    ■ 貿易の技術的障害に関する協定 云々
    

    View Slide

36. 所感: 金融って大変だな…
    

    View Slide

37. おまけ
    

    View Slide

38. 正しく実装できているかチェック
    ● Self Certify 出来る（Docker Image の配布もある）
    ● Self Certify を公開すると FTC法5条 が適用される
    ● 公開せずにチェックツールとして使うのも良い
    

    View Slide

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)
    

    View Slide

40. これから想定される OAuth
    ● ネットに繋いでいない（ブラウザを開くなどしていない）ユーザの認可
    ○ サーバからユーザのスマフォに push 通知で認可を求める
    

    View Slide

41. Closed Circuit
    Factory
    Application
    Social Sharing
    Financial API
    - Read only
    Financial API
    - Read & Write
    環境制御レベル
    高 低
    高
    低
    対
    象
    の
    価
    値
    終
    ──────
    ⓣⓜⓓ
    

    View Slide