web-dev-qa-db-ja.com

CSRFから保護する_ _ VIEWSTATE

私は.NET開発者ではなく、__ ViewStateがCSRF/XSRF攻撃からどのように保護するかを理解しようとしています。

私は以下に遭遇しました：

同様のトピックに関するセキュリティスタック交換の議論 および CSRF保護のためのOWASPガイド

ここでCSRF保護がどの程度正確に行われているのか、少し混乱しています。上記のOWASPリンクから取得した以下のコードを見てみると、

    private const string AntiXsrfTokenKey = "__AntiXsrfToken";
    private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";
    private string _antiXsrfTokenValue;
    protected void Page_Init(object sender, EventArgs e)
{
    // The code below helps to protect against XSRF attacks
    var requestCookie = Request.Cookies[AntiXsrfTokenKey];
    Guid requestCookieGuidValue;
    if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
    {
       // Use the Anti-XSRF token from the cookie
       _antiXsrfTokenValue = requestCookie.Value;
       Page.ViewStateUserKey = _antiXsrfTokenValue;
    }
    else
    {
       // Generate a new Anti-XSRF token and save to the cookie
       _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
       Page.ViewStateUserKey = _antiXsrfTokenValue;
       var responseCookie = new HttpCookie(AntiXsrfTokenKey)
       {
          HttpOnly = true,
          Value = _antiXsrfTokenValue
       };
       if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
       {
          responseCookie.Secure = true;
       }
       Response.Cookies.Set(responseCookie);
    }
    Page.PreLoad += master_Page_PreLoad;
}

私が理解できることから、上記のコードは '__AntiXsrfToken'という名前のCookieがすでに存在するかどうかを確認します。

そうでない場合は、新しいランダムな値が生成されます。これはViewStateUserKeyに割り当てられ、Cookie「__ AntiXsrfToken」の値としても設定されます。

Cookieが既に存在する場合、Cookieの値が取得され、ViewStateUserKeyに割り当てられます。

さて、私が理解していないのは、antiXSRFトークンの要点は推測できないこと、そして確かにCookieで渡されないことです。Cookieは常に、ブラウザ。上記の場合、AntiXsrfトークンがCookieとして使用されているので、それをどのように保護しますか？そして、実際にはViewStateUserKeyの使用とは何ですか？ここでXSRFに対する保護にどのように役割を果たしますか？

csrfasp.netviewstate
5
qre0ct

問題は、OWASPガイドのコードサンプルが完全でないことです。具体的には、master_Page_PreLoadメソッドの最後の行に配線されるPage_Initメソッドの実装がありません。

そのメソッドが含まれている場合（そしてここですぐに追加します）に表示されるのは、Cookieによって設定されているViewStateUserKey値が、フォームのViewStateフィールドで送信されているViewState [AntiXsrfTokenKey]値と比較されていることです。

これがCSRF保護を提供するものです。悪意のあるリクエストが送信されると、偽造防止トークンを持つCookieと共に送信され、ViewStateUserKey値に設定されることは間違いありません。ただし、表示されていないのは、これが送信されたフォームの値と比較されていることです。クロスサイトリクエストフォージェリのシナリオでは、そのフォームの値は攻撃者の偽造防止トークンになります。 his ViewStateUserKeyになるようにビューステートとして追加されたもの。これは、Cookie内の値と一致しません。そのため、検証は失敗し、リクエストは成功しません。

現在、OWASPページのコード以外は何もないので、混乱するのは当然です。

9
Xander

ただし、CookieとセッションにはWebサイトのすべてのページからアクセスできますが、ViewStateの値はページ間では伝達されず、ポストバック間で値が伝達されることに注意してください。

Webサイトがユーザーを認証する場合、Page_InitイベントハンドラーでViewStateUserKeyプロパティを設定して、ページのビューステートを特定のユーザーに関連付けることができます。これにより、悪意のあるユーザーが、以前に作成されたページからビューステートを含む有効な、事前に入力されたWebページを作成するワンクリック攻撃を防ぐことができます。次に、攻撃者は被害者をだまして、被害者のIDを使用してページをサーバーに送信するリンクをクリックさせます。

ViewStateUserKeyプロパティが設定されている場合、攻撃者のIDを使用して、元のページのビューステートのハッシュが作成されます。被害者がページを再送信するように誘惑された場合、ユーザーキーが異なるため、ハッシュ値は異なります。ページは検証に失敗し、例外がスローされます。

ViewStateUserKeyプロパティは、ユーザー名や識別子など、ユーザーごとに一意の値にする必要があります。

あなたのコードで：

//新しいAnti-XSRFトークンを生成し、Cookieに保存します

_antiXsrfTokenValue = Guid.NewGuid().ToString("N");
   Page.ViewStateUserKey = _antiXsrfTokenValue;
   var responseCookie = new HttpCookie(AntiXsrfTokenKey)
   {
      HttpOnly = true,
      Value = _antiXsrfTokenValue
   };

ページが読み込まれるたびに新しいAnti-XSRFトークンが生成されます。そのため、攻撃者は値を推測できません。Cookieの値が変更されるたびに。したがって、ハッキングすることは非常に困難です。

0
Arunprasanth KV