ユーザー自身のローカルネットワークにアクセスするサイトを制限する提案

 (github.com/explainers-by-googlers)
1 ポイント 投稿者 GN⁺ 2025-06-05 | 1件のコメント | WhatsAppで共有
  • Chrome セキュリティチームが、ウェブサイトのローカルネットワークアクセス問題を解決するため、新しい**「ローカルネットワークアクセス権限」**制度を提案
  • 現在は公開ウェブサイトがユーザーのプリンターなどのローカルネットワーク機器に無断でアクセス・攻撃できる可能性があるが、この提案はユーザーの許可なしにローカルネットワークリクエストをブロックすることを目指す
  • 既存の Private Network Access(PNA) とは異なり、preflight ではなくユーザーの権限同意を基盤として動作し、ユーザーの制御権を強化しつつ、機器の変更なしにサイト更新だけで対応可能
  • 具体的には、公開サイトがローカル IP、.local ドメインなどに fetch リクエストを送る際、権限がなければブラウザーがユーザーに明示的な同意要求を表示
  • このポリシーによりセキュリティ・プライバシーを強化すると同時に、IoT 機器の設定など正当なユースケースはユーザーの許可があれば正常動作を保証

提案の概要と目的

  • Chrome Secure Web and Network チームが、公開ウェブサイトによるローカルネットワークへの無断アクセス問題を解決するため、「ローカルネットワークアクセス」権限付与方式の初期設計案を公開
  • これまでは訪問したサイトが、ユーザーのプリンターやルーターなどのローカルネットワーク機器に対して CSRF や各種攻撃を試みる可能性があった
  • 今後は公開 IP → ローカル IPなど、アドレス空間の境界を越えるリクエストをブラウザーがブロックし、サイトごとに明示的なユーザー許可を得た場合にのみ許可する構造を提案

背景と相違点

  • 既存の Private Network Access(PNA) は preflight（事前リクエスト/レスポンス）ベースで、機器側にも変更が必要なため導入が難しかった
  • 今回の提案はユーザーの権限同意だけで処理でき、サイト側の小規模な修正だけで済むため、実際の適用と普及が容易

目標と非目標

  • 目標
    • ドライブバイ型のウェブ経由による脆弱な機器・サーバーの悪用を防止
    • ユーザーが望み許可した場合にのみ、公開ウェブサイトからローカル機器との通信を許可
  • 非目標
    • 既存のローカル機器設定・制御などの合理的な利用フロー全体を遮断することは避ける
    • ローカルネットワークにおける HTTPS 問題や複雑な証明書発行などは今回の提案範囲外

ユースケース

  • 1つ目: 一般ユーザーが望まない場合、example.com が 192.168.0.1 などへリクエストすると、ブラウザーが許可可否を確認し、拒否時はリクエストをブロック
  • 2つ目: IoT やルーターなど機器メーカーの公式ウェブ設定ページは、初回アクセス時にユーザーの許可を得て通信を許可

