ローカルネットワークアクセス

1. 序論

この節は規範的ではない。

[RFC1918] は、20年以上前から「プライベート」と「パブリック」の インターネットアドレスの区別を規定しているが、ユーザーエージェントは 両者を分離することについて大きな進展を遂げていない。パブリックインターネット上の ウェブサイトは、ローカルデバイスやサーバーにリクエストを行うことができ、 これにより、[DRIVE-BY-PHARMING]、[SOHO-PHARMING]、および [CSRF-EXPLOIT-KIT] に記録されているような、ユーザーのルーターに対する攻撃を含む多くの悪意ある 振る舞いが可能になる。

Local Network Access は、ローカルネットワーク上の安全でない デバイスへのこれらの望ましくないリクエストを防ぐことを目的とする。 これは、パブリックウェブサイトからローカル IP アドレスへの直接アクセスを 非推奨にし、代わりに、開始元ウェブサイトがユーザーのローカルネットワークへ 接続するためにユーザーが権限を付与することを要求することで達成される。

注: この提案は、以前に停止された Chrome の [PRIVATE-NETWORK-ACCESS] の作業の上に構築されるが、 プリフライトリクエストではなく権限によってアクセスを制御する点で異なる。

1.1. 目標

包括的な目標は、ユーザーのローカルイントラネット上で実行されている デバイス、またはユーザーのマシン上で直接実行されているサービスに対する 攻撃を、ユーザーエージェントが不注意に可能にしてしまうことを防ぐことである。 たとえば、次のものに対する攻撃を緩和したい:

• [SOHO-PHARMING] で概説されているユーザーのルーター。 なお、現状の CORS 保護は、ここで議論される種類の攻撃から保護しない。 それらは CORS セーフリスト化メソッドと CORS セーフリスト化リクエストヘッダーのみに 依存するためである。CORS プリフライトはトリガーされず、攻撃者は レスポンスを読むことを気にしない。リクエスト自体が CSRF 攻撃だからである。

• ユーザーのループバックアドレス上でウェブインターフェイスを実行しているソフトウェア。 良くも悪くも、これはあらゆる種類のアプリケーションに共通する デプロイ機構になりつつあり、実際には存在しない保護をしばしば仮定している （最近の例については [AVASTIUM] および [TREND-MICRO] を参照）。

ユーザーがローカルネットワークアクセスリクエストの発生を期待しており、 かつ明示的に許可している場合に、これらのリクエストを許可するための 明確な経路があるべきである。たとえば、plex.tv にログインしたユーザーは、 リモートサーバーを経由する代わりに、サイトがローカルメディアサーバーへ 接続してローカルネットワーク経由でメディアコンテンツを直接読み込むことを 許可したい場合がある。さらなる例については、以下の § 1.3 例を参照。

1.2. 非目標

この仕様は、ローカルネットワークデバイス上で HTTPS 接続を使いやすくすることを 試みない。これは有用な目標ではあるが、この問題を解決することは この仕様の範囲外である

1.3. 例

1.3.1. ユーザーが権限を付与する

1.3.2. ユーザーが権限を拒否する

1.3.3. 新しいデバイスの設定

1.3.4. アプリベースのサインイン

2. フレームワーク

2.1. IP アドレス空間

IPAddressSpace を次のように定義する:

enum IPAddressSpace { "public", "local", "loopback" };

すべての IP アドレスは IP アドレス 空間に属し、それは次の3つの異なる値のいずれかである:

1. loopback: ローカルホスト上でのみアクセス可能な ループバックアドレスを含む。言い換えれば、対象がデバイスごとに異なる アドレスである。

2. local: 現在のネットワーク内でのみ意味を持つ アドレスを含む。言い換えれば、対象がネットワーク上の位置に応じて異なる アドレスである。

3. public: それ以外のすべての アドレスを含む。言い換えれば、対象が IP ネットワーク上のすべてのデバイスで グローバルに同じであるアドレスである。

便宜上、さらに次の用語を定義する:

1. loopback address は、その IP アドレス空間 が loopback である IP アドレスである。

2. local address は、その IP アドレス空間 が local である IP アドレスである。

3. public address は、その IP アドレス空間 が public である IP アドレスである。

IP アドレス空間 lhs は、 次のいずれかの条件が真である場合、IP アドレス空間 rhs より less public である:

1. lhs が loopback であり、rhs が local または public のいずれかである。

2. lhs が local であり、rhs が public である。

IP アドレス address の IP アドレス空間を 決定するには、次の手順を実行する:

1. address が ::ffff:0:0/96 「IPv4-mapped Address」 アドレスブロックに属する場合、address をその埋め込み IPv4 アドレスで置き換える。

2. 非パブリック IP アドレスブロック 表の各 row について:

   1. address が row のアドレスブロックに属する場合、 row のアドレス空間を返す。

3. public を返す。

