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

このセクションでは、WebDAV アプリケーションが認識する必要があるセキュリティへの影響に関する問題について詳しく説明します。

HTTP/1.1 のすべてのセキュリティ上の考慮事項 ([RFC2616] で議論) と XML のすべてのセキュリティ上の考慮事項 ([RFC3023] で議論) も WebDAV に適用されます。さらに、リモートオーサリングに固有のセキュリティリスクには、より強力な認証技術が必要であり、いくつかの新しいプライバシーの懸念が導入され、不適切なサーバー設計による危険が増す可能性があります。これらの問題を以下に詳しく説明します。

20.1. Authentication of Clients (クライアントの認証)

オーサリングを重視するため、WebDAV サーバーは、ネットワークリソースへのアクセスだけでなく、リソースの整合性も保護するために認証技術を使用する必要があります。さらに、ロック機能の導入には、認証のサポートが必要です。

パスワードが傍受される可能性があるため、安全でないチャネルを介して平文で送信されるパスワードは、リソースのアクセス可能性と整合性を保護するための不十分な手段です。HTTP/1.1 の基本認証は本質的にパスワードの平文送信を実行するため、接続が安全でない限り、基本認証を使用して WebDAV クライアントをサーバーに認証してはなりません (MUST NOT)。さらに、接続が安全でない限り、WebDAV サーバーは WWW-Authenticate ヘッダーで基本認証チャレンジを送信してはなりません (MUST NOT)。安全な接続の例としては、強力な暗号スイートとサーバー認証を使用するトランスポート層セキュリティ (TLS) 接続があります。

WebDAV アプリケーションはダイジェスト認証スキーム [RFC2617] をサポートしなければなりません (MUST)。ダイジェスト認証は、その秘密を平文で送信することなく、通信の両当事者が共有秘密 (パスワード) を知っていることを検証するため、基本認証に固有のセキュリティ問題を回避しながら、幅広いシナリオで役立つレベルの認証を提供します。

20.2. Denial of Service (サービス拒否)

サービス拒否攻撃は、WebDAV サーバーにとって特に懸念される問題です。WebDAV と HTTP を組み合わせることで、システムリソースのあらゆる部分に対してサービス拒否攻撃が可能になります。

非常に大きなファイルを PUT することで、基盤となるストレージが攻撃される可能性があります。
大規模なコレクションに対して再帰的な操作を要求することで、処理時間が攻撃される可能性があります。
複数の接続で複数のパイプライン化されたリクエストを行うことで、ネットワーク接続が攻撃される可能性があります。

WebDAV サーバーは、すべてのレベルでサービス拒否攻撃の可能性を認識する必要があります。このような攻撃に対する適切な応答は、単に接続をドロップすることかもしれません (MAY)。または、サーバーが応答できる場合、サーバーは 400 (Bad Request) などの 400 レベルのステータスリクエストを使用し、リクエストが拒否された理由を示すことができます (MAY) (500 レベルのステータス応答は問題がサーバーにあることを示しますが、意図しない DoS 攻撃はクライアントが修正できるものです)。

20.3. Security through Obscurity (隠蔽によるセキュリティ)

WebDAV は、PROPFIND メソッドを通じて、コレクションのメンバーリソースをリストするメカニズムを提供します。これにより、ネットワークリソースの名前を発見することの困難性のみに依存するセキュリティまたはプライバシー技術の有効性が大幅に低下します。WebDAV サーバーのユーザーは、リソース名の相対的な隠蔽性に依存するのではなく、アクセス制御技術を使用してリソースへの望ましくないアクセスを防ぐことが推奨されます。

20.4. Privacy Issues Connected to Locks (ロックに関連するプライバシーの問題)

ロックリクエストを送信するとき、ユーザーエージェントは、ロックを取得している人の連絡先情報を提供する 'owner' XML フィールドも送信することができます (人間がロックを取得している場合、ロボットではない場合)。この連絡先情報は、リソースの DAV:lockdiscovery プロパティに保存され、他の協力者がリソースへのアクセスについて交渉を開始するために使用できます。ただし、多くの場合、この連絡先情報は非常にプライベートである可能性があり、広く配布すべきではありません。サーバーは、適切に DAV:lockdiscovery プロパティへの読み取りアクセスを制限すべきです (SHOULD)。さらに、ユーザーエージェントは、連絡先情報を送信するかどうか、および連絡先情報が送信される場合、正確にどの情報が送信されるかについての制御を提供すべきです (SHOULD)。

20.5. Privacy Issues Connected to Properties (プロパティに関連するプライバシーの問題)

プロパティ値は通常、ドキュメントの作成者などの情報を保持するために使用されるため、リソースのプロパティデータへの広範なアクセスから生じるプライバシーの懸念が生じる可能性があります。プロパティを介した私的情報の不注意な漏洩のリスクを減らすために、サーバーは、リソース本体への読み取りアクセスとリソースのプロパティへの読み取りアクセスを分離するアクセス制御メカニズムを開発することが推奨されます。これにより、ユーザーは、リソースのコンテンツへのアクセスを過度に制限することなく、プロパティデータの配布を制御できます。

