プライベート ネットワーク アクセス: プリフライトの導入

Titouan Rigoudy

Eiji Kitamura

Yifan Luo

更新

• 2022 年 7 月 7 日: 現在のステータスを更新し、IP アドレス空間の定義を追加しました。
• 2022 年 4 月 27 日: タイムラインのお知らせを更新しました。
• 2022 年 3 月 7 日: Chrome 98。

はじめに

Chrome は、パブリック ネットワークからプライベート ネットワーク エンドポイントへの直接アクセスを廃止します ウェブサイトの一部である プライベート ネットワーク アクセス（PNA） 仕様。

Chrome は、サブリソースのプライベート ネットワーク リクエストに先立って、CORS プリフライト リクエストの送信を開始します。 明示的な許可を得る必要があります。このプリフライト リクエストは 新しいヘッダー Access-Control-Request-Private-Network: true と、 そのレスポンスには対応するヘッダー、 Access-Control-Allow-Private-Network: true。

目的は、クロスサイト リクエスト フォージェリ（CSRF）攻撃からユーザーを保護することです。 プライベート ネットワーク上のルーターなどのデバイスをターゲットにしています。これらの攻撃は数十万人のユーザーに影響を与えており、 攻撃者は悪意のあるサーバーにリダイレクトできます。

リリース スケジュール

Chrome では、ウェブサイトが認識するまでに時間を確保するために、この変更を 2 段階でロールアウトします。 それに応じて調整します

1. Chrome 104 では次のようになります。

   • プライベート ネットワークの前にプリフライト リクエストを送信して Chrome でテスト サブリソース リクエストだけです。
   • プリフライト エラーでは、DevTools に警告のみが表示されます。 プライベート ネットワーク リクエストに影響を与えます。
   • Chrome が互換性データを収集し、影響を受ける最も大きい連絡先に連絡する ウェブサイト。
   • この機能は、既存のウェブサイトと幅広く互換性を持つことが予想されます。
   で確認できます。
   警告: まだプリフライトをサポートしていないウェブサイトへの影響を抑えるために、 Chrome 104 ではタイムアウトが 200 ミリ秒に制限されました。この制限は、 警告モードで適用されますこの特別なタイムアウト制限は [Respect the result of Private Network] を切り替えて、強制モードを有効にします。 プリフライトにアクセス」[有効] に変更します。chrome://flags 内。デフォルトの上限は 5 あります

2. Chrome 113 以降:

   • この処理は、互換性データに 必要に応じて直接アウトリーチしました
   • Chrome では、プリフライト リクエストは成功し、成功しないと失敗するように強制されている 提供します。
   • デプリケーション トライアルの開始日 同時に、このフェーズの影響を受けるウェブサイトが 指定することもできます。トライアルは少なくとも 6 か月間継続されます。

で確認できます。

注: Chrome 98 と Chrome 102 では以前から警告を展開しようと試みていますが、 このブログ投稿でお知らせしたとおりです。これは、安定した状態でロールバックされ、 ロールアウト中に互換性の問題が見つかった。 特定された問題は Chrome 104 で修正されています。

プライベート ネットワーク アクセス（PNA）とは

プライベート ネットワーク アクセス （旧称 CORS-RFC1918） により、Web サイトからプライベート サーバーにリクエストを送信できる機能が制限されます。 接続します

Chrome には仕様の一部がすでに実装されています。Chrome 96 では、 プライベート ネットワーク リクエストの実行が許可されます。詳しくは、 以前のブログ投稿をご覧ください。

この仕様では、クロスオリジン リソース シェアリング（CORS）も拡張されています。 プロトコルを使用して、ウェブサイトがサーバーに許可を明示的にリクエストする必要がある 任意のリクエストの送信が許可されます。

重要な用語: プライベート ネットワーク リクエストとは、ターゲット サーバーの IP アドレスが リクエスト イニシエータのフェッチ元よりも機密性が高くなります。たとえば 公開ウェブサイト（https://example.com）から非公開ウェブサイトへのリクエスト （http://router.local）、非公開ウェブサイトから localhost へのリクエストなどです。

PNA による IP アドレスの分類とプライベート ネットワークの特定方法

IP アドレスは、次の 3 つの IP アドレス空間に分類されます。 - public - private - local

ローカル IP アドレス空間には、IPv4 の IP アドレスか、 RFC1122 のセクション 3.2.1.3 で定義されているループバック アドレス（127.0.0.0/8） RFC4291 のセクション 2.5.3 で定義されている IPv6 ループバック アドレス（::1/128）。