ユーザーエージェントは、管理者またはユーザー設定を通じて、特定の IP アドレスブロックの アドレス空間を 上書きできるようにしてもよい。これは、たとえば、上記のアルゴリズムではほとんどの IP アドレスが public とみなされる IPv6 イントラネットを保護するために、代わりに ユーザーエージェントがそのイントラネットを local と扱うよう設定する場合などに 有用であり得る。

注: 169.254.0.0/16 などの リンクローカル IP アドレスは local とみなされる。なぜなら、そのようなアドレスはネットワークリンク上の すべてのデバイスに対して同じ対象を識別できるからである。この仕様の 以前のバージョンでは、それらを代わりに loopback とみなしていた。

注: 各 IP アドレス空間の内容は、ある時点では IANA Special-Purpose Address Registries （[IPV4-REGISTRY] および [IPV6-REGISTRY]）と そこで定義される Globally Reachable ビットに従って決定されていた。 これは、wicg/private-network-access issue #50 で説明されているように、私たちの用途には不正確なシグナルであることが判明した。

注: [PRIVATE-NETWORK-ACCESS] は アドレス空間 public、private、および local を使用していた。この仕様では、アドレス空間をそれぞれ public、local、および loopback に改名する。

注: [FETCH] は、null IP アドレスへのリクエストを ネットワークエラーとして扱うことを規定する予定である。私たちは IPv4 null IP アドレス空間と IPv6 未指定アドレスの両方を loopback にマップする。これは、一部のシステムが それらを依然としてローカルホストマシンへルーティングできるためである（また 0.0.0.0/8 は「このネットワーク上の指定されたホスト」を指すことができるため、 local にマップされる） これは [RFC5735] に従う。Fetch への変更が行われ採用されれば、 この仕様でそれらを扱う必要はなくなる。

2.2. ローカルネットワークリクエスト

リクエスト（request）は、request の 現在の URL の host が、request の ポリシーコンテナーの IP アドレス空間より less public である IP アドレス空間を持つ IP アドレスにマップされる場合、ローカルネットワークリクエスト である。

IP アドレスを2つの広い アドレス空間に分類することは、 不完全で理論的に厳密ではないアプローチである。これは、2つのネットワークエンドポイントが 自由に通信することを許可されるべきかどうか、言い換えれば、エンドポイント A が エンドポイント C 上のユーザーエージェントを経由してピボットすることなく エンドポイント B から到達可能かどうかを判断するために用いられるプロキシである。

このアプローチにはいくつかの欠点がある:

• 偽陽性: public address を持つイントラネットサーバーが、 同じイントラネット上の local address を持つ別のサーバーへ直接リクエストを発行できない場合がある。

• 偽陰性: たとえばホームネットワークと VPN のような2つの異なる local ネットワークに接続されたクライアントは、 VPN から提供されるウェブサイトがホームネットワーク上のデバイスにアクセスすることを 許可してしまう場合がある。下記の issue も参照。

それでも、この仕様は、ネットワーク構成がそれほど複雑ではないほとんどの Web ユーザーに 広く影響するセキュリティ問題に対して、実用的な解決策を提供することを目指している。

loopback address から発信されるリクエストは、 ローカルネットワークリクエスト とみなされるべきではなく、ローカルネットワークアクセスチェックの対象とされるべきではない。 ユーザーのデバイス上で実行されるソフトウェアは、すでにユーザーのネットワーク上で 最も特権のある視点にあるためである。

ローカルネットワークリクエスト の定義は、 現在の URL の host が、IP アドレス空間が public ではない IP アドレスへ マップされる、すべてのクロスオリジンリクエストをカバーするように拡張できる。 これにより、ローカルネットワーク上の悪意あるサーバーが、 localhost 上のサーバーを含む他のサーバーを攻撃することを防げる。 wicg/private-network-access issue #39 を参照。

注: 現在、Chromium は Local Network Access 制限を public から local または loopback へのリクエストにのみ実装しており、クロスオリジンの local リクエストに対して権限を強制していない。この制限は、将来の実装で 段階的改善として出荷できる。

注: ローカル名とアドレスは ネットワークの境界外では意味を持たないため、実装者はクロスオリジンの local の場合には、public から local の場合とは異なる権限プロンプトを使用したい場合がある。さらに、実装者は これらの権限付与を特定のネットワーク、または現在の閲覧セッションのみに スコープしたい場合がある。

注: 一部の ローカルネットワークリクエストは、 他のものよりも保護が困難である。詳細については § 4.4 展開上の困難を参照。

2.3. ローカルネットワークリクエスト権限プロンプト

パブリックウェブサイトからローカルネットワークサーバーへの ローカルネットワークリクエスト をユーザーが承認できるようにするため、ローカルネットワークアクセス権限プロンプトが導入される。

ローカルネットワークリクエスト が検出されると、ローカルネットワークへアクセスする権限を求めるプロンプトが ユーザーに表示される。ユーザーが権限の付与を決定した場合、fetch は続行される。 そうでない場合、それは失敗する。

