クロスドメインフォームのPOST

私はこのトピックに関する記事や投稿（SOを含む）をすべて見てきましたが、主流のコメントは、同一生成元ポリシーがドメイン間でフォームPOSTを防止するというものです。同じ起源のポリシーがフォームの投稿に適用されないことを誰かが示唆しているのを見た唯一の場所はここです。

もっと「公式」または正式な情報源からの回答を希望します。たとえば、同一生成元がフォームPOSTにどのように影響するか、または影響しないかを扱うRFCを誰かが知っていますか？

説明：GETまたはPOSTを構築して任意のドメインに送信できるかどうかは尋ねていません。私は尋ねています：

1. Chrome、IE、またはFirefoxでドメイン「Y」のコンテンツがドメイン「X」にPOSTを送信できる場合
2. POSTを受信するサーバーが実際にフォームの値をまったく表示する場合。私がこれを言ったのは、オンラインディスカッションの大多数がテスターがサーバーが投稿を受け取ったと記録しているが、フォームの値はすべて空である/取り除かれているためです。
3. 公式ドキュメント（RFCなど）は、（ブラウザが現在実装しているものに関係なく）予想される動作を説明しています。

ちなみに、同一生成元がフォームのPOSTに影響を与えない場合は、偽造防止トークンが必要な理由がいくらか明らかになります。攻撃者が単純にHTTP GETを発行して偽造防止トークンを含むフォームを取得し、同じトークンを含む不正なPOSTを作成する可能性があると信じるのは簡単すぎるため、「やや」と言います。コメント？

同じ生成元ポリシーは、ブラウザ側のプログラミング言語にのみ適用されます。したがって、JavaScriptを使用して配信元サーバーとは異なるサーバーに投稿しようとすると、同じ配信元ポリシーが機能しますが、フォームから直接投稿すると、アクションは次のような別のサーバーを指します。

<form action="http://someotherserver.com">

フォームの投稿にJavaScriptが含まれていない場合、同じ生成元ポリシーは適用されません。

詳細については、ウィキペディアを参照してください

任意のGETまたはPOSTリクエストを作成し、被害者のブラウザがアクセスできる任意のサーバーに送信することが可能です。これには、プリンターやルーターなど、ローカルネットワーク上のデバイスが含まれます。

CSRFエクスプロイトを構築するには多くの方法があります。 メソッドを使用して、単純なPOSTベースのCSRF攻撃を送信できます.submit()。クロスサイトファイルアップロードなどのより複雑な攻撃CSRF攻撃は、xhr.withCredentals動作のCORS使用を悪用します。

SOPはJavaScript がクライアントのリクエストに対するサーバーの応答を読み取ることに関係しているため、CSRFはJavaScrip t の同一生成ポリシーに違反しません。CSRF攻撃は応答を気にせず、副作用や、管理ユーザーの追加やサーバーでの任意のコードの実行など、リクエストによって生成される状態変化を気にします。

OWASP CSRF防止に関するチートシートで説明されている方法のいずれかを使用して、リクエストが保護されていることを確認してください。CSRFの詳細については、CSRFのOWASPページを参照してください。

同じ発信元ポリシーは、別のURL（異なるプロトコル、ドメイン、またはポート）へのリクエストの送信とは関係ありません。

それはすべて、別のURLからの応答データへのアクセス（読み取り）を制限することです。したがって、ページ内のJavaScriptコードは、任意のドメインに投稿したり、ページ内のフォームを任意の場所に送信したりできます（フォームが異なるURLのiframeにある場合を除く）。

ただし、これらのPOSTリクエストが非効率的なのは、これらのリクエストに偽造防止トークンがないため、他のURLでは無視されるためです。さらに、JavaScriptがAJAXリクエストを被害者のURLに送信することでそのセキュリティトークンを取得しようとすると、Same Origin Policyによってそのデータにアクセスできなくなります。

良い例：ここに

そしてMozillaからの良いドキュメント：ここ