ユーザーセッションごとに固有のCSRFトークン-なぜですか？
OWASP 推奨CSRFトークンはユーザーセッションごとに一意である必要があります。
- その背後にある攻撃ベクトルまたは理由は何ですか？
- 攻撃者はログアウト後にCSRFトークンを無効にしない（またはログイン後に更新する）Webアプリケーションをどのように悪用する可能性がありますか？
- Webアプリケーションがその推奨事項に従わない場合、どれほど深刻ですか？
- これは、あらゆる種類の（アンチ）CSRF保護実装（カスタムヘッダーを介して送信されるトークンなど）に適用されますか、それとも特定の形式のCSRFトークンにのみ適用されますか？
ここでの攻撃方法は、トークンの開示です。弁護側は、そのトークンがどのように開示されるかについては特にそれほど懸念していませんが、攻撃者がその値を取得する可能性のあるあらゆる方法に対処しています。攻撃者がトークンを入手できれば、CSRF攻撃を仕掛けられる可能性が広がります。この場合も、特定の攻撃方法自体は問題ではありません。
トークンを変更する目的は、機会を制限することです。 CSRFトークンを月に1回変更したり、リクエストごとに変更したりできます。セッションごとに変更することは、トークンの変更が速すぎることによる複雑さの一部を回避しながら、露出の適切な制限を提供する適切な中間基盤です。セッションを終了することも自然な状態遷移であるため、CSRFトークンを変更するのにも適しています。
CSRFへの全体的な露出を制限すると、すべてのセッションでCSRFトークンを変更する重要性が低くなります。これを行ういくつかの方法は次のとおりです。
- トークンをフォーム値ではなくHTTPヘッダーとして渡す。
- データの更新時またはトランザクションの開始時にPOST vs GETリクエストを適切に使用する。
- SameSite Cookie属性、Secure属性、および__Host-または__Secure- Cookieプレフィックスを使用して、Cookieが情報を公開したり上書きされたりしないように保護します。
- OriginおよびReferer HTTPヘッダーを使用して、リクエストが予期した場所から送信されたことを確認します。
- 確認ページや最も機密性の高いアクションの再認証など、追加のインタラクティブなステップを提供します。
CSRFトークンをいつ更新するかは、全体的なリスクとCSRF攻撃に対する一般的な抵抗によって決まります。優れた多層防御戦略を使用すると、そのトークンを変更する頻度について妥協できる可能性があります。
サーバーは、ログアウト時にシンクロナイザトークンに対して何もする必要はありません。ログインのたびに新しいトークンを生成するだけです。
Syncrhronizerトークンが機能するための明白な条件は、攻撃者が被害者のCSRFトークンを知らないことです。それ以外の場合、攻撃者は悪意のある要求の一部としてトークンを送信するだけなので、トークンは無意味になります。
新しいセッションごとに（つまり、ログイン時に）トークンを再生成しない場合、攻撃者がトークンを入手する方法は2つあります。
CSRFトークンの修正。セッション固定に関連する概念。攻撃者が自分のセッションIDとCSRFトークンを被害者のブラウザに挿入し、被害者がログインを実行したとします。サーバーがセッションIDを再生成することでセッションの固定を軽減し、CSRFトークンは再生成しないとします。攻撃者はセッションIDを持っていないにもかかわらず、被害者のCSRFトークンをすでに持っているため、CSRF攻撃を実行する可能性があります。
アルゴリズム推測。 CSRFトークンがユーザーに対して変更されない場合、本質的には永続的にユーザーに関連付けられます。特に攻撃者がアルゴリズムや使用されているパラメータを見つけ出した場合、それは時間の問題（ブルートフォース）であると推測します。ログインごとにトークンを再生成すると、ブルートフォース攻撃ウィンドウが大幅に小さくなります。