私は CSRF/XSRF について少し読んでいますが、ユーザーの自動ログインに関与する可能性があるため、多くは Cookie について話しているようです。
あなたのサイトは Cookie を使用していないのでしょうか、それとも Cookie の使用について心配する必要がありますか、それとも一般にアクセス可能なフォームでの Cookie の使用について心配する必要がありますか?
ユーザーはすでにブラウザ内でログインしている可能性があり、その後ブラウザにさらされる可能性があるため、まだそうしていると思います。
パブリック フォームに関しては、明らかに、これらの保護が必要な唯一の理由は、リモート サイトからそれらに正しく投稿されたくない場合です!?
クロスサイトリクエストフォージェリ（CSRF）は、Cookieを実装するサイトに向けられた攻撃ではなく、サイトAにアクセスするユーザーのブラウザにサイトBでアクションを呼び出させる機能を伴う攻撃です。アクセスするにはログインする必要がありますが、必須ではありません。
たとえば、サイトBに簡単な「お問い合わせ」フォームがあるとします。このフォームは一般公開されており、ユーザーログインは必要ありません。サイトAがJavaScript（またはFlashなど）を介してクライアントのブラウザからこのフォームを送信できる場合、「お問い合わせ」フォームは実際にサイトBにアクセスしたことのないエンドユーザーから送信されたように見えるため、これはCSRFと見なされます。 。
現在、この攻撃は、「アカウントXからアカウントYに送金する」などの単純な「お問い合わせ」フォームよりもアクションが複雑な場合、はるかに危険です。これらのアクションでは通常、ユーザーがサイトにログインする必要があります。サイトは通常、何らかの形式のCookieを使用します（セッションIDはブラウザーからサーバーにCookieとして送受信されます）。CSRF保護（トークンなど）がない場合、ユーザーがアクティブに開いているセッションを持っている限り、「転送」アクションを実行できます。ただし、サイトが実際にCookieを保存して、ユーザーが毎回クレデンシャルを送信する必要がない「Remember Me」機能を許可する場合、CSRFは、ユーザーがアクティブなセッションを持たなくても送信できるはずです。
クロスサイト リクエスト フォージェリは、状態がクライアント側で維持され、ユーザーの承認なしに送信された場合に問題になります。
認証に使用される状態の最も一般的な例は実際には HTTP Cookie ですが、他にも存在します。
HTTP 認証: 基本認証、ダイジェスト認証、または統合 Windows 認証。基本認証はルーター管理インターフェースでよく使用されますが、その多くは CSRF に対して脆弱です。
HTTPS クライアント証明書。
クライアント IP アドレス、HTTPS セッション ID、または User-Agent を認証受け入れ決定の信頼性の低い部分として使用するなどのわずかな問題。
これらのいずれかが、関連するプリンシパルに関連付けられた送信本文で検証可能なサーバー発行トークンなしで使用されている場合、CSRF 問題が発生しています。
認証の概念がなく、公開フォームしかない場合、CSRF自体は実際にはありません。ユーザーAがユーザーBに公開フォームを投稿するよう説得しても、偽造とは見なされません。とにかく、サイトはユーザー A からの送信とユーザー B からの送信を区別するために何もしていません。
ただし、何らかのフォームのサーバー発行トークンを含まない公開フォームは、DDoS 攻撃に対してより脆弱です。攻撃者は、フォーム自体を DoS 攻撃する代わりに、訪問した人にフォームを送信するようにプッシュするサイトを作成できます。 . これにより、攻撃が増幅され、多くのソースから来るため、ブロックが難しくなります。トークンは、単純なフォームのスパマー ボットに対する防御としても役立ちます。これらは CSRF の問題ではありませんが、同じ種類の防御で軽減できます。