メインコンテンツまでスキップ

17. Security Considerations (セキュリティに関する考慮事項)

このセクションは, HTTPセマンティクスおよびインターネット上での情報転送に使用される際の既知のセキュリティ問題について, 開発者, 情報提供者, ユーザーに通知することを目的としています. キャッシュに関する考慮事項は[CACHING]の第7節で議論されており, HTTP/1.1メッセージ構文と解析に関する考慮事項は[HTTP/1.1]の第11節で議論されています.

以下の考慮事項のリストは網羅的ではありません. HTTPセマンティクスに関連するセキュリティ問題の大部分は, サーバー側アプリケーション(HTTPインターフェイスの背後にあるコード)の保護, HTTP経由で受信したコンテンツのユーザーエージェント処理の保護, または一般的なインターネットの安全な使用に関するものであり, プロトコル自体のセキュリティに関するものではありません. HTTP操作の基礎となるURIのセキュリティ考慮事項は, [URI]の第7節で議論されています. さまざまな組織がWebアプリケーションセキュリティに関する現在の研究へのトピック情報とリンクを維持しています(例えば, [OWASP]).

17.1. Establishing Authority (権威の確立)​

HTTPは「権威ある応答」の概念に依存しています: ターゲットURI内で識別される オリジンサーバーによって(またはその指示のもとで)決定された応答であり, 応答メッセージ生成時のターゲットリソースの状態を考慮して, そのリクエストに対する最も適切な応答です.

権威コンポーネントで登録名が使用される場合, "http" URIスキーム(セクション4.2.1)は, ユーザーのローカル名前解決サービスに依存して, 権威ある応答をどこで見つけることができるかを決定します. これは, ユーザーのネットワークホストテーブル, キャッシュされた名前, または名前解決ライブラリへの攻撃が, "http" URIの権威確立への攻撃の手段となることを意味します. 同様に, ドメインネームサービス(DNS)のためのサーバーのユーザーの選択, およびそこから解決結果を取得するサーバーの階層は, アドレスマッピングの真正性に影響を与える可能性があります; DNSセキュリティ拡張(DNSSEC, [RFC4033])は真正性を向上させる1つの方法であり, より安全な転送プロトコルを介してDNSリクエストを行うさまざまなメカニズムも同様です.

さらに, IPアドレスが取得された後, "http" URIの権威確立は インターネットプロトコルルーティングへの攻撃に対して脆弱です.

"https"スキーム(セクション4.2.2)は, ネゴシエートされた接続が保護されており, クライアントが通信サーバーのIDがターゲットURIの権威コンポーネントと一致することを適切に検証する限り(セクション4.3.4), これらの権威確立に対する潜在的な攻撃の多くを防ぐ(または少なくとも明らかにする)ことを目的としています. このような検証を正しく実装することは困難な場合があります([Georgiev]を参照).

特定のオリジンサーバーの権威は, プロトコル拡張を通じて委任できます; たとえば, [ALTSVC]. 同様に, 接続が権威あるとみなされるサーバーのセットは, [RFC8336]のようなプロトコル拡張を使用して変更できます.

共有プロキシキャッシュなどの非権威ソースから応答を提供することは, パフォーマンスと可用性を向上させるために有用であることが多いですが, そのソースが信頼できる場合, または信頼できない応答が安全に使用できる場合にのみ有用です.

残念ながら, ユーザーに権威を伝えることは困難な場合があります. たとえば, 「フィッシング」は, ユーザーの権威の認識に対する攻撃であり, ハイパーテキストで類似のブランディングを提示することによってその認識が誤解される可能性があり, userinfoが権威コンポーネントを難読化することによって支援される可能性があります(セクション4.2.1を参照). ユーザーエージェントは, ユーザーがアクションを実行する前にターゲットURIを簡単に検査できるようにし, userinfoが存在する場合に目立つように区別(または拒否)し, 参照ドキュメントが未知または信頼できないソースからのものである場合に保存された認証情報とCookieを送信しないことによって, フィッシング攻撃の影響を軽減できます.

