ラベル RFC の投稿を表示しています。 すべての投稿を表示
ラベル RFC の投稿を表示しています。 すべての投稿を表示

2024年2月12日月曜日

OAuth2.0 Security Best Current Practiceを読んでみる(2)

こんにちは、富士榮です。

前回に続き、OAuth2.0 Security Best Current Practiceを読んでいきます。

今回は2つ目のブロックである「攻撃モデルの更新」です。今回は短めです。


攻撃モデルの更新

RFC6819に定義されている攻撃モデルの最新化しているセクションです。ここで定義された攻撃モデルに対して次のセクションで緩和策が定義される、という流れになっています。
定義されているのは、以下の5つのモデルです。
  • A1)攻撃者がブラウザやサーバに任意のエンドポイントをセットアップできる環境にあるケース
    • まぁ正直これができる環境だともう何も信じられなくなりますが、攻撃者はユーザを独自の認可サーバに誘導したり、認可コードやトークンの搾取ができてしまう可能性を考慮する必要があります。
  • A2)通信ネットワークを完全に制圧されているケース
    • これも当然ですが盗聴やなりすましが容易にできてしまう可能性を考慮する必要があります。
  • A3)認可レスポンスを攻撃者が見れてしまうケース
    • レスポンスの改ざんはできなくても見られてしまうケースは想定しておかないといけません。オープンリダイレクタなどが典型ですね。
  • A4)同様に認可リクエストを攻撃者が見れてしまうケース
    • リクエストが漏えいすることで攻撃者に情報を与えてしまう、というのはよくあることですね。
  • A5)アクセストークンを攻撃者が取得できてしまうケース
    • リソースサーバが攻撃者によって侵害されてしまっているケースなどが考えられますね。
これらの攻撃モデルのうち、A3〜A5は通常A1もしくはA2と同時に発生します。また、ここは大切なポイントだと思いますが「複数の攻撃者が協力して攻撃する可能性」についても考慮しておく必要がるとも述べられています。

次回は最終回、攻撃パターンと緩和策について読んでいきたいと思います。

2024年2月11日日曜日

OAuth2.0 Security Best Current Practiceを読んでみる(1)

こんにちは、富士榮です。

昨日ポストした通り、OAuth2.0 Security Best Current PracticeがLast Callの段階に進みました。2024年2月22日までのレビュー期間を経て正式にRFCに向けたステップに進みます。

ということで少しだけこのドキュメントを見ていきたいと思います。

何に関するドキュメントなのか

Abstract、Introductionを軽く要約すると、
  • 対象はRFC6749(The OAuth 2.0 Authorization Framework)、RFC6750(The OAuth 2.0 Authorization Framework: Bearer Token Usage)、そしてRFC6819(OAuth 2.0 Threat Model and Security Considerations)の3点
  • OAuth2.0のフレームワークの活用が進むにつれ、当初想定していた以上に重要なシナリオ(金融やヘルスケア、行政サービスなど)でも利用されるようになってきた
  • 当然さまざまな攻撃パターンも編み出されてきており、基本的にはRFC6819により対応してきてはいるが継続的に対応していくことが重要となってきている
  • そのため、このドキュメントでは最新のセキュリティ上の推奨事項を提供する
ということになっています。

文章の構造

目次を眺めると、
  • ベストプラクティス
  • 攻撃モデルの更新
  • 攻撃パターンと緩和策
という形になっています。

まずはベストプラクティスに従いアーキテクチャを設計を行い、RFC6819発行時点に加えて最新化された攻撃モデルを念頭に置きつつ、各攻撃パターンに対する緩和策を実装していく、という流れでシステム化を進めていく、という使い方が想定されているのだと思います。

今回はベストプラクティスの部分を見ておきましょう。

ベストプラクティス

以下のベストプラクティスが定義されています。
  • リダイレクトベースのフローの保護
    • 全体
      • オープンリダイレクト対策として登録済みredirect_uriとの完全一致を検証すること
      • CSRF対策をすること。PKCEやstateですね
      • Mix up攻撃に対策すること
      • 資格情報を含む情報をリダイレクトする際は誤って転送しないようにすること
    • 認可コードグラントの場合
      • 認可コードインジェクション対策を行うこと。PKCEですね
    • インプリシットグラントの場合
      • トークン漏えい対策をしない限りは使わないこと
  • トークンリプレイ対策
    • アクセストークン
      • DPoP、mTLSなどの送信者制限トークンを利用すること
    • リフレッシュトークン
      • パブリッククライアントの場合は送信者制限を行うかローテーションを行うこと
  • アクセストークンの権限の制限
    • 必要最低限の権限に絞ること
    • 特定のリソースサーバで利用するようにAudienceを絞ること
  • リソースオーナーパスワードクレデンシャルグラント
    • 利用してはならない
  • クライアント認証
    • 可能な限りクライアント認証を実装すること
    • mTLSやprivate_key_jwtなどを用いることを推奨
  • その他
    • RFC8414のOAuth Authorization Server Metadataを使うことは有用であるため認可サーバはメタデータを公開することを推奨
    • リソースサーバがクライアントを混同するような可能性のある属性を許可してはいけない
    • クライアントとリソースサーバの間はTLSで保護されるべきである
    • 認可応答はlocalhostおよびリダイレクトを使うネイティブアプリ(カスタムURIスキーム)を除き暗号化されていないネットワークを許可してはならない
    • postMessageで認可応答を送信する場合は送信開始者と受信者の厳密な検証を行うこと
    • 認可エンドポイントはユーザーエージェントが直接アクセスするためCORSを許可してはいけない
結構たくさんありますが、原則的なことが多いので実装する際のチェックとして利用すると良いと思います。

次回は続きを紹介したいと思います。


2015年9月26日土曜日

[SCIM] SCIM2.0がRFCに!

こんにちは、富士榮です。

プロビジョニングの標準仕様策定を目指して2011年にver1.0、2012年にver1.1がリリースされたSCIM(System for Cross-domain Identity Management)ですが、ついにver2.0がRFC化されました。

対象となったのは、以下の3つです。

RFC7642(http://www.rfc-editor.org/rfc/rfc7642.txt)
  System for Cross-domain Identity Management:
  Definitions, Overview, Concepts, and Requirements

RFC7643(http://www.rfc-editor.org/rfc/rfc7643.txt)
  System for Cross-domain Identity Management:
  Core Schema

RFC7644(http://www.rfc-editor.org/rfc/rfc7644.txt)
  System for Cross-domain Identity Management:
  Protocol

ちなみに、OpenIDファウンデーション・ジャパンのEnterprise Identity Working Group(EIWG)ではエンタープライズにおけるOpenID ConnectやSCIMの利用促進を目指し、「OpenID ConnectとSCIMのエンタープライズ利用ガイドライン」を2013年に公開しており、新版を10月にも公開する予定となっていますので、こちらも期待しておきましょう。

 OpenIDファウンデーション・ジャパン エンタープライズ・アイデンティティ・ワーキンググループ『OpenID ConnectとSCIMのエンタープライズ利用ガイドライン』を公開
 https://www.openid.or.jp/working-group/2013/12/openid-openid-connectscim.html


最近では、Oracle Identity ManagementやExgenのLDAP ManagerなどSCIMに対応したプロビジョニング製品も出てきていますし、Ping ONE / Ping FederateなどSCIMを使ってID管理を行うIdP製品やサービスも出てきているので、今後さらに普及していくと思われますので、要チェックですね。