このページは Cloud Translation API によって翻訳されました。

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

クライアントの内部ネットワーク上のデバイスやサーバーが意図せずウェブ全体に漏洩することによるリスクを軽減する。

Eiji Kitamura

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

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

現状はどうなってるの？

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

CORS-RFC1918

同様の攻撃の脅威を軽減するために、ウェブコミュニティは RFC1918 で定義されたプライベートネットワークに特化した CORS-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）、IPv4 の IPv4 の IPv6 の IPv6.2 プレフィックス（2.2、{link-2}-1、{/16、{1RFC4193 のセクション 3.2}セクション 3.2}-1 セクション 3.2 でセクション 3.1{/193 のセクション 3.2.1.1.3 で定義される / RFC4193 セクション 3.2.1.3 で定義される「リンクローカルアドレス」{/1.1.3）に解決される宛先の宛先。fc00::/7RFC4193fe80::/10RFC4291

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

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

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

Chrome では、次の 2 つの手順で CORS-RFC1918 が導入されます。

ステップ 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 ヘッダーで応答して、リソースへのアクセスを許可したことを明示的に示すことができます。