17.2. Risks of Intermediaries (仲介者のリスク)​

HTTP仲介者は本質的にパス攻撃の位置に置かれています. 仲介者が実行されているシステムの侵害は, 深刻なセキュリティとプライバシーの問題を引き起こす可能性があります. 仲介者は, セキュリティ関連情報, 個々のユーザーと組織に関する個人情報, およびユーザーとコンテンツプロバイダーに属する独自情報にアクセスできる可能性があります. 侵害された仲介者, またはセキュリティとプライバシーの考慮事項を考慮せずに実装または構成された仲介者は, 広範囲の潜在的な攻撃の実行に使用される可能性があります.

共有キャッシュを含む仲介者は, [CACHING]の第7節で説明されているように, キャッシュポイズニング攻撃に対して特に脆弱です.

実装者は, その設計とコーディングの決定, およびオペレーターに提供する構成オプション(特にデフォルト構成)のプライバシーとセキュリティへの影響を考慮する必要があります.

仲介者は, それらを運用する人々とポリシーよりも信頼できません; HTTPはこの問題を解決できません.

17.3. Attacks Based on File and Path Names (ファイル名とパス名に基づく攻撃)​

オリジンサーバーは, ターゲットURIからリソース表現へのマッピングを管理するために, ローカルファイルシステムを頻繁に使用します. ほとんどのファイルシステムは, 悪意のあるファイル名またはパス名から保護するように設計されていません. したがって, オリジンサーバーは, ターゲットリソースをファイル, フォルダ, またはディレクトリにマッピングする際に, システムにとって特別な意味を持つ名前へのアクセスを避ける必要があります.

たとえば, UNIX, Microsoft Windows, およびその他のオペレーティングシステムは, 現在のディレクトリの上のディレクトリレベルを示すパスコンポーネントとして".."を使用し, システムデバイスにデータを送信するために特別に名前が付けられたパスまたはファイル名を使用します. 他のタイプのストレージシステム内にも同様の命名規則が存在する可能性があります. 同様に, ローカルストレージシステムは, 無効または予期しない文字, 分解された文字の再構成, および大文字小文字を区別しない名前の大文字小文字の正規化を処理する際に, セキュリティよりもユーザーフレンドリーさを優先する傾向があります.

このような特別な名前に基づく攻撃は, サービス拒否(たとえば, COMポートから読み取るようにサーバーに指示する)または提供されることを意図していない構成ファイルとソースファイルの開示に焦点を当てる傾向があります.

17.4. Attacks Based on Command, Code, or Query Injection (コマンド, コード, またはクエリインジェクションに基づく攻撃)​

オリジンサーバーは, システムサービスを識別したり, データベースエントリを選択したり, データソースを選択したりする手段として, URI内のパラメータを頻繁に使用します. ただし, リクエストで受信したデータは信頼できません. 攻撃者は, コマンド呼び出し, 言語インタープリタ, またはデータベースインターフェイスを通じて渡されたときにコマンド, コード, またはクエリとして誤解される可能性があるデータを含むように, リクエストデータ要素(メソッド, ターゲットURI, ヘッダーフィールド, またはコンテンツ)のいずれかを構築できます.

たとえば, SQLインジェクションは一般的な攻撃であり, ターゲットURIまたはヘッダーフィールド(たとえば, Host, Refererなど)の一部に追加のクエリ言語が挿入されます. 受信したデータがSELECTステートメント内で直接使用される場合, クエリ言語は単純な文字列値ではなくデータベースコマンドとして解釈される可能性があります. この種の実装の脆弱性は, 防止が容易であるにもかかわらず, 非常に一般的です.

一般的に, リソース実装は, 命令として処理または解釈されるコンテキストでリクエストデータを使用することを避けるべきです. パラメータは固定文字列と比較し, その比較の結果として行動すべきであり, 信頼できないデータに対して準備されていないインターフェイスを通じて渡すべきではありません. 固定パラメータに基づいていない受信データは, 誤解を避けるために慎重にフィルタリングまたはエンコードする必要があります.

