PHP のトークンをすべてのフォームの隠し入力に含めることで、CSRF 保護を実装しました。もちろん、各トークンは 1 回しか使用できません。
ただし、入力を変更できる Web 開発者ツールなどのツールがあります。たとえば、ページ上の入力フォームを変更できます。無効になっているチェックボックスを有効にしたり、ページをリロードしたりせずに入力ボックスをテキストエリア ボックスに変更したりできます。CSRF はそのような変更をキャッチしません。
では、安全を確保するためには、どの程度のフォームを検証する必要があるのでしょうか? 選択、チェックボックス、非表示の入力など、変更されていないことを確認するために、すべての入力を検証する必要がありますか? これらが変更されていないと仮定するのは安全ではないでしょうか?
検証する必要があるすべてのものを (サーバー側で) 検証する必要があります。何を検証する必要があるかは、多くの要因と個人の選択によって異なります。一部は安全のためかもしれませんが、多くの場合、最低限必要なものだけです。ほとんどの場合、検証はユーザー エクスペリエンスを改善または作成することです。
たとえば、有効な電子メール アドレスが入力されているかどうかを確認できます。そうでない場合は、メッセージを送信できます。これを行わなくても、アプリケーションに悪いことは何も起こりませんが、ユーザーはあなたからの電子メールを受信できなくなります。
検証とサニテーションの間にも重要な違いがあります。衛生管理はセキュリティのために行われます (例: 注射を防ぐため)。検証は、入力がアプリケーションで正しく動作するための要件を満たしていることを確認するために行われますが、誤った入力は無害である可能性があります。サニタイズされた悪意のある入力が有効である可能性もあります。
すべての入力はサニタイズする必要があります。入力を検証する必要はないので、それは本当にあなた次第です。
CSRF 保護は、検証とは何の関係もありません。トークンを生成して表示する唯一の方法は、最初にサイトにリクエストを送信することであるため、ユーザーが外部ソースからフォームを使用してリクエストを作成できないようにするだけです。
CSRF を使用してやろうとしていることは、リクエストが信頼できるソースからのものであることを確認することです。たとえば、あなたがする必要があるのは、非表示フィールドの値が正常であることを確認することです。また、フォームがサーバーによってレンダリングされたときに提供されたものと同じである場合にのみ、(トークンが十分に強力であるという条件で) 正常に動作します。
フォームのフィールドが変更されたかどうかは、単なるアプリケーション ロジックです。csrfとは関係ありません。トークンが正常であれば、それは正しいソースからのものです。ここで、フォームに値を入力したのが同じ人物である場合、たとえば csrf の範囲内ではありません。
私はあなたがここでスティックの間違った終わりを得ていると思います. トークンは、送信時のフォームのハッシュではありません。
これが機能する方法は、フォームの非表示フィールドに一意のトークンを格納し、元のページをサーバーに送信するときにセッションに格納することです。
ユーザーから POST/GET されたページを取得すると、ページのトークンが以前にセッションに保存されたトークンと同じであることを確認します。
フィールドの変更を引き続き許可する必要があります。そうしないと、ユーザーはフォームにデータを入力できなくなります。送信したものと同じフォームが戻ってきたことを確認しているだけです。トークンが同じであり、別の場所からのものではなく、つまり、クロスサイト リクエスト フォージェリではないためです。
データベースに保存する前に、すべてのフィールドを検証し、データの準備を行う必要があります。