権限の正確なスコープは実装定義である。権限は、特定のオリジンが ローカルネットワーク上の任意のエンドポイントに ローカルネットワークリクエスト を送信できるようにする程度に粗くてもよく、または特定のオリジンが ローカルネットワーク上の特定のエンドポイントとだけ通信できるようにする程度に 細かくてもよい。ユーザーエージェントは、権限疲れを減らすため、この決定を永続化してもよい。

2.4. セキュアコンテキスト制限

ローカルネットワークリクエストを行う能力は 強力な機能であり、 セキュアコンテキストからのみ許可されなければならない。

将来的にすべての クロスオリジン local リクエストに LNA チェックを適用できるようにするため （上記の Issue を参照）、Chromium は現在、公的に信頼された HTTPS 証明書を 取得できそうにないローカルサーバー（たとえば .local 上のサーバーや プライベート IP リテラル）をこの要件から除外する予定である。 さらなる議論については § 4.4 展開上の困難を参照し、また wicg/private-network-access issue #96 も参照。

2.5. 混在コンテンツ

多くのローカルネットワークサーバーは HTTPS を実行していない。ローカルネットワークサーバーを HTTP から移行することは困難であり、時には不可能でさえあることが判明しているためである。 これは問題である。なぜなら、セキュアコンテキスト制限と混在コンテンツチェックが組み合わさることで、 ユーザーがリクエストの発生を許可したとしても、多くの ローカルネットワークリクエストが ブロックされるためである。

この問題の1つの解決策は、そのリクエストが ローカルネットワークリクエストであることが わかっている状況では、混在コンテンツチェックを迂回することである。これは いくつかの状況でわかる:

• リクエスト対象のホスト名が、非パブリック IP アドレスブロック" 表で local と識別される IP リテラルである場合（たとえば [RFC1918] IP リテラル）

• リクエストのホスト名が .local ドメイン（RFC 6762）である場合

上記のいずれにも当てはまらないが、サイトがリクエストを ローカルネットワークリクエストとして識別したい状況が 存在する場合がある。これは、fetch() オプションバッグに新しいパラメーターを 追加することで緩和できる:

fetch("http://router.local/ping", {
  targetAddressSpace: "local",
});

これは、スキームが非セキュアであっても、ブラウザーが fetch に混在コンテンツチェックを 迂回させ、対象サーバーへの接続を取得する可能性があるよう指示する。 新しい fetch() API は後方互換である。

この機能は、一般的な混在コンテンツの迂回に悪用できないことに注意。 解決されたリモート IP アドレスが targetAddressSpace オプション値として指定された IP アドレス空間に属さない場合、リクエストは失敗する。それに属する場合は、 権限を確認してリクエストを許可または失敗させることができる。

Chromium は現在、 非標準の CSP ディレクティブ treat-as-public-address をサポートしている （private-network-access#csp を参照）。 wicg/private-network-access issue #39 が実装されれば、このディレクティブは不要になる。

2.6. 権限

この文書は、次の 既定の強力な機能を定義する。これらは ポリシー制御機能であり、既定の許可リスト が 'self' である:

• "local-network"。これは ローカルネットワークリクエストを local address へ行う能力を制御する。

• "loopback-network"。これは ローカルネットワークリクエストを loopback address へ行う能力を制御する。

注: 以前、これは local と loopback の両方のケースを対象とする 単一の 既定の強力な機能、 "local-network-access" として 規定されていた。Chromium は現在もこれを新しい細粒度の権限名のエイリアスとして、 また ポリシー制御機能名として使用するためにサポートしている。

2.7. treat-as-public-address Content Security Policy ディレクティブ

treat-as-public-address ディレクティブは、たとえ文書が実際にはローカルアドレスまたはループバックアドレスから配信されたものであっても、その文書が公開アドレスから配信されたものとして扱うようユーザーエージェントに指示する。すなわち、 これは非公開文書が、プリフライトなしで他の非公開文書に接続する権限を放棄できるようにする仕組みである。

このディレクティブの構文は、次の ABNF 文法で記述される:

directive-name  = "treat-as-public-address"
directive-value = ""

このディレクティブには報告要件はない。Content-Security-Policy-Report-Only ヘッダーで配信された場合、または <meta> 要素内で配信された場合は、完全に無視される。

このディレクティブの初期化アルゴリズムは次のとおりである。 環境設定オブジェクト (context)、 Response (response)、および policy が与えられたとする:

1. policy の disposition が「enforce」である場合、 context のポリシーコンテナーの IP address space を公開に設定する。

https://github.com/WICG/private-network-access/issues/88 では、 これを CSP ディレクティブから別の場所へ移すことが推奨された。

3. 統合

この節は非規範的である。

この文書は、上記で概説した保護を実装するため、他の仕様へのいくつかの変更を提案する。 これらの統合は明確さのためここで概説されるが、外部文書が規範的参照である。

