二重送信された Cookie の CSRF 防止スキームでは、サーバーが Cookie を提供する必要がありますか?
クライアントページでjavascriptを生成してCookie「anti_csrf」を設定し、それを2回送信することができるようです(1回はCookieとして、ブラウザによって行われ、1回はリクエストの本文で)。
外部ドメインは、「anti_csrf」Cookie を読み書きしてリクエストの本文に含めることができません。
これは安全ですか、それとも何かを見落としていますか?
二重送信された Cookie の CSRF 防止スキームでは、サーバーが Cookie を提供する必要がありますか?
クライアントページでjavascriptを生成してCookie「anti_csrf」を設定し、それを2回送信することができるようです(1回はCookieとして、ブラウザによって行われ、1回はリクエストの本文で)。
外部ドメインは、「anti_csrf」Cookie を読み書きしてリクエストの本文に含めることができません。
これは安全ですか、それとも何かを見落としていますか?
Tgr、これを読んでください:
http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html
攻撃者が必要とするのは、乱数ジェネレーターから 1 つまたは 2 つのトークンを取得することだけです。そうすれば、暗号的に安全でない場合、後続および前のすべての乱数を予測できます。乱数生成が Javascript でクライアント側で行われる場合、暗号的に安全な乱数生成器を使用する単一のブラウザーを知らないため、Math.random() を数回呼び出すだけで何を解決できますか? Cookie のトークンが生成されました。
ユーザーがすでにドメインに「anti_csrf」Cookie を設定している場合、CSRF 攻撃者は無事です! HTTP リクエストはCookieとともに送信されます。もちろん、値がわかっている場合は、パラメータを POST に含めるのは簡単です。
Cookie名はシークレットである必要はありませんが、Cookie の値は、ユーザー セッションだけが知っている、推測しにくいシークレットである必要があります。そうすれば、攻撃者は、攻撃する HTTP トランザクションに何を入れればよいかわかりません (また、推測することもできません)。
Cookie の値を構成するコードをページに配置する場合、攻撃者がサイトで独自のセッション (つまり、有効な「実際の」ログイン) を取得し、コードを直接調べることができると想定する必要があります。Cookie の値がクライアント側でどのように生成されるかを簡単に理解できる場合 (そして、人間が知っているほぼすべてのクライアント側のソリューションについてはそうなるでしょう)、攻撃者は攻撃ページに正しいパラメーター値を含めることができます。攻撃POST。
一見安全そうに見えますが、JavaScript を使用していないユーザーはフォームを使用できません。