VC-JOSE-COSEがCRに

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

VC-JOSE-COSEがW3CのCR（勧告候補）になっていますね。

https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/

Mike Jonesも書いているように先日同じく勧告候補になったVCDM（Verifiable Credentials Data Model）v2.0では前のバージョンと異なりクレデンシャルフォーマットにJSON-LDだけをサポートするようになっています。

一方でこのVC-JOSE-COSEはJOSE、SD-JWT、COSEをスコープとしているのでなんだかチグハグな感じになりつつあります。

まぁ、そもそもクレデンシャルフォーマットがISOのmDoc、IETFのSD-JWTやJWP、W3CのVCDMと割れてしまっているが今後どうなっていくんだろうか・・・という話ではあるんですが。

追記）崎村さんからOpen Wallet Foundationが見ているクレデンシャルフォーマットの一覧を頂いたので貼っておきます。16種類もある・・・（2024年4月末時点）

https://github.com/openwallet-foundation/credential-format-comparison-sig/tree/main/data/Credential-Format

IETF 119で発表されたJOSE、COSE、OAuth関連のスペック

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

IETF 119がブリスベンで本日まで開催されています。

実は私はIETFは参加したことがない（昨年の横浜も忙しくて行けなかった・・・）のですが、参加している人たちから色々と情報が流れてきています。

Mike Jonesさんが以下のポストをしています。

Eight Specifications Published in Preparation for IETF 119

https://self-issued.info/?p=2503

ポストによると主にMikeが絡んでいるスペック中心ではありますが、以下のスペックに関するUpdateがあったとのことです。

• JSON Web Proof
• JSON Proof Algorithms
• JSON Proof Token
• Fully-Specified Algorithms for JOSE and COSE
• OAuth 2.0 Protected Resource Metadata
• COSE "typ" (type) Header Parameter
• Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE
• Use of Hybrid Public-Key Encryption (HPKE) with Javascript Object Signing and Encryption (JOSE)

実装を追いかけている人は必読ですね。

OAuth2.0 Security Best Current Practiceを読んでみる（３）

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

前回、前々回とOAuth2.0 Security Best Current Practiceについてみてきました。

今回は攻撃パターンと緩和策についてみていきます。18パターンも定義されているので今回は最初の3つを紹介していきます。

攻撃パターンと緩和策

このセクションでは攻撃ごとに緩和策が記載されています。ここまでのベストプラクティス、攻撃モデルを考慮して、自身の実装を分析し該当する攻撃パターンが当てはまる可能性があるなら緩和策を考える、という使い方になると思います。