20.6. Implications of XML Entities (XML エンティティの影響)

XML は、[REC-XML] のセクション 4.2.2 で定義されている "外部エンティティ" として知られる機能をサポートしており、XML プロセッサに追加の XML を取得して含めるように指示します。外部 XML エンティティは、XML ドキュメントに関連付けられたドキュメントタイプ宣言 (DTD) を追加または変更するために使用できます。外部 XML エンティティは、XML ドキュメントのコンテンツ内に XML を含めるためにも使用できます。本仕様で使用される XML のような非検証 XML の場合、外部 XML エンティティを含めることは XML では必須ではありません。ただし、XML は、XML プロセッサが独自の裁量で外部 XML エンティティを含めることができると述べています。

外部 XML エンティティには固有の信頼性がなく、あらゆる HTTP GET リクエストに蔓延しているすべての攻撃の影響を受けます。さらに、外部 XML エンティティが DTD を変更する可能性があり、したがって XML ドキュメントの最終形式に影響を与え、最悪の場合、そのセマンティクスを大幅に変更したり、XML プロセッサを [RFC3023] で議論されているセキュリティリスクにさらしたりする可能性があります。したがって、実装者は、外部 XML エンティティを信頼できないものとして扱う必要があることを認識する必要があります。サーバーが外部 XML エンティティを処理しないことを選択した場合、外部エンティティを含むリクエストに 'no-external-entities' 条件コードで応答すべきです (SHOULD)。

外部 XML エンティティを使用する広く展開されたアプリケーションに伴うスケーラビリティリスクもあります。この状況では、1 つの外部 XML エンティティに対する大量のリクエストが発生する可能性があり、外部 XML エンティティを含むリソースに対するリクエストを処理するサーバーが過負荷になる可能性があります。

さらに、[REC-XML] のセクション 4.2.2 で定義されている "内部エンティティ" の評価に基づくリスクもあります。ネストされた内部エンティティを使用して慎重に作成された小さなリクエストは、処理に膨大な量のメモリおよび/または処理時間を必要とする場合があります。サーバー実装者はこのリスクを認識し、このようなリクエストを可能な限り早期に検出して拒否できるように XML パーサーを構成する必要があります。

20.7. Risks Connected with Lock Tokens (ロックトークンに関連するリスク)

本仕様は、空間と時間にわたってその一意性を保証するために、ロックトークン (セクション 6.5) に "通用一意識別子 (UUID) URN 名前空間" ([RFC4122]) の使用を推奨しています。バージョン 1 UUID (セクション 4 で定義) には、"IEEE 802 MAC アドレス (通常はホストアドレス) で構成される" "node" フィールドが含まれる場合があります (MAY)。複数の IEEE アドレスを持つシステムの場合、利用可能な任意のアドレスを使用できます"。WebDAV サーバーはその存続期間中に多くのロックを発行するため、IEEE 802 アドレスも公開される可能性があります。

IEEE 802 アドレスの公開に関連するいくつかのリスクがあります。IEEE 802 アドレスを使用すると:

サブネットからサブネットへのハードウェアの移動を追跡することが可能です。
WebDAV サーバーを実行しているハードウェアの製造元を特定できる可能性があります。
WebDAV を実行している各タイプのコンピューターの数を決定できる可能性があります。

このリスクは、ホストアドレスベースの UUID バージョンにのみ適用されます。[RFC4122] のセクション 4 では、ホストアドレスを含まないため、このリスクの影響を受けない UUID を生成するためのいくつかの他のメカニズムが説明されています。

20.8. Hosting Malicious Content (悪意のあるコンテンツのホスティング)

HTTP には、クライアントマシンで実行されるプログラムをホストする機能があります。これらのプログラムは、Web スクリプト、実行可能ファイル、プラグインモジュール、ドキュメント内のマクロなど、さまざまな形式をとることができます。WebDAV は、これらのプログラムに関するセキュリティ上の懸念を変更しませんが、WebDAV は多くの場合、幅広いユーザーがサーバー上にドキュメントを公開できるコンテキストで使用されます。サーバーは、ドキュメントを公開している作成者と緊密な信頼関係を持っていない可能性があります。クライアントが任意のコンテンツを公開できるようにするサーバーは、サーバーに公開されたコンテンツが他のクライアントに有害でないことを確認するための予防措置を有効に実装できます。サーバーは、公開が許可されているコンテンツのタイプを制限したり、公開されたコンテンツでウイルスおよびマルウェア検出ソフトウェアを実行したりするなどの技術によってこれを行うことができます。サーバーは、サーバーにコンテンツを公開することが許可されているユーザーの適切なアクセス制限と認証を行うことで、リスクを軽減することもできます。