では、理解を深めるために、問題をアトミックな質問に分割しましょう。
このCSRFとは何ですか？
これは一種のWebアプリケーションの脆弱性です。最も基本的なレベルでは、CSRFの理由は、アクションがユーザーによって意図的に実行されたかどうか（たとえば、フォームのボタンをクリックしたり、ハイパーリンクをクリックしたりするなど）をブラウザが理解できないためです。ユーザーが無意識のうちにアクションを実行した（たとえば、ユーザーが何らかのドメインからページにアクセスした、たとえばbad.com、ユーザーがすでにgood.comにログインしているときにbad.comがgood.com/some_actionにリクエストを送信したなど）。
では、CSRFの影響は何ですか
次に、上記のgood.comをfacebook.comに置き換えましょう。そして、facebook.comにログインしているユーザーが自分の壁にコメントを投稿すると、
https：//facebook.com/postComment?userId=Abhinav_123&comment=の形式で送信されるHTTPGETリクエストがあると仮定します。 HiIAmAbhinav。
ここで、ユーザーがまだfacebook.comにログインしているときに、bad.comのページにアクセスするとします。現在、bad.comは攻撃者に属しており、bad.comで次のようにコーディングしています。
<img src="https: //facebook.com/postComment?userId=Abhinav_123&comment=I_AM_AN_IDIOT>
これで、ユーザーのブラウザがこのページのコンテンツをbad.comにロードするとすぐに、リクエストがfacebook.comに次のように送信されます。
https：//facebook.com/postComment?userId=Abhinav_123&comment=I_AM_AN_IDIOT
ブラウザがimgタグをレンダリングしようとするためです。そのためには、srcで指定されたリソースをフェッチする必要があるため、上記のHTTPGETリクエストを送信します。したがって、本質的に、攻撃者は実際にこれを知らなくても、ユーザーに代わってfacebook.comにリクエストを送信する可能性があります。
では、この攻撃を防ぐ可能性があるのは何でしょうか。
リクエストがユーザーによって意図的に行われたかどうかを識別する方法があった場合のみ。そのため、これを行うために、反CSRFトークンが登場しました。これは、サーバー（上記の例ではfacebook.com）によって生成され、ユーザーに送信され、ユーザーのブラウザーにCookieとして設定されたランダムで一意の文字列です。これで、機密性の高いアクション（上記のFacebookの例にコメントを投稿するなど）を含むすべてのリクエストに対して、ブラウザはリクエストと一緒にこのランダムな文字列を送信し、アクションを実行する前にサーバーはランダムな文字列が持っていたものであるかどうかを確認しますブラウザに送信されるかどうか。
このランダムな文字列は攻撃者に知られていません。したがって、攻撃者が上記のようにimg srcを作成し、ユーザーがbad.comにアクセスした場合でも、アクション（上記の例ではコメントを投稿する）は実行されません。これは、実行されるアクションがURL以外であるためです。 、追加のものも必要です。これは、攻撃者が持っていないランダムな文字列です。
しかし、このランダムな文字列をCookieに設定すると、大きな欠陥があります
Cookieの設計方法とブラウザがCookieを処理する方法のため、Cookieにこのランダムな文字列（アンチCSRFトークン）を設定しても、目的は果たされません。設計上、Cookieは、クライアントがサーバーに対して行うすべての要求とともにサーバーに自動的に送信されます（簡単に言えば、簡単にするために詳細は省略されています。詳細については、RFC2965を参照してください） 。
したがって、上記の例では、攻撃者は実際にはランダムな文字列を知る必要はありません。ユーザーがbad.comにアクセスして投稿コメントURL（上記で説明）をロードするとすぐに、ランダムなアンチCSRFトークン（Cookieに存在する）が自動的にリクエストに付随するため、投稿コメントアクションは引き続き完了します。
では、解決策は何ですか？
アンチCSRFトークンをCookieに入れる代わりに、サーバー（facebook.com）はそれをフォームの非表示パラメーターとして入れ、ユーザーがコメントの投稿を要求したときにこのフォームを作成する必要があります（アンチCSRFトークンを保持します）。また、投稿する必要があります。
現在、攻撃者はユーザーに代わってこの機密アクションを実行する方法がありません（ランダムなアンチCSRFトークン自体を何らかの方法で見つけた場合を除く）
CSRFへのログインとCookieの二重送信の問題が発生しました
多くの場合、Webサイトは、何らかの形式のanti_CSRFトークンアーキテクチャを展開することにより、CSRF攻撃から身を守ります。しかし、多くの場合、WebサイトはCSRF攻撃からログインフォームを保護することをあまり気にしません。なんで ？-ログインフォームでさえCSRFに対して脆弱であり、攻撃者は自分のドメイン（bad.com）を介してgood.com（facebook.com）へのログイン要求をフレーミングすることによってそれを悪用しようとするため、ユーザーは引き続き有効な資格情報を入力する必要がありますfacebook.comにログインします。これらの資格情報は、攻撃者ではなく本物のユーザーのみが使用できるため、攻撃者は成功したログイン要求を組み立てることができません。
では、ここでの攻撃者にとっての攻撃の機会は何ですか？
攻撃者はfacebook.comで自分のアカウントを作成できます。彼は現在、自分自身の有効な資格情報のセットを持っています。現在、彼はfacebook.comへのログイン要求を、自分のログイン資格情報と自分のドメイン（bad.com）でフレーム化します。これで、ユーザーがページbad.comにアクセスすると、ユーザーは私のアカウントにログインします。攻撃を受けた私は、後でアカウントでユーザーが実行したすべてのアクティビティを確認して、機密情報も開示する可能性があります（たとえば、ユーザーが新しい友達リクエストを送信することを選択した場合に送信される友達リクエスト、誰かに送信されるメッセージ、ユーザーが送信する場合など）私のアカウントにログインした後。これらの可能性はすべて、ユーザーが自分のアカウントにログインしたことをユーザーがどの程度確信しているかによって異なります。この場合も、攻撃者は自分のFacebookページを被害者に近づけることで対処できます。
では、これに対する緩和手法は何ですか？
ここで必要なのは二重送信Cookieです。
これは正確にはどういう意味ですか
Cookieの二重送信は、Cookieとリクエストパラメータの両方でランダムな値を送信することとして定義され、サーバーはCookieの値とリクエストの値が等しいかどうかを確認します。
攻撃を軽減するのにどのように役立ちますか？
ダブルCookieの実装原則に従って、匿名ユーザー（ログインしていないユーザー）がログインページにアクセスすると、サーバーはユーザーのブラウザにランダムな文字列を含むCookieを設定し、リクエストパラメータにも同じものを設定します（たとえば、フォームの隠しフィールド）。ユーザーがログイン要求を送信すると、これらのものが要求とともに送信されます。ユーザーの資格情報、非表示のフォームフィールドのランダムな文字列、およびランダムな文字列を保持するCookie（もちろん自動的に送信されます）。
これで、攻撃者は自分の資格情報にアクセスできるようになります。これは、サーバーがCookieと攻撃者の非表示のフォームフィールドに設定したランダムな文字列です。攻撃者がこの細工されたログイン要求をユーザー（被害者）に送信し、ユーザーがこの要求を行おうとすると、ユーザーはまだログインしておらず、これまでのところサーバーの匿名ユーザーです。そのため、サーバーはユーザーのブラウザに（攻撃者の）ランダムな値とは異なるCookieを設定します。これで、ユーザーが攻撃者の細工したリンクを介してログインを要求すると、要求には攻撃者の資格情報、非表示のフォームフィールドに攻撃者のランダムな文字列が含まれますが、Cookieにはユーザーのランダムな文字列が含まれます（ユーザーのブラウザから送信されます）。このリクエストがサーバーに到達すると、
したがって、これが暗号化された値がフォームとともに返される理由でもあります。それが概念をクリアすることを願っています。