リクエストデータが保存され, 後で処理される場合, たとえばログファイル, 監視ツール内, または埋め込みスクリプトを許可するデータ形式に含まれる場合にも, 同様の考慮事項が適用されます.

17.5. Attacks via Protocol Element Length (プロトコル要素長による攻撃)​

HTTPは主にテキストの, 文字区切りのフィールドを使用するため, パーサーは非常に長い(または非常に遅い)データストリームの送信に基づく攻撃に対して脆弱であることが多く, 特に実装が事前定義された長さのないプロトコル要素を期待している場合です(セクション2.3).

相互運用性を促進するために, フィールドの最小サイズ制限について具体的な推奨事項が行われています(セクション5.4). これらは最小限の推奨事項であり, リソースが限られた実装でもサポート可能なように選択されています; ほとんどの実装は大幅に高い制限を選択することが期待されています.

サーバーは, 長すぎるターゲットURI(セクション15.5.15)または大きすぎるリクエストコンテンツ(セクション15.5.14)を持つメッセージを拒否できます. HTTPの拡張[RFC6585]によって容量制限に関連する追加のステータスコードが定義されています.

受信者は, リクエストメソッド, レスポンスステータスフレーズ, フィールド名, 数値, チャンク長を含む(ただしこれらに限定されない)他のプロトコル要素を処理する程度を慎重に制限すべきです. そのような処理を制限しないと, バッファまたは算術オーバーフローによる任意のコード実行が発生し, サービス拒否攻撃に対する脆弱性が増加する可能性があります.

17.6. Attacks Using Shared-Dictionary Compression (共有辞書圧縮を使用した攻撃)​

暗号化されたプロトコルに対する一部の攻撃は, 動的圧縮によって作成されるサイズの違いを使用して機密情報を明らかにします; たとえば, [BREACH]. これらの攻撃は, 攻撃者が制御するコンテンツと機密情報の間に冗長性を作成することに依存しており, 両方のコンテンツに同じ辞書を使用する動的圧縮アルゴリズムは, 攻撃者が制御するコンテンツが機密コンテンツの一部と一致する場合により効率的に圧縮します.

HTTPメッセージは, TLS圧縮, コンテンツコーディング, 転送コーディング, およびその他の拡張またはバージョン固有のメカニズムを使用するなど, 多くの方法で圧縮できます.

このリスクに対する最も効果的な緩和策は, 機密データの圧縮を無効にするか, 機密データと攻撃者が制御するデータを厳密に分離して, 同じ圧縮辞書を共有できないようにすることです. 慎重な設計により, HPACK([HPACK])のように, 限られたユースケースで悪用可能とはみなされない方法で圧縮スキームを設計できます.

17.7. Disclosure of Personal Information (個人情報の開示)​

クライアントは, リソースとの対話のためにユーザーが提供した情報(たとえば, ユーザーの名前, 場所, メールアドレス, パスワード, 暗号化キーなど)や, 時間の経過に伴うユーザーのブラウジング活動に関する情報(たとえば, 履歴, ブックマークなど)を含む大量の個人情報を持っていることがよくあります. 実装は, 個人情報の意図しない漏洩を防ぐ必要があります.

17.8. Privacy of Server Log Information (サーバーログ情報のプライバシー)​

サーバーは, 時間の経過に伴うユーザーのリクエストに関する個人データを保存できる位置にあり, それらの読書パターンまたは興味のあるトピックを識別できる可能性があります. 特に, 仲介者によって収集されたログ情報には, 多数のサイトにわたるユーザーエージェントの対話の履歴が含まれていることが多く, 個々のユーザーまでさかのぼることができます.

HTTPログ情報は本質的に機密です; その取り扱いは多くの場合, 法律と規制によって制約されています. ログ情報は安全に保存される必要があり, その分析には適切なガイドラインに従う必要があります. 個々のエントリ内の個人情報の匿名化は役立ちますが, 通常は他のアクセス特性との相関に基づいて実際のログトレースが再識別されるのを防ぐには不十分です. したがって, キーが仮名であっても, 特定のクライアントに関連付けられたアクセストレースを公開することは安全ではありません.