プライベート IP アドレス空間には、意味のある IP アドレスのみが含まれる 現在のネットワーク内で、10.0.0.0/8、172.16.0.0/12、 RFC1918 で定義されている 192.168.0.0/16 RFC3927 で定義されているリンクローカル アドレス169.254.0.0/16 一意のローカル IPv6 ユニキャスト アドレス fc00::/7（RFC4193 で定義） RFC4291 のセクション 2.5.6 で定義されているリンクローカル IPv6 ユニキャスト アドレス fe80::/10 マッピングされた IPv4 アドレス自体がプライベートである IPv4 マップド IPv6 アドレス。

パブリック IP アドレス空間には、上記以外のすべてのアドレスが含まれます。

ローカル IP アドレスは、プライベート IP アドレスよりもプライベートであるとみなされます。 プライベート IP アドレスは パブリック IP アドレスよりもプライベート性が高いと見なされます

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> プライベート ネットワークのパブリック、プライベート、ローカル ネットワーク間の関係 Access（CORS-RFC1918）

をご覧ください。

詳細については、フィードバックを送信する: プライベート ネットワークの CORS（RFC1918）をご覧ください。

プリフライト リクエスト

背景

プリフライト リクエストは、クロスオリジン リソース シェアリング（CORS）標準によって導入されたメカニズムです。 HTTP リクエストを送信する前に、対象のウェブサイトから権限をリクエストする 悪影響を及ぼす可能性があります。これにより、ターゲット サーバーが CSRF 攻撃のリスクを大幅に低減できます。

権限リクエストは、特定の CORS リクエスト ヘッダーを使用して OPTIONS HTTP リクエストとして送信されます。 続く HTTP リクエストを記述します。レスポンスには特定の CORS レスポンス ヘッダーが含まれている必要がある 同意することもできます。

プライベート ネットワーク アクセスの新機能

プリフライト リクエストにリクエスト ヘッダーとレスポンス ヘッダーの新しいペアが導入されています。

• Access-Control-Request-Private-Network: true は、すべての PNA プリフライト リクエストに設定されます。
• すべての PNA プリフライト レスポンスで Access-Control-Allow-Private-Network: true を設定する必要があります

PNA のプリフライト リクエストは、すべてのプライベート ネットワーク リクエストに対して送信されます。 リクエストメソッドと mode:イベントの通知は cors モード、no-cors モード、他のすべてのモードでのリクエストより優先的に処理されます。この すべてのプライベート ネットワーク リクエストが CSRF 攻撃に使用できるからです。 リクエスト モードや、レスポンスの内容が実際に メッセージを表示できます。

注: プライベート ネットワーク リクエストが cors モードで実行される場合、CORS ヘッダーは プリフライト レスポンスに加えて、最終レスポンスで設定します。

同一オリジン リクエストの PNA プリフライト リクエストも、 ターゲット IP アドレスがイニシエータよりもプライベートになります。これは通常の CORS。プリフライト リクエストはクロスオリジン リクエストのみを対象とします。プリフライト 同一オリジン リクエストのリクエストは、 DNS リバインディング攻撃。

例

観測可能な動作は、アプリケーションの リクエストのモード。

非 CORS モード

https://foo.example/index.html 件の埋め込みと話す <img src="https://bar.example/cat.gif" alt="dancing cat"/> bar.example は 192.168.1.1 に解決されます。これは、次に従ってプライベート IP アドレスです。 RFC 1918。

まず Chrome がプリフライト リクエストを送信します。

HTTP/1.1 OPTIONS /cat.gif
Origin: https://foo.example
Access-Control-Request-Private-Network: true

このリクエストを成功させるには、サーバーが次のレスポンスを返す必要があります。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Private-Network: true

警告: サーバーで Access-Control-Allow-Origin: * を設定できますが、これは危険です。 失望します。プライベート ネットワーク リソースに誰でもアクセスできることはほとんどない そのため、このようなヘッダーの設定に伴うリスクについて慎重に検討してください。

その後、Chrome は実際のリクエストを送信します。

HTTP/1.1 GET /cat.gif
...

サーバーが通常どおり応答できる場所。

CORS モード

https://foo.example/index.html が次のコードを実行するとします。

await fetch('https://bar.example/delete-everything', {
  method: 'PUT',
  credentials: 'include',
})

ここでも、bar.example が 192.168.1.1 に解決されるとします。

まず Chrome がプリフライト リクエストを送信します。

HTTP/1.1 OPTIONS /delete-everything
Origin: https://foo.example
Access-Control-Request-Method: PUT
Access-Control-Request-Credentials: true
Access-Control-Request-Private-Network: true

