+コメントW3C は、結局ほとんど使われない API 標準を導入し、コード ベースに脆弱性を積み込むだけになってしまいます。
これは、来週ダラスで開催される ACM のコンピューターおよび通信セキュリティ会議で発表される、イリノイ大学シカゴ校の研究者による論文の結論です。
Chrome 56 に Bluetooth スニッチ API がひっそりと追加されました
続きを読む
arXiv で公開されている研究「ほとんどのウェブサイトは振動する必要はない: ブラウザのセキュリティを向上させるための費用対効果の高いアプローチ」は Firefox に焦点を当てていますが、その研究結果は全般に当てはまります。
コンピュータサイエンスの大学院生ピーター・スナイダー氏と同僚のシンシア・テイラー氏、クリス・カニッチ氏は、ブラウザ開発者が対処しなければならない74ものAPIの存在に関する費用対効果分析として論文を構成しています。費用対効果の面では、ある機能を利用するウェブサイトの割合（つまりブラウザのサポートが重要になる）を測定し、費用対効果の面では、ある機能がもたらすセキュリティリスクを測定しようとしました。
「コスト」側では、機能に関連付けられている過去の CVE の数 (これは API を安全にコード化することが難しいことを示唆しているため) や、機能に関連付けられている API エントリ ポイントとコード行の数 (これはコードが複雑であることを示すため) など、いくつかの特性を考慮します。
彼らの目玉となる発見はブラウザの作者を震え上がらせるはずだ。
「74の標準のうち15をブロックすることで、以前のCVEに関連するコードパスの52.0%と、当社の指標で特定された実装コードの50.0%を回避でき、測定対象のウェブサイトの94.7%の機能には影響しません。」
Mitre CVE (Common Vulnerabilities and Exposures) データベースを検索した結果、2010 年以降の Firefox の CVE が 1,554 件見つかりました。これは十分なサンプル数です (Chrome では同時期に 1,523 件)。そのうち 175 件は 39 個の Web API の実装に関連し、13 件は複数の標準に関連しています。
研究者たちは、リスク測定に基づいて API をブロックするブラウザ拡張機能を作成しましたが、結果は次のようになりました。
危険な API をブロックしても、Web サイトが壊れることはほとんどありませんが、
ユーザーのセキュリティは強化されます。
+コメント
この結果はVulture Southにとってさほど意外なことではない。過去 2 年間、私たちは広告主のためにユーザーのプロファイルを作成する以外の目的を持たない API のプライバシーへの影響にますます関心を寄せてきたからだ。
AppleとMozilla、W3Cのバッテリー監視標準を枯渇させるためAPIを廃止
続きを読む
例としては、プライバシーの懸念から Apple と Mozilla が廃止した Web Battery API、Bluetooth API、スマート クッキーが電話のロック解除コードを盗み見るために使用するモーション センサー API、危険な周囲光感知 API などがあります (これらのほとんどは、セキュリティ研究者の Lukasz Olejnik 氏のおかげです)。
これは、W3C がインターネット アーキテクチャ委員会のやり方に倣い、ユーザー保護を後付けではなくその使命の一部にする必要がある、もう一つの理由です。®