3.1. Fetch との統合

この文書は [FETCH] へのいくつかの変更を提案し、それにより次が意味される: ローカルネットワークリクエスト は、その クライアントが セキュアコンテキスト であり、かつユーザーによって権限が付与されている場合にのみ許可される。 リクエストが混在コンテンツとしてブロックされるはずであった場合でも、ウェブサイトが ローカルネットワークへアクセスする意図を示し、ユーザーが権限を与える限り、許可できる。

注: これにはナビゲーションも含まれる。 それらは、サブリソースリクエストほど巧妙ではないとはいえ、CSRF 攻撃をトリガーするために 実際に使用できる。

Chromium は現在、 LNA 制限を iframe ナビゲーションにのみ適用している。 これをメインフレームナビゲーション（特に opener によって制御され得る ポップアップウィンドウ）に拡張する価値があるかもしれない。

注: [FETCH] は、DNS 解決の詳細を Fetch アルゴリズムにまだ統合していないが、 この仕様にとって十分な 接続を取得するアルゴリズムを 定義している。Local Network Access チェックは、新たに取得された接続に適用される。 Happy Eyeballs （[RFC6555]、[RFC8305]）などの複雑さを考えると、 これらのチェックは、IP アドレス空間の境界をまたぐ複数の IP アドレスを持つホストについて 非決定的に成功または失敗する可能性がある。

3.1.1. フェッチ

注: [FETCH] における接続管理は 意図的にやや曖昧であるため、以下の一部は実装者への注によって説明される。この節は、 実装者が接続を取得した後、ただしその接続を用いて fetch の実行を続行する前に、 ローカルネットワークアクセスチェックを実行することを示す。

wicg/local-network-access issue #103 に対処するには、代わりに 接続を取得するの Step 4.6 に統合し、 オリジンを解決した後、実際の接続が作成される前にチェックを実行する必要がある。

[FETCH] を次のように更新する:

1. Connection オブジェクトには新しい IP address プロパティが与えられる。その値は null または IP アドレスであり、 初期値は null である。

2. 接続を作成するアルゴリズムにおいて、新しい接続を確立した直後 （Step 2 と Step 3 の間）に新しいステップを追加する。

   1. host が IP アドレスである場合、 connection の IP address を host に設定する。

3. Request オブジェクトには新しい target IP address space プロパティが与えられ、初期値は null である。

4. Response オブジェクトには新しい IP address プロパティが与えられる。その値は null または IP アドレスであり、初期値は null である。

5. 新しい Local Network Access check アルゴリズムを定義する。 リクエスト request と IP アドレス address が与えられたとき:

   注: このアルゴリズムは IP アドレスを受け取るため、 HTTP-network fetch（そこでは 接続がある）または HTTP-network-or-cache fetch（そこでは保存された レスポンスがあり、 保存された IP アドレスを持つ）のいずれからも 呼び出すことができる。 ユーザーエージェントによってマッピングが動的に更新され得るため、これは意図的に 毎回 IP アドレス空間を再計算する。

   1. addressSpace を、address に対して IP アドレス空間を決定するアルゴリズムを 実行した結果とする。

   2. request の origin が potentially trustworthy origin であり、 request の current URL の origin が request の origin と same origin である場合、null を返す。

   3. request の policy container が null である場合、 null を返す。

      注: request の policy container が null である場合、 LNA チェックは request に適用されない。fetch アルゴリズムの利用者は、 request の client を、非 null の policy container を持つ environment settings object に設定し、 fetch に request の policy container をそれに応じて初期化させるか、 または request の policy container を直接 non-null 値に 設定するよう注意しなければならない。

   4. request の target IP address space が null でない場合:

      1. Assert: request の target IP address space は public ではない。

      2. addressSpace が request の target IP address space と等しくない場合、 ネットワークエラーを返す。

      3. null を返す。

   5. addressSpace が、request の policy container の IP address space より less public である場合:

      1. error を ネットワークエラーとする。

      2. request の client が セキュアコンテキストでない場合 （null である場合を含む）、error を返す。

      3. error の IP address プロパティを address に設定する。

      4. permissionName を、addressSpace が local である場合は "local-network"、 addressSpace が loopback である場合は "loopback-network" とする。

      5. settingsObject を request の client とする。

      6. global を settingsObject の global object とする。

      7. document を global の 関連付けられた Document とする。

      8. document が null である場合、error を返す。

         注: Service Workers は必ずしも 関連付けられた Document を持つとは限らないため、このステップにより Service Workers からのローカルネットワークリクエストは失敗する。 この仕様の将来バージョンでは、特に Permissions Policy が Workers で まだサポートされていないことから、Workers の扱いを定義する必要がある。 w3c/webappsec-permissions-policy#207 を参照。

         Service Workers に対するローカルネットワークアクセスの振る舞いを定義する。

      9. document が permissionName を 使用を許可されて いない場合、error を返す。

      10. permissionState を、permissionName と global が与えられたときの 現在の権限状態を取得する 結果とする。

      11. permissionState が denied である場合、 error を返す。

      12. permissionState が granted である場合、 null を返す。

      13. global について permissionName を付与するかどうかを ユーザーに選択させる:

          1. ユーザーが権限を付与した場合、null を返す。

          2. ユーザーが権限を拒否した場合、error を返す。

   6. null を返す。

