2011-02-06 9 views
5

AntiForgeryTokenはCSRF攻撃を防止するために使用されていますが、MSDNのリンクでは、AntiForgeryTokenの正確な動作や動作の仕組み、ASP.NET MVC3のAntiForgeryTokenの実装の詳細とその根拠は何ですか?

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

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

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

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

    CSRFが何であるか疑問に思っていますか?具体的にどのようにMSはそれを扱うのですか?それとも一般的にどのように対処するのでしょうか? – CtrlDot

    +0

    @CtrlDot - 私はMSFTの実装の背後にあるすべての詳細について知りたいです。 http://security.stackexchange.comにアクセスして、CSRFに関する情報を取得し、クッキーをダブル送信することができます – LamonteCristo

    答えて

    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

    関連する問題