Google Chrome の新機能のテストが開始：プライベート・ネットワークへの攻撃をブロック

New Google Chrome feature blocks attacks against home networks

2024/02/17 BleepingComputer — Google Chrome の新機能のテストが始まった。その機能というのは、悪意の Web サイトがユーザーのブラウザを経由して、内部プライベート・ネットワーク上のデバイスやサービスを攻撃するのを防ぐためのものだ。簡単に言うと Google は、インターネット上の悪質な Web サイトを訪問したユーザーの、自宅やコンピュータ上のデバイスが、攻撃されることを防ごうと計画しているのだ。一般的に、これらのデバイスは、インターネットにはダイレクトに接続されておらず、ルーターにより保護されているため、安全だと考えられている。

この新機能について Google は、「ユーザー・エージェントのネットワークを経由した、悪意の Web サイトからの、デバイスやサービスへの攻撃を阻止する。つまり、ユーザーのローカル・イントラネットやマシンに存在するデバイスなどは、インターネットからはアクセスできないと合理的に想定されている」と、サポート文書で詳述している。

内部ネットワークへの安全でないリクエストをブロックする

Chrome の新機能 “Private Network Access Protections” は、Chrome 123 から “warning-only” モードとして導入される。そして、ある Web サイト (以下 “site A”) が、ユーザーのプライベート・ネットワーク内の別のサイト (“site B”) へのアクセスを、Web ブラウザに指示する前にチェックが行われる。

ここで実施されるチェックは、リクエストのコンテキストにおける安全性の確認である。さらに、送信元のWeb サイトからのアクセスの許可について、CORS-preflight リクエストと呼ばれる特定のリクエストを通じて、Site B  (ループバック・アドレスやルーターの Web パネル上で動作する HTTP サーバなど) が判断するための、予備リクエストの送信なども行われる。

この機能は、潜在的な脅威からユーザーのプライベート・ネットワークを保護することを主目的とした、サブリソースやワーカーに対する既存の保護機能とは異なるものであり、ナビゲーション・リクエストに特化している。

Google が挙げた例では、訪問者のローカルネットワーク上のルーターの、DNS 設定を変更するために CSRF 攻撃を実行する、悪意の Web サイト上の HTML iframe が紹介されている。

<iframe href="https://admin:admin@router.local/set_dns?server1=123.123.123.123">
</iframe>

この新機能では、公開サイトから内部デバイスへの接続が施行されたことを、Web ブラウザが検知すると、そのデバイスに対して CORS-preflight リクエストが送信される。

応答がない場合には、この接続はブロックされるが、内部デバイスが応答した場合には、”Access-Control-Request-Private-Network” ヘッダーを使用することで、リクエストを許可すべきかどうかが Web ブラウザに伝えられる。

それにより、オープンな Web サイトからの接続を、内部ネットワーク上のデバイスが明示的に許可しない限り、対象となるデバイスへのリクエストは自動的にブロックされる。

警告のステージでは、チェックに失敗してもリクエストはブロックされない。その代わりに、開発者の DevTools コンソールに警告が表示され、より厳格な運用が始まる前の調整の時間が与えられる。

しかし Google が警告しているのは、たとえリクエストがブロックされたとしても、Web ブラウザによる自動再読み込みは、内部から内部への接続とみなされるため、リクエストを通過させてしまうという点だ。

Google は、「プライベート・ネットワーク・アクセスの保護は、よりパブリックな Web ページからユーザーのプライベート・ネットワークを保護するために設計されているため、この場合は適用されない」と述べている。

それを防ぐために Google が推奨するのは、プライベート・ネットワーク・アクセス機能が、対象となるページを以前にブロックしていた場合には、そのページの自動リロードをブロックすることである。

こういった場合、 Web ブラウザでは、手動でページを再読み込みすることでリクエストを許可するという、以下のようなエラー・メッセージが表示される。このような状況において Web ブラウザは、次に示すエラー メッセージを表示して、そのページを手動でリロードすることで、リクエストの通過を許可できることを示唆する。

このページには、Google Chrome の新しいエラー・メッセージである “BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS” が表示される。このメッセージが知らせるのは、Private Network Access のセキュリティ・チェックを通過しなかったことで、そのページが読み込めないことである。

セキュリティ・アップグレードの背景

この新機能の開発の目的は、安全だと思われていたユーザーの内部ネットワーク内のデバイスやサーバの脆弱性を、インターネット上の悪意の Web サイトが攻撃するという、オンライン・ベースの脅威を排除するところにある。

そこに含まれるものとしては、ユーザーのルーターや、ローカル・デバイス上で動作するソフトウェア・インターフェイスへの不正アクセスからの保護もある。

Google のサポート文書によると、プライベート・ネットワーク (localhost またはプライベート IP アドレス) 内のリソースに対する、外部の Web サイトからの有害なリクエストを防ぐために、このアイデアの検討を、2021年から開始したようだ。

当面の目標は、”SOHO Pharming” 攻撃や CSRF (Cross-Site Request Forgery) 脆弱性などのリスクを軽減することだが、この機能は、ローカル・サービスの HTTPS 接続は保護の対象としていない。

Chrome 123 から、この機能が入ってくるようなので、とても楽しみです。なんというか、良さそうなことが書かれているけど、訳す方はタイヘンという記事でした。いくつかのソース・リンクを埋め込んでいますが、いつものように整理された、Google のドキュメントが有るわけではないので、筆者の Mayank Parmar さんも、かなり苦労して書き上げたのではないかと思っています。同じく 2月17日にポストされた、「Google Magika がオープンソース化：AI でファイルの安全性を識別」も、よろしければ、ご参照ください。