すべての投稿方法で自分の Web サイトに CSRF トークンを実装しています。しかし、別のタブで自分の Web ページにアクセスすると、両方のページでトークンが変更され、トークンが一致しなくなります。私のトークンはDOMに保存されており、SESSIONを使用してトークンを照合しています。これを解決する方法。
5 に答える
リクエストが成功するたびにトークンを変更します
ええ、これが、リクエストが成功するたびにトークンを無効にしない理由です。これは、マルチタブ ブラウジングを中断するだけでなく、戻るボタンを押してから送信するなどの操作ができないことも意味します。
「すべてのリクエストでトークンを無効にする」は、テスターが実際に脆弱なものをあまり発見していないペンテスト レポートから得られる偽のセキュリティ推奨事項です。実行するかどうかは常にトレードオフですが、ほとんどの場合、使いやすさのマイナス面が最小限のセキュリティ上の利点を上回ります。
特権レベルの変更時、特にログイン時にCSRFトークンを (セッション トークンと共に) 無効にする必要があるだけです。これにより、ログイン前にセッションと CSRF トークンを知っている攻撃者が、ログイン後にそれらのトークンを悪用するのを防ぐことで、セッション固定攻撃を軽減します。
ajax を使用していない限り、サンプル コードを投稿してください (新しいタブを開いた場合に両方のタブでコードが変更されるべきではない CSRF トークンにはお勧めしません)。また、私は bobince に同意しません。ロジックを配置したら、すべてのフォームで簡単かつ簡単に使用できるため、この手段を実装するのは正しいことです。これを実装する最善の方法は、各トークンを一定時間後に期限切れにすることです。
bobince: CSRF トークンは、セッション固定攻撃ではなく、CSRF 攻撃を防ぐために使用されます。前者はスクリプトがユーザーに代わってアクションを実行するのを防ぎますが、後者は悪意のあるユーザーが通常のユーザーになりすます攻撃であり、セッション固定攻撃ではありません。セッションID。
これは簡単に実現できます。
サーバー側では、次のように CSRF トークンをセッションに保存します。
$_SESSION['csrf_tokens']['form1'] = //code to generate csrf token
フォーム送信時にトークンを検証する際に、次のことを確認できます。
$_SESSION['csrf_tokens']['form1'] === $_POST['csrf_token']
安全なトークンを生成する openssl_random_pseudo_bytes() を使用してセッションに基づいてトークンを作成しない理由は、このように不必要で安全ではなく、正しいかどうかを確認するか、2〜5分後に期限切れにするためにも使用できます。 dom のトークンについて owasp を確認してください。簡単に偽装できます !!!