クライアントの内部ネットワーク上のデバイスやサーバーが意図せずウェブ全体に漏洩することによるリスクを軽減する。
プライベート ネットワークでホストされているデバイスやサーバーにリクエストを行う悪意のあるウェブサイトは、以前から脅威であり続けています。たとえば、攻撃者がワイヤレス ルーターの構成を変更して、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::/7
RFC4193fe80::/10
RFC4291
パブリック ネットワーク その他すべてのネットワーク。
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 ポリシーエラーとしてコンソールに報告されるようになります。
Chrome DevTools の [ネットワーク] パネルで、[ブロックされたリクエスト] チェックボックスをオンにすると、ブロックされたリクエストに注目できます。
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
ヘッダーで応答して、リソースへのアクセスを許可したことを明示的に示すことができます。
フィードバックのお願い
パブリック ネットワークからのリクエストを想定しているウェブサイトをプライベート ネットワーク内でホストしている場合、Chrome チームはフィードバックとユースケースを歓迎します。そのためにできることが 2 つあります。
about://flags#block-insecure-private-network-requests
に移動し、フラグをオンにして、ウェブサイトからプライベート ネットワーク リソースに想定どおりにリクエストが送信されたかどうかを確認します。- 問題が発生した場合や、フィードバックがある場合は、crbug.com で問題を報告し、コンポーネントを
Blink>SecurityFeature>CORS>RFC1918
に設定します。
フィードバックの例
ワイヤレス ルーターは同じプライベート ネットワークの管理ウェブサイトに HTTP を経由します。管理ウェブサイトを埋め込んでいるウェブサイトで HTTPS が必要な場合は、混合コンテンツになります。閉鎖されたネットワークの管理ウェブサイトで HTTPS を有効にする必要がありますか?
Chrome ではまさにこのようなフィードバックを求めています。具体的なユースケースについては、crbug.com で報告してください。Chrome では皆様のご意見をお待ちしております。
ヒーロー画像(作成者: Stephen Philips、Unsplash)