具体設計

  • アドレス空間の分離:
    • loopback（自分自身専用）、local（ローカルネットワーク内部）、public（誰でもアクセス可能）の 3 層としてIP ネットワーク層を分類
    • .local ドメイン、RFC1918/4193 のプライベート IP、RFC6762 のリンクローカル名など、さまざまなローカルネットワーク識別基準を含む
  • ローカルネットワークリクエスト: public→local、public→loopback、local→loopback など、より公開されたアドレスから内部ネットワークへアクセスする場合に権限を要求
    • 公開ネットワークからローカル/ループバックネットワークへのリクエストに加え、ローカルからループバックへのリクエストまでをローカルネットワークリクエストと見なす
    • 例外: local→local、loopback→任意のアドレスなどは制限対象ではない
  • 権限プロンプト:
    • サイトがローカルネットワークへリクエストする際、権限がなければブラウザーがユーザーに許可可否を尋ねるプロンプトを表示
    • 拒否時はリクエストをブロックし、承諾時はリクエストを続行
  • fetch API 統合: fetch 呼び出し時に targetAddressSpace: "local" などのオプションを明示し、明確に区別可能
    • Fetch 仕様は DNS 解決なしの単純な接続のみを定義しているため、新しい接続でローカルネットワークリクエストかどうかを判断
    • セキュアコンテキストでのみローカルネットワークリクエストを許可し、権限未取得ならプロンプト、権限付与時にリクエストを許可
    • fetch() の options に targetAddressSpace パラメーターを追加し、開発者が宛先アドレス空間を明示的に指定可能
    • 実際に接続されたアドレスがオプションの空間と異なる場合は、リクエスト失敗として処理し、mixed content の回避を防止
  • HTML、WebRTC、ServiceWorker などにも同一ポリシーを適用
    • HTML 文書/ワーカーにアドレス空間値を追加し、オリジンベースで空間を追跡
    • WebRTC 内の ICE Agent が候補を追加する際、ローカル/ループバックアドレスには権限プロンプトを使用
    • 権限は Permissions API と連携し、サイトが現在の権限状態をクエリー可能
    • 基本的に最上位文書でのみローカルネットワークアクセスが可能で、必要に応じて Permissions Policy の委任ポリシーで子フレームへ権限委任が可能
  • mixed content（HTTP/HTTPS）問題:
    • 非セキュアコンテキストでのローカルネットワークアクセス試行、HTTP ベースのサブリソース読み込み、mixed content ブロック適用シナリオなど
    • プライベート IP リテラル、.local ドメイン、targetAddressSpace 指定リクエストなどは mixed content のアップグレードおよびブロック段階を省略し、後続接続時に権限のないオリジンならブロック
  • 動作方式の例
    • 予期しないローカルネットワークアクセスが発生した場合、ユーザーは権限を拒否して無断リクエストを遮断できる
    • メーカーが運営する機器制御ページの場合、適切なプロパティ（例: targetAddressSpace="local"）で呼び出せば、ユーザー同意がある場合は従来どおり動作可能

代替案と議論

  • PNA 方式:
    • 従来の PNA はCORS プリフライトを要求していたが、実際の適用と配布の難しさが大きかった
    • 一部区間では権限プロンプトと mixed content 例外許可案も提案
    • DNS 問題、機器ごとの仕様未対応などにより現実的な限界が存在
  • すべてのローカルネットワークリクエストをブロック: 単純ではあるが、ユースケースの破壊や回避コスト増加の懸念から現実的ではない
  • 現状維持: OS がアプリごとにローカルネットワーク権限を管理し始めているため、ブラウザー層での管理必要性が強調される
  • mixed content の代替案:
    • 「セキュアなローカルネットワークサブリソースのみ許可」など、接続方法の安全性評価と実装負担が議論されている
    • レスポンスヘッダー/メタタグによるアドレス空間宣言、HTML 要素属性の追加なども代替案として議論

追加論点

  • HTML subresource（iframe、img など）にもアドレス空間属性を追加する可能性を議論
  • 権限付与時の過剰な権限伝播（transitivity）問題など、研究結果を反映
  • メインフレーム遷移時にローカルネットワークアクセスを制限する、または警告インタースティシャルを表示
  • ローカル/ループバックアドレス宛てのすべてのクロスオリジンリクエストを広くローカルネットワークリクエストと見なす案も検討
  • ネットワークごとに細分化された権限付与案の研究や、別ネットワークへの移動時（別の場所へ接続時）に再同意が必要かどうか

セキュリティ・プライバシー上の考慮事項

  • 権限を得たサイトは、ユーザーのネットワーク全体の機器に対する探索・接続権限が拡大する懸念
  • ユーザーはプロンプト承諾時に意図を明確に認識できる必要があり、preflight ベースよりも直接的な制御が可能
  • 事前権限なしではいかなるローカルネットワークリクエストも不可能であり、プライバシー保護の面でも強化される

関連記事