6. fetch アルゴリズムは、request の policy container が設定された直後に、 2つの新しいステップを追加するよう修正される:

   1. request の target IP address space が null である場合:

      1. request の URL の host host が IP アドレス であり、host に対して IP アドレス空間を決定する アルゴリズムを実行した結果が local である場合、request の target IP address space を local に設定する。

      2. request の URL の host の public suffix が "local" である場合、request の target IP address space を local に設定する。

         注: request の URL の host が “localhost” または “127.0.0.1” である場合にも、target IP address space を local に設定することはできる （[LET-LOCALHOST-BE-LOCALHOST] のため）が、 loopback ケースはすでに potentially trustworthy とみなされ、混在コンテンツチェックを トリガーしないため、特別な処理は不要である。

         注: 明示的な targetAddressSpace が fetch() API によって設定されている場合にそれを優先するため、 ここでは target IP address space がすでに non-null である場合は設定しない。

7. HTTP-network fetch アルゴリズムは、新たに取得された connection が failure でないことを確認した直後に、3つの新しいステップを追加するよう 修正される:

   1. response の IP address を connection の IP address に設定する。

   2. localNetworkAccessCheckResult を、 fetchParams の request と connection の IP address について Local Network Access check を実行した結果とする。

   3. localNetworkAccessCheckResult が ネットワークエラーである場合、 localNetworkAccessCheckResult を返す。

8. HTTP-network-or-cache fetch アルゴリズムは、 Step 9 の直後に新しいステップを追加するよう修正される:

   1. response が null でない場合:

      1. localNetworkAccessCheckResult を、 request と response の IP address について Local Network Access check を実行した結果とする。

      2. localNetworkAccessCheckResult が ネットワークエラーである場合、 localNetworkAccessCheckResult を返す。

注: ローカルネットワークリクエストが セキュアコンテキストから行われる必要があるという要件は、そのリクエストが ローカルネットワークリクエストとみなせることを事前に知ることができない限り、 すべての非セキュアリクエストが混在コンテンツとしてブロックされることを意味する。 target IP address space プロパティを設定することで（上記の Step 6i と 6ii を参照）、 Mixed Content には小さな変更を加えるだけでよい — § 3.2 Mixed Content との統合を参照。

3.1.2. Fetch API

Fetch API も調整する必要がある。

• RequestInfo に任意の entry を追加する。その key は targetAddressSpace であり、value は IPAddressSpace である。

  partial dictionary RequestInit {
    IPAddressSpace targetAddressSpace;
  };
  

• 上記を表す新しい targetAddressSpace を request に定義する。

  partial interface Request {
    readonly attribute IPAddressSpace targetAddressSpace;
  };
  

• new Request(input, init) には、 this の request を request に設定する直前に、次のステップが追加される:

  1. init["targetAddressSpace"] が 存在する場合、 init["targetAddressSpace"] について switch する:

     public

     何もしない。

     local

     request の targetAddressSpace を local に設定する。

3.2. Mixed Content との統合

fetching request は mixed content としてブロックされるべきか? は、 次の条件を allowed 条件の1つに追加するよう修正される:

1. request の origin が potentially trustworthy origin ではなく、 request の target IP address space が local である。

「必要に応じて、 request を mixed content として a priori authenticated URL にアップグレードする」 アルゴリズムは、step 1 でのアップグレードからの例外として、次の条件を追加するよう修正される:

6. request のtarget IP address space が local である

3.3. WebSockets との統合

WebSockets 接続は、同じローカルネットワークアクセス権限要件の対象となるべきである。 WebSocket opening handshake は step 11 で fetch を直接適用するため、 上記で提案された fetch 変更を超える WebSocket 仕様への変更は不要である。

Fetch API と WebSockets API の小さな違いの1つは、 WebSockets には fetch の RequestInit に相当するものがないため、 ws:// URL の混在コンテンツチェックを迂回するための targetAddressSpace オプションを 入れる場所がないことである。

3.4. WebTransport との統合

WebTransport 接続は、同じローカルネットワークアクセス権限要件の対象となるべきである。

WebTransport 仕様への変更は不要である。WebTransport 仕様では、 WebTransport 接続を取得する ことが step 6 で接続を取得するために Fetch 仕様を参照しており、それは § 3.1.1 フェッチで修正されるためである

3.5. HTML との統合

