Successfully reported this slideshow.
Your SlideShare is downloading. ×

KeycloakでFAPIに対応した高セキュリティなAPIを公開する

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 63 Ad
Advertisement

More Related Content

More from Hitachi, Ltd. OSS Solution Center. (20)

Recently uploaded (20)

Advertisement

KeycloakでFAPIに対応した高セキュリティなAPIを公開する

  1. 1. © Hitachi, Ltd. 2022. All rights reserved. KeycloakでFAPIに対応した高セキュリティなAPIを公開する CloudNative Days Tokyo 2022 株式会社 日立製作所 田畑 義之
  2. 2. 1 © Hitachi, Ltd. 2022. All rights reserved. 自己紹介 田畑 義之 (たばた よしゆき)  株式会社 日立製作所 アーキテクチャセンタ  ソフトウェアエンジニア  GitHub: @y-tabata • 認証認可やAPI関連分野のソリューション開発&コンサルティング  金融、公共、社会、産業分野における API管理基盤や認証認可システムの導入支援 • 認証認可・API管理関連のOSSへのコントリビュート  Keycloak (IAMのOSS)  3scale (API管理のOSS) • 情報発信  Keycloak書籍  ThinkIT/@ITでのWeb記事連載  Apidays/OAuth Security Workshop/CloudNative Daysなど、国内外のイベントでの登壇
  3. 3. 2 © Hitachi, Ltd. 2022. All rights reserved. セッション概要 • FAPI (Financial-grade API)という高セキュリティなAPIを公開するための仕様があります。 • システムのセキュリティは高ければ高いほど望ましいですが、実案件では対応コストやユー ザビリティとの トレードオフを見ていかないといけません。  一方で、FAPIに準拠しないにしても、どんな攻撃のリスクがあるかを知り、自システムで はどうやって対策 できるかを考えておくことは大切です。 低い対応コスト/ 高いユーザビリティ 高いセキュリティレベル • FAPIの概要のご説明 • FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介 • IAMを実現するOSSであるKeycloakにおけるFAPI対応のご紹介 本セッションでは・・・
  4. 4. © Hitachi, Ltd. 2022. All rights reserved. Contents 3 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  5. 5. © Hitachi, Ltd. 2022. All rights reserved. Contents 4 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  6. 6. 5 © Hitachi, Ltd. 2022. All rights reserved. FAPIとは • Financial-grade API (FAPI)セキュリティプロファイルは、「API認可」のプロトコルとし てよく使われるOAuth 2.0や「SSO」のプロトコルとしてよく使われるOpenID Connect (OIDC)をベースに、高い レベルのセキュリティを必要とするあらゆる市場領域のAPIに適用するためのOAuth 2.0や OIDCの セキュアな使い方を定義している。 Financial-grade API Security Profile 1.0 Part 2: Advanced RFC 7519: JSON Web Token (JWT) RFC 7636: Proof Key for Code Exchange by OAuth Public Clients RFC 6819: OAuth 2.0 Threat Model and Security Considerations RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 6749: The OAuth 2.0 Authorization Framework OpenID Connect Core 1.0 RFC 8705: OAuth 2.0 Mutual- TLS Client Authentication and Certificate-Bound Access Tokens RFC 9126: OAuth 2.0 Pushed Authorization Requests Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
  7. 7. © Hitachi, Ltd. 2022. All rights reserved. Contents 6 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  8. 8. 7 © Hitachi, Ltd. 2022. All rights reserved. 前提 • OAuth 2.0/OIDCで最も推奨される認可コードフローを前提とします(ハイブリッドフロー を含む)。 ※インプリシットフローやリソースオーナパスワードクレデンシャルズフローだと、説明すべき攻撃方法の数が多くなってしまうため。 正当なユーザ クライアント リソースサーバ 認可サーバ アクセス 認可リクエスト ログイン画面 ログイン 認可レスポンス トークンリクエスト トークンレスポンス APIリクエスト APIレスポンス 画面表示
  9. 9. 8 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 ※参考: FAPI 2.0 Attacker Model https://openid.net/specs/fapi-2_0-attacker-model-00.html
  10. 10. 9 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント 正当なユーザ 正当なユーザとしてログインすることで以下のようなことができる。 • クライアントに設定している情報からの、正当なユーザの個人情報の取得 →住所や電話番号、プライベートな写真の取得など。 • 正当なユーザの周辺のユーザへの攻撃 →「友達」として登録されているユーザへのプリペイドカード番号の要求など。
  11. 11. 10 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント 正当なユーザ リソースサーバ 正当なユーザのリソースにアクセスすることで以下のようなことができる。 • リソースサーバに保存している情報からの、正当なユーザの個人情報の取得 →保存しているドキュメントや写真、動画の取得など。 • 金融取引をトリガーするために利用できるAPIのコール →正当なユーザの口座から攻撃者の口座への送金のリクエストなど。
  12. 12. 11 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者の目的は何か ~ 1. 正当なユーザとしてクライアントにログインすること。 2. 正当なユーザのリソースにアクセスすること。 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 正当なユーザ 攻撃者 クライアント リソースサーバ 攻撃者 攻撃者 正当なユーザに攻撃者としてログインさせたり、攻撃者のリソースにアクセスさせることで以下のようなことができる。 • 攻撃者アカウントへ登録された正当なユーザの情報の取得 →正当なユーザが誤って攻撃者のアカウントへ登録してしまった個人情報や口座情報の取得など。 • 正当なユーザのアカウント情報を用いた他システムへのログイン →正当なユーザが誤って攻撃者のアカウントへ紐づけてしまった他システムのアカウントを用いたログインなど。
  13. 13. 12 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。 2. 正当なユーザにリンクを送付して、そこに訪問させることができる。 3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。 4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができる。 5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。 6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレスポ ンスを改ざんすることができる。 7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加し、認 可サーバからトークンを取得することができる。 ※参考: FAPI 2.0 Attacker Model https://openid.net/specs/fapi-2_0-attacker-model-00.html
  14. 14. 13 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 1. ブラウザ等を用いて、各コンポーネントとメッセージのやり取りができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 自作メッセージを 送付 改ざんした メッセージを送付 正当なメッセージを 送付
  15. 15. 14 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 2. 正当なユーザにリンクを送付して、そこに訪問させることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 攻撃者のサイト リンクを 送付 訪問
  16. 16. 15 © Hitachi, Ltd. 2022. All rights reserved. 不正なWiFiアクセスポイントや 侵害したネットワーク内 まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 3. 正当なユーザのメッセージのやり取りを傍受・ブロック・改ざんすることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 復号化キーがなければ、 中身の読み取りまではできない。 傍受 ブロック 改ざん
  17. 17. 16 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 4. ブラウザ履歴や各種ログなどから、認可リクエストや認可レスポンスを読み取ることができ る。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ ブラウザの 履歴の入手 認可サーバや 手前のリバプロのログの入手 認可リクエストや 認可レスポンスを読み取る 認可リクエスト
  18. 18. 17 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 5. トークンエンドポイントになりすまして、トークンリクエストを取得することができる。 クライアント管理者 攻撃者 クライアント リソースサーバ 認可サーバ エンドポイント 変更の通知 攻撃者のサーバ 正規のトークン リクエスト 誘導された トークンリクエスト トークン リクエストを取得 クライアント設定の変更
  19. 19. 18 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 6. リソースサーバの手前のリバプロでAPIリクエストやAPIレスポンスを読み取ったり、APIレ スポンスを改ざんすることができる。 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ リバプロ APIリクエスト APIリクエスト 盗聴・改ざん TLS 終端
  20. 20. 19 © Hitachi, Ltd. 2022. All rights reserved. まずは攻撃者を知ろう ~ 攻撃者はどんなことができる? ~ 正当なユーザ 攻撃者 クライアント リソースサーバ 認可サーバ 攻撃者配下の 認可サーバ 7. 認可サーバになりすまして、正当なユーザと認可サーバ/クライアントとのやり取りに参加 し、認可サーバからトークンを取得することができる。 メール等で 誘導 実際の やり取り トークンを取得 正当な やり取り 正当な やり取り 正当なユーザが 想定したやり取り
  21. 21. 20 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  22. 22. 21 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  23. 23. 22 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 正当なユーザの認可レスポンスを盗聴して自身のブラウザからクライアントに流し込めれば、正当なユー ザとしてクライアントにログインできる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス トークンリクエスト トークンレスポンス 正当なユーザ としてログイン GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org ※そのまま送る。 POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com
  24. 24. 23 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com セッションに stateを保存 認可レスポンスに 同一のstateを付与 セッションのstateと 認可レスポンスの stateを比較検証 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org
  25. 25. 24 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。攻撃者から送られてきた認可レスポン スには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検知でき る。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス セッションに stateを保存 盗聴 認可レスポンス GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org ※そのまま送る。 認可レスポンスに 同一のstateを付与 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 認可レスポンスと 同一のstateが セッションに無い ことを検知
  26. 26. 25 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 事前に認可リクエストをトリガーし、stateを払い出しておく。正当なユーザの認可コードのみを盗聴し て攻撃者用の認可レスポンスを作成し、自身のブラウザからクライアントに流し込めれば、正当なユーザ としてクライアントにログインできる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス トークンリクエスト トークンレスポンス 正当なユーザ としてログイン POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 アクセス 認可リクエスト GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org ※stateは自身のものを流用。 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com
  27. 27. 26 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 署名を検証 GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。
  28. 28. 27 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可 レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス アクセス 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org ※stateを自身のものを変えたとする。 GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。 署名の検証で 改ざんを検知 GET /authorize? response_type=code … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com
  29. 29. 28 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー ドとstateのハッシュ値を含める。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code id_token &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 署名とハッシュ値 を検証 GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj &id_token=eyJr… HTTP/1.1 Host: client.example.org <IDトークン> { "sub": "1001", "aud": "s6BhdRkqt3", "c_hash": "QR2z…", "s_hash": "9s6C…", "auth_time": 1594140090, "iss": "https://server.example.com/", "exp": 1594140390, "iat": 1594140090 } ※署名あり。
  30. 30. 29 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 2. 認可コード横取り攻撃 ← 分離署名としてのIDトークン OIDCのハイブリッドフローを使用し、認可レスポンスでIDトークンを返し、IDトークンには認可コー ドとstateのハッシュ値を含める。IDトークンの署名とそれらハッシュ値を検証することで、クライアン トは認可レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 盗聴 認可レスポンス アクセス 認可リクエスト GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk &id_token=eyJr… HTTP/1.1 Host: client.example.org ※stateを自身のものに変えたとする。 署名とハッシュ値の 検証で改ざんを 検知 GET /authorize? response_type=code id_token … &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /cb# code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj &id_token=eyJr… HTTP/1.1 Host: client.example.org <IDトークン> { "sub": "1001", "aud": "s6BhdRkqt3", "c_hash": "QR2z…", "s_hash": "9s6C…", "auth_time": 1594140090, "iss": "https://server.example.com/", "exp": 1594140390, "iat": 1594140090 } ※署名あり。 GET /authorize? response_type=code id_token &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com
  31. 31. 30 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  32. 32. 31 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 TLS終端するリソースサーバの手前のリバプロのログからAPIリクエスト(アクセストークン含む)を盗聴 できれば、正当なユーザのリソースにアクセスできるアクセストークンを取得できる。 リソースサーバ 認可サーバ 攻撃者 APIリクエスト 盗聴 APIリクエス ト アクセストークン の取得 GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… ※そのまま送る GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… クライアント リバプロ
  33. 33. 32 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド (RFC 8705) クライアント証明書をアクセストークンにバインドする。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 クライアント証明書 を相互TLSで提示 リソースサーバ APIリクエスト クライアント証明書の ハッシュ値を比較検証 アクセストークンに クライアント証明書 のハッシュ値を バインドする クライアント証明書 を相互TLSで提示
  34. 34. 33 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書のバインド (RFC 8705) クライアント証明書をアクセストークンにバインドする。たとえアクセストークンを取得しても攻撃者は クライアント証明書の秘密鍵は取得できず、その所持をリソースサーバに示すことができないため、保護 リソースを取得できなくなる。 リソースサーバ 認可サーバ 攻撃者 アクセス 盗聴 APIリクエス ト アクセストークン の取得 GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… ※そのまま送る GET /resource HTTP/1.1 Host: resource.example.com Authorization: Bearer eyJr… クライアント リバプロ 正当なユーザ APIリクエスト 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス クライアント証明書を提示しない/ クライアント証明書が一致しない 不正なリクエストを検知 クライアント証明書の秘密鍵は 提示されないので奪えない
  35. 35. 34 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 リダイレクトURIを改ざんした認可リクエストを正当なユーザに送り付け、攻撃者のサイトで認可コード を盗聴して自身で 認可サーバに送ることができれば、正当なユーザのリソースにアクセスできるアクセストークンを取得で きる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト 認証 認可レスポンス 傍受 トークンリクエスト トークンレスポンス APIリクエスト アクセストークン の取得 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: attacker.example.org POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3
  36. 36. 35 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック 事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの 完全一致を検証する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com 事前に登録された リダイレクトURIと 認可リクエストの リダイレクトURIを 比較検証 事前にリダイレクトURIを 完全URIで登録
  37. 37. 36 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック 事前に登録されたクライアントのリダイレクトURIと認可リクエストに付与されたリダイレクトURIとの 完全一致を検証する。 攻撃者が送り付けた認可リクエストはリダイレクトURIが一致しないため、認可サーバは攻撃を検知でき る。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com リダイレクトURIの完全一致の 検証でリダイレクトURIの不正 を検知
  38. 38. 37 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート トークンエンドポイントでのクライアント認証を強制する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 &client_secret=jngso0033i クライアント認証を強制し クライアントクレデンシャル を比較検証
  39. 39. 38 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 4. リダイレクトURI改ざん攻撃 ← パブリッククライアントの非サポート トークンエンドポイントでのクライアント認証を強制する。アクセストークンの入手にはクライアントク レデンシャルの取得も必要になり、盗聴した認可コードだけではアクセストークンを取得できなくなる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサイト 攻撃者 リンクの送付 認可リクエスト 認証 認可レスポンス 傍受 トークンリクエスト GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://attacker.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: attacker.example.org クライアントクレデンシャルを 提示しない不正なリクエストを 検知 POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3
  40. 40. 39 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 トークンエンドポイントの変更通知をクライアント管理者に送り付けてエンドポイントの設定を変更させ、 攻撃者のサイトでトークンリクエストを取得できれば、認可コードもクライアントクレデンシャルも取得 でき、それらでアクセストークンを取得できる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサーバ 攻撃者 エンドポイント 変更通知 アクセス 認証 認可レスポンス 傍受 トークンリクエスト トークンレスポンス APIリクエスト アクセストークン の取得 POST /token HTTP/1.1 Host: attacker.example.org Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3 &client_secret=jngso0033i クライアント管理者クライアント エンドポイント 変更 認可リクエスト トークンリクエスト 認可コードもクライアント クレデンシャルも取得できる
  41. 41. 40 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認 証 (RFC 8705) クライアント証明書をクライアント認証に用いる。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 クライアント証明書を使った クライアント認証を強制し クライアント証明書を比較検証
  42. 42. 41 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクライアント認 証 (RFC 8705) クライアント証明書をクライアント認証に用いる。トークンリクエストを取得しても攻撃者はクライアン ト証明書の秘密鍵は取得できず、その所持を認可サーバに示すことができないため、クライアント認証に 失敗しアクセストークンを取得できなくなる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者のサーバ 攻撃者 エンドポイント 変更通知 アクセス 認証 認可レスポンス 傍受 トークンリクエスト POST /token HTTP/1.1 Host: attacker.example.org Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://attacker.example.org/cb &client_id=s6BhdRkqt3 クライアント管理者クライアント エンドポイント 変更 認可リクエスト トークンリクエスト クライアント証明書の秘密鍵は 提示されないので奪えない クライアント証明書を提示しない 不正なリクエストを検知
  43. 43. 42 © Hitachi, Ltd. 2022. All rights reserved. 認可リクエスト 自身に対する 認可リクエストをトリガ FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 6. IdP mix-up攻撃 認可サーバを準備し、正当なクライアントの認可サーバとして、かつ正当な認可サーバのクライアントと して登録する。 正当なユーザを攻撃者配下の認可サーバに誘導することで、アクセストークンを取得できる。 正当なユーザ リソースサーバ 認可サーバ 攻撃者 アクセスを誘導 認証 認可レスポンス 傍受 APIリクエスト アクセストークン の取得 クライアント トークンリクエスト 正当なクライアントの認可サーバ として登録されている 攻撃者配下の 認可サーバ 認可リクエスト トークンリクエスト トークンレスポンス 正当な認可サーバのクライアント として登録されている POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=o3ksnRuew2 GET /cb? code=SplxlOBeZQQYbY… &state=af0ifjsldkj HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=o3ksnRuew2 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=af0ifjsldkj HTTP/1.1 Host: server.example.com
  44. 44. 43 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザのリソースにアクセスすること。 6. IdP mix-up攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。JWT内のissクレームとaudクレームを検証す ることで、クライアントは認可レスポンスの不正を検知できる。 認可リクエスト 自身に対する 認可リクエストをトリガ 正当なユーザ リソースサーバ 認可サーバ 攻撃者 アクセスを誘導 認証 認可レスポンス クライアント 攻撃者配下の 認可サーバ 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &response_mode=jwt &client_id=o3ksnRuew2 … HTTP/1.1 Host: attacker.example.com <JARMレスポンス> { "aud": "o3ksnRuew2", "iss": "https://server.example.com/", … } ※署名あり。 issクレームとaudクレームの検証で 意図した認可サーバからのレスポンスではないことや 自身宛てのレスポンスではないことを検知
  45. 45. 44 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的 1. 正当なユーザとしてクライアントにログインすること。 1. 認可レスポンス横取り攻撃 2. 認可コード横取り攻撃 2. 正当なユーザのリソースにアクセスすること。 3. アクセストークン横取り攻撃 4. リダイレクトURI改ざん攻撃 5. トークンエンドポイントなりすまし攻撃 6. IdP mix-up攻撃 3. 正当なユーザに攻撃者としてログインさせること。 4. 正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 8. 認可コード挿入攻撃
  46. 46. 45 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 7. 認可レスポンス挿入攻撃 攻撃者の認可レスポンスを正当なユーザに送り付け、正当なユーザのブラウザからクライアントに流し込 ませることができれば、攻撃者としてクライアントにログインさせることができる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス トークンリクエスト トークンレスポンス 攻撃者として ログイン GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA HTTP/1.1 Host: client.example.org ※そのまま送る。 POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email HTTP/1.1 Host: server.example.com
  47. 47. 46 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザとしてクライアントにログインすること。 7. 認可レスポンス挿入攻撃 ← stateを使った対抗策 stateを使って認可リクエストと認可レスポンスをバインドする。正当なユーザから送られてきた認可レ スポンスには同一のstateを使ってバインドされた認可リクエストがないため、クライアントは攻撃を検 知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org ※そのまま送る。 GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com 認可レスポンスと 同一のstateが セッションに無い ことを検知
  48. 48. 47 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 事前に正当なユーザの認可リクエストを盗聴し、stateを取得しておく。攻撃者の認可コードのみを使っ て正当なユーザ用の認可レスポンスを作成し、クライアントに流し込ませることができれば、攻撃者とし てクライアントにログインさせることができる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス トークンリクエスト トークンレスポンス 攻撃者として ログイン POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri= https://client.example.org/cb &client_id=s6BhdRkqt3 アクセス 認可リクエスト GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=af0ifjsldkj HTTP/1.1 Host: client.example.org ※stateは正当なユーザのものを流用。 GET /cb? code=SplxlOBeZQQYbYS6WxSbIA &state=bk8kejboqlk HTTP/1.1 Host: client.example.org GET /authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 盗聴
  49. 49. 48 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests) 認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに 登録する。 正当なユーザ クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス トークンリクエスト トークンレスポンス PARリクエスト PARレスポンス POST /par HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn:ietf:params:oauth:client- assertion-type:jwt-bearer &client_assertion=eyJr… &request=eyJr… &client_id=s6BhdRkqt3 <リクエストオブジェクト> { "aud": "https://server.example.com/", "nbf": 1594140030, "scope": "openid profile email", "iss": "s6BhdRkqt3", "response_type": "code id_token", "redirect_uri": "https://client.example.org/cb", "state": "af0ifjsldkj", "exp": 1594140390, "client_id": "s6BhdRkqt3“, "code_challenge": "K2-l…", "code_challenge_method": "S256" } ※署名あり。 GET /authorize? client_id=s6BhdRkqt3 &request_uri= urn:ietf:params:oauth: request_uri:6esc… HTTP/1.1 Host: server.example.com HTTP/1.1 201 Created Content-Type: application/json Cache-Control: no-cache, no-store { "request_uri": "urn:ietf:params:oauth: request_uri:6esc…", "expires_in": 60 } 事前にパラメータを JWTにまとめて送信 認可リクエストに パラメータは直接 含まれない
  50. 50. 49 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 ← PAR (OAuth 2.0 Pushed Authorization Requests) 認可リクエストパラメータから署名付きのJWT(リクエストオブジェクト)を作成し、事前に認可サーバに 登録する。認可 リクエストにはリクエストオブジェクトへの参照URIしか含まれないため、stateを取得できなくなる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト GET /authorize? client_id=s6BhdRkqt3 &request_uri= urn:ietf:params:oauth: request_uri:6esc… HTTP/1.1 Host: server.example.com 盗聴 PARリクエスト PARレスポンス POST /par HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn:ietf:params:oauth:client- assertion-type:jwt-bearer &client_assertion=eyJr… &request=eyJr… &client_id=s6BhdRkqt3 <リクエストオブジェクト> { "aud": "https://server.example.com/", "nbf": 1594140030, "scope": "openid profile email", "iss": "s6BhdRkqt3", "response_type": "code id_token", "redirect_uri": "https://client.example.org/cb", "state": "af0ifjsldkj", "exp": 1594140390, "client_id": "s6BhdRkqt3“, "code_challenge": "K2-l…", "code_challenge_method": "S256" } ※署名あり。 stateを盗聴できないので 攻撃が成立しない (正当なユーザ用の認可 レスポンスを作成できない)
  51. 51. 50 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 攻撃者の目的: 正当なユーザに攻撃者としてログインさせること。/正当なユーザに攻撃者のリソースにアクセスさせること。 8. 認可コード挿入攻撃 ← JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 認可レスポンスをJWT形式で返し、JWTに署名を入れる。署名を検証することで、クライアントは認可 レスポンスの改ざんを検知できる。 正当なユーザ 攻撃者 クライアント 認可サーバ アクセス 認可リクエスト 認証 認可レスポンス 送信 認可レスポンス アクセス 認可リクエスト GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org ※stateを正当なユーザのものに 変えたとする。 GET /authorize? response_type=code &response_mode=jwt &client_id=s6BhdRkqt3 &redirect_uri= https://client.example.org/cb &scope=openid profile email &state=bk8kejboqlk HTTP/1.1 Host: server.example.com GET /authorize? response_type=code … &state=af0ifjsldkj HTTP/1.1 Host: server.example.com 盗聴 GET /cb? response=eyJr… HTTP/1.1 Host: client.example.org <JARMレスポンス> { "aud": "s6BhdRkqt3", "code": "Splx…", "iss": "https://server.example.com/", "state": "af0ifjsldkj", "exp": 1594141090 } ※署名あり。 署名の検証で 改ざんを検知
  52. 52. 51 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠することで防げる攻撃8選 ~ まとめ ~ 1. 認可レスポンス横取り攻撃 • stateを使った対抗策 2. 認可コード横取り攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 分離署名としてのIDトークン 3. アクセストークン横取り攻撃 • アクセストークンへのクライアント証明書のバインド (RFC 8705) 4. リダイレクトURI改ざん攻撃 • リダイレクトURIの完全一致チェック • パブリッククライアントの非サポート 5. トークンエンドポイントなりすまし攻撃 • クライアント証明書を使ったクライアント認証 (RFC 8705) 6. IdP mix-up攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 7. 認可レスポンス挿入攻撃 • stateを使った対抗策 8. 認可コード挿入攻撃 • PAR (OAuth 2.0 Pushed Authorization Requests) • JARM (JWT Secured Authorization Response Mode for OAuth 2.0)
  53. 53. © Hitachi, Ltd. 2022. All rights reserved. Contents 52 1. FAPIとは 2. FAPIに準拠することで防げる攻撃 ~8選~ 3. KeycloakにおけるFAPI対応
  54. 54. 53 © Hitachi, Ltd. 2022. All rights reserved. 主な特徴  OAuth 2.0/OpenID ConnectやSAMLに対応  LDAPサーバやActive Directoryと連携可能  GitHubなどのユーザアカウントを利用した ソーシャルログインにも対応 Keycloakとは • Keycloakは、Red Hat社を中心に開発されている IAM (Identity and Access Management: IDアクセス管理)のOSS。 • シングルサインオンや、OAuth 2.0の認可サーバの機能を提供。 主要標準に対応したID連携 (OAuth 2.0の認可サーバーを含む) Keycloak LDAP Active Directory RDB OpenID Connect SAML GitHub Twitter Facebook ID管理と認証 ソーシャルログイン (Identity Brokering)
  55. 55. 54 © Hitachi, Ltd. 2022. All rights reserved. Keycloakの強み • 最先端の標準仕様にいち早く追従していく、コミュニティ力! • Keycloakメンテナの乗松さん(日立)が、FAPI-SIG (Financial-grade API Security : Special Interest Group)を立ち上げ、活動をリードしています。 標準仕様 Keycloakのサポート 日 OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Flow - Core 1.0 2021/5 Financial-grade API (FAPI) Security Profile 1.0 - Part 1: Baseline 2021/6 Financial-grade API (FAPI) Security Profile 1.0 - Part 2: Advanced 2021/6 Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) 2021/7 Financial-grade API: Client Initiated Backchannel Authentication Profile (FAPI-CIBA) 2021/7 RFC 9126: OAuth 2.0 Pushed Authorization Requests (PAR) 2021/7 Open Finance Brasil Financial-grade API Security Profile 1.0 2021/7 FAPI 2.0 Baseline Profile 絶賛作業中! Grant Management for OAuth 2.0 絶賛作業中! OAuth 2.0 Rich Authorization Requests (RAR) 絶賛作業中! OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) 絶賛作業中!
  56. 56. 55 © Hitachi, Ltd. 2022. All rights reserved. FAPIに準拠する際の一般的な課題 FAPIに準拠することで防げる攻撃 1. 認可レスポンス横取り攻撃 • stateを使った対抗策 2. 認可コード横取り攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 分離署名としてのIDトークン 3. アクセストークン横取り攻撃 • アクセストークンへのクライアント証明書のバインド (RFC 8705) 4. リダイレクトURI改ざん攻撃 • リダイレクトURIの完全一致チェック • パブリッククライアントの非サポート 5. トークンエンドポイントなりすまし攻撃 • クライアント証明書を使ったクライアント認証 (RFC 8705) 6. IdP mix-up攻撃 • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) 7. 認可レスポンス挿入攻撃 • stateを使った対抗策 8. 認可コード挿入攻撃 • PAR (OAuth 2.0 Pushed Authorization Requests) • JARM (JWT Secured Authorization Response Mode for OAuth 2.0) • 設定項目が多すぎる。。。 ・・・ 今回ご紹介した以下のような対抗策を適切に設定する必要がある。 • 適切に設定されているか、つまりFAPIに準拠した状態になっているか、設定ミスによってセ キュリティホールが生じていないかを確認するのも大変。
  57. 57. 56 © Hitachi, Ltd. 2022. All rights reserved. • クライアントポリシーという機構を使います。 特定の条件(コンディション)に合致するクライアントに、FAPIのようなセキュリティプロファイルを適用することができま す。 セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか myroleというロールを持つ myscopeというスコープを持つ FAPI 1.0 - Part 1 Baseline FAPI 1.0 - Part 2 Advanced FAPI-CIBA 例えば以下のようなことをクライアントポリシーで設定できます。 に合致する クライアントに を適用する。 など など • これによって何がうれしいか • 対象のクライアントを自動的にFAPIに準拠させてくれる! ← 細かな設定が不要に! • クライアントと紐づいたKeycloakへのリクエストがFAPIに準拠しているかどうかを チェックしてくれる。 • クライアントの設定がFAPIに準拠しているかをチェックしてくれる。
  58. 58. 57 © Hitachi, Ltd. 2022. All rights reserved. セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか myroleというロールを持つ FAPI 1.0 - Part 2 Advanced 例えば以下のようなクライアントポリシーを作成した場合: に合致する クライアントに を適用する。 GET /realms/myrealm/protocol/openid-connect/auth? client_id=myclient &response_type=code &scope=openid &state=kci63sqvvwd &nonce=c93vbo8v8ead &redirect_uri=https://localhost:8082/callback HTTP/1.1 Host: localhost:8443 ログイン画面が表示される エラーが返される HTTP/1.1 302 Found Location: https://localhost:8082/callback? error=invalid_request &error_description= Missing parameter: ‘request’ or ‘request_uri’ &state=kci63sqvvwd リクエストオブジェクトがないという意 以下のようなリクエスト(FAPIに非準拠)を送ると・・・ myroleロールを持たないクライアントの場合: myroleロールを持つクライアントの場合: myroleロールを付けると myroleロールを取ると
  59. 59. 58 © Hitachi, Ltd. 2022. All rights reserved. セキュリティプロファイル コンディション KeycloakではFAPIをどのように設定するか myroleというロールを持つ FAPI 1.0 - Part 2 Advanced 例えば以下のようなクライアントポリシーを作成した場合: に合致する クライアントに を適用する。 GET /realms/myrealm/protocol/openid-connect/auth? client_id=myclient &response_type=code id_token &scope=openid &request=eyJraWQiOiI2R2l… HTTP/1.1 Host: localhost:8443 ログイン画面が表示される もちろんFAPIに準拠したリクエストを送ると・・・ myroleロールを持つクライアントでも
  60. 60. 59 © Hitachi, Ltd. 2022. All rights reserved. KeycloakではFAPIをどのように設定するか ちなみに、FAPIに準拠したリクエストを送るのがハードルが高いという方は・・・ 日立からOIDFのCertificationをパスしたFAPIのクライアント実装を公開していますので是非ご活用ください! 参考: https://openid.net/developers/certified/#FAPIRP
  61. 61. 60 © Hitachi, Ltd. 2022. All rights reserved. まとめ - FAPIの概要のご説明  OAuth 2.0やOIDCをベースにした、高いレベルのセキュリティを必要とするあら ゆる市場領域のAPIに適用できる仕様です。 - FAPIに準拠するとどんな攻撃から身を守ることができるのかのご紹介 1. 認可レスポンス横取り攻撃 ← stateを使った対抗策 2. 認可コード横取り攻撃 ← JARM、分離署名としてのIDトークン 3. アクセストークン横取り攻撃 ← アクセストークンへのクライアント証明書の バインド 4. リダイレクトURI改ざん攻撃 ← リダイレクトURIの完全一致チェック、パブ リッククライアントの 非サポート 5. トークンエンドポイントなりすまし攻撃 ← クライアント証明書を使ったクラ イアント認証 6. IdP mix-up攻撃 ← JARM、分離署名としてのIDトークン 7. 認可レスポンス挿入攻撃 ← stateを使った対抗策 8. 認可コード挿入攻撃 ← PAR、JARM、分離署名としてのIDトークン - KeycloakにおけるFAPI対応のご紹介
  62. 62. 61 © Hitachi, Ltd. 2022. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries. • Twitterは、Twitter,Inc.の登録商標です。 • Facebookは、Facebook,Inc.の登録商標です。 • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.

×