1件のコメント

 
GN⁺ 2025-06-05
Hacker Newsのコメント

  • 最初に見たとき、この機能を気に入った。そもそもWebサイトがローカルIP（あるいは任意のIP）にHTTPリクエストを投げられるという概念自体が、とんでもなく危険だと思う。これによって一部の企業向けアプリや統合機能が壊れるとしても気にしない立場で、企業は管理ツールでこの機能を再有効化すればいいし、一般ユーザーは自分で設定すればよいという意見。「このWebサイトはローカルデバイスを制御しようとしています - 許可/拒否」というポップアップを出すだけで十分だと主張

    • 誤解を含む見方だという指摘。ローカルネットワーク上のデバイスはCORSのおかげで任意のWebサイトから保護されており、完璧ではないにせよかなり有効な仕組みだという見解。問題は、CORSがターゲットサーバー側の同意のみに依存している点だと強調する。サーバーが特定のヘッダーでそのWebサイトからのアクセスを許可しなければならないからだ。今回の提案は、サーバーとWebサイトの双方が通信を望んでいたとしても、ユーザーの明示的な承認を必須にする形でさらに強化する趣旨。以前はサーバーとWebサイトの合意だけで十分だと考えられていたが、最近のFacebookのような事例では、Webサイトがスマートフォン内のアプリへ密かにアクセスすることでこの原則が崩れてしまったという意見。つまり、Webサイトとローカルネットワーク上のサーバーがユーザーの利益に反して動作できる現実を指摘している

    • 「一般ユーザーは自分でポップアップで許可/拒否を設定すればよい」という意見に対して、macOSは現在アプリごとにこうした権限要求を行っているが、ほとんどのユーザーは深く考えずに「許可」を押すと述べている。サイトごとにしたとしても警戒心が大幅に高まるわけではないだろうという推測

    • Webサイトがなぜローカルネットワークにアクセスする必要があるのか理解できないという内容。これはまったく新しいセキュリティ脅威モデルを作るだけだという主張で、そもそも他により良い解決策がないケースがあるのかも疑問視している

  • Apple、Microsoft、Googleなどにも、USBやBluetoothについて同様のアプローチを取ってほしいという意見。最近インストールするほぼすべてのアプリがBluetoothアクセス権を要求してきて非常に不快だと感じている。アプリがアクセス可能なBluetoothデバイスIDをmanifestに明記し、OS側でそのデバイスだけにアクセスを制限してほしいと望んでいる。たとえばBoseアプリはBose機器だけを見られるべきだという意見。アプリがどんな権限を求めているのか分からず拒否した経験があり、カメラやGPS権限のようにデバイスID登録とユーザープロンプトがあるとよいという考え。Boseならprefixをbose.xxxとして登録し、manifestではbose.*へのアクセスのみ要求し、OSがそのルールだけを許可するような形を想定している。USBやローカルネットワーク機器にも似たID体系を適用し、OSがアプリによるネットワーク、USB、Bluetoothの探索をできなくする方向を提案

    • いつかAppleでも、アプリに対して「偽の権限許可」オプションを提供してほしいという期待。たとえばアプリが連絡先一覧をどうしても必要だと言うとき、本物と見分けのつかないランダムな一覧を見せる方法。GPSでも同様のことを適用してほしい。WhatsAppは連絡先を共有しないと連絡先名を付けられないと聞いたことがあるという経験

    • GitHubのサードパーティアプリ連携のように、「ABCが自分のリポジトリを参照したがっています。どのリポジトリを共有しますか？」といった細かな選択権モデルを好む

  • Internet Explorerは昔、ゾーン分けシステムでこうした問題を解決していたという立場。詳細は MSドキュメント を参照との意見

    • 皮肉なことにChromeもWindows上では部分的にIEのゾーンセキュリティ体系を使っていたが、その公式ドキュメントはほとんどなかったという内容

    • この現代的な代替手段が存在しないのはばかげているという評価。ローカルネットワークアクセスもカメラやマイクのように、特別な権限でのみ許可されるべきだと考えている

  • Webブラウザがデフォルトでこうした行為を許していたという現実が信じがたい。公開Webサイトが自分のファイルシステム全体に密かにアクセスできると考えれば恐ろしいセキュリティ脆弱性なのに、ローカルネットワークサービスについてはXHRで普通に使えてしまい、安全性をサーバー設定だけに委ねている実態がある。開発者なら、自分の開発PC上でテスト用に社内Webアプリを動かしているとき（セキュリティ設定が非常に緩いか、まったくない場合）、facebook.comやgoogle.comなどから直接アクセス可能になる。家庭でもルーターのファイアウォールを信じて認証なしサービスを動かしている人は多いが、全員がCORS設定を正しくしているとは到底思えないという問題意識

    • 本当に誰もがCORS設定を正しくしているのかという懐疑。実際には未設定がほぼ0%に近いのではなく、設定されていないケースがほとんどだろうという主張

  • 今回の提案は、Metaが自社SDKを使ってネイティブアプリとWebサイトの間でlocalhostベースのトリックを用いて識別コードを共有するのを防ぐのに役立つかもしれないという期待。特にAndroidでの事例については 詳細はこちら

  • Webサイトがローカルネットワークにアクセスする権限そのものが非常に大雑把で、不必要に広すぎる許可だという指摘。実際に権限を必要とするサイトの大半は、たった1台のローカルサーバーにアクセスできればよいだけだ。すべてのローカルアクセスを許可するのは最小権限の原則に反する。ほとんどのユーザーはlocalhostやネットワーク上で何が動いているのか分かっておらず、危険性も十分に認識できないという問題提起

    • ほとんどの人はlocalhostやネットワーク上で何かが動いていること自体を知らないため、ブラウザがたとえば http://localhost:3146 や http://localhost:8089 への接続許可を求めても、それが何を意味するのか見当もつかない。技術用語ではなく、「このサイトはローカルネットワークリソースにアクセスしようとしています」のような直感的なメッセージのほうがユーザーにはよいという意見

    • きちんと実装するなら、実質的にブラウザ内ファイアウォール級の仕組みが必要で、どのCIDR、どのポート、といった細かな制御が可能なAPIがあるとよいという意見。ブラウザ拡張でもそうしたfirewall APIを使えたり、標準UIで特定のマシン（例: ルーター）、LAN、VPN、Windowsのprivate networkなどの範囲を明確に区別して、それぞれにアクセス権を求められるようになることを望んでいる

  • 以前はNPAPIプラグインが消えた後、複数の公開Webサイトがローカルソフトウェアと連携するにはlocalhostでHTTPサーバーを立てるしかない構造になったという点。もしこの使い勝手まで複雑にしてしまえば、非常に不便になるだろうという懸念。ブラウザ開発者はNPAPI以後に代替技術を用意すべきだったのに、今となってはもう遅いという主張

    • 大半のソフトウェアはOSレベルでプロトコルハンドラーを登録し、たとえばWebサイトが zoommtg:// のようなリンクを渡すと、ブラウザがZoomなどと連携する方式を好む。Jupyter Notebookのようにクロスオリジンリクエストなしでローカル利用するものは影響を受けない。OAuth2ログイン後にlocalhost URLへ送るケースも単なるリダイレクトなので問題ないだろうという見方

    • この方式（ローカルアプリとのHTTPサーバー経由の通信）が完全になくなるなら、そのほうがむしろよいという立場。セキュリティ脆弱性の温床になってきたという主張

    • Mozilla Native messaging のような技術はすでに存在しており、拡張機能のインストールは必要だが、NPAPIと比べれば公正な方法だという見方

    • もしローカルソフトウェアが「pull」方式（アプリが定期的に外部へリクエストする形）で動作するなら、わざわざサーバーを立てる必要はなくなる。副次的に、Webサイトが他人のローカルネットワークをあちこち勝手にスキャンすることもなくなるのでよいという意見

  • JavaScriptでcorsオプションなしにfetchやPOSTリクエストを投げると、CORSはレスポンスを読めなくするだけで、実際のリクエスト送信自体はブラウザが行う。もしローカルアプリがサーバー上のプロキシ経由でCORSヘッダーを追加できるようにすれば、どのサイトからでもJSのfetch/XMLHttpRequestでアクセス可能になる。拡張機能はヘッダーを書き換えてCORSを回避することもできる。ヘッダー操作でこうした回避が簡単すぎる一方、CSP（Content Security Policy）は実際には回避が非常に難しい、あるいはほぼ不可能だという指摘。Facebookアプリは今でも独自のCORSプロキシサーバーを動かしてこの構造を運用している。WebSocketもあるため、Chromeにlocalhostアクセス遮断フラグがあっても無意味だという主張。localhostを完全に遮断するのはむしろ害が大きい。多くのユーザーがself-hostedのブックマーク、ノート、パスワード管理アプリなどでローカルサーバーを活用しているため、こうしたケースを塞ぐのは不合理だとする

  • IPv6環境で問題が起きるのではという懸念。実際にIPv6アドレスが部分的にローカルかどうかを判定する方法があるのか疑問で、なければIPv6 onlyネットワークでは今回の提案が問題になると見ている。IoTアプリで同様の問題を経験し、IPv6アドレスがローカルか識別しづらいため、ひとまずIPv6はすべてIPv4ローカルへリダイレクトする方式を選んだという話。IPv6 link localも実際には一般アプリでは使いづらく、大きな意味はなかったという。.localドメインをローカルサーバーとして認めるのも扱いが難しく、OSごとに解釈が異なるため実装に一貫性がない。例として、Raspberry Pi OSでは some_address はmDNSで解決されるが someaddress.local はだめで、Ubuntu 24.04では someaddress.local だけが通り someaddress はだめ、someaddress.local. も動かないという。最後に、ローカルネットワークアドレスに対してプライベート証明書を使えない点も不満で、「ローカルアドレスに対するhttps制限」の問題も必ず解決すべきだと強調している

    • IPv6でも依然として「ルーティング可能」という概念は残っているため、論理的にはルーティングテーブル単位でsite-localかどうかを定義できるという意見。昔のIPv4では第2オクテットがsite、第3オクテットがVLANという構造だったが、IPv6にはもっと多くの選択肢がある。すべてのIPv6デバイスはlink localアドレスを持ち（ローカルVLAN）、.localはAppleやDNSなどの名前とアドレスの対応に関する用語であり、IPアドレスそのものとは直接関係しない。ローカルネットワークでのhttps証明書はLet's EncryptのDNS-01認証やCNAMEなどを使って取得可能で、かなり面倒ではあるが無料の方法は存在し、acme.shのようなツールも勧められている。IPv4、IPv6、DNS、mDNS、Bonjourなどの概念をより明確に整理する必要があるという話で、パケットキャプチャですら有料だった時代を思い出し、今はずいぶん良くなったと振り返っている

    • IPv6アドレスが「ローカル」かどうかをエンドポイント側で判別する方法はないという主張を明確化している。これはIPv6の原理がグローバルルーティングだからだという。記事中でもGoogleが「local」の意味を議論しているうちに途中で「private」の定義へと言い換えるなど混乱があったと指摘。HTTP拡張で非標準なCIDRベースのセキュリティ境界線を作るのは奇妙なアプローチであり、アプリは公開サービスであることを前提にセキュリティモデルを設計すべきだという立場。.localはmDNSの仕様に含まれているが、実際にはほとんど無視されているとも述べている

  • この方式が早く実現してほしいと心から願っている。特にHTTPSドメインからHTTPのローカルサイトへアクセスできる機能があることを期待しており、スマートホーム、メディア/エンターテインメントなどに素晴らしい活用例が多いと述べている