[FETCH] におけるチェックを サポートするため、ユーザーエージェントはネットワークリクエストが行われるコンテキストの 送信元 IP アドレス空間を記憶しなければならない。このため、 [HTML] 仕様は次のように パッチされる:

1. 新しい IP address space プロパティが policy container struct に追加される。

   1. 初期値は public である。

2. policy container を複製するアルゴリズムに、追加のステップが加えられる:

   1. clone の IP address space を policyContainer の IP address space に設定する。

3. fetch response から policy container を 作成する アルゴリズムに、追加のステップが加えられる:

   1. result の IP address space を、response の IP address に対して IP アドレス空間を決定する アルゴリズムを実行した結果に設定する。

TODO: HTML § 7.1.4 Cross-origin embedder policies における Private Network Access への参照も更新する。

3.6. Workers との統合

この節は非規範的である。

WorkerGlobalScope はすでに、 policy container フィールドを持ち、 それは fetch response から policy container を 作成するアルゴリズムを使用して設定されるため、上記の Fetch および HTML との統合は 文書と同様に worker コンテキストにも適用される。

Chromium の実装は現在、 service worker が開始する fetch に対して、worker のスクリプトオリジンに基づいて LNA 権限を適用している（service worker の実行時にはアクティブな document が 存在しない場合があるため）。これは worker の partitioned storage key に基づく方が よいかもしれず、permissions policy が service workers をサポートするとよい。

Service Worker の soft update アルゴリズムは、更新されたスクリプトを fetch するとき、 残念ながら request client を "null" に設定する。 これはさまざまな問題を引き起こし、上記のローカルネットワークアクセスチェックアルゴリズムに 干渉する。実際、fetch の間に policy container をコピーする元となる request client が存在しない。wicg/private-network-access issue #83 を参照。

4. 実装上の考慮事項

4.1. File URL

file URL が上記で概説した public/local スキームにどのように適合するかは 完全には明らかでない。一方では、悪意ある HTML ファイルをローカルで開くことで 人々が自分自身を害することを防げるとよいが、他方では、ローカルで実行されるコードは 首尾一貫した脅威モデルの外側にある程度存在する。

当面は、file URL を local として扱う側に寄せることにする。これは、 それらが loopback address 上のあらゆるものと同じくらいローカルシステムの一部であるように 見えるためである。

実装経験の後にこれを再評価する。

4.2. プロキシ

Chromium におけるこの仕様の現在の実装では、プロキシはそれらがプロキシするリソースの アドレス空間に影響する。具体的には、プロキシ経由で fetch されたリソースは、 プロキシ自身の IP アドレスから fetch されたものとみなされる。

public address 上の foo.example によって提供される Document が、local address 上のプロキシを介して ユーザーエージェントによって fetch された場合、その Document の policy container の IP address space は local に設定される。

その Document は、ブラウザーからアクセス可能な他の local address へ リクエストを行うことが許可されるようになる。

これにより、ウェブサイトは local address へリクエストできることを観測することで、 自分がプロキシされたことを知ることができ、これはプライバシー情報の漏えいである。 ただし、これはローカルネットワーク上のリソースの URL を正しく推測する必要があるが、 1つでも正しい推測があれば十分である。

これは比較的まれであり、さらなる緩和策を正当化しないと予想される。 結局のところ、現状ではすべてのウェブサイトが制限なしにすべての IP アドレスへ リクエストできる。

プロキシが「このリソースを public/local として扱ってください」とブラウザーに伝え、 それによってプロキシの背後にある IP アドレスに関する情報を渡すことができる仕組みを 探るのは興味深いだろう。

4.3. HTTP キャッシュ

HTTP キャッシュからのレスポンスは、上記の § 3.1 Fetch との統合で 規定されているように Local Network Access チェックの対象となる。以下では、キャッシュから読み込まれるリソースの種類に応じて、 それらのチェックが実際にどのように機能するかについて、いくつかの追加詳細 （例を含む）を示す。

4.3.1. メインリソース

キャッシュされた response から構築された document は、その response が最初に読み込まれた IP アドレスを 記憶する。その document の IP アドレス空間は、その IP アドレスから新たに導出される。

一般的な場合、これは document の policy container の IP アドレス空間が変更されずに復元されることを意味する。しかし、ユーザーエージェントの 設定が変更された場合、導出される IP アドレス空間は異なる可能性がある。

4.3.2. サブリソース

メインリソースと同様、キャッシュされたレスポンスから構築されたサブリソースは、 そのレスポンスが最初に読み込まれた IP アドレスを記憶する。レスポンスの IP アドレス空間は、その IP アドレスから新たに導出される。

一般的な場合、これはレスポンスの IP アドレス空間が変更されずに復元されることを 意味する。しかし、ユーザーエージェントの設定が変更された場合、導出される IP アドレス空間は異なる可能性がある。

