CSRFはどのようにして同一生成元ポリシーと相関するのですか？
私は、CSRFと同じOriginがグランドスキームで果たす役割を理解しようとしています。 CSRFを使用すると、要求を行うことで、クライアントの他のWebサイトでほとんど何でもできます。同じオリジンポリシー（SOP）は他のドメインのデータを保持するため、CSRFの使用を無効にします。
同じ起源のポリシーがXMLHTTPRequestにのみ適用されることを考えると、巧妙に作成されたフォームを使用して、POSTリクエストを無効にできますSOPで、したがって必要CSRFトークン用。
これで、CSRFはSOPを回避するのでしょうか、それともうまく機能しますか？私は答えるのが難しいと思いますが、おそらく質問自体が混乱しているためです。
「Origin」という用語を定義することから始めましょう。ページの起点は、ホスト名、プロトコル、ポート番号の3つの固有の要素によって決定されます。例えば、 http://test.comおよびhttps://test.comプロトコルが異なるため、起源が異なります。同様にhttp://one.test.comおよびhttp://two.test.comホスト名が異なるため、生成元が異なります。 Originプロパティは、同じホスト上で実行されている2つのサービスのポート番号が異なる場合も異なります。 http://test.com:8081およびhttp://test.com:8082は異なる起源と見なされます。
Same Origin Policy（SOP）は、ブラウザレベルのセキュリティ制御であり、あるOriginが提供するドキュメントまたはスクリプトが他のOriginのリソースとどのように対話するかを指示します。 基本的に、あるOriginで実行されているスクリプトが別のOriginからデータを読み取ることを防ぎます。
クロスドメイン要求とフォーム送信は引き続き許可されますが、別のオリジンからのデータの読み取りは許可されません。つまり、脆弱なサイトでCSRF攻撃を実行して、サーバー側の状態を変更した場合（ユーザーの作成、ドキュメントの削除など）、攻撃は成功しますが、応答を読み取ることはできません。
つまり、SOPは、異なるオリジンから提供されたデータの読み取りを防ぐだけです。CSRF攻撃を実行するために使用されるクロスドメインフォームの送信は対象外です。
AJAXを使用してクロスドメイン通信を実行することに関する限り、通信を指示する他のいくつかのセキュリティ制御があります。 Cross Origin Resource Sharing を参照してください。CORSにより許可制御された方法でデータを通信および共有するためのさまざまな発信元とCORSの構成ミスも security vulnerabilities を引き起こす可能性があります。
SOPは、スクリプトタグ、CSS、およびイメージタグを使用して、さまざまなドメインでホストされているリソースがページに埋め込まれるのを防ぎません。これにより、コンテンツを直接読み取ることはできませんが、副作用ロードとレンダリングの一部を使用してコンテンツ（の一部）を決定できます。また、WebSocketはSOPでカバーされていないため、クロスサイト読み取りが可能です。
追伸私の blog から取得。
同一生成元ポリシー（SOP）は他のドメインのデータを保持します...
SOPには2つの部分があります。
- Origin AのスクリプトがOrigin Bからデータを読み取るのを防ぎます。
- これは、オリジンAのサイトがいわゆる「単純な」リクエスト以外をオリジンBに送信するのを防ぎます。単純なリクエストはGETとPOSTに制限されており、変更できるのは少数のヘッダーのみです。
...したがって、CSRFの使用を無効にします。
SOPはCSRFから保護しません。なぜですか？
- CSRF攻撃は、要求を送信することで行われ、応答から何かを読み取ることでは行われません。実際、応答を読み取ることはできませんし、必要もありません。
- 通常、CSRF攻撃では単純な要求を使用します。
ご覧のように、SOP=が導入されているという上記の制限は、CSRF攻撃を防止しません。
同じ起源のポリシーを検討すると、XMLHTTPRequestにのみ適用されます...
いいえ、違います。ブラウザが処理するすべてのデータに適用されます。 XMLHTTPRequestを使用する場合、通常のフォーム、またはフェッチAPIは無関係です。同じ制限が適用されます。
...巧妙に細工されたフォームを使用して、POSTリクエスト魔女がSOPを無効にすることで、CSRFトークンの必要性を回避できます。
巧妙に作成されたフォームを使用すると、POSTリクエストでCSRF攻撃を実行できます。そうです。そのため、CSRFトークンなどの特別な保護が必要です。
これで、CSRFはSOPを回避するのでしょうか、それとも機能しますか？
SOPが意味する「回避」または「回避」の意味がわかりません。代わりに、これを言いましょう。ブラウザがクロスオリジンを送信できるため、CSRFが可能ですPOSTリクエスト。
サイトAは、サイトAのHTML内にサイトBの画像を含めるなど、さまざまな方法で異なるサイトBにリクエストを送信できます（つまり、<img src=http://B/...>）または、フォーム、JavaScriptまたはHTTPリダイレクトで同様のことを行います。あるサイトから開始されたが別のサイトに送信されたリクエストは、クロスサイトリクエストと呼ばれます。
クロスサイトリクエストフォージェリ（CSRF）は、クロスサイトリクエストが悪用される可能性があることを意味します。これは通常、リクエストがサイトA、つまりクロスサイトから開始された場合でも、サイトBへの以前の接続からの既存のセッションCookieがこのサイトの各リクエストに送信されるためです。これは、リクエストがサイドBにログインしているユーザーのIDを使用して実行されることを意味します。CSRF攻撃が成功すると、このようなクロスサイトリクエストは、たとえば 脆弱なルーターのDNS設定を変更することによって） CSRF 。
Same-Origin Policy（SOP）はCSRFを不可能にしませんが、リクエストはサイトBに送信されますが、サイトBのサーバーから返された結果は攻撃者には見えないという点で、CSRFの影響を何らかの形で制限します。したがって、SOPはCSRFを書き込み専用にします。つまり、CSRFを使用して不要なアクションを実行することはできますが、サイトBからデータを引き出すためにそれ自体を使用することはできません。たとえば、外部の攻撃者がCSRFの脆弱性を使用する可能性があります。社内Wikiで既存のユーザーの名前で新しい投稿を作成するか、投稿を削除しますが、SOPのため、彼は社内Wikiのコンテンツを読み取ってそれを外部の攻撃者。
すべてのクロスサイト通信がSOPによって制限されているわけではないことに注意してください。特に Websocketは制限されていません なので、サイトAの攻撃者がブラウザをトランポリンとして使用して、ログインしているユーザーの権限でサイトBのWebsocketと完全に通信する可能性があります。データの書き込みと読み取りの両方。