5. セキュリティに関する考慮事項 (Security Considerations)
本セクションでは、ベアラートークンを使用する際のトークン処理に関する関連するセキュリティ脅威について説明し、これらの脅威を軽減する方法を説明します。
5.1. セキュリティ脅威 (Security Threats)
以下のリストは、何らかの形式のトークンを利用するプロトコルに対するいくつかの一般的な脅威を示しています。この脅威のリストは、NIST Special Publication 800-63 [NIST800-63]に基づいています。本文書はOAuth 2.0認可仕様 [RFC6749]に基づいて構築されているため、そこまたは関連文書で説明されている脅威の議論は除外します。
トークンの製造/変更 (Token manufacture/modification) : 攻撃者は、偽造トークンを生成するか、既存のトークンのトークン内容(認証またはAttribute文など)を変更し、リソースサーバーにクライアントへの不適切なアクセスを許可させる可能性があります。例えば、攻撃者は有効期間を延長するためにトークンを変更する可能性があります。悪意のあるクライアントは、表示すべきでない情報へのアクセスを取得するためにアサーションを変更する可能性があります。
トークンの開示 (Token disclosure) : トークンには、機密情報を含む認証およびAttribute文が含まれている可能性があります。
トークンのリダイレクト (Token redirect) : 攻撃者は、1つのリソースサーバーによる消費のために生成されたトークンを使用して、トークンが自分のものであると誤って信じている別のリソースサーバーへのアクセスを取得します。
トークンのリプレイ (Token replay) : 攻撃者は、過去にそのリソースサーバーで既に使用されたトークンを使用しようとします。
5.2. 脅威の軽減 (Threat Mitigation)
デジタル署名またはメッセージ認証コード (Message Authentication Code, MAC) を使用してトークンの内容を保護することにより、幅広い脅威を軽減できます。あるいは、ベアラートークンには、情報を直接エンコードするのではなく、認可情報への参照を含めることができます。このような参照は、攻撃者が推測することが不可能でなければなりません (しなければならない)。参照を使用すると、参照を認可情報に解決するためにサーバーとトークン発行者との間に追加の相互作用が必要になる場合があります。このような相互作用のメカニズムは、本仕様では定義されていません。
本文書では、トークンのエンコーディングまたは内容を指定していません。したがって、トークンの整合性保護を保証する手段に関する詳細な推奨事項は、本文書の範囲外です。トークンの整合性保護は、トークンが変更されるのを防ぐのに十分でなければなりません (しなければならない)。
トークンのリダイレクトに対処するには、認可サーバーが、意図された受信者(オーディエンス)、通常は単一のリソースサーバー(またはリソースサーバーのリスト)のIDをトークンに含めることが重要です。また、トークンの使用を特定のスコープに制限することも推奨されます (推奨される)。
認可サーバーは、TLSを実装しなければなりません (しなければならない)。実装すべきバージョンは、時間の経過とともに変化し、実装時の広範な展開と既知のセキュリティ脆弱性に依存します。本文書の執筆時点では、TLSバージョン1.2 [RFC5246]が最新バージョンですが、実際の展開は非常に限られており、実装ツールキットですぐに利用できない可能性があります。TLSバージョン1.0 [RFC2246]が最も広く展開されているバージョンであり、最も広範な相互運用性を提供します。
トークンの開示から保護するために、機密性と整合性保護を提供する暗号スイートを使用したTLS [RFC5246]を使用して、機密性保護を適用しなければなりません (しなければならない)。これには、クライアントと認可サーバー間の通信相互作用、およびクライアントとリソースサーバー間の相互作用が、機密性と整合性保護を利用する必要があります。TLSは本仕様で実装および使用することが必須であるため、通信チャネルを介したトークン開示を防ぐための推奨アプローチです。クライアントがトークンの内容を観察することが妨げられている場合、TLS保護の使用に加えて、トークン暗号化を適用しなければなりません (しなければならない)。トークン開示に対するさらなる防御として、クライアントは、証明書失効リスト (Certificate Revocation List, CRL) [RFC5280]のチェックを含め、保護されたリソースへのリクエストを行うときにTLS証明書チェーンを検証しなければなりません (しなければならない)。
Cookieは通常、平文で送信されます。したがって、それらに含まれる情報は開示のリスクがあります。したがって、ベアラートークンは、平文で送信できるCookieに保存してはなりません (してはならない)。Cookieに関するセキュリティ考慮事項については、「HTTP State Management Mechanism」[RFC6265]を参照してください。
ロードバランサーを利用するデプロイメントを含む一部のデプロイメントでは、リソースサーバーへのTLS接続は、リソースを提供する実際のサーバーの前に終了します。これにより、TLS接続が終了するフロントエンドサーバーとリソースを提供するバックエンドサーバーの間でトークンが保護されないままになる可能性があります。このようなデプロイメントでは、フロントエンドサーバーとバックエンドサーバーの間のトークンの機密性を確保するために十分な措置を講じなければなりません (しなければならない)。トークンの暗号化は、そのような可能な措置の1つです。
トークンのキャプチャとリプレイに対処するために、以下の推奨事項が行われます: 第一に、トークンの有効期間は制限されなければなりません (しなければならない)。これを実現する1つの手段は、トークンの保護された部分内に有効時間フィールドを配置することです。短期間(1時間以下)のトークンを使用すると、漏洩した場合の影響を軽減できることに注意してください。第二に、クライアントと認可サーバー間、およびクライアントとリソースサーバー間の交換の機密性保護を適用しなければなりません (しなければならない)。結果として、通信パス上の盗聴者はトークン交換を観察できません。その結果、このような経路上の攻撃者はトークンをリプレイできません。さらに、リソースサーバーにトークンを提示する場合、クライアントは、「HTTP Over TLS」[RFC2818]のセクション3.1に従って、そのリソースサーバーのIDを検証しなければなりません (しなければならない)。保護されたリソースへのこれらのリクエストを行う場合、クライアントはTLS証明書チェーンを検証しなければならない (しなければならない)ことに注意してください。認証されていない無許可のリソースサーバーにトークンを提示したり、証明書チェーンの検証に失敗したりすると、攻撃者がトークンを盗み、保護されたリソースへの不正アクセスを取得することができます。
5.3. 推奨事項のまとめ (Summary of Recommendations)
ベアラートークンを保護する (Safeguard bearer tokens) : クライアント実装は、ベアラートークンが意図しない当事者に漏洩しないことを保証しなければなりません (しなければならない)。漏洩した場合、それらを使用して保護されたリソースへのアクセスを取得できるためです。これは、ベアラートークンを使用する際の主要なセキュリティ考慮事項であり、以下のより具体的な推奨事項の基礎となります。
TLS証明書チェーンを検証する (Validate TLS certificate chains) : クライアントは、保護されたリソースへのリクエストを行うときにTLS証明書チェーンを検証しなければなりません (しなければならない)。これを行わないと、DNSハイジャック攻撃によってトークンを盗み、意図しないアクセスを取得される可能性があります。
常にTLS (https)を使用する (Always use TLS (https)) : クライアントは、ベアラートークンを使用してリクエストを行う場合、常にTLS [RFC5246] (https)または同等のトランスポートセキュリティを使用しなければなりません (しなければならない)。これを行わないと、トークンが多数の攻撃にさらされ、攻撃者に意図しないアクセスを与える可能性があります。
ベアラートークンをCookieに保存しない (Don't store bearer tokens in cookies) : 実装は、平文で送信できるCookie(これはCookieのデフォルトの送信モードです)内にベアラートークンを保存してはなりません (してはならない)。Cookieにベアラートークンを保存する実装は、クロスサイトリクエストフォージェリに対する予防措置を講じなければなりません (しなければならない)。
短期間のベアラートークンを発行する (Issue short-lived bearer tokens) : トークンサーバーは、特にWebブラウザ内で実行されるクライアントまたは情報漏洩が発生する可能性のある他の環境にトークンを発行する場合、短期間(1時間以下)のベアラートークンを発行すべきです (すべきである)。短期間のベアラートークンを使用すると、漏洩した場合の影響を軽減できます。
スコープ付きベアラートークンを発行する (Issue scoped bearer tokens) : トークンサーバーは、意図された依拠当事者または依拠当事者のセットへの使用をスコープ化する、オーディエンス制限を含むベアラートークンを発行すべきです (すべきである)。
ページURLでベアラートークンを渡さない (Don't pass bearer tokens in page URLs) : ベアラートークンは、ページURL(例えば、クエリ文字列パラメータとして)で渡すべきではありません (すべきでない)。代わりに、ベアラートークンは、機密性対策が講じられているHTTPメッセージヘッダーまたはメッセージボディで渡すべきです (すべきである)。ブラウザ、Webサーバー、およびその他のソフトウェアは、ブラウザ履歴、Webサーバーログ、およびその他のデータ構造でURLを適切に保護しない可能性があります。ベアラートークンがページURLで渡された場合、攻撃者は履歴データ、ログ、またはその他の保護されていない場所からそれらを盗むことができる可能性があります。