サブリソースリクエストが LNA チェックによってブロックされる場合（すなわち、権限が 拒否された場合）、キャッシュされるリソースレスポンスは存在しない。権限が後で リセットまたは付与された場合、サブリソースリクエストはネットワークへ行く。

セキュリティ上の含意についての議論は § 5.6 HTTP キャッシュを参照。

4.4. 展開上の困難

Local Network Access は本質的に、ローカルネットワークへの直接アクセスを非推奨にし、 より安全なユーザーエージェント仲介型の代替手段を優先する。Web の非推奨化は難しい。 Chromium は以前、[PRIVATE-NETWORK-ACCESS]（この仕様の前身）の一部を 出荷する過程で多くの障害に遭遇した。

特に、ローカル IP アドレス空間内の 非セキュアコンテキストから localhost 上のサービスへの fetch に制限を出荷することは、より低い見返りに対して特に困難であることが判明している。 実際、そのような fetch を悪用するには、攻撃者はすでにプライベートネットワーク内に足がかりを 持っている必要があり、これは攻撃の難易度を大幅に高める。その結果、Chromium は これらの fetch を一時的に制限から除外し、パブリック IP アドレス空間からの fetch に集中することを 選択している。セキュリティ上の含意については § 5.5 ローカルネットワーク攻撃者を参照。

5. セキュリティとプライバシーに関する考慮事項

5.1. ユーザー仲介

この文書の提案は、パブリックインターネットからのアクセスに対してユーザーが同意することのみを 保証する。この提案は、デバイスがパブリックインターネットからの接続を 明示的に承認することを可能にしない。

デバイスがパブリックインターネットからの接続を明示的に承認しなければならない 代替モデルは、[PRIVATE-NETWORK-ACCESS] で試みられたが、 展開上の困難に直面した。

対象エンドポイントが接続にオプトインするかどうかにかかわらず、ユーザー仲介を要求することは、 ローカルエンドポイントとリモートウェブサイトが結託してユーザー ID を結び付ける "Local Mess" 追跡手法のようなプライバシー問題の 緩和にも役立つ。

5.2. DNS リバインディング

ここで説明する緩和策は、特定のリソースを読み込むときにユーザーエージェントが 実際に接続する IP アドレスに基づいて動作する。このチェックは、新しい接続が 行われるたびに実行されなければならない。そうしないと、DNS リバインディング攻撃により、 ユーザーエージェントが開示すべきでない情報を明らかにしてしまう可能性がある。

DNS リバインディング攻撃は、ローカルネットワークアクセスチェックがすべての public から local へのリクエストに適用されなければならないことも意味する （すなわち、アルゴリズムを「local エンドポイントへの任意のクロスオリジンリクエスト」 に単純化することはできない。そうすると、ユーザーが a.example へナビゲートした後、 ネットワークを移動したり DNS が変更されたりして a.example が local address を指すようになる リスクが生じるためである）。

5.3. 緩和の範囲

この文書の提案は、ローカル Web サービスに対する攻撃を単に緩和するだけであり、 それらを完全に解決することはできない。たとえば、ルーターの Web ベースの管理インターフェイスは、 自ら CSRF に対して防御するよう設計および実装されなければならず、 この文書で規定されるように振る舞う UA に依存すべきではない。この文書が規定する緩和策は、 今日のローカル Web サービス実装品質の現実を考えると必要であるが、すべての UA が この緩和策を実装したとしても、ベンダーは自らの責任を免れたと考えるべきではない。

5.4. クロスネットワーク混乱

ほとんどのローカルネットワークは互いに通信できないが、この仕様ではそれらすべてが local IP アドレス空間に属するものとして扱われる。さらに、local address は それが使用されるローカルネットワーク上でのみ意味を持つ。同じ IP アドレスが、 2つの異なるネットワークではまったく異なるデバイスを指す可能性がある。 ユーザーが a.example にローカルネットワークリクエストを行う権限を付与した後、 別のネットワークへ移動すると、a.example は引き続きローカルネットワークリクエストを 行えることになる。

これはクロスネットワーク攻撃への道を開く:

• ユーザーが2つの異なるローカルネットワーク、すなわち自宅 Wi-Fi ネットワークと 企業 VPN に接続する。彼らのスマート冷蔵庫がハッキングされている。彼らが スマート冷蔵庫の Web インターフェイスを開くと、それが VPN 経由でアクセス可能な 企業ウェブサイトに対して CSRF 攻撃を実行する。

• ユーザーが、ユーザーにキャプティブポータルページを開いたままにすることを要求する 悪意あるインターネットカフェ Wi-Fi に接続する。彼らはラップトップを閉じて帰宅し、 もう一度ラップトップを開く。キャプティブポータルページ（まだ開いているか、 ユーザーエージェントが以前の状態を復元するときにキャッシュから再読み込みされる）が CSRF

• ユーザーの自宅デバイスに対する攻撃を実行する。

