フィードバックのお願い: プライベートネットワーク用の CORS（RFC1918）

クライアントの内部ネットワーク上のデバイスとサーバーが意図せずウェブ全体に公開されるリスクを軽減します。

Eiji Kitamura

悪意のあるウェブサイトがプライベートネットワークでホストされているデバイスやサーバーにリクエストを送信することは、長らく脅威となってきました。たとえば、攻撃者はワイヤレスルーターの構成を変更して、 Man-in-the-Middle 攻撃を可能にする可能性があります。CORS-RFC1918 は、ブラウザでこのようなリクエストをデフォルトでブロックし、内部デバイスがパブリックインターネットからのリクエストをオプトインすることを義務付ける提案です。

この変更がウェブエコシステムに与える影響を把握するため、Chrome チームはプライベートネットワーク用のサーバーを構築するデベロッパーからのフィードバックを求めています。

現状の問題点

多くのウェブサーバーはプライベートネットワーク内で実行されています。ワイヤレスルーター、プリンタ、イントラネットウェブサイト、エンタープライズサービス、モノのインターネット（IoT）デバイスはその一部にすぎません。これらのサーバーは、一般公開されているサーバーよりも安全な環境にあるように見えるかもしれませんが、ウェブページをプロキシとして使用する攻撃者によって悪用される可能性があります。たとえば、悪意のあるウェブサイトに URL を埋め込むと、被害者が（JavaScript が有効なブラウザで）その URL を表示するだけで、被害者の家庭用ブロードバンドルーターの DNS サーバー設定を変更しようとします。このタイプの攻撃は「ドライブバイファーミング」と呼ばれ、 2014 年に発生しました。 30 万台以上の脆弱なワイヤレスルーターが、DNS 設定を変更され、攻撃者がユーザーを悪意のあるサーバーにリダイレクトできるように悪用されました。

CORS-RFC1918

同様の攻撃の脅威を軽減するため、ウェブコミュニティは CORS-RFC1918（RFC1918で定義されたプライベートネットワークに特化したクロスオリジンリソースシェアリング（CORS））を導入しています。

CORS を実装するブラウザは、別のオリジンから読み込んでも問題ないかどうかをターゲットリソースに確認します。これは、アクセスを説明する追加のヘッダーをインラインで使用するか、プリフライトリクエストと呼ばれるメカニズムを使用することで実現されます。詳しくは、クロスオリジンリソースシェアリングをご覧ください。

CORS-RFC1918 では、サーバーが CORS と HTTPS を使用して明示的に許可しているリソースを除き、ブラウザはデフォルトでプライベートネットワーク経由のリソースの読み込みをブロックします。これらのリソースにリクエストを送信するウェブサイトは CORS ヘッダーを送信する必要があり、サーバーは対応する CORS ヘッダーで応答することで、クロスオリジンリクエストを受け入れることを明示的に示す必要があります。（正確な CORS ヘッダーは現在開発中です）。

このようなデバイスやサーバーのデベロッパーは、次の 2 つを行う必要があります。

プライベートネットワークにリクエストを送信するウェブサイトが HTTPS で提供されていることを確認します。
CORS-RFC1918 のサーバーサポートを設定し、想定される HTTP ヘッダーで応答します。

どのようなリクエストが影響を受けますか？

影響を受けるリクエストは次のとおりです。

パブリックネットワークからプライベートネットワークへのリクエスト
プライベートネットワークからローカルネットワークへのリクエスト
パブリックネットワークからローカルネットワークへのリクエスト

プライベートネットワーク IPv4 の RFC1918 のセクション 3 で定義されているプライベートアドレス空間に解決される宛先、マッピングされた IPv4 アドレス自体がプライベートである IPv4 マップ IPv6 アドレス、または ::1/128、2000::/3、ff00::/8 サブネット外の IPv6 アドレス。

ローカルネットワーク IPv4 のRFC1122 のセクション 3.2.1.3 で定義されている「ループバック」空間（127.0.0.0/8）に解決される宛先、IPv4 のRFC3927 で定義されている「リンクローカル」空間（169.254.0.0/16）、IPv6 のRFC4193 のセクション 3 で定義されている「ユニークローカルアドレス」プレフィックス（fc00::/7）、または IPv6 のRFC4291 のセクション 2.5.6 で定義されている「リンクローカル」プレフィックス（fe80::/10）。

パブリックネットワーク : その他すべて。

CORS-RFC1918 におけるパブリックネットワーク、プライベートネットワーク、ローカルネットワークの関係。

CORS-RFC1918 を有効にする Chrome の計画

Chrome は、CORS-RFC1918 を 2 つのステップで導入します。

ステップ 1: プライベートネットワークリソースへのリクエストは HTTPS ウェブページからのみ許可される

Chrome 87 では、プライベートネットワークリソースにリクエストを送信するパブリックウェブサイトが HTTPS 上にあることを義務付けるフラグが追加されます。about://flags#block-insecure-private-network-requests に移動して有効にできます。このフラグをオンにすると、HTTP ウェブサイトからプライベートネットワークリソースへのリクエストはすべてブロックされます。

Chrome 88 以降、CORS-RFC1918 エラーはコンソールに CORS ポリシーエラーとして報告されます。

CORS-RFC1918 エラーは、コンソールで CORS ポリシーエラーとして報告されます。 — CORS-RFC1918 エラーは、[**コンソール**] に CORS ポリシーエラーとして報告されます。

Chrome DevTools の [ネットワーク] パネルで [ブロックされたリクエスト] チェックボックスをオンにすると、ブロックされたリクエストに絞り込むことができます。

CORS-RFC1918 エラーも、ネットワークパネルで CORS エラーとして報告されます。 — CORS-RFC1918 エラーは、[**ネットワーク**] パネルに CORS エラーとしても報告されます。

Chrome 87 では、CORS-RFC1918 エラーは DevTools コンソールに ERR_INSECURE_PRIVATE_NETWORK_REQUEST としてのみ報告されます。

こちらのテストウェブサイトで試すことができます。

ステップ 2: 特別なヘッダーを含むプリフライトリクエストを送信する

今後、パブリックウェブサイトがプライベートネットワークまたはローカルネットワークからリソースを取得しようとすると、Chrome は実際のリクエストの前にプリフライトリクエストを送信します。

リクエストには、他の CORS リクエストヘッダーに加えて Access-Control-Request-Private-Network: true ヘッダーが含まれます。これらのヘッダーは、リクエストを行うオリジンを識別し、きめ細かいアクセス制御を可能にします。サーバーは Access-Control-Allow-Private-Network: true ヘッダーで応答して、リソースへのアクセスを許可することを明示的に示すことができます。