盗難または偶発的な公開のリスクを最小限に抑えるために, セキュリティ, 監査可能性, または詐欺制御の運用上のニーズをサポートするためにもはや必要でなくなったら, ログ情報はユーザー識別子, IPアドレス, およびユーザー提供のクエリパラメータを含む個人を識別できる情報をできるだけ早く削除すべきです.

17.9. Disclosure of Sensitive Information in URIs (URI内の機密情報の開示)​

URIは保護されるのではなく, 共有されることを意図しています, それらが安全なリソースを識別する場合でも. URIは多くの場合ディスプレイに表示され, ページが印刷されるときにテンプレートに追加され, さまざまな保護されていないブックマークリストに保存されます. 多くのサーバー, プロキシ, およびユーザーエージェントは, 第三者に見える可能性がある場所でターゲットURIをログまたは表示します. したがって, URIに機密の, 個人を識別できる, またはリスクのある情報を含めることは賢明ではありません.

アプリケーションがクライアント側のメカニズムを使用してユーザー提供の情報からターゲットURIを構築する場合, たとえばGETを使用するフォームのクエリフィールドなど, URIに開示するのに適さない潜在的に機密のデータが提供される可能性があります. これらの場合, POSTがしばしば好まれます, なぜならそれは通常URIを構築しないからです; 代わりに, フォームのPOSTはリクエストコンテンツ内で潜在的に機密のデータを送信します. ただし, これはキャッシングを妨げ, 本来は安全なリクエストに対して安全でないメソッドを使用します. 代替の回避策には, URIを構築する前にユーザー提供のデータを変換すること, または機密ではない一般的な値のみを含めるようにデータをフィルタリングすることが含まれます. 同様に, クエリの結果を異なる(サーバー生成の)URIにリダイレクトすることで, 後のリンクから潜在的に機密のデータを削除し, 後で再利用するためのキャッシュ可能な応答を提供できます.

Refererヘッダーフィールドはターゲットサイトにリクエストをもたらしたコンテキストを伝えるため, ユーザーの即座のブラウジング履歴および参照リソースのURIで見つかる可能性のある個人情報に関する情報を明らかにする可能性があります. Refererヘッダーフィールドの制限は, そのセキュリティ考慮事項の一部に対処するためにセクション10.1.3で説明されています.

17.10. Application Handling of Field Names (フィールド名のアプリケーション処理)​

サーバーは, 受信したリクエストを処理し, 応答のコンテンツを生成するために, 非HTTPゲートウェイインターフェイスとフレームワークを頻繁に使用します. 歴史的な理由により, このようなインターフェイスは多くの場合, 環境変数に適した名前マッピングを使用して, 受信したフィールド名を外部変数名として渡します.

たとえば, [RFC3875]のセクション4.1.18で定義されたコモンゲートウェイインターフェイス(CGI)のプロトコル固有のメタ変数マッピングは, CGIの標準変数の1つに対応しない受信ヘッダーフィールドに適用されます; そのマッピングには, 各名前の前に"HTTP_"を追加し, ハイフン("-")のすべてのインスタンスをアンダースコア("_")に変更することが含まれます. 他の多くのアプリケーションフレームワークは, アプリケーションをあるプラットフォームから別のプラットフォームへ移動するのを簡素化するために, この同じマッピングを継承しています.

CGIでは, 受信したContent-Lengthフィールドは, 受信したフィールド値と一致する文字列値を持つメタ変数"CONTENT_LENGTH"として渡されます. 対照的に, 受信した"Content_Length"ヘッダーフィールドは, プロトコル固有のメタ変数"HTTP_CONTENT_LENGTH"として渡され, アプリケーションがデフォルトのメタ変数の代わりにプロトコル固有のメタ変数を誤って読み取る場合, これはいくつかの混乱を招く可能性があります. (この歴史的な慣行が, セクション16.3.2.1がアンダースコアを含む新しいフィールド名の作成を推奨しない理由です.)

