CSRFの「DoubleSubmitCookie」手法では、CookieとHTTP POSTのシード値を変える必要がありますか？
OWASP二重送信Cookie 保護方法について読んでいますが、ヘッダーとフォームの間のCookie値が一致する必要があると記載されています。
記事に記載されているように、フォームに埋め込まれた値はDOMとJavascriptからアクセスできるため、これは多少のリスクがあるようです。
悪意のあるスクリプトがCookieの値を推測できないように、CookieとHTTP POST埋め込み値）に異なるシード値を設定する方が安全ではないでしょうか。
ASP.NETのAntiForgeryTokenは、二重送信Cookieの例です。そのトークンがフォームと同じ値をCookieに使用しているかどうかはわかりません。
注意点：
- あなたが言ったように、そして記事が述べているように、これはあまり安全ではなく、他の攻撃にさらされる可能性があるので、二重送信Cookieを使用しないでください。
"a differently seeded value for the cookie and the HTTP POST embedded value"-はい、このアプローチは非常に好まれますが、これはnot二重送信Cookieです-フォームトークンと呼ばれるものを参照しています。- フォームトークンを使用することは、それを正しくし、ソリューションを無効にする微妙なエラーを回避することが困難であったため、以前はより問題がありました。今日では、 OWASPのCSRFGuard など、これを行う非常に優れたパッケージがあります。同様のメカニズムは、ASP.NETを含む多くのフレームワークにも組み込まれています。
- 前述したように、ASP.NETのAntiForgeryToken（実際にはASP.NET MVC ...）はフォームトークンに基づいており、notはCookieを二重送信しません。前述のように、これは安全ではありません。
- ASP.NET自体には、UserKey属性を使用する場合、ViewStateに基づく保護も含まれています。
- Spring、RoRなど、他の多くの最新のフレームワークにも保護機能が組み込まれています。
- 関連する場合もしない場合もある別の代替手段は、特定のアクションに対するユーザーの再認証です。例えば。銀行口座から第三者に多額のお金を送金する前、またはLinkedInで接続を承認する前。
- 二重送信Cookieを使用しないでください。
クッキーとフォームの値が異なると、より強力な保護が提供されるのは正しいと思います。欠点は、Cookieの値がフォームの値と一致するかどうかを確認するだけでなく、どのCookieの値が各フォームの値と一致するかを追跡する必要があることです。また、OWASPのドキュメントに記載されているように、これはすべて、ブラウザが同一生成元ポリシー（ 思ったよりも難しい場合があります ）と適切な（予測できない）疑似乱数値の生成を適切に適用することに依存しています。