• ユーザーが悪意あるインターネットカフェ Wi-Fi に接続し、そのキャプティブポータル ウェブサイトが http://router.example/popular-library.js から悪意あるスクリプトを 非常に長い有効期限でキャッシュする（カフェのネットワーク管理者は悪意ある DNS サーバーを 運用している）。ユーザーはコンピューターの電源を切って帰宅し、再びコンピューターを起動して http://router.example にあるルーターの管理インターフェイスを訪問する。その管理インターフェイスは /popular-library.js を埋め込む。悪意あるスクリプトは、管理インターフェイスの ファーストパーティコンテキストで読み込まれる。

これらの攻撃はいずれも新しいものではない。これらはこの仕様の限界の例にすぎない。

潜在的な緩和策には、 ネットワーク変更を検知し、以前のネットワークに固有の状態を消去することが必要になる。 これを完全に一般的な方法で行うことは、すべての状態を消去する以外にはおそらく不可能である。 実用的な妥協点に到達できるかもしれない。 wicg/private-network-access issue #28 を参照。

代替アプローチは、権限付与を異なるネットワークを区別する識別子にスコープすることかもしれない。

5.5. ローカルネットワーク攻撃者

ローカルネットワークアクセスチェックが local アドレス空間へのすべての クロスオリジンリクエストに適用されるまで、ローカルネットワーク上の悪意あるサーバーが (1) ローカルネットワーク上の他のサーバーを攻撃し、(2) ユーザーのマシン上の localhost で実行されているサービスを攻撃することが可能である。(1) は ユーザーのブラウザーを悪用する必要なしにすでに可能であるが、(2) は依然として懸念である。 たとえば、キャプティブポータルは、ユーザーを悪意あるページへリダイレクトし、 ユーザーのマシン上で実行されている脆弱な localhost サービスをプローブおよび 攻撃しようとする可能性がある。（wicg/private-network-accesss issue #39 も参照。）

私たちは、ドライブバイ Web 上のパブリックウェブサイトを、より緊急のセキュリティ （およびプライバシー）リスクと見なしており、ローカルネットワーク攻撃者からのリスクが 残るにもかかわらず、これらの保護を段階的に展開することは価値ある進歩であると考えている。

5.6. HTTP キャッシュ

5.6.1. チェックをサブリソースに適用する

キャッシュされたサブリソースは、この仕様によって保護される。HTTP キャッシュは ソース IP アドレスを記憶しており、それは HTTP-network-or-cache fetch 中の Local Network Access チェックアルゴリズムで使用できるためである。

このチェックがなければ、悪意あるパブリックウェブサイトは、ユーザーが過去に特定の プライベートウェブサイトを訪問したかどうかを判断できる可能性がある。

HTTP キャッシュのパーティショニングにより、サブリソースは、そのキャッシュエントリの network partition key を再現できた悪意ある攻撃者によってのみキャッシュから読み込まれる。 攻撃者がこれを達成する方法の1つは、DNS を操作し（§ 5.2 DNS リバインディングも 参照）、キャッシュされたリソースを最初に埋め込んだトップレベルサイトになりすますことである。

ユーザーエージェントは http://router.example へナビゲートし、それは 192.168.1.1 から提供される。ウェブサイトは http://router.example/$BRAND-logo.png からロゴを埋め込み、それがキャッシュされる。

その後、悪意ある攻撃者が router.example を攻撃者が制御する public IP アドレスへ再バインドし、何らかの方法でユーザーを再び http://router.example へ訪問させる。悪意あるウェブサイトはロゴを埋め込もうとし、 読み込みが成功するかどうかを監視する。成功した場合、攻撃者はユーザーのルーターの ブランドを特定したことになる。

5.6.2. HTTP キャッシュポイズニング

この仕様は、ローカルネットワークサーバーがパブリックウェブサイトからリクエストを受け取ることを 保護することを目的としているが、DNS リバインディングは、認証されていないリソースの キャッシュポイズニングを通じて類似の攻撃を実行するために使用できる。

http://router.com になりすました攻撃者は、 http://router.com/totally-legit.js に悪意あるスクリプトをキャッシュできる。 後でユーザーが http://router.com/ へナビゲートすると、そのページは汚染されたスクリプトを リクエストし、攻撃者のコードを less public な IP アドレス空間で実行する可能性がある。

この攻撃は、キャッシュパーティショニングによって部分的に緩和される。これにより、 攻撃者はリソースをキャッシュする前にトップレベル閲覧コンテキストを http://router.com/ へナビゲートしなければならず、それは巧妙さに欠ける。 また、これは Local Network Access に固有のものではなく、むしろ平文 HTTP に 認証と完全性保護がないことの症状である。

6. 謝辞

元の Private Network Access の提案と仕様に取り組み、その作業について寛大に議論し、 今後の道筋をブレインストーミングする手助けをしてくれた Titouan Rigoudy、Jonathan Hao、および Yifan Luo からの貴重なフィードバックと助言に深く感謝する。