Error Events

October 1, 2020

Webページがサーバにリクエストを発行すると（例：フェッチ、HTMLタグ）、サーバはこのリクエストを受信して処理します。 受信した際にサーバは与えられた条件に基づいて、リクエストが成功（例：200）すべきか失敗（例：404）すべきかを決定します。 レスポンスがエラーステータスを持つ場合、ページを処理するためにブラウザによってerror eventが発行されます。 これらのエラーは、例えばHTMLコンテンツを画像として埋め込もうとした時のようなパーサーの処理が失敗するケースにも対応しています。

たとえば、攻撃者は認証されたユーザだけが利用できるリソースにユーザがアクセスできるかどうかを確認することで、ユーザがサービスにログインしているかどうかを検出できます¹。 このXS-Leakの影響はアプリケーションによって異なりますが、ユーザを非匿名化する高度な攻撃につながる可能性があります²。

エラーイベントは様々な HTMLタグからスローされる可能性があり、ブラウザによって動作が異なるものもあります ³。 例えば、読み込まれたリソースやHTMLタグ、特定のヘッダ（例えば nosniff や Content-Type ）の存在、あるいはブラウザのデフォルトの保護機能の適用などによって動作が変わることがあります。

エラーイベントで情報をリークさせる原理は、さまざまなXS-Leakに抽象化して適用できます。 たとえば、Cache Probingの1つの手法では、特定の画像がブラウザによってキャッシュされたかどうかの検出にエラーイベントを使用しています。

コード #

以下のコードは、<script> タグを使用してエラーイベントを検出する方法を示しています。

function probeError(url) {
  let script = document.createElement('script');
  script.src = url;
  script.onload = () => console.log('Onload event triggered');
  script.onerror = () => console.log('Error event triggered');
  document.head.appendChild(script);
}
// google.com/404 が HTTP 404 を返すため、スクリプトはエラーイベントを発生する
probeError('https://google.com/404');

// google.com は HTTP 200 を返すので、スクリプトは onloadイベントをトリガーする
probeError('https://google.com/');

対策 #

このXS-Leakの緩和策は、アプリケーションが特定のリソースをどのように処理するかによって異なる可能性があります。 一般的なアプローチとしては、可能な限り一貫した挙動を採用することです。 特定のシナリオでは、アプリケーションはSubresource Protectionsを使用して、攻撃者がURLを予測して攻撃を進行させることを防ぐことができます。 最後に、一般的なWebプラットフォームのセキュリティ機能を導入することで、アプリケーションの実装に大きな変更を加えることなく、このXS-Leakをより大幅に緩和することができます。

1. resource isolation policyはエラーベースのcross-site leaksを防ぐのに十分な有効なはずですが、Framing Isolation Policyがないシナリオでは、iframeを通してエラーイベントが漏洩する可能性があります。

実例 #

特定のユーザしかアクセスできないTwitter APIのエンドポイントを悪用できるバグがありました。 このエンドポイントは、所有者以外のすべてのTwitterユーザに対してエラーを返します。 攻撃者はこの挙動を悪用して、ユーザを非匿名化させる可能性があります。 同様に、別のバグではプライベートメッセージの画像認証機構を悪用して、同じ目的を達成することができました^{4 2}。

参考文献 #