2011-12-28 13 views

答えて

33

は、それだけでone token per sessionを、持っているだけで十分いわゆるセッションごとのトークン:一般的に

、開発者のみ現在のセッションのために一度、このトークンを生成する必要があります。このトークンの最初の生成後、その値はセッションに格納され、セッションが終了するまで各後続の要求に使用されます。

あなたは、さらにセキュリティを強化したい場合は、各フォーム/ URLごとに1つのトークンを使用することができます(ごとの形式トークン)への影響を軽減する際に1つのトークンリーク(例えばXSS)など攻撃者は特定のフォーム/ URLだけを攻撃することができます。

しかし、要求ごとのトークンを使用して、、i。 e。

この提案されたデザインのセキュリティをさらに強化するために、各リクエストごとにCSRFトークン[...]をランダム化することを検討してください。このアプローチを実装すると、セッションごとのトークンではなく、要求ごとのトークンが生成されます。ただし、これはユーザビリティの懸念につながる可能性があることに注意してください。たとえば、「戻る」ボタンのブラウザ機能は、前のページにもはや有効ではないトークンが含まれる可能性があるため、しばしば妨げられます。この前のページとの対話は、サーバーでCSRFの偽陽性セキュリティイベントとなります。

したがって、セッションごとのトークンまたはフォームごとのトークンを使用することをお勧めします。

+0

私はフォームトークンが動作すると思う:** a)**ユーザーが最初にフォームを読み込んだときにのみトークンを作成し、それ以降のフォームロードはそのフォームの最初のトークンを再利用する必要があります。 ** b)**トークンをセッションに格納するときは、特定のページ/フォームの識別子を含める必要があります。例えば。 SESSION ['edit-user-csrf']とSESSION ['edit-order-csrf']を実行すると、別のタブで別のページを開くことができます。トークン(各フォームに1つ)。ページはそのページにあるため、どのcsrfトークンをチェックして使用するかを知っています。 – zuallauz

+0

再認証と新しいトークン生成が必要な非アクティブセッションタイムと絶対セッション時間があることを確認してください。 (例:20分間の休止または4時間の絶対時間) – LaJmOn

+0

@zuallauzフォームのURLを使用してフォームを識別できます。それだけでは不十分な場合は、他の識別情報(例:隠れた入力値)を追加することもできますし、[フォームコンテナを使って隠れた入力値を格納することもできます](http://stackoverflow.com/a/9108483/53114)、隠された入力値のなりすましを防ぎます(http://stackoverflow.com/a/9209121/53114)。 – Gumbo

11

いいえ、あなたはgenerate a token on a per-session basisにする必要があります。

ユーザーが誤ってトークンを流出する可能性は非常に低く、フォームごとにトークンを生成すると、ユーザーが2つの異なるタブ/ウィンドウで同時にサイトを参照すると非常に複雑になります。一般的に

+0

ありがとうございます。したがって、トークンはまだすべてのフォームに配置されます(しかし、セッションごとのトークンは違いはありません)。 – Centurion

+0

はい、そうです。 – Quentin

関連する問題