web-dev-qa-db-ja.com

アクセス制御により、Originブラウザーの保護を効率化

私は実験としてウェブサイトを構築していて、さまざまなサイトへのajaxリクエストをいくつか使用してみました。一部のサイトではエラーが発生します:

XMLHttpRequestが読み込めません http://example.com/path 要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。したがって、Origin 'null'はアクセスを許可されません。

Wiresharkを開いてネットワークの状況を確認すると、エラーが発生したサイト(応答にAccess-Control-Allow-Originが含まれていなかった)でも、リクエストがサイトに送信されていることがわかりました。 Access-control-allow-Origin:*ヘッダーを含めるように応答を変更した場合、応答は私のサイトで必要に応じて処理されます。

私の質問は次のとおりです。要求されたサイトに対してCSRFを実行しようとしていた場合、応答は要求ほど重要ではありません。要求がexample.comで処理されている限り、応答にAccess-Control-Allow-Originヘッダーが含まれていないかどうかは関係ありません(応答を気にしないと仮定すると、アクションが必要だっただけです)行われます)。

私は正しいのですか、保護が役に立たないのですか、それとも何か不足していますか?

2
t0m9er

CORSがすべてのセキュリティ問題を解決するのではなく、サードパーティのリソースからデータを読み取りできる特定の問題を解決することに注意することが重要です(私はgoogle.comにいますが、facebook.comのCookieを読み込もうとしています)。

見てください ここ

Cross-Origin Resource Sharing標準は、サーバーがWebを使用して情報をreadすることを許可されているオリジンのセットを記述することを可能にする新しいHTTPヘッダーを追加することで機能しますブラウザ。

CORSはサードパーティのWebサイトの読み取りを保護するためだけに存在し、CSRF攻撃はデータを送信すると、起動されたCSRF攻撃はおそらく機能しますが、応答が得られません(これも読み取りが制限されているためです)。

注:CORSを介して実行できなかった場合でもCSRF攻撃を開始できるため、ここでは特別なことはありません。 AJAX経由で送信する代わりに、location.href = www.example.com/csrfhack=some_hackを使用してユーザーを特定のURLにリダイレクトすることができます

1
Bubble Hacker