サーバ側でanti-XSRF/CSRFトークンを生成する必要はありますか？

Question

CSRFトークンはサーバー側で生成されるべきであると、CSRF対策メカニズムに関するほとんどすべての文書に記載されています。しかし、私はそれが必要かどうか疑問に思います。

私はこれらの手順で抗CSRFを実装する：

1. なし、サーバー側で生成されたCSRFトークンはありません。

2. ブラウザ側では、すべてのAJAXまたはフォーム提出時に、JavaScriptがトークンとしてランダムな文字列を生成します。このトークンは実際のAJAXまたはフォーム提出が起こる前にクッキーcsrfに書き込まれます。トークンはパラメータ_csrfに追加されます。サーバ側で

3. は、各要求は CSRFクッキーと _csrf提出引数を持っていることになっています。これらの2つの値が比較されます。それが違う場合は、CSRFの攻撃であることを意味します。

サーバー側でCSRFトークンを発行する必要はありません。チェックするだけです。トークンはブラウザ側で完全に生成されます。もちろん、これは反CSRFのためのものです。ユーザーIDを検証するためにサーバー側で認証プロセスが必要です。

これはCSRFの有効な解決策と聞こえますが、このアプローチに関するドキュメントがない理由はわかりません。

このanti-CSRFメカニズムには何らかの障害がありますか？

Answer 1

私が理解する限り、クライアント側で反CSRFを作成し、それをクッキーに格納し、リクエストパラメータとして追加することで、サーバーがリクエストを読み込んだときにCSRFトークンのCookieとパラメータが一致するかどうかを検証し、有効な要求かどうかを判断します。

サーバー側で偽造トークンを生成する理由は、サーバーがそのトークンを作成し、サーバーのみが正しい値を認識するため、そのパラメーターがクライアント側でわずかに改ざんされた場合です。サーバーに格納されているものと同一ではなく、クロスサイトリクエスト偽造攻撃として要求にフラグを付けるのに十分です。 クライアント側で生成されたデータは、攻撃者によって改ざんされる可能性があります。そのため、そのアプローチに頼ることはできません。たとえば、クライアント側でランダムな値を作成し、 CSRFクッキーとあなたの_csrfパラメータに、あなたの値が "h246drvhd4t2cd98"だとしましょうが、クライアント側の2つの変数が同じ値であることを検証しているだけなので、攻撃者は簡単にCSRFクッキーと変数を"I'mByPassingThis"のような値が有効なリクエストとしてフラグを立てるので、セキュリティはまったく得られません。 一方、サーバーでトークンが生成された場合、攻撃者は期待値を知る方法がなく、要求ごとにその値が異なるため、攻撃者の最善の方法は、サーバ側で予測可能な乱数生成器を使用している場合を除き、事実上不可能であるはずです。

また、独自の偽造トークンメカニズムを作成したい場合は、暗号で保護された疑似乱数ジェネレータを使用することを考慮する必要がありますが、正直なところ、 （あなたのフレームワークにはこのためのメカニズムが組み込まれていると仮定すると、偽造防止トークンを生成するために暗号的に安全な擬似乱数ジェネレータを使用していることを確認する必要があります）。

ユーザーの投稿した情報を信用しないことを忘れないようにしてください。常に改ざんされる可能性があるため、サーバー側で常にダブルチェックを実行する必要があります。この場合、サーバーに偽造防止トークンを生成することは、提出された反偽造トークン。