CSRFトークンをダブルサブミットする必要があるのはなぜですか？
OWASPのCSRF防止に関するチートシートを確認しました。 cookieの二重送信方法 について、それは言う：
サイトは（暗号的に強力な）疑似ランダム値を生成する必要があります
この方法は、攻撃者がCookie/Headerを挿入できないという事実に完全に依存しています。
攻撃者は、同じ元のポリシーに従って、サーバーから送信されたデータを読み取ったり、Cookieの値を変更したりすることはできません。
それでは、なぜ疑似乱数値は暗号的に強力である必要があるのでしょうか。
短い答え：CSRFトークンの総当たりを防ぐため。
簡単な例を見てみましょう：トークンが1桁で、0から9までの値を受け入れるとします。
これで、攻撃者はCookieまたはヘッダーからこの値を読み取ることができなくなりましたが、必ずしもそうする必要はありません。攻撃者は、可能な値ごとに1つずつ、10個のCSRF要求を送信することができます。それらの1つが正しいでしょう。
暗号的に強力なランダム値を使用すると、これを防ぎ、攻撃者がこの攻撃を拡大しようとするのを防ぐことができます（攻撃に、たとえば10または10,000の代わりに1000リクエストを送信させることにより...）
両方の答えのうち最良のものを組み合わせる：
トークンの長さは、被害者の数と被害者ごとのリクエストの数に比例する必要があります。攻撃者が
Xの被害者に自分のページに移動するように（スパムまたはフィッシング攻撃によって）説得し、そのような各ページがY異なるトークンを試みる場合、2から身を守る必要があります。x * y 攻撃。たとえば、トークンの長さが16ビット長の場合、攻撃者は2を送信する必要があります。16 それぞれ1つのトークン、または2つのトークンを試みるメール8 2を試みるメール8 それぞれトークン。攻撃者は、JavaScriptを使用するか、ページごとに複数の悪意のある画像リンクを埋め込むことにより、シングルクリックで複数のトークンをテストできます。暗号で保護された乱数ジェネレータを使用して、攻撃者が自分で複数のトークンを要求するのを防ぎ、取得したシーケンスを使用して、どのトークンを予測するかを予測しますotherユーザーが近い将来に取得します。
それはしません
疑似ランダムでなければなりません。
CSRFはブルートフォース攻撃と互換性がありません。攻撃ベクトルについて考えてみましょう。
- 悪意のあるユーザーが、興味のあるサイトに投稿するHTMLを含む特別な電子メールまたはWebページを作成する
- ユーザーが対象のサイトにログオンし、セッションIDが受動的に渡される（Cookieである）
- ユーザーがだまされて、特別に細工された電子メールまたはWebページのリンクをクリックする
- リンクはリクエストを「偽造」します。リンクはCookie内にあるため、セッションIDを含める必要はありません。そして、ヘッダーにあるCSRFトークンを渡す必要はありません（受動的に渡されます-Cookieです）。ただし、フォームの投稿にCSRFトークンを含める必要があります。
ハッカーが誰かをだましてリンクを何百回もクリックする方法はありません。 1回のクリックで大量のリクエストを送信するスクリプトであっても（ハッカーがその方法を理解していると仮定すると、ブラウザーはクロスドメインのAJAXリクエストを許可しないため、たぶん何百ものクリアなGIFや他の何かがまったく奇抜なページについて話していると思いますが）、タイムアウトせずに多くの検索スペースを通過することはできません。
また、攻撃者が特定の値に対して攻撃が機能したかどうかを判断する方法はありません。これは「ファイアアンドフォーゲット」攻撃です。
したがって、CSRFトークンをブルートフォースにすることができるという考えは、せいぜいフェッチされているだけです。ハッカーは個人的にログオンする必要があります-これはまったく別の攻撃です。
エントロピーがまったく必要な唯一の理由は、CSRF攻撃はスパムを介して配信される傾向があるためです。あなたがばかで、CSRFトークンに16ビットのエントロピーしかなく、ハッカーがまったく同じトークンで65,536のスパムメールを送信したとします。 65536/2 ^ 16 = oneこれらの攻撃のうち実際に成功するのは、メールの0％がスパムフィルターにヒットしたと想定すると、ユーザーの100％がそれらを開いて、悪意のあるリンクをクリックした瞬間にユーザーの100％がアプリにログインしました。
大量のユーザーを吸うことを期待する以外に、ハッカーが攻撃にそれを総当たり攻撃と呼ぶのに十分な規模に拡大する方法はありません。