セキュリティキーハックが明らかにする隠れた WebUSB 論争:ブラウザアクセスとセキュリティ懸念の対立

BigGo Editorial Team
セキュリティキーハックが明らかにする隠れた WebUSB 論争:ブラウザアクセスとセキュリティ懸念の対立

ある開発者が、U2Fセキュリティキーをエミュレートすることで、 Firefox の WebUSB 制限をバイパスする方法を実証し、ブラウザのハードウェアアクセス機能に関する議論が再燃しています。この実証実験では、 Raspberry Pi Pico をプログラムして、 Firefox が WebUSB をサポートしていないにもかかわらず、ウェブページと通信できることを示しており、現代のブラウザにおける機能性とセキュリティのバランスの複雑さを浮き彫りにしています。

このハックは、 Firefox が WebUSB をサポートしていないものの、U2Fセキュリティキーはサポートしているという事実を利用しています。開発者はマイクロコントローラをプログラムしてセキュリティキーのふりをさせ、U2F認証メッセージのキーハンドルと署名フィールドを通じて任意のデータを密かに送信することで、バックドア通信チャネルを作成しました。これにより、明示的な WebUSB サポートなしでも、ウェブサイトがデバイス上の LED などのハードウェアを制御することが可能になります。

WebUSB の分断: Chrome 対 Firefox と Safari

コメントを見ると、 WebUSB サポートに関してテクノロジーコミュニティに深い分断があることが分かります。 Chrome (および Chromium ベースのブラウザ)は WebUSB をサポートしていますが、 Firefox と Safari は意図的にこれを実装していません。これは単なる技術的な違いではなく、ブラウザのセキュリティモデルに関する根本的な哲学の違いを反映しています。

Mozilla と Apple は、プライバシーとセキュリティの観点から WebUSB を拒否しており、USBデバイスは潜在的に悪意のある相互作用を処理するように設計されておらず、有意義なユーザー同意を得ることが難しいと主張しています。 Google のアプローチは、許可プロンプトとデバイスブロックリストを使用して機能を実装することであり、特に FIDO/U2F キーなどのセキュリティに敏感なデバイスに対して注意を払っています。

主要ブラウザによる WebUSB サポート

  • Chrome/Chromium: 完全サポート
  • Firefox: サポートなし(セキュリティとプライバシーの懸念)
  • Safari: サポートなし(セキュリティとプライバシーの懸念)

よく言及される WebUSB の使用例

  • ESP32 やその他のマイクロコントローラーへのファームウェアの書き込み
  • プログラム可能なキーボードの設定
  • Stadia コントローラーなどのハードウェアの更新
  • ラベルプリンターの管理
  • MiniDisc レコーダーなどの特殊なハードウェアのサポート

セキュリティ上の懸念

  • USB デバイスは敵対的な入力に対して設計されていない
  • 有意義なユーザー同意を得ることの難しさ
  • デバイスフィンガープリンティングの可能性
  • WebUSB プロンプトとセキュリティキープロンプトの類似性
  • 許可の混乱によるフィッシング攻撃のリスク

実際のユースケースとセキュリティ懸念

多くの開発者や趣味のユーザーにとって、 WebUSB は大きな実用的なメリットを提供します。キーボードのブラウザベース設定、ESP32などのマイクロコントローラへのファームウェアの書き込み、プラットフォーム固有のソフトウェアをインストールせずにデバイスをプログラミングすることが可能になります。これらの機能のユーザーは、従来のネイティブアプリケーションを必要とする方法と比較して、その体験を「魔法のよう」と表現しています。

しかし、セキュリティの専門家は、USBデバイスをウェブサイトに公開することの潜在的なリスクについて警告しています。USBプロトコルはウェブセキュリティを念頭に設計されておらず、多くのデバイスは悪意のある入力に対する保護が不足しています。また、USBデバイス識別子を通じたフィンガープリンティングやトラッキングに関する懸念もあります。

「誰もがブラウザが安全なサンドボックスであり、ユーザーが信頼できないコードを実行できることを喜んでいます。なぜ人々がサンドボックスに多くの穴を開けたいのか理解できません。」

より広い問題:ブラウザは何をすべきか?

この議論は、ウェブブラウザの役割に関する根本的な問題に触れています。ブラウザは限られた機能を持つ最小限のドキュメントビューアであるべきか、それともシステムリソースへのアクセスを持つ包括的なアプリケーションプラットフォームに進化すべきか?

多くのコメント投稿者は、 WebUSB の代替手段は多くの場合、ネイティブアプリケーションをダウンロードしてインストールすることであり、それらは通常、ブラウザよりも広範なシステムアクセスと少ないセキュリティ制限を持っていると指摘しています。一方で、一般的なユーザーは WebUSB 機能をほとんど必要としないため、より広い人口に対して追加のセキュリティリスクを負うことは疑問視されています。

また、この議論は有意義な同意を提供する許可システムの設計の難しさも浮き彫りにしています。多くのユーザーは、特に正当な認証リクエストと似たプロンプトの場合、その意味を完全に理解せずに許可プロンプトをクリックしてしまいます。

ブラウザが進化し続ける中で、機能の拡張とセキュリティの維持の間のこの緊張関係は、ウェブプラットフォーム開発の中心に残り続けるでしょう。この記事で紹介された創造的なハックは、開発者の独創性とブラウザベンダーが対処しなければならない複雑なセキュリティ考慮事項の両方を示しています。

参考: Update: Hi HN et al.!