このリクエストを成功させるには、サーバーが次のレスポンスを返す必要があります。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true

その後、Chrome は実際のリクエストを送信します。

HTTP/1.1 PUT /delete-everything
Origin: https://foo.example

サーバーが通常の CORS ルールに従って応答できる対象は次のとおりです。

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://foo.example

ウェブサイトが影響を受けているかどうかを確認する方法

Chrome 104 以降では、プライベート ネットワーク リクエストが検出されると、プリフライト その前にリクエストが送信されます。このプリフライト リクエストが失敗した場合、 リクエストは送信されますが、DevTools に警告が表示されます。 [問題] パネルで確認できます。

影響を受けるプリフライト リクエストは、ネットワーク パネルで表示、診断することもできます。

リクエストによって通常の CORS プリフライトがトリガーされ、 ルールがある場合、2 つのプリフライトが 最初のパネルは常に失敗しているように見えます。これは 既知のバグであり、無視してかまいません。

プリフライトの成功が適用された場合の結果を確認するには、次の操作を行います。 次のコマンドライン引数を渡す Chrome 98 以降:

--enable-features=PrivateNetworkAccessRespectPreflightResults

プリフライト リクエストが失敗すると、取得が失敗します。これにより、 ウェブサイトが機能 リリース計画の第 2 フェーズに進みましたエラーは 上記の DevTools パネルを使用して、警告と同じ方法で警告できます。

ウェブサイトが影響を受けている場合の対処方法

この変更が Chrome 104 でリリースされても、 確認できますただし、影響を受けるリクエストパスを ウェブサイトが想定どおりに稼働していることを確認します

次の 2 つのソリューションを使用できます。

1. サーバー側でプリフライト リクエストを処理する
2. エンタープライズ ポリシーで PNA チェックを無効にする

サーバー側でプリフライト リクエストを処理する

影響を受ける取得のターゲット サーバーを更新して PNA プリフライトを処理する できます。まず、標準 CORS プリフライト リクエストのサポートを ルートを確認できます。次に、2 つの新しいレスポンス ヘッダーのサポートを追加します。

サーバーがプリフライト リクエスト（CORS を含む OPTIONS リクエスト）を受け取ったとき ヘッダーを含む場合、サーバーは Access-Control-Request-Private-Network: true ヘッダー。このヘッダーが サーバーは、Origin ヘッダーと リクエスト パス、その他の関連情報（例: Access-Control-Request-Headers など）を使用して、リクエストが安全に許可されることを確認します。 通常は、1 つの送信元へのアクセスを許可して管理する必要があります。

警告: 保護されていない（https 以外）オリジンは認証されていないため、注意が必要です。通行 攻撃者がそのような送信元を装う可能性があります。

サーバーがリクエストを許可すると、サーバーが応答するはずです。 204 No Content（または 200 OK）: 必要な CORS ヘッダーと新しい PNA できます。これらのヘッダーには、Access-Control-Allow-Origin と Access-Control-Allow-Private-Network: true などのプロパティを追加します。

具体的なシナリオについては、例をご覧ください。

エンタープライズ ポリシーを使用してプライベート ネットワーク アクセスのチェックを無効にする

ユーザーに対する管理権限がある場合は、限定公開の Google アクセスを無効にし、 ネットワーク アクセスは、次のいずれかのポリシーを使用してチェックします。

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

詳しくは、Chrome ポリシー管理の概要をご覧ください。

ご意見をお寄せください

プライベート ネットワーク内でウェブサイトをホストしていて、 Chrome チームは、皆様からのフィードバックとユースケースをお待ちしています。 crbug.com で Chromium の問題を報告し、次のように設定します。 コンポーネントを Blink>SecurityFeature>CORS>PrivateNetworkAccess に設定します。

次のステップ

次に、Chrome はプライベート ネットワーク アクセスのチェックを拡張して、 web Worker: 専用のワーカー、共有ワーカー、Service Worker などがあります。暫定的に目標として 警告の表示を開始します

その後、Chrome はプライベート ネットワーク アクセスのチェックを拡張して、ナビゲーション、 iframe やポップアップなどを含めることができますChrome 108 のリリースを暫定的に目指す 表示されます。

どちらの場合も、同様の段階的な公開を慎重に進めていく予定です。 ウェブ デベロッパーが互換性リスクの調整と見積もりを行うための時間を確保できるようにしたいと考えています。

謝辞

Mark Olsen によるカバー写真、オン スプラッシュを解除。