Compute でサブリソースをモニタリング

アプリケーションと API の保護 (WAAP) において、アプリ運営者やユーザーを最も悩ませている問題の一つは、攻撃者が Web サイトが機能するのに必要なリソースを操作して決済情報やパスワードを盗んだり、マルウェアをインストールすることです。

そこでこの問題に対応するため、サブリソースをモニタリングしてリソースの変更や操作による顧客の悩みを解消できるソリューションがないか検討しました。この記事では、この問題の概要と、サーバーレスコンピューティング環境の Compute を活用したソリューションについてご紹介します。

リソース/サブリソースとは何か？

「リソースとは、アイデンティティを持つあらゆるものを指します。身近な例では、電子文書、画像、サービス (「ロサンゼルスの本日の天気予報」など)、他のリソースを集めたものなどがあります」-- RFC 2396、1998年8月

サブリソースは、他のリソースの一部として読み込まれるリソースのことで、ここでは統一リソース識別子、すなわち URI (URL もそのタイプの一つ) を持つあらゆるものを指すと定義します。Web ページ (リソース) がブラウザに読み込まれるようユーザーがリクエストすると、そのページのレイアウトを決定する CSS ファイルと、ページに必要な機能を含む JavaScript ファイルもサブリソースとして読み込まれる必要があります。これらのサブリソースは、CDN (コンテンツ配信ネットワーク) など、コンテンツを迅速かつ確実にユーザーに提供することを専門とするサードパーティーから読み込まれることがよくあります。

Fastly の CDN 上に構築された Compute は、このようなサブリソースをモニタリングするのに最適です。Fastly のエッジ・コンピューティング・ネットワークを活用して、開発者は Fastly のグローバルに分散されたエッジクラウドプラットフォームでカスタムロジックを直接実行することができます。

攻撃者がサブリソースに変更を加える場合

攻撃者がサブリソースに変更を加えると、複数の異なる種類の問題が生じますが、それらはすべてスクリプトの依存関係を変更することを目的としています。

現在の Web サイトのほとんどが、必要な機能をユーザーに提供するのに最低一つの JavaScript ファイルを必要とします。通常、これらの必要な JavaScript は「スクリプトの依存関係」と呼ばれます。クレジットカードのスキミングを行うためにオンライン決済フォームに JavaScript コードを挿入する Magecart は、スクリプトの依存関係を悪用する攻撃の典型的な例です。

多くの場合、攻撃者はサードパーティとの依存関係を悪用して元のスクリプトを変更しようとしますが、最初は正当なスクリプト管理者のふりをして、後に悪意のある行為をしかける長期型の攻撃もあります。

スクリプトの依存関係の変更は、クロスサイトスクリプティング (XSS) やクロスサイト・リクエスト・フォージェリ (CSRF) などの攻撃を助長します。

• XSS 攻撃は、ユーザーのアカウントや Web 閲覧のセッションを乗っ取ることで、決済情報やパスワードを盗んだりするほか、マルウェアをインストールすることもあります。

• CSRF 攻撃は、ユーザーが知らないうちに、またはユーザーの同意を得ずに、ユーザーが Web アプリでリクエストを送信するよう強制することで、攻撃者が Web アプリのステートを操作してパスワードの変更や送金、購入などを実行したり、その他のアプリの機能を悪用できるようにします。

サブリソースの変更を防ぐ一般対策

一般的に、アプリケーションに必要なあらゆるスクリプト、スタイルシート、その他のリソースのインベントリを作成し、サブリソースの完全性をチェックする SRI (Subresource Integrity) 機能を活用することで、サブリソースの変更による攻撃を防ぐことができます。SRI は、ブラウザが強制するスクリプトやスタイルシートのリンクタグのオプション (ただし強く推奨される) の属性で、意図しない、もしくは承認されていない変更なしにリソースがオリジンサーバーまたは CDN から提供されていることを検証します。違反があった場合、コンテンツ・セキュリティ・ポリシー・ヘッダーによって、指定されたエンドポイントに報告されます。

しかし、攻撃者が悪意のあるスクリプトを挿入した場合、SRI で Web アプリを保護することはできません。残念ながら、攻撃者はスクリプトに完全性の属性を含むような親切なことはしません。従って、ブラウザは何も強制できません。ただし、コンテンツセキュリティポリシーで、厳格なポリシーを実装 (unsafe-inline を許可しないなど) することで、この問題を回避することができます。

サブリソースの変更を防ぐ、より効果的な対策

エッジで実装可能な、より効果的な防御対策があります。Compute では、サブリソースを追跡し、コンテンツセキュリティポリシーの違反を自動的にモニタリングするプロキシを実装できます。この仕組みを具体的に見てみましょう。

Compute でプロキシを実装することで、クライアントからのリクエストに対するレスポンスに見られるあらゆるサブリソースを追跡することが可能になります。これにより、特定の Web サイトの新しいサブリソースが確認されると、プロキシによってアラートがサービスの所有者に送信され、未承認の変更が外部のスクリプトや CSS ファイルに加えらていることを報告します。プロキシのプロセスは以下のようになります。

例えば、お客様が Fastly 経由で Web サイトの index.html を配信している場合、Compute のプロキシは、オリジンサーバーからのレスポンスに含まれるスクリプトソースで、初めて確認されたものをすべて検出できます。この情報を利用してアラートを生成したり、UI に通知を表示することができるため、Web サイトの所有者は予期せぬサブリソースが検出され場合、それを把握できます。以下のスクリーンショットに見られる https://sketchcdn.attacker.com/js/bootstrap.bundle.min.js はその一例です。

また、Content-Security-Policy-Report-Only ヘッダーを Compute に実装されたプロキシに追加して、ポリシー違反の自動モニタリングを強化することも可能です。例えば、攻撃者が既知の URI でスクリプトを変更しようとする場合、Compute 経由で提供されるレポート用のエンドポイントを使用することで、ブラウザが違反をレポートするように設定し、既存のリアルタイムログ機能の統合を利用してお客様に違反レポートを転送することも可能になります。

まとめ

今回のプロジェクトでは、Compute のパワーとポジションを活用して攻撃者によるサブリソースの変更をモニタリングするプロキシを実装しました。今後、例えばサードパーティリソースを取得し、定期的にハッシュ化して比較し、リソースの完全性に変化があった場合にサイト所有者に警告する別のプロセスを使用して、ブラウザの完全性チェックと同等のチェックをブラウザの外で実行できるようにすることが可能です。

Compute で他に何ができるか興味がおありですか？現在、無料クレジットを使ってコミットメントなしでどなたでもこのプラットフォームを試すことができます。詳しくはこちらをご覧ください。