残念ながら, フィールド名を異なるインターフェイス名にマッピングすると, マッピングが不完全または曖昧な場合, セキュリティ脆弱性につながる可能性があります. たとえば, 攻撃者が"Transfer_Encoding"という名前のフィールドを送信した場合, 単純なインターフェイスは, "Transfer-Encoding"フィールドと同じ変数名にマッピングする可能性があり, 潜在的なリクエストスマグリング脆弱性([HTTP/1.1]のセクション11.2)をもたらします.

関連するリスクを軽減するために, このようなマッピングを実行する実装は, 名前として受信される可能性のあるオクテットの完全な範囲に対してマッピングを明確かつ完全にすることをお勧めします(HTTP構文によって推奨されないまたは禁止されているものを含む). たとえば, 異常な名前文字を持つフィールドは, リクエストがブロックされるか, 特定のフィールドが削除されるか, または他のフィールドと区別するために異なるプレフィックスで名前が渡されることになる可能性があります.

17.11. Disclosure of Fragment after Redirects (リダイレクト後のフラグメントの開示)​

URI参照で使用されるフラグメント識別子はリクエストで送信されませんが, 実装者はそれらがユーザーエージェントおよび応答の結果として実行される拡張またはスクリプトに表示されることに注意する必要があります. 特に, リダイレクトが発生し, 元のリクエストのフラグメント識別子がLocation(セクション10.2.2)の新しい参照に継承される場合, これはあるサイトのフラグメントを別のサイトに開示する効果を持つ可能性があります. 最初のサイトがフラグメント内で個人情報を使用する場合, 他のサイトへのリダイレクトに(おそらく空の)フラグメントコンポーネントを含めて, その継承をブロックすることを確認する必要があります.

17.12. Disclosure of Product Information (製品情報の開示)​

User-Agent(セクション10.1.5), Via(セクション7.6.3), およびServer(セクション10.2.4)ヘッダーフィールドは, それぞれの送信者のソフトウェアシステムに関する情報を明らかにすることがよくあります. 理論的には, これは攻撃者が既知のセキュリティホールを悪用しやすくなります; 実際には, 攻撃者は使用されている明らかなソフトウェアバージョンに関係なく, すべての潜在的なホールを試す傾向があります.

ネットワークファイアウォールへのゲートウェイとして機能するプロキシは, ファイアウォールの背後にあるホストを識別できるヘッダー情報の転送について特別な予防措置を講じるべきです. Viaヘッダーフィールドは, 仲介者が機密のマシン名を仮名で置き換えることを許可します.

17.13. Browser Fingerprinting (ブラウザフィンガープリンティング)​

ブラウザフィンガープリンティングは, その独自の特性セットを通じて時間の経過とともに特定のユーザーエージェントを識別するための一連の技術です. これらの特性には, 基礎となるトランスポートプロトコルの使用方法, 機能能力, およびスクリプト環境に関連する情報が含まれる場合がありますが, ここで特に興味深いのは, HTTP経由で伝達される可能性のある独自の特性のセットです. フィンガープリンティングは, ユーザーが他の形式のデータ収集(たとえば, Cookie)に対して持つ可能性のある対応する制御なしに, ユーザーエージェントの動作を時間の経過とともに追跡できるため([Bujlow]), プライバシーの懸念と見なされています. 多くの汎用ユーザーエージェント(すなわち, Webブラウザ)は, そのフィンガープリントを減らすための手順を実行しています.

フィンガープリンティングを有効にするのに十分にユニークな情報をサーバーに明らかにする可能性のあるリクエストヘッダーフィールドが多数あります. Fromヘッダーフィールドは最も明白ですが, Fromはユーザーが自己識別を望む場合にのみ送信されることが期待されています. 同様に, Cookieヘッダーフィールドは意図的に再識別を可能にするように設計されているため, フィンガープリンティングの問題は, Cookieが無効化されているか構成によって制限されている状況にのみ適用されます.

