ASP.NET MVC3のAntiForgeryTokenの実装の詳細とその根拠は何ですか？

Question

AntiForgeryTokenはCSRF攻撃を防止するために使用されていますが、MSDNのリンクでは、AntiForgeryTokenの正確な動作や動作の仕組み、

私が収集したものから、WebページとCookieの内部にハッシュが作成されます。一方または両方がハッシュIPrincipal.Nameを使用し、対称暗号化を使用します。

誰がするように、光を当てることができます：AntiForgeryTokenが内部で

推論は何を保護するために使用すべきではありませんどのよう

を保護するために使用すべきか

仕組み

1. 上の＃1の実装選択の背後にある？
   • 例：
     • は、実装は、ユーザが複数のタブを開いた場合
     • は、実装上の問題はあります「DoubleSubmit」クッキーおよびその他の一般的な脆弱性から安全である
     SANSで入手可能なものとは異なるMSFTの実装を行い何

Answer 1

さて、ここで私のベストショットです。

1）内部的に、mvcはRNG暗号化方式を使用してXSRFトークンとして動作する128ビット文字列を作成します。この文字列は、フォームのどこかの隠しフィールドと同様、Cookieにも格納されます。 Cookie名は、__RequestVerificationToken +アプリケーションパス（サーバー側）のベース64エンコードバージョンの形式であるようです。このHTMLの一部は、データ の以下の部分をシリアル化するためにAntiForgeryDataSerializerを使用しています - ソルト - 値（トークン文字列） を - 作成日 のダニ - ユーザ名は（Context.Userのように思える）

validateメソッドは、基本的にCookieとフォームの値を逆シリアル化し、値（salt/value/ticks/username）に基づいて比較します。

2/3）この議論は、XSRFトークンをいつ使用するのか、そうでないのかについて、もっと議論すると思います。私の心の中で、あなたはこれをあらゆる形で使うべきです（私はなぜそうではないのでしょう）。これが保護しないと私が考えることができる唯一のことは、実際に問題のフォームにヒットしたかどうかである。アプリケーション名のbase64エンコーディングを知ることで、攻撃者はXSRF攻撃中にCookieを見ることができます。たぶん私の解釈は間違っています。

4）あなたが探している商品が正確かわからないのですか？私はセッションにXSRFトークンを保存しようとするメカニズムを構築していたと思います。もしそうでなければ、クッキーアプローチを試してみてください。使用される暗号のタイプについては、私はこれを発見しました。 Pros and cons of RNGCryptoServiceProvider