サードパーティJavaScriptスクリプトのセキュリティ上の懸念

SnykCon 2020でのウェブセキュリティに関する講演で、Liran TalとEric Grahamは、フロントエンドの攻撃対象領域に関するセキュリティ上の考慮事項について議論しました。サードパーティの依存関係に見つかったセキュリティ脆弱性に起因するリスクを説明したうえで、Google Tag Managerなど、マーケティング目的で追加されるサードパーティスクリプトにも潜在的なセキュリティリスクがあることを示しました。

この記事では、A/BテストサービスやGoogle Analyticsなど、マーケティング目的でウェブサイトに追加されるスクリプトによるセキュリティリスクを取り上げ、その軽減方法を紹介します。

Play Video: Securing Front-end Attack Surfaces - Eric Graham and Liran Tal

ウェブセキュリティにおけるサードパーティスクリプトのセキュリティ上の懸念とは？

その答えを探るため、Eric Grahamが動画で、ウェブアプリケーションや静的ウェブサイトにサードパーティのコードを追加する手順を詳しく解説します。さまざまなベンダーやオープンソースメンテナーに由来するソースコードが、どれほど広範に含まれているかを示します。

ご覧のとおり、顧客に提供するコード全体のうち、チームの開発者が書いたコードはほんの一部にすぎません。そこには、A/Bテストやユーザビリティテスト、ユーザーのセグメンテーションや販売ファネルの改善など、マーケティングや営業に関わる用途のスクリプトも含まれています。

サードパーティスクリプトは、どのように、そしてなぜウェブサイトに追加されるのでしょうか？

さらに問題なのは、こうしたスクリプトは多くの場合、マーケティング担当者やウェブマネージャーがソフトウェア開発ライフサイクルやCI/CDパイプラインの外で追加するため、開発者によるコードレビューやテストを完全に回避してしまうことです。これに使われるソフトウェアはタグマネージャーと呼ばれます。よく知られているのはGoogle（GTM）と、Launchを提供するAdobeです（LaunchはDynamic Tag Manager（DTM）の後継です）。

こうしたタグマネージャーはさらに別のスクリプトを読み込むため、異なるドメインへのHTTP接続がいっそう増えます。これらのドメインがハッキングされ、マルウェアを配布するために悪用される可能性もあります。つまり、マルバタイジングの領域に踏み込むことになります。

マーケターやアナリティクスエンジニアは、グロースハックやユーザーのセグメンテーション、販売ファネルの改善を目的として、ウェブサイトの機能を拡張するサードパーティJavaScriptスクリプトを日常的に利用しています。よく使われるのが、いわゆるGTMやAdobeのLaunchツールで、前身のDynamic Tag Manager（DTM）から大きく改良されています。

マーケティングパイプラインに大きなビジネスインパクトをもたらすため、プロダクトマーケティングやアナリティクスのチームは、こうした追加スクリプトをウェブサイトやウェブアプリケーションにすばやく導入し、試行錯誤することを優先します。

こうしたサードパーティのマーケティングスクリプトは、セキュリティレビューを受けているのでしょうか？

作業が終わったあと、ウェブアプリケーションからサードパーティスクリプトを削除することを、チームは忘れずにいるでしょうか。削除が保証されているとは限らず、見落とされることもあります。その結果、信頼できないコードを実行しているのに、そのことに気づかない可能性があります。

ウェブページに追加されるこうしたサードパーティJavaScriptスクリプトは、DevOpsパイプラインや、開発プロセスで定められたセキュリティプロセスやガイドラインを完全に迂回します。

さらに、サードパーティはDOMに直接コードを挿入するため、開発者が利用できるすべての機能にアクセスできます。これにより、顧客に大きな被害をもたらすおそれがあります。

メディアでは、ウェブアプリケーションにサードパーティJavaScriptスクリプトが悪意を持って挿入されたセキュリティインシデントが複数報じられています。さらに、ハッカーがウェブサイトのCSSファイルにウェブスキマーを隠す手口も報告されています。これ以前にも、ファビコン、ライブチャットメッセージ、ソーシャルメディア共有ボタンに仕込まれたMagecartスクリプトに関連するセキュリティインシデントが発生していました。

サードパーティJavaScriptのセキュリティ上の懸念に対処するには？

JavaScriptのセキュリティ上の懸念に対処するため、ウェブサイトのコードベースでサードパーティJavaScriptをより安全に利用し、セキュリティリスクを軽減または低減する方法を見ていきましょう。

技術的なアプローチ

選択肢の一つは、サードパーティJavaScriptをiFrame内に読み込み、allow属性やsandbox属性で制限することです。ただし、意図した機能が動作しなくなる場合があります。

もう一つの方法は、サブリソース完全性（SRI）を適用することです。ただし、そのためにはスクリプト提供元が、コンテンツに含まれるライブラリのハッシュ値を共有する必要があります。しかし、コンテンツはパーソナライズされていることが多く、動的に変化します。

W3Cのワーキンググループは、ユーザー行動の指標収集などを目的とした標準を、次の文書で提案しています。Customer Experience Digital Data Layer 1.0。第6.11項では、どの種類のサードパーティスクリプトがどのデータ型にアクセスできるかを定めています。ただし、その適用はデータレイヤーの管理者に委ねられています。

文化的なアプローチ

技術的なアプローチだけでは不十分なため、文化的なアプローチについて考えてみましょう。

マーケティングもソフトウェア開発ライフサイクルのプロセスに組み込み、変更をDevOpsパイプライン経由でコミットするべきでしょうか？エンジニアとの連携が理想的ですが、ビジネス上の優先順位や部門間のコミュニケーションを考えると、簡単に実現できることではありません。

ウェブアプリケーションやドメインから送信されるすべてのHTTPリクエストを、積極的に監視していますか？AkamaiのPage Integrity Managerや、無料のオープンソースウェブツールWebPageTestなどを使ってHTTPリクエストを監視し、継続的インテグレーション（CI）パイプラインに組み込むこともできます。

最後に、組織文化を整えることで、アナリティクスやその他のサードパーティJavaScriptウィジェットを実装する際に、エンジニアやマーケターがプライバシーを重視する意識をさらに高められます。

まとめ

フロントエンドの攻撃対象領域は広範です。ウェブアプリケーションのソースコードや依存関係にとどまらず、開発プロセスの外で追加されるサードパーティスクリプトにまで及びます。

技術的な対策に加え、インターネット上で安全を保つために、組織文化の変革にも取り組みましょう。

詳しくは、次のリソースをご覧ください。

1. Jim Gordonがブログ記事で詳しく解説する、イベント駆動型アーキテクチャのトレンドをご覧ください。https://jimalytics.com/tag-management/the-event-driven-data-layer。

2. Jan Exnerのブログhttps://webanalyticsfordevelopers.comでは、エンジニアにも理解しやすいレベルで、開発者向けのウェブアナリティクスを解説しています。

3. このセキュリティリスクの広がりを詳しく解説する、SnykConの講演Securing Frontend Attack Surfacesをご覧ください。