User-Agentヘッダーフィールドには, 特に他の特性と組み合わせた場合, 特定のデバイスを一意に識別するのに十分な情報が含まれる場合があり, 特にユーザーエージェントがユーザーのシステムまたは拡張機能について過度な詳細を送信する場合です. ただし, ユーザーが最も期待しない独自の情報のソースは, Accept, Accept-Charset, Accept-Encoding, およびAccept-Languageヘッダーフィールドを含むプロアクティブネゴシエーション(セクション12.1)です.

フィンガープリンティングの問題に加えて, Accept-Languageヘッダーフィールドの詳細な使用は, ユーザーが私的な性質であると考える可能性のある情報を明らかにする可能性があります. たとえば, 特定の言語セットを理解することは, 特定の民族グループのメンバーシップと強く相関する可能性があります. このようなプライバシー損失を制限するアプローチは, 明示的に許可されたサイトを除いてAccept-Languageの送信を省略することであり, おそらく言語ネゴシエーションが有用である可能性があることを示すVaryヘッダーフィールドを検出した後の対話を介して行われます.

プロキシがプライバシーを強化するために使用される環境では, ユーザーエージェントはプロアクティブネゴシエーションヘッダーフィールドを送信する際に保守的であるべきです. 高度なヘッダーフィールド構成可能性を提供する汎用ユーザーエージェントは, 詳細が多すぎると結果として生じる可能性のあるプライバシー損失についてユーザーに通知すべきです. 極端なプライバシー対策として, プロキシは中継されたリクエストでプロアクティブネゴシエーションヘッダーフィールドをフィルタリングできます.

17.14. Validator Retention (バリデータ保持)​

この仕様で定義されたバリデータは, 表現の有効性を確保したり, 悪意のある変更から保護したり, オンパス攻撃を検出したりすることを意図していません. せいぜい, すべての参加者が適切に動作している場合に, より効率的なキャッシュ更新と楽観的な同時書き込みを可能にします. 最悪の場合, 条件は失敗し, クライアントは条件付きリクエストなしのHTTP交換よりも有害ではない応答を受け取ります.

エンティティタグは, プライバシーリスクを生み出す方法で悪用される可能性があります. たとえば, サイトは意図的にユーザーまたはユーザーエージェントに固有の意味的に無効なエンティティタグを構築し, 長い鮮度時間を持つキャッシュ可能な応答でそれを送信し, 後でそのユーザーまたはユーザーエージェントを再識別する手段として, 後の条件付きリクエストでそのエンティティタグを読み取ることができます. このような識別タグは, ユーザーエージェントが元のキャッシュエントリを保持している限り, 永続的な識別子になります. 表現をキャッシュするユーザーエージェントは, ユーザーがプライバシー維持アクション(保存されたCookieのクリアやプライベートブラウジングモードへの切り替えなど)を実行するたびにキャッシュがクリアまたは置き換えられることを確認すべきです.

17.15. Denial-of-Service Attacks Using Range (範囲を使用したサービス拒否攻撃)​

制約のない複数範囲リクエストは, 同じデータの多くの重複する範囲を要求するために必要な労力が, 要求されたデータを多くのパートで提供しようとすることによって消費される時間, メモリ, および帯域幅と比較して微小であるため, サービス拒否攻撃を受けやすくなっています. サーバーは, 2つ以上の重複する範囲のリクエストや単一セット内の多くの小さな範囲のリクエストなど, 過度の範囲リクエストを無視, 結合, または拒否すべきであり, 特に範囲が明らかな理由なく順不同でリクエストされている場合です. マルチパート範囲リクエストは, ランダムアクセスをサポートするように設計されていません.

17.16. Authentication Considerations (認証に関する考慮事項)​

