分析： Googleのエンジニアたちは今月、軽いPR攻勢の中で、Chromeブラウザ拡張機能の刷新によって広告ブロッカーが消滅するわけではないと主張した。しかし、Googleのエンジニアたちはプラグインの安全性向上に取り組んでいるという。エンジニアたちの仕事は、見た目以上に多岐にわたるようだ。
ウェブ広告ブロッカーがもたらす収益への脅威に関する Google の公開文書や、モバイル アプリの広告への干渉を制限するために同社が Google Play ストアで講じた措置をひとまず脇に置いておくと、このインターネットの巨人には Chrome 拡張機能のエコシステムを徹底的に見直す理由がある。なぜなら、それがトランプのトランプタワーのように脆弱だからだ。
Googleは、2018年初頭以降、悪質な拡張機能のインストールが89パーセント減少したと指摘し、この状況に対処していると主張している。しかし、このテクノロジー界の巨人である同社のプログラマーたちは、依然として根本的な原因、つまりガードレールの少ないプラットフォームの問題に取り組んでいる。
Chrome拡張機能は、開発者とユーザーにとって明らかな有用性を持っています。プライバシーを強化し、機能を追加し、ウェブブラウジング体験を向上させることができます。しかし、あまりにも強力であるため、悪用される可能性が高く、GoogleがChromeウェブストアに導入しているセキュリティプロセスは万全ではありません。
Google：広告ブロッカーを廃止するつもりはありません。つまり、強力にしすぎたので、この魔神を瓶に戻します。
続きを読む
主な問題は、Chrome拡張機能がブラウザのセキュリティモデルを無効化し、機密データを取得できることです。この問題について詳しく説明してくれた読者は、Chrome拡張機能がどれほど制約のないものであるかを人々が本当に理解していれば、CVEスコア10.0を付与し、企業から排除すべきだと示唆しました。
この混乱の中心にある API、特にwebRequestAPI のブロック機能は、非常に便利なため、保留中のプラットフォーム改修が完了した後も引き続き企業が利用できることを考えると、これは多少誇張されているかもしれません。
uBlock Origin の開発者である Raymond Hill 氏は、この説明に異議を唱え、ヘッダーを変更する機能は本質的に API の設計の一部でありwebRequest、見落としではないと述べています。
「拡張機能はオプトインであり、拡張機能のインストールを選択したユーザーには拡張機能の機能が公開されているため、CVEの問題は発生しません」と彼はThe Registerへの電子メールで述べた。
しかし、Googleのプラットフォーム設計上の決定はセキュリティに影響を及ぼします。Mozillaも同様です。FirefoxもwebRequestアドオン（拡張機能）用のAPIをサポートしているからです。
昨年 10 月に開催されたカナダのセキュリティ カンファレンス SecTor で、偶然にも Google が Chrome 拡張機能の改訂計画 (Manifest v3 として知られている) を発表したのと同じ月に、GoSecure のセキュリティ アプリケーション開発者である Lilly Chalupowski 氏が「The Chrome Crusader」というプレゼンテーションを行いました。
セキュリティが剥奪される
Chalupowski氏は、Chrome拡張機能がウェブサイトとのやり取りからセキュリティヘッダーを含むHTTPヘッダーを削除する機能を備えていることを実証しました。その結果、ブラウザの同一オリジンセキュリティモデルを破る拡張機能を作成するのは容易になりました。
彼女はThe Registerとの電話インタビューでこう語った。「インジェクションは機能です。」
「インジェクションが機能として備わっている場合、懸念し始めなければなりません」と Chalupowski 氏は言う。「特に、セキュア ヘッダーをオンザフライで修正し、文字通り望むものに変更する機能を引き渡す場合はなおさらです。」
デモの中で、Chalupowski 氏は、デモ用にローカルで実行されている Flask コマンド アンド コントロール サーバーと対話してオンライン バンキングの Web サイトからパスワードを盗む基本的な Chrome 拡張機能を作成する方法を示しました。
Google は悪質な拡張機能に目を光らせているが、Chalupowski 氏は悪意のあるユーザーが検出を逃れる方法をいくつか提案した。
Chalupowski 氏は GitHub に PoC コードを掲載しています。The Register では、 PoC コードの最初の公開以降に Chrome に加えられた変更が機能に影響するかどうかはまだ判断していません。
「uBlock Originをはじめとするいくつかのブラウザは、セキュリティの観点から、この機能をヘッダーの改ざんに利用しています」と彼女は述べた。「同時に、ChromeやFirefoxでも同じ機能が悪意のある目的で利用されるでしょう。」
そして、そこに問題があります。善意の開発者は有益な拡張コードを作成できますが、悪意の開発者は同じ API を使用して信頼を悪用し、情報を盗むことができます。
2010年にAPIが開発されていた当時webRequest、プライバシーとセキュリティへの影響について多少の議論はありましたが、最優先事項ではありませんでした。設計書ではこの問題について簡単に触れられています。
Chrome拡張機能はかつてはもっとオープンでした。ヒルズ氏によると、2013年当時、Chrome拡張機能はwebRequestAPI経由で他の拡張機能のネットワークリクエストを確認できました。これは便利な機能でしたが、悪用される可能性もあったため削除されました。
Google はwebRequestリスクを軽減する必要があるかもしれないが、拡張機能を開発する人たちの間では、セキュリティの代償が効果のないコンテンツのブロックや標準以下のプライバシー制御ではないという希望がある。
ヒル氏は、GoogleはCORSヘッダーとCSPヘッダーの制限を緩和するために、よりきめ細かな権限モデルを実装すべきだと主張している。そうすれば、特定の機能を必要とする拡張機能は、機能の低いAPIに頼るのではなく、直接それらの機能を要求できるようになる。また、GooglewebRequestが既に一部のケースで行っているように、より広範なリクエストヘッダーへのAPIアクセスを拒否することも提案した。
「今のところ、ブラウザはブラウザ拡張機能が優れていると本質的に信じているだけです」とチャルポウスキー氏は述べた。「それを変えることは、ユーザーにとって良いニュースに他なりません」と彼女は述べた。
インストールするソフトウェアについて責任ある選択を行える開発者やユーザーにとっては、状況はもう少し複雑です。®
追加更新
月曜日のメールで、チャルポウスキー氏は、以前の概念実証が最新バージョンのChromiumでは動作しなくなったことを確認できたと述べました。クロスオリジン読み取りブロッキング（CORB）がリクエストをブロックしているように見えること、そしてヘッダーを削除するコードが動作していることを示すログエントリを生成しなくなったことを明らかにしました。これはStrict Site Isolationなどの機能の追加によるものか、それとも他の何かによるものかは不明だと彼女は述べています。
「それが機能していないという事実は良い兆候です」と彼女は言った。
