Report URIのセキュリティ研究者は、現在悪意のあるJavaScriptに感染している15,579の固有なウェブサイトを特定しました。これらのサイトは、控えめに見積もっても毎月1億3,500万回以上の訪問があると考えられています。研究者たちはこれらの感染を確認する証拠を手にしていますが、重大な物流上の障害に直面しています。それは、侵害されたサイトの量が、影響を受ける組織に通知する能力よりも速いスピードで増加していることです。研究者たちは、直接の顧客としてではなく自動化されたクロールを通じてこれらのサイトを特定するため、標準的な開示プロセスを開始するために必要な連絡先情報を欠いていることが多々あります。
この画像は、記事の核心的なテーマである、大量の感染に対して責任ある開示をスケールさせることの難しさを表しています。
Report URIによって特定された感染には、さまざまな高リスクのペイロードが含まれています。これらは、支払いページを標的にして財務情報を盗むMagecartとして一般に知られるクレジットカードスキマーから、ユーザーを騙してマルウェアをインストールさせるように設計されたClickFix攻撃まで多岐にわたります。その他の特定された脅威には、DarkSwordやCorunaといったスパイウェアなどのデバイスの悪用や、訪問者をフィッシングページや詐欺サイトに送る悪意のあるリダイレクトが含まれます。これらの感染は通常、WordPressのようなプラットフォームの直接的な侵害、サードパーティのスクリプトが乗っ取られるサプライチェーン感染、従来のクロスサイトスクリプティング（XSS）の脆弱性、および「DeadTag」攻撃という4つの主要な経路を通じてウェブサイトに入り込みます。DeadTagのシナリオでは、脅威グループはウェブサイトがいまだにスクリプトを読み込んでいる期限切れのドメインを購入して再開させ、それらを使用してマルウェアを配信します。
現在の修復におけるボトルネックは、スケーラブルな通知メカニズムの欠如です。研究者たちは影響の大きいサイトには連絡を取っていますが、そのプロセスはリソースを大量に消費し、返信がないことも頻繁にあります。セキュリティ連絡先情報を提供する標準である`security.txt`の採用率の低さが、自動化されたアウトリーチをさらに複雑にしています。これに対処するため、コミュニティの議論では、通知の負担をより大きなインフラプロバイダーに移行することが提案されています。潜在的な解決策には、主要なブラウザベンダーにドメインを報告して「赤い警告」ページをトリガーすること、Google Safe Browsingのブロックリストにデータを送信してトラフィックを遮断すること、または国家的なCERT（コンピュータ緊急対応チーム）と連携して地域的な通知を促進することなどが含まれます。しかし、研究者たちは現在、脅威を特定することと、所有者が修復のための行動をとることを保証することの間の乖離を埋めるための決定的な解決策を欠いています。