HTTP認証のトピックに関するすべてがセキュリティ考慮事項であるため, 以下の考慮事項のリストは網羅的ではありません. さらに, それは一般的な認証フレームワークに関するセキュリティ考慮事項に限定されており, 特定の認証スキームのすべての潜在的な考慮事項を議論するものではありません(それらのスキームを定義する仕様に文書化されるべきです). さまざまな組織は, 実装で見つかる認証スキームの一般的な落とし穴を含む, Webアプリケーションセキュリティに関する現在の研究へのトピック情報とリンクを維持しています(たとえば, [OWASP]).

17.16.1. Confidentiality of Credentials (認証情報の機密性)​

HTTP認証フレームワークは, 認証情報の機密性を維持するための単一のメカニズムを定義していません; 代わりに, 各認証スキームは, 送信前に認証情報をエンコードする方法を定義します. これは将来の認証スキームの開発に柔軟性を提供しますが, それ自体で機密性を提供しない既存のスキーム, またはリプレイ攻撃から十分に保護しないスキームの保護には不十分です. さらに, サーバーが各個人ユーザーに固有の認証情報を期待する場合, それらの認証情報の交換は, 認証情報の内容が機密のままであっても, そのユーザーを識別する効果があります.

HTTPは, フィールドの機密送信を提供するために, 基礎となるトランスポートまたはセッションレベル接続のセキュリティプロパティに依存しています. 個々のユーザー認証に依存するサービスは, 認証情報を交換する前に安全な接続(セクション4.2.2)を必要とします.

17.16.2. Credentials and Idle Clients (認証情報とアイドルクライアント)​

既存のHTTPクライアントとユーザーエージェントは通常, 認証情報を無期限に保持します. HTTPは, オリジンサーバーがこれらのキャッシュされた認証情報を破棄するようにクライアントに指示するメカニズムを提供していません, なぜならプロトコルはユーザーエージェントが認証情報を取得または管理する方法を認識していないからです. 認証情報を期限切れまたは取り消すメカニズムは, 認証スキーム定義の一部として指定できます.

認証情報のキャッシングがアプリケーションセキュリティモデルと干渉する可能性がある状況には, 次のものが含まれますがこれらに限定されません:

  • 長時間アイドル状態のままになっているクライアントマシン, その後サーバーはクライアントにユーザーに認証情報を再プロンプトさせたい場合があります.

  • セッション終了指示を含むアプリケーション(ページ上の"ログアウト"または"送信"ボタンなど), その後アプリケーションのサーバー側は, クライアントが認証情報を保持する理由がこれ以上ないことを"知っています".

認証情報をキャッシュするユーザーエージェントは, ユーザー制御下でキャッシュされた認証情報を破棄するための簡単にアクセスできるメカニズムを提供することが推奨されます.

17.16.3. Protection Spaces (保護空間)​

保護空間を確立するために"realm"メカニズムのみに依存する認証スキームは, オリジンサーバー上のすべてのリソースに認証情報を公開します. リソースへの認証されたリクエストを正常に行ったクライアントは, 同じオリジンサーバー上の他のリソースに対して同じ認証資格情報を使用できます. これにより, 異なるリソースが他のリソースの認証資格情報を収集することが可能になります.

これは, オリジンサーバーが同じオリジン下で複数のパーティのリソースをホストしている場合に特に懸念されます(セクション11.5). 可能な緩和戦略には, 認証資格情報への直接アクセスの制限(すなわち, Authorization request header fieldの内容を利用可能にしない), および各パーティに異なるホスト名(またはポート番号)を使用して保護空間を分離することが含まれます.

17.16.4. Additional Response Fields (追加の応答フィールド)​

暗号化されていない接続で送信される応答に情報を追加すると, (他の)安全な通信に関する情報が漏洩する可能性があります. たとえば, 認証スキームへの特定の拡張は, Authentication-InfoまたはProxy-Authentication-Infoヘッダーフィールドを使用して, 後続のリクエストに関する情報(リプレイ攻撃の防止に役立つ次のnonceなど)を提供します. このような情報が暗号化されていない接続を介して通信される場合, 攻撃者はそれを観察する可能性があり, したがってその有効性を低下させます.

に最終更新