ログインや登録を含め、すべての形式でAntiForgeryTokenを使用する必要がありますか？
私は毎日何千もの訪問があるかなり大きなサイトとかなり大きなユーザーベースを運営しています。 MVC 3への移行を開始して以来、AntiForgeryTokenを、保護されたデータなどを変更するさまざまな形式で配置しています。
ログインや登録など、他のいくつかのフォームでもAntiForgeryTokenが使用されていますが、いくつかの理由から、そもそもその必要性について疑わしくなっています...
ログインフォームでは、投稿者が正しい資格情報を知っている必要があります。特に、リクエストが同じホストからのものであることを確認する場合（Refererヘッダーを確認する場合）、CSRF攻撃がここで利益を得る方法を実際に考えることはできません。
AntiForgeryTokenトークンは、ページが読み込まれるたびに異なる値を生成します。ログインページで2つのタブを開いて投稿しようとすると、最初のタブが正常に読み込まれます。 2番目はAntiForgeryTokenExceptionで失敗します（最初に両方のページをロードしてから、それらを投稿してみてください）。より安全なページの場合-これは明らかに必要な悪であり、ログインページの場合-やり過ぎのようで、問題を求めているだけです。
Onesフォームでトークンを使用する必要があるかどうかには、他の理由が考えられます。すべての投稿フォームでトークンを使用するのはやり過ぎだと思いますが、正しい場合、どのような種類のフォームが有益であり、どのフォームが間違いなくnotメリットになるでしょうか？
追伸この質問 また尋ねられます StackOverflowについてですが、私は完全には確信していません。詳細については、ここで尋ねると思いましたセキュリティカバレッジ
はい、ログインページには偽造防止トークンを含めることが重要です。
どうして？ 「ログインCSRF」攻撃の可能性があるため。ログインCSRF攻撃では、攻撃者は被害者を攻撃者のアカウントで標的サイトにログインさせます。たとえば、悪質な攻撃者であるイブリンによるPaypalのユーザーであるアリスへの攻撃を考えてみます。 PaypalがCSRF攻撃から（たとえば、偽造防止トークンを使用して）ログインページを保護しなかった場合、攻撃者はアリスのブラウザをPaypalのEvelynのアカウントに静かにログインさせることができます。 AliceがPaypal Webサイトにアクセスし、Aliceはログインしていますが、Evelynとしてログインしています。次に、アリスがページをクリックしてクレジットカードをPaypalアカウントにリンクし、クレジットカード番号を入力するとします。アリスは自分のクレジットカードをPaypalアカウントにリンクしていると思っていますが、実際にはそれをEvelynのアカウントにリンクしています。これで、Evelynはアイテムを購入し、アリスのクレジットカードに請求することができます。おっとっと。これは微妙で少しあいまいですが、ログインに使用されるフォームアクションターゲットに偽造防止トークンを含める必要があるほど深刻です。詳細とそのような実際の例については このペーパー を参照してください脆弱性。
偽造防止トークンを省略してもよいのはいつですか？一般に、ターゲットがURLであり、そのURLにアクセスしても副作用がない場合、そのURLに偽造防止トークンを含める必要はありません。
おおまかな目安は、すべてのPOSTリクエストに偽造防止トークンを含めることですが、GETリクエストには必要ありません。ただし、このおおまかな目安は、非常に大まかな概算です。 。GETリクエストはすべて副作用がないと想定しています。適切に設計されたWebアプリケーションでは、そうする必要がありますが、実際には、Webアプリケーション設計者がそのガイドラインに従っていない場合や、GETハンドラーを実装していない場合があります。副作用がある（これは悪い考えですが、それは珍しいことではありません）そのため、GETとではなく、リクエストがWebアプリケーションの状態に副作用があるかどうかに基づいてガイドラインを提案します役職。
ログインページにトークンを配置する必要があるのは、特定の資格情報を使って悪意のあるユーザーがサイトにログインするのを防ぐ必要がある場合です。特定のユーザーでログインする必要がある何かのために誰かがフレームに入れられている場合、これが事実であることがわかります。そうは言っても、それは少し不自然な例です。