エディター
シェーン・ウィーデン、IBM
アン・ホー、IBM
要約
セッションハイジャックは、オンライン詐欺やアカウント乗っ取りの初期攻撃ベクトルとして増えています。FIDO認証は、クレデンシャルスタッフィングやフィッシングなど、他の単純な侵害形態の有効性を低下させるため、サイバー犯罪者はベアラートークンの盗難や再利用に目を向けます。ベアラートークンは、Webサイトに接続するブラウザで使用されるセッションCookieと、ネイティブモバイルアプリケーションなどの他のシッククライアントアプリケーションタイプで使用されるOAuthアクセストークンを含む資格情報の形式です。これらの資格情報が長期間存続し、悪意のある攻撃者が別のマシンから使用できるように作成されたマシンから「リフトアンドシフト」できる場合、その取引可能な価値は重要になります。ブラウザ用の Device Bound Session Credentials (DBSC) や OAuth アプリケーション用の Demonstration Proof of Possession (DPoP) などの新しいテクノロジーは、セッション ハイジャックの脅威を軽減しようとしています。この記事では、これらのテクノロジーがセッションハイジャックの問題にどのように対処するか、また、オンラインエコシステムにおける強力なフィッシング耐性認証をどのように補完するかについて説明します。
聴衆
このホワイトペーパーは、オンラインIDおよびアクセス管理のセキュリティとライフサイクルをオンライン詐欺から保護する責任を負う最高情報セキュリティ責任者(CISO)および技術スタッフを対象としています。
1. イントロダクション
認証と承認は、特にオンライン資格情報エコシステムにとって、ID ライフサイクルの不可欠な部分です。コストのかかるセキュリティインシデントや侵害を伴うオンラインID詐欺の脅威が増大しているため、企業はフィッシング、クレデンシャルスタッフィング、セッションハイジャックなどのさまざまな攻撃ベクトルによるアカウント乗っ取りから従業員を保護および保護する方法を模索しています。認証では、パスキーによるFIDO認証は、ユーザーに「より安全で、より安全で、より高速なオンライン体験」を提供し、パスキーの採用の増加は、中間者(MITM)フィッシング攻撃によるクレデンシャルフィッシング、クレデンシャルスタッフィング、セッションハイジャックなどの攻撃ベクトルの成功率の低下に貢献しています。しかし、認証式の後はどうなるのでしょうか?
認証後、ブラウザーとアプリケーションクライアントには通常、他の資格情報が発行されます。エンタープライズアプリケーションは、一般に、Webブラウザベースで状態管理にセッションCookieを使用するアプリケーションと、OAuthアクセストークンを使用するシッククライアントアプリケーション(これには、一部のブラウザベースのシングルページアプリケーションとほとんどのネイティブモバイルアプリケーションが含まれます)の2つの主要なカテゴリに分類されます。どちらのタイプの資格情報 (セッション Cookie とアクセス トークン) も、基本的な使用法では “ベアラー” トークンと見なされます。トークン (セッション Cookie またはアクセス トークン) がある場合は、そのトークンを認証して所有したユーザーとして、そのトークンの有効期間中、トランザクションを継続できます。このホワイトペーパーでは、ベアラートークンの「リフトアンドシフト」攻撃ベクトルに対処する隣接するテクノロジーと、これらのテクノロジーがFIDOベースの認証メカニズムをどのように補完するかについて説明します。特に、このホワイトペーパーでは、ブラウザーセッションCookieを保護するために提案されているWeb標準 Device Bound Session Credentials(DBSC) に焦点を当て、 OAuth 2.0 OAuth 助成金を保護するための所有証明 (DPoP) の実証 。
2. 用語
セッションハイジャック: 通常、セッション Cookie に対して管理される Web セッション制御メカニズムの悪用。
クレデンシャルスタッフィング:盗んだユーザー名とパスワードのペア(認証情報)をWebサイトのログインフォームに自動挿入して、ユーザーアカウントに不正にアクセスします。
1. パスキー – https://fidoalliance.org/passkeys/
2. デバイスバインドセッションクレデンシャル – https://github.com/w3c/webappsec-dbsc
3. OAuth 2.0 所持証明 (DPoP) の実証 – RFC9449: https://datatracker.ietf.org/doc/html/rfc9449
4. セッションハイジャック攻撃 https://owasp.org/www-community/attacks/Session_hijacking_attack
5. クレデンシャルスタッフィング https://owasp.org/www-community/attacks/Credential_stuffing
アクセス・トークン: クライアント側アプリケーションがユーザーに代わってAPIコールを呼び出すために使用する資格情報。
セッション Cookie: ブラウザと Web サイト間のセッション状態を維持するためにブラウザによって管理される資格情報。
ベアラートークン: トークン (このホワイトペーパーのコンテキストでは、アクセストークンまたはセッション Cookie を指す場合があります) は、トークンを保持しているユーザーがトークンを使用してリソースにアクセスできるため、そう呼ばれています。ベアラートークンは、それ自体で別のコンピューティングデバイスで使用するために「リフトアンドシフト」できます。
送信者制約付きトークン: 認証プロセス中にトークンを確立したクライアント以外のユーザーが、サーバー側リソースに対する後続の要求でそのトークンを使用するリスクを最小限に抑えるように設計されたメカニズムによって保護されたトークン。
Device Bound Session Credential (DBSC): 送信者に制約のある Cookie を確立および維持するためのプロトコルとブラウザーの動作を定義する W3C Web 標準の提案。このメカニズムは、非対称暗号鍵の所有証明を使用して、セッション Cookie の乗っ取りを軽減します。OAuth 2.0 Proof of Procession (DPoP) のデモンストレーション: トークンを使用するときにクライアントが非対称暗号化キーの所有を証明する必要がある、送信者制約付きアクセス トークンを実装するためのメカニズム。
OAuth 2.0 Proof of Procession (DPoP) のデモンストレーション: トークンを使用するときにクライアントが非対称暗号化キーの所有を証明する必要がある、送信者制約付きアクセス トークンを実装するためのメカニズム。
3. 安全なエコシステムのための隣接/補完技術
FIDO認証技術は、ログインプロセス中に発生するフィッシング攻撃やクレデンシャルスタッフィング攻撃を効果的に排除することができますが、ベアラートークンの盗難に関連する脅威を軽減するためのソリューションを追加することも同様に重要です。ログインプロセス中に攻撃が阻止された悪意のある行為者は、チェーンの次に最も弱いリンクを狙い、認証後のベアラートークンを盗もうとします。このセクションでは、ベアラートークンを保護するための2つのテクノロジーについて説明します。デバイスバインドセッション資格情報(DBSC)はブラウザベースのセッションCookieを保護し、デモンストレーションプルーフオブオブジェーション(DPoP)はOAuth許可を保護します。ベアラートークンを保護するための代替アプローチについても説明します。
単一のテクノロジーですべての脅威から保護できるわけではないため、適切な保護には複数のテクノロジーの組み合わせが必要です。
表1:セキュリティを強化するためのテクノロジーの組み合わせ
| 技術 | 認証の脅威 | 認証後の脅威 | |
| リモートフィッシング | クレデンシャルスタッフィング | トークンの盗難 | |
| パスキー | ✅ | ✅ | ❌ |
| DBSC/DPoP | ❌ | ❌ | ✅ |
| パスキー + DBSC/DPoP | ✅ | ✅ | ✅ |
3.1 ブラウザセッションCookieのセキュリティ
Device Bound Session Credentials(DBSC)について説明する前に、ブラウザーセッションCookieに関して対処されている問題を理解する必要があります。Cookieの盗難によるセッションハイジャックにより、盗んだCookieを所有する攻撃者は、強力な認証や多要素認証(MFA)を含むエンドユーザー認証をバイパスできます。これは、ブラウザーが有効期間の長いセッション Cookie (ベアラー トークンの一種) を作成する場合に特に問題になりますが、これらの Cookie はユーザーのプライマリ認証資格情報の代替として取引され、攻撃者のマシンから使用される可能性があるためです。これにより、機密データへの不正アクセス、経済的損失、組織の評判の低下につながる可能性があります。
攻撃者は、ユーザーの既存のMFAログインプロセスの中間者フィッシング(FIDOなどのフィッシング耐性認証が使用されていない場合)、クライアント側のマルウェア、そして時にはサーバー側のインフラストラクチャやソフトウェアの脆弱性など、さまざまな方法でCookieの盗難を実行します。Cookieの盗難がどのように行われるかに関係なく、これらの攻撃が成功した場合、危険であるだけでなく、隔離して検出することも困難です。Device Bound Session Credentials(DBSC)などの補完的なテクノロジーは、認証中に発行されたマシン以外のマシンから盗まれたCookieを使用できなくなることで、ブラウザのCookieの盗難に関連するリスクを最小限に抑えます。
3.2 デバイスバインドされたセッション資格証明 – DBSC
DBSC は、W3C の Web アプリケーション セキュリティ ワーキング グループ内で現在開発中の提案された Web 標準を指します[2]。DBSC の目標は、盗まれた Web セッション Cookie 市場と闘い、混乱させることです。これは、HTTP メッセージングプロトコルを定義し、アプリケーションセッション Cookie の使用をユーザーのコンピューティングデバイスにバインドするために必要なブラウザーとサーバーの動作によって実現されます。DBSC は非対称キー ペアを使用し、ブラウザの実装では、秘密キーは攻撃者によって抽出できないようにする必要があります (たとえば、トラステッド プラットフォーム モジュール (TPM)、セキュア エレメント、または同様のハードウェア ベースの暗号化モジュール内に格納されます。
大まかに言うと、API はユーザーのブラウザーおよび安全なキー ストレージ機能と組み合わせて、次のことを可能にします。
- サーバーは、新しい DBSC セッションを確立するための要求をブラウザーに通信します。これには、サーバー提供のチャレンジが含まれます。
- ブラウザーは非対称キーペアを生成し、署名されたチャレンジとともに公開キーをサーバーに送信します。このプロセスは、DBSC 登録と呼ばれます。DBSC のブラウザー実装では、秘密キーの安全なハードウェア バインド ストレージと使用を容易にするオペレーティング システム API を使用する必要があります。
- サーバーは、有効期間の短い更新可能なauth_cookieを発行することで、公開鍵をブラウザーセッションにバインドし、その後のブラウザー要求で Web サーバーに送信する必要があります。
auth_cookieは定期的に期限切れになるため、ブラウザーがプライマリ アプリケーション Web トラフィックに対して非同期的にauth_cookieを更新するメカニズムが必要です。更新プロセスでは、DBSC 登録時に作成されたのと同じ秘密鍵を使用して、サーバーが発行した新しいチャレンジに署名する必要があり、それによってクライアント ブラウザがまだ同じ秘密鍵を所有していることを (定期的に) 再証明します。
auth_cookieの有効期間を短期間(数分など)に制限すると、有効期間の長いセッションCookieの取引市場が混乱します。攻撃者は、盗んだセッション Cookie (auth_cookieを含む) を短期間しか使用できず、更新操作を実行するために必要な秘密キーはクライアント マシンから抽出できないため、更新操作を実行できません。
DBSC は、アプリケーションへの最小限の変更で既存のデプロイに導入できます。DBSCは、既存のサーバー側テクノロジー(Apacheモジュール、サーブレットフィルター、リバースプロキシ機能など)にWebプラグインモジュールとして簡単に組み込むことができるため、これは重要です。これにより、企業は現在のすべてのインフラストラクチャを完全に見直すことなく、DBSCの展開を段階的に展開することができ、企業は特定の重要なエンドポイントやリソースに最初に優先順位を付けることができます。
DBSC サーバー側の実装は、セマンティクスを許可する方法で記述することもできます (たとえば、ブラウザーが DBSC をサポートしている場合は DBSC を使用し、それ以外の場合は通常のセッション特性にフォールバックします)。これにより、ユーザーは、すべてのユーザーが最初にブラウザをアップグレードする必要がなく、DBSC をサポートするブラウザを使用すると、DBSC のセキュリティ上の利点を得ることができます。
DBSC キーペアに構成証明を追加するエンタープライズ固有の拡張機能の提案など、DBSC プロトコルと標準の詳細については、 Device Bound Session Credentials の説明を参照してください 。
3.2.1 DBSCがFIDOを補完するテクノロジーである理由は何ですか?
DBSC ドラフト標準では、ログイン プロセスを DBSC API と密接に統合できます。FIDOは認証をより安全でフィッシングに強い仕組みですが、DBSCはベアラークレデンシャル(セッションCookie)を認証後の安全にする仕組みです。これらは、アカウントの乗っ取りや悪用のリスクを軽減することで相互に補完し合い、アプリケーションセッションのライフサイクル全体をより安全にします。
3.2.2 代替ソリューション
DBSC は、クライアント デバイスへのバインド セッション Cookie を提案する最初の標準ではありません。トークンバインディングは、 IETF RFC 8471、 8472、 および8473を組み合わせた代替手段です。HTTP 経由のトークン バインディングは、トランスポート層セキュリティ (TLS) 拡張機能を介して実装され、暗号化証明書を使用してトークンを TLS セッションにバインドします。トークンバインディングはブラウザの採用が限られており、アプリケーション層とTLSセキュリティスタックでの変更が必要なため、実装が複雑です。Token Binding over HTTP 標準は広く採用されておらず、現在サポートを提供している主要なブラウザは 1 つだけです。
3.2.3 助言
DBSC 標準は、ブラウザーのセッションにバインドされた秘密鍵の保存と使用のために、ローカル デバイス セキュリティとオペレーティング システム API に依存しています。これらの秘密キーを別のデバイスにエクスポートすることはできませんが、キーはローカル システムで利用でき、ユーザーのデバイスに存在するマルウェアによって実行される可能性があります。同様に、ブラウザ内マルウェアは、通常のセッション Cookie と短命なauth_cookiesの両方を完全に可視化します。DBSC はクライアント側のマルウェア保護に代わるものではなく、DBSC の脅威モデルは永続的なクライアント側マルウェアからの保護を提供しません。最終的に、ユーザーはブラウザを信頼する必要があります。
ブラウザが時間の経過とともに DBSC をサポートし始めると、サーバーがこのテクノロジのサポートを含むブラウザと含まれていないブラウザを組み合わせて動作できるようになることが重要になります。企業によっては、企業が発行したマシンにDBSCをサポートすることが知られているブラウザを含めるように指示する場合がありますが、多くの企業はサポートしていません。サーバー側の実装では、ブラウザが登録要求に応答するときに DBSC を使用し、ブラウザが応答しない場合はバインドされていないセッション Cookie を許容して、この点を考慮する必要があります。商用ソリューションを構築または選択するときは、このシナリオを考慮し、高度に制御または規制された環境、または特定のアプリケーションに対して DBSC を厳密に必要とするアクセス制御ポリシーを実装する機能を含めてください。
この記事の執筆時点では、DBSC は初期の進化段階にあります。ブラウザベンダーに広く採用されるかどうかはまだわかりません。W3C を通じてこの標準をインキュベートし、開発することで、WebAuthn API がすべての主要なブラウザ実装にパスキー認証をもたらすために採用されたのと同様に、以前の提案よりも広く採用されることが期待されています。
4. OAuth助成金
前のセクションでは、Web ブラウザーでのセッション Cookie の盗難から保護する手段として DBSC を紹介しました。モバイルアプリケーションやシングルページWebアプリケーションなどのシックアプリケーションクライアントは、通常、セッションCookieの代わりにOAuth付与を利用したステートレスAPI呼び出しを使用します。OAuth許可はいくつかの方法で確立できますが、 シッククライアントに推奨されるパターン は、最初にシステムブラウザを使用してユーザーを認証し、アプリケーションがユーザーに代わって動作するようにアクセスを許可することです。概念的には、これは、可能な場合はエンドユーザー認証にFIDO認証を使用する機能や推奨事項など、ブラウザベースのセッションと非常によく似ています。このフローのブラウザー・ベースの認証部分の終了時に、制御はシック・クライアント・アプリケーションまたはシングルページ Web アプリケーションに返され、そこでプログラムによる API 呼び出しで使用するためのトークンが確立されます。
この時点から発生するチャレンジは、ブラウザーで説明されているものとほぼ同じです – OAuth トークンは、悪意のあるアクターに公開された場合、正当なアプリケーションからではなくリモート マシンからアプリケーション API を呼び出すために使用できるベアラー トークンです。
このセクションでは、DBSC と同様に、非対称キー ペアと秘密キーの継続的な所有証明を利用する、OAuth で保護された API 呼び出しで使用される資格情報の「リフト アンド シフト」を保護するテクノロジーである DPoP の使用について説明します。
4.1 所持証明 (DPoP) の証明
OAuth 2.0 Demonstrating Proof of Possession (DPoP) は、デバイス バウンド (または送信者制約) の OAuth アクセスおよび更新トークンを実装するための既存の OAuth 2.0 標準の拡張です。これは、OAuth許可に関連付けられたトークン(つまり、更新トークンとアクセストークン)が、公開キーと秘密キーのペアを使用して要求されたクライアントにバインドできるようにするアプリケーションレベルのメカニズムです。そのため、クライアントは、アクセストークンの更新操作を実行するときに承認サーバーに対して、アクセストークンを使用してAPIを呼び出すときにリソースサーバーに対して、秘密キーの所有権を証明する必要があります。
6. ネイティブアプリ用のOAuth 2.0 https://datatracker.ietf.org/doc/html/rfc8252
金融グレード API (FAPI 2.0) などの高保証 OpenID 仕様では、送信者制約付きトークンの使用が義務付けられており、相互 TLS (mTLS) が利用できない場合にこの要件を実装するには DPoP が推奨されます。
大まかに言うと、DPoP では次のことが必要です。
- クライアントは、DPoP 証明の構築に使用する付与ごとの公開鍵と秘密鍵のペアを生成します。ベスト プラクティスの実装では、オペレーティング システム API を使用して、秘密キーが抽出不可能であることを確認する必要があります。
- 最初の許可の確立時 (たとえば、OAuth 承認コードを許可の最初のアクセス トークンと更新トークンと交換するなど)、DPoP 証明 (特に公開鍵のコピーを含むクライアントの秘密鍵によって署名された JWT) を使用して、公開鍵を許可にバインドします。
- この方法で取得したアクセストークンを使用してリソースサーバーへの要求には、付与の確立中に使用される秘密鍵の所有を継続的に証明するDPoP証明ヘッダーも含まれている必要があります。これは、すべての API リクエストに対して行われます。リソース・サーバーは、アクセス・トークンが送信者に制約されているかどうかを確認し、公開鍵を確認し、各API呼び出しでDPoP証明ヘッダーを検証する必要があります。
- パブリッククライアントの場合、認可サーバーのトークンエンドポイントへの後続のrefresh_tokenフローには、最初の許可確立時に使用したのと同じキーで署名されたDPoP証明も含まれている必要があります。更新トークンは有効期間が長いことが多く、ベアラートークンの一種でもあるため、これは特に重要です(つまり、持っている場合は使用できます)。認可サーバーは、これらの更新トークン・フローにDPoP証明の使用を強制し、初期付与の確立時に登録されたのと同じ公開鍵を介して署名の検証が行われるようにする必要があります。
すべての所有者が使用できるプレーンベアラーアクセストークンとは異なり、DPoPベースのアクセストークンは、そのクライアントのみが秘密鍵を使用してDPoP証明に署名できるため、最初にOAuth許可を確立したクライアントにバインドされます。このアプローチにより、悪意のある攻撃者が漏洩したアクセス トークンを取引することに関連するリスクが最小限に抑えられます。
詳細については、 DPoP RFC 9449 – OAuth 2.0 Demonstrating Proof of Posion (DPoP) を参照してください。
4.2 DPoPがFIDOを補完するテクノロジーである理由は何ですか?
FIDOは、OAuth付与の確立時に、フィッシングに強いエンドユーザー認証に活用できます。この認証後にクライアントによって取得された更新トークンとアクセストークンは、ブラウザベースのアプリのセッションCookieと同様に、「リフトアンドシフト」攻撃から保護する必要があります。DPoPは、これらのOAuthトークンを認証後の不正使用から保護するために推奨されるソリューションです。エンドユーザー認証用の FIDO と OAuth トークンをクライアントデバイスにバインドするための DPoP は、相互に補完し合い、シッククライアントアプリケーションで使用される ID の全体的なセキュリティ体制を改善します。
4.2.1 DPoPの代替ソリューションは?
RFC8705 – OAuth 2.0 相互 TLS クライアント認証と証明書バインド アクセス トークン では、アクセス トークンをクライアント証明書にバインドするためのトランスポーター層ソリューションを提供するメカニズムについて説明します。オープンバンキングソリューションの FAPI 2.0 での使用は承認されていますが、ネイティブモバイルアプリケーションなどのパブリッククライアントには特に適していません。
RFC9421 – HTTP メッセージ署名は、HTTP メッセージの一部に署名するためのアプリケーション レベルのメカニズムを定義します。クライアントと検証者間のキーの確立と共有は、この仕様では定義されていませんが、これは、DPoP と同様の方法で、最初の許可の確立時に 最初のユーザーの信頼 方式で実行できます。HTTP メッセージ署名の使用を OAuth クライアントアプリケーションでの送信者制約付きベアラートークンのユースケースにマッピングする既知の公開仕様はありません。このような公開仕様がない場合、このユースケースが広く採用される可能性は低いです。
4.2.2 アドバイス
送信者に制約のあるトークンは良いアイデアであり、一部のデプロイでは、規制要件です。たとえば、OAuth の FAPI プロファイルの使用は、現在、多くのソブリン オープン バンキング イニシアチブによって義務付けられています。DPoP は、この要件を達成するための比較的簡単な方法であり、幅広いアプリケーション クライアント タイプをカバーするのに十分な柔軟性を備えています。とはいえ、DPoP のセキュリティ上の考慮事項を遵守するように注意する必要があります。 RFC9449のセクション 11 に細心の注意を払い、シナリオに応じてネイティブまたはブラウザーベースのシングルページアプリケーションに他のアプリケーションセキュリティ戦略を適用してください。DPoP は、取引や悪意のある攻撃者による使用など、トークン流出に関連する脅威に対処することのみに焦点を当てていることに注意してください。これは、OAuth アプリケーションの多層防御戦略の一部と見なす必要があります。
5. まとめ
このホワイトペーパーの目的は、さまざまなWebセキュリティ標準がどのように組み合わさっているか、そしてそれらの標準がユーザーに対するFIDO認証の使用にどのように関連しているかについての考えを促すことです。非常に多くの標準と標準化団体が存在するため、どれが同じ分野で競合し、どれが相互に補強して、オンラインアプリケーションにおけるID詐欺保護のための包括的な多層防御戦略の一部を形成するかを理解するのが難しいことがよくあります。
このホワイトペーパーでは、特定の一般的なアプリケーションセキュリティ問題、つまり盗まれたCookieとアクセストークンの悪意のある取引と使用に取り組みました。また、DBSCやDPoPなどのテクノロジーがトークンの盗難に関連する脅威をどのように軽減するか、また、これらのテクノロジーがFIDO認証をどのように補完するかも示しました。FIDO、DBSC、DPoPと組み合わせることで、アプリケーション全体のID詐欺保護が強化されます。
