web-dev-qa-db-ja.com

MVC偽造防止トークンのデフォルトのヘッダー/ Cookieの目的は何ですか？

MVC偽造防止トークンは、セキュリティトークンをフォームフィールドに格納し、ブラウザーによって自動的に送信されたデフォルトのヘッダー/ Cookie値を、すべてのリクエストでMVCによって設定されたフィールド値と比較することで、CSRF攻撃を無効にすることを読みました。悪意のあるWebサイトは、トークンを格納するフィールドにどの値を与えるべきかわからないため、CSRF攻撃は失敗します。

では、トークンをヘッダーに格納する意味は何でしょうか？ JavaScriptから手動ですべてのリクエストのフォームフィールドにトークンを保存し、比較を完全にスキップできませんか？

この質問は私に当てはまります。SignalR、ajaxリクエスト、ASP.NETフォームで実行されるさまざまなアプリに対してシングルサインオン認証スキームを作成しているためです。 ASP.NETフォームの非表示フィールド、AJAXのreq bodyの一部、SignalRのクエリ文字列（デフォルト設定を無効にして）クロスオリジンリクエスト）。デフォルトのヘッダーとCookieを完全に回避します。

csrfasp.net-mvc
2
Ian

ASP.NET MVCは シンクロナイザートークンパターン のバリエーションを使用します。一般的な実装では、syncrhonizerトークンパターンは、大きなランダムトークンを生成し、それを2つの場所に保存することで機能します。

  1. セッション状態（サーバーまたはクライアントのいずれか）
  2. 非表示のフォームフィールド

フォームが送信されると、サーバーは両方の値が一致することを確認し、一致しない場合は失敗します。これは、攻撃者が事前にトークン値を取得できないために機能します。

ASP.NET MVCは、セッションCookieを使用する代わりにセッション状態を使用しないことにより、このパターンをわずかに変更します。トークンには、Cookieトークンかフォームフィールドトークンかによって、いくつかの追加データも含まれます。

    /* The serialized format of the anti-XSRF token is as follows:
     * Version: 1 byte integer
     * SecurityToken: 16 byte binary blob
     * IsCookieToken: 1 byte Boolean
     * [if IsCookieToken != true]
     *   +- IsClaimsBased: 1 byte Boolean
     *   |  [if IsClaimsBased = true]
     *   |    `- ClaimUid: 32 byte binary blob
     *   |  [if IsClaimsBased = false]
     *   |    `- Username: UTF-8 string with 7-bit integer length prefix
     *   `- AdditionalData: UTF-8 string with 7-bit integer length prefix
     */

どちらのトークンも暗号化および認証されているため、クライアント側では読み取ることができません。シリアライザの実装 here を参照してください。上記のトークンの構造を考えると、クライアント側でも同じではないことがわかります。どちらも2つの異なる暗号文に暗号化され、そこで検証することはできません。

おそらく、CSRFトークンのサーバー側をセッション状態に格納することで、Cookieが不要になるように動作を変更できます。ただし、CSRF保護を機能させるには、実際に2つ必要であり、それらを比較する必要があります。

[〜＃〜]編集[〜＃〜]

元の質問により直接的に回答するには

MVC偽造防止トークンのデフォルトのヘッダー/ Cookieの目的は何ですか？

いつでも、どのようなアプリケーションでも機能する完全なソリューションを提供します。

ログインページを保護する機能 ：

匿名認証

アンチXSRFシステムには、匿名ユーザーに対する特別なサポートが含まれています。「匿名」は、IIdentity.IsAuthenticatedプロパティがfalseを返すユーザーとして定義されています。シナリオには、ログインページ（ユーザーが認証される前）にXSRF保護を提供することや、アプリケーションがIIdentity以外のメカニズムを使用してユーザーを識別するカスタム認証スキームが含まれます。これらのシナリオをサポートするには、セッショントークンとフィールドトークンが、128ビットのランダムに生成された不透明な識別子であるセキュリティトークンによって結合されていることを思い出してください。このセキュリティトークンは、ユーザーがサイトをナビゲートするときに個々のユーザーのセッションを追跡するために使用されるため、匿名識別子の目的を効果的に果たします。上記の生成および検証ルーチンでは、ユーザー名の代わりに空の文字列が使用されます。

コメントに従って、暗号化されたユーザー名と有効期限を非表示のフォームフィールドに含めることで、Cookieなしでそれができるかどうか疑問に思っています。答えはです。

このようなトークンはXSS攻撃で盗まれる可能性がありますが、httpOnlyでマークされた認証Cookie（またはCSRFトークンCookie）は盗まれませんでした。これにより、有効期限内にソリューションが脆弱になります。これが許容できるかどうかは、ユーザーとアプリケーションのタイプによって異なります。たとえば、ネットバンキングアプリケーションは、いかなる種類のCSRF脆弱性も許容しませんが、単純なオンラインゲームは許容します。

認証トークンの保存にCookieを使用しない場合は、CSRFを完全に回避できます。

3
Marko Vodopija

クライアント側のハッシュCookieをどこに置くかは関係ありません。フォームの隠しフィールドにも配置できます。とにかくクライアント側のすべてがアクセス可能になります。正当なユーザーが誰にアクセスしているかは問題ではありません。

あなたが言ったポイントは、それを同時にサーバー側で生成し、それからクライアントからそれを受け取ってマッチングがOKかどうかをチェックすることです。このようにして、リクエストを正当化できます。それで全部です。

たぶん、攻撃者がクライアントから1つのCookie /ハッシュを盗むことができれば、CSRF攻撃を実行することができますが、あまり意味がありません...おそらく、クライアントから盗むことができれば、もっと興味深いでしょう。ログイン用のセッションCookieなどの盗むもの。

0
OscarAkaElvis