a.comでホストされている、簡略化されたTwitterのようなWebサイトがあるとします。サインインしているユーザーは、POSTリクエストとしてサーバーに送信され、送信ボタンを押すと公開されるフォームにテキスト（ツイート）を入力できます。サーバー上では、ユーザーは一意のセッションIDを含むCookieによって識別されるため、サーバーはツイートを投稿したユーザーを認識します。
フォームは次のように単純にすることができます。
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
想像してみてください。悪者がこのフォームをコピーして悪意のあるWebサイトに貼り付けたとします（b.comなど）。フォームは引き続き機能します。ユーザーがTwitterにサインインしている限り（つまり、ユーザーがa.comの有効なセッションCookieを持っている場合）、http://a.com/tweetユーザーが送信ボタンをクリックすると、POSTリクエストが送信
され、通常どおり処理されます。
これまでのところ、ユーザーがフォームの正確な機能を認識している限り、これは大きな問題ではありませんが、悪者が次のようにフォームを微調整するとどうなるでしょうか。
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
さて、ユーザーの1人が悪者のWebサイトに行き、「クリックして勝つ！」ボタンをクリックすると、フォームがWebサイトに送信され、ユーザーはCookieのセッションIDによって正しく識別され、非表示のツイートが公開されます。
私たちの悪者がさらに悪い場合は、JavaScriptを使用してWebページを開くとすぐに、罪のないユーザーがこのフォームを送信するようにします。これは基本的にクロスサイトリクエストフォージェリです。
フォームはどこからでもどこでも簡単に送信できます。通常、これは一般的な機能ですが、フォームが属するドメインからのみフォームの送信を許可することが重要である場合がさらに多くあります。
WebアプリケーションがPOST要求とGET要求を区別しない場合（たとえば、PHPで$ _POSTではなく$ _REQUESTを使用する場合）は、事態はさらに悪化します。やめろ！データ変更リクエストは簡単に送信できます<img src="http://a.com/tweet?tweet=This+is+really+bad">、悪意のあるWebサイトやメールに埋め込まれて、送信できます。
自分のWebサイトからのみフォームを送信できるようにするにはどうすればよいですか？これがCSRFトークンの出所です。CSRFトークンは、ランダムで推測が難しい文字列です。保護したいフォームのあるページで、サーバーはランダムな文字列、CSRFトークンを生成し、それを非表示フィールドとしてフォームに追加し、セッションに保存するかCookieを設定することによって、何らかの形で記憶します値を含みます。フォームは次のようになります。
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
ユーザーがフォームを送信すると、サーバーは投稿されたフィールドcsrf-token（名前は関係ありません）の値をサーバーが記憶しているCSRFトークンと比較するだけです。両方の文字列が等しい場合、サーバーはフォームの処理を続行します。それ以外の場合、サーバーはフォームの処理を直ちに停止し、エラーで応答する必要があります。
なぜこれが機能するのですか？上記の例の悪者がCSRFトークンを取得できない理由はいくつかあります。
非表示フィールドの値はユーザーごとに異なるため、静的ソースコードをページから別のWebサイトにコピーしても意味がありません。悪意のあるユーザーのWebサイトが現在のユーザーのCSRFトークンを知らなければ、サーバーは常にPOST要求を拒否します。
悪意のあるユーザーの悪意のあるページは、ユーザーのブラウザーによって別のドメイン（a.comではなくb.com）から読み込まれるため、JavaScriptをコーディングすることはできません。これにより、コンテンツが読み込まれ、ユーザーの現在のCSRFトークンがあなたのウェブサイト。これは、ウェブブラウザがデフォルトでクロスドメインAJAXリクエストを許可していないためです。
ドメインが一致しないため、悪意のあるユーザーはサーバーによって設定されたCookieにもアクセスできません。
クロスサイトリクエストフォージェリから保護する必要があるのはいつですか？上記のようにGET、POST、およびその他のリクエストメソッドを混同しないようにできる場合は、デフォルトですべてのPOSTリクエストを保護することから始めます。
上記で説明したように、標準のHTMLフォームは、これらのメソッドを使用するブラウザから送信できないため、PUTおよびDELETEリクエストを保護する必要はありません。
一方、JavaScriptは実際に、jQueryの$ .ajax（）関数を使用するなど、他のタイプの要求を行うことができますが、AJAX要求が機能するためには、ドメインが一致する必要があります（他の方法で明示的にWebサーバーを構成しない限り） 。
これは、POSTリクエストであっても、CSRFトークンをAJAXリクエストに追加する必要がない場合が多いことを意味しますが、実際のPOSTリクエストが実際のリクエストである場合は、WebアプリケーションのCSRFチェックのみをバイパスする必要があります。 AJAXリクエスト。これは、AJAXリクエストに通常含まれているX-Requested-Withのようなヘッダーの存在を探すことで実行できます。別のカスタムヘッダーを設定して、サーバー側でその存在を確認することもできます。ブラウザは通常のHTMLフォームの送信（上記を参照）にカスタムヘッダーを追加しないため、安全です。BadGuy氏がこの動作をフォームでシミュレートする機会はありません。
AJAXリクエストに疑問がある場合は、何らかの理由でX-Requested-Withのようなヘッダーを確認できないため、生成されたCSRFトークンをJavaScriptに渡して、AJAXリクエストにトークンを追加します。これにはいくつかの方法があります。通常のHTMLフォームと同じようにペイロードに追加するか、AJAXリクエストにカスタムヘッダーを追加します。サーバーが着信要求でそれを探す場所を認識し、それをセッションまたはcookieから記憶した元の値と比較できる限り、ソートされます。