• redirect_uriの検証が不十分
• 基本は完全一致を検証することになりますが、パターンマッチングのロジックによってはエンコードされた値などをうまくハンドリングできていないケースなどもあり得そうです。
• 認可コードグラント
• redirect_uriにワイルドカードを使うケースが主に取り上げられています。
• 例えば、「https://*.somesite.example/*」という値がredirect_uriとして登録されていた場合、「https://attacker.example/.somesite.example」も通してしまう可能性があります
• また、CNAMEレコードのメンテナンスについても言及されています。使われていないCNAMEレコードのポイント先のURLを攻撃者が取得することで意図しないredirect_uriへ誘導されてしまう可能性があります
• インプリシットグラント
• 認可コードグラントで述べた攻撃はインプリシットでも同様に発生する可能性があります
• さらにインプリシットの場合、Locationヘッダにフラグメントがついていない場合、フラグメントを再付与してしまう問題により被害を大きくする可能性があります。例えばオープンリダイレクトにより転送された先にアクセストークンを付与してしまうことで攻撃者が用意した転送先にアクセストークンを直接的に送信してしまうことが発生します
• 緩和策
• これはシンプルにredirect_uriの完全一致を確認する、につきます
• ※localhostの場合を除きますが
• リファラーヘッダーを介した資格情報の漏洩
• 認可コード、stateパラメータ、さらにインプリシットの場合はフラグメントに設定されるアクセストークンが認可リクエスト・認可レスポンスのURIの内容に含まれることからリファラーヘッダを介して攻撃者に情報が知られてしまう可能性があります
• OAuthクライアントからの漏洩
• 通常OAuthクライアントは認可サーバからの認可レスポンスを受け取るとクライアント側の画面をレンダリングする訳ですが、そのページ上に例えば攻撃者のページがリンクとして存在していて強制クリックさせたり、iFrame内の広告などとして埋め込まれていると、リファラーヘッダーを介して認可コード、state、場合によってはアクセストークンなどが意図せずに漏洩します
• 認可サーバからの漏洩
• 認可サーバから漏れるような状態になっているとどうしようもない気もしますが、上記と同じように攻撃者のサイトへ誘導される仕組みがあると資格情報が漏洩します
• 漏洩の結果として、認可コードによるアクセストークンの取得や、アクセストークンそのものの搾取による攻撃が成立してしまいます
• 緩和策
• OAuthの認可レスポンスの結果レンダリングされるページや、認可エンドポイントにサードパーティのリソースや外部サイトへのリンクを含まないようにする（まぁ、当たり前ですがたまに認可エンドポイントに広告載せたい事業者とかGAタグを埋め込む事業者いますよね・・・）
• さらに安全にするには、
• リファラーヘッダを抑制するリファラーポリシーを適用する
• 認可コードグラントを利用する（インプリシットを使わない）
• PKCEを使う
• 認可コードは一度限りの利用にする（トークンエンドポイントに渡された段階で無効化する）
• stateを一度限りの利用にする（リダイレクト先で評価された段階で無効化する）
• 認可レスポンスをリダイレクトではなくform_postを利用する（repsonse_modeパラメータ）
• ブラウザ履歴による資格情報の漏洩
• 上記のリファラーヘッダと類似ですが、認可コードやアクセストークンがブラウザの履歴に残るケースが考えられます（これ、攻撃ではありませんがログイン画面をブックマークしちゃう人もいるんですよね・・・）
• 認可コード
• redirect_uriへの認可レスポンスが履歴に残るとcode=xxxの部分も残ってしまうことがあり、この認可コードを再利用されることがあります
• 対策としては、リファラーヘッダのケースと類似ですが、
• 認可コードを一度限りの利用にする
• response_modeとしてform_postを利用する
• となります
• アクセストークン
• こちらも前述のものと同じですが、フラグメントだけでなくクエリパラメータでアクセストークンを渡すケースがあり、ブラウザ履歴に情報の残ることがあります
• 対策としては、
• クエリパラメータでアクセストークンを渡さない
• response_modeとしてform_postを利用する
• となります

とりあえず今回はここまでです。

当たり前に聞こえますが広告とかGAタグは割と普通に実装されている気がするので十分に注意しましょう。

OAuth2.0 Security Best Current Practiceを読んでみる（２）

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

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

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

攻撃モデルの更新

RFC6819に定義されている攻撃モデルの最新化しているセクションです。ここで定義された攻撃モデルに対して次のセクションで緩和策が定義される、という流れになっています。

定義されているのは、以下の5つのモデルです。

• A1）攻撃者がブラウザやサーバに任意のエンドポイントをセットアップできる環境にあるケース
• まぁ正直これができる環境だともう何も信じられなくなりますが、攻撃者はユーザを独自の認可サーバに誘導したり、認可コードやトークンの搾取ができてしまう可能性を考慮する必要があります。
• A2）通信ネットワークを完全に制圧されているケース
• これも当然ですが盗聴やなりすましが容易にできてしまう可能性を考慮する必要があります。
• A3）認可レスポンスを攻撃者が見れてしまうケース
• レスポンスの改ざんはできなくても見られてしまうケースは想定しておかないといけません。オープンリダイレクタなどが典型ですね。
• A4）同様に認可リクエストを攻撃者が見れてしまうケース
• リクエストが漏えいすることで攻撃者に情報を与えてしまう、というのはよくあることですね。
• A5）アクセストークンを攻撃者が取得できてしまうケース
• リソースサーバが攻撃者によって侵害されてしまっているケースなどが考えられますね。

これらの攻撃モデルのうち、A3〜A5は通常A1もしくはA2と同時に発生します。また、ここは大切なポイントだと思いますが「複数の攻撃者が協力して攻撃する可能性」についても考慮しておく必要がるとも述べられています。

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

OAuth2.0 Security Best Current Practiceを読んでみる（１）

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

昨日ポストした通り、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を許可してはいけない

結構たくさんありますが、原則的なことが多いので実装する際のチェックとして利用すると良いと思います。

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