フォーム送信時のCSRFについて
CSRFの攻撃と保護がどのように機能しているかの画像には、確かに何か不足しています。
フォーム送信の風景における私の理解は、予測できないトークンに保護が依存していることです。どういうわけか、攻撃者はトークンを取得できないと想定されていますが、なぜですか？
攻撃者が私にフォームを送信させるのに十分である場合（ [〜＃〜] owasp [〜＃〜] で言及）、送信前に攻撃者がトークンを取得できないのはなぜですか？
挿入できるJavaScriptのサイズ/構文には制限があります。または、Same-Origin Policyを備えた最新のブラウザを使用していると仮定しただけですが、何が表示されていませんか？
編集
私の疑い、私が攻撃者であり、ユーザーフォームにJavaScriptを挿入できる場合、なぜシークレットトークンでフォームを取得（ajaxを使用）できず、送信するフォームにトークンを抽出して注入できないのですか？
編集2
面倒なことは許してくださいが、PHPサーバーでCSRF保護を使用しようとしていますが、理解できないと間違って設定する可能性があります。
OWASPのPOSTシナリオの例についてsubmit onload、evil.com攻撃されたユーザーがアクセスしているサイトは正しいですか？ targetSite.com、例のjavasript onloadは単純ですが、送信する前に秘密トークンを含むフォームのgetを使用すると複雑になる可能性がありますか？
これが事実である場合、攻撃されたユーザーを保護するのはSame-Origin-Policyだけですか？
サイトがアクションを実行するユーザーになりすますことができる理由は、ブラウザーがHTMLを喜んで送信するためです<form>action属性を使用して指定された他のドメインに、オリジンが同じであることや、ターゲットドメインによって提供される他の制限を気にせずに。元のドメインには、ユーザーが受信したものや、要求が成功したかどうかを読み取る方法がありません。元のドメインは、1つの特定のアクションを実行するために、ターゲットドメインにユーザーを送ります。*
トークンの使用時にこのCSRF攻撃が機能しないのは、ユーザーが各リクエストでターゲットドメインに関連するCookieも送信するためです。ターゲットドメインが他のドメインとの関係を示している特定の場合を除いて、Cookieはクロスドメインで機能しないため、元のドメインではこれらを読み取ることができません。したがって、ターゲットドメインのトークンが何であるかを確実に予測することはできません。
ターゲットドメインが行う必要があるのは、リクエストで送信された値が送信されたCookieと一致することを確認することだけです。
* 元のドメイン-ユーザーにPOST/GETリクエストの送信を強制するドメイン
* ターゲットドメイン-ドメインはリクエストを受信し、CSRFトークンCookieを「所有」します。
元のドメインへのリクエストは失敗するため、元のドメインにはトークンを表示する方法がありません。
- 元のドメインがPHPを使用して要求した場合、ターゲットドメインは、その特定の「ユーザー」（攻撃されたユーザーではなく、元のドメインサーバー）を対象としたまったく無関係なCookieを表示する必要があります。
- 元のドメインがCookieを読み取ろうとした場合、ブラウザには元のドメインに関連するCookieのみが表示され、別のドメインからCookieを読み取る可能性がなくなります。
- 元のドメインがJavaScriptを使用してページをリクエストした場合、クロスドメインのajaxリクエストは許可されないため、ブラウザはそれを拒否する必要があります（ターゲットドメインが明示的に許可していない場合）。
攻撃者が私にフォームを送信させるのに十分である場合（OWASPで言及）、送信前に攻撃者がトークンを取得できないのはなぜですか
攻撃者が必要とする唯一のスキルは、HTMLとJavaScriptを記述し、攻撃しようとしているリクエストがどのように見えるかを知る能力です。これらはすべて、簡単にアクセスでき、決して秘密にされていないものです。
したがって、フォームを作成する機能がランダムトークンを予測できることを意味するとの仮定は正しくありません。
各トークンは認証されたユーザーに固有であり、別の脆弱性がない限り、そのトークンが何であるかを理解する方法はありません。
あなたの質問がどのように語られているかに基づいて、CSRFがどのように機能するかを完全に理解しているとは思いません。これは侮辱を意味するものではありません。最初に把握するのは難しい概念です。
私の提案は、この種の攻撃に対して脆弱なフォームを作成し、それに対して攻撃を実行することです。これは、この攻撃のしくみを完全に理解するための優れた方法です。あなたがこれをしたら-私はあなたがこの答えをよりよく理解すると思う。
乾杯！
更新：
CSRFとXSSは同じものであると想定しているようです。明確にするために、only CSRFの脆弱性があるサイトでは、悪意のあるユーザーはJavaScriptを挿入できません。したがって、トークンを取得するためにJavaScriptを使用する方法はありません。サイトにXSSの脆弱性がある場合、CSRF攻撃を実行する必要はありません。必要なことを実行するJavaScriptを挿入する方がはるかに簡単だからです。また、CSRFは「一方向」の攻撃です。つまり、リクエストを誰かとして送信できますが、結果を読み取ることはできません。これは理にかなっていますか？
更新2：
あなたのコメントに関して：
明確にしていただきありがとうございます。セクションPOSTシナリオ、サブミットオンロード）にリンクされているOWASPページを見ていたのですが、JavaScriptインジェクションによるCSRF攻撃ではありませんか？
ああ-私はあなたの混乱を理解しています。いいえ、表示されているJavaScriptは攻撃者が制御するサイトにあります。したがって、攻撃者がevil.comを制御している場合、JavaScriptはそこにあり、ユーザーの既存のセッションを使用してtargetSite.comへのHTTPリクエストを起動するために使用されます。 CSRFは、HTTPリクエストレベルで行われる既存のセッションへの攻撃です。 se javascriptがこの攻撃を仕掛ける可能性がありますが、攻撃はまだHTTPリクエストです。
私はCSRFの専門家ではありません（誤解がある場合はコメントしてください）が、 wikipedia からです
[same-Origin policy]の下で、Webブラウザは最初のWebページに含まれるスクリプトが2番目のWebページのデータにアクセスすることを許可しますが、両方のWebページの起源は同じです。オリジンは、URIスキーム、ホスト名、およびポート番号の組み合わせとして定義されます。
簡単な例は次のとおりです：ブラウザーで3つのタブを開いて、3つのソース（1.aaa.com、2.aaa.com、www.bbb.com）からスクリプトを読み込んだとします。同一起源ポリシー（SOP）に基づくブラウザでは、1.aaa.comと2.aaa.comのスクリプトが相互にデータを読み書きできるようにします。これは、すべてのタブでFacebookがログインした状態を維持する方法です（Facebook以外のページでも、埋め込まれたFacebookスクリプトが*.facebook.comから動的に読み込まれるため、同じOriginが使用されます）。
ただし、SOPを実装するブラウザは、スクリプトがwww.bbb.comからデータを読み取ることができないようにします*.aaa.comスクリプトの場合。これにより、悪意のあるスクリプトが、別のスクリプトが割り当てられているランダムトークンを見ることができなくなります。SOPは書き込みをブロックしないため、悪意のあるスクリプトが要求を送信して、別のスクリプトにする必要がありますが、ランダムトークンを推測できない限り、その要求は無視されます。
私はシステムが少し心がゆがんでいることに同意しますが、それは機能します。
トークンチェックがなければ、攻撃者はJavaScriptを挿入する必要さえありません。
たとえば、彼らは https：//evil.example/ にフォームを作成します-- https：//target.example/ でアクションに送信します。ターゲットサイトにJavaScriptを挿入する代わりに、コントロールするサイトに直接JavaScriptを配置して、ユーザーをだまして訪問させることができます。 POSTリクエストにはまだtarget.exampleのCookieが含まれています。トークンを確認しない場合、フォームの送信は、target.example自体から直接送信されたかのように受け入れられます。
ただし、トークンのチェックがある場合、evil.exampleはsame-Originポリシーのためにトークンを取得できません。そのため、ターゲットサイトに追加の脆弱性が必要になります。たとえば、XSSは、攻撃者がAJAX経由でトークンを取得することを許可します。