ASP.NET MVC と Web ページの XSRF/CSRF 防止XSRF/CSRF Prevention in ASP.NET MVC and Web Pages

Rick Andersonby Rick Anderson

クロスサイト要求偽造 (XSRF または CSRF とも呼ばれます) は、web でホストされるアプリケーションに対する攻撃であり、悪意のある web サイトが、クライアントブラウザーとそのブラウザーによって信頼されている web サイトとの間の対話に影響を与える可能性があります。Cross-site request forgery (also known as XSRF or CSRF) is an attack against web-hosted applications whereby a malicious web site can influence the interaction between a client browser and a web site trusted by that browser. Web ブラウザーは web サイトへのすべての要求で認証トークンを自動的に送信するため、これらの攻撃が可能になります。These attacks are made possible because web browsers will send authentication tokens automatically with every request to a web site. 標準的な例は、ASP.NET のフォーム認証チケットなどの認証クッキーです。The canonical example is an authentication cookie, such as ASP.NET's Forms Authentication ticket. ただし、永続的な認証メカニズム (Windows 認証、基本など) を使用する web サイトは、これらの攻撃の対象にすることができます。However, web sites which use any persistent authentication mechanism (such as Windows Authentication, Basic, and so forth) can be targeted by these attacks.

XSRF 攻撃はフィッシング攻撃とは異なります。An XSRF attack is distinct from a phishing attack. フィッシング攻撃には攻撃対象とのやり取りが必要です。Phishing attacks require interaction from the victim. フィッシング攻撃では、悪意のある web サイトがターゲット web サイトを模倣し、攻撃者に機密情報を提供することはできません。In a phishing attack, a malicious web site will mimic the target web site, and the victim is fooled into providing sensitive information to the attacker. XSRF 攻撃では、多くの場合に攻撃対象とのやり取りは必要ありません。In an XSRF attack, there is often no interaction necessary from the victim. 攻撃者は、ブラウザーによって、関連するすべての cookie が送信先の web サイトに自動的に送信されます。Rather, the attacker is relying on the browser automatically sending all relevant cookies to the destination web site.

詳細については、 Open Web Application Security Project(owasp) XSRFを参照してください。For more information, see the Open Web Application Security Project(OWASP) XSRF.

攻撃の構造Anatomy of an attack

XSRF 攻撃を実行するには、いくつかのオンラインバンキングトランザクションを実行する必要があるユーザーを考えてみます。To walk through an XSRF attack, consider a user who wants to perform some online banking transactions. このユーザーは、最初に WoodgroveBank.com にアクセスしてログインします。この時点で、応答ヘッダーには自分の認証クッキーが含まれます。This user first visits WoodgroveBank.com and logs in, at which point the response header will contain her authentication cookie:

HTTP/1.1 200 OK
Date: Mon, 18 Jun 2012 21:22:33 GMT
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH={authentication-token}; path=/; secure; HttpOnly;
{ Cache-Control, Content-Type, Location, Server and other keys/values not listed. }

認証 cookie はセッション cookie であるため、ブラウザープロセスが終了すると、ブラウザーによって自動的にクリアされます。Because the authentication cookie is a session cookie, it will be automatically cleared by the browser when the browser process exits. ただし、その時点までは、ブラウザーには、WoodgroveBank.com に対する各要求に cookie が自動的に含まれます。However, until that time, the browser will automatically include the cookie with each request to WoodgroveBank.com. これで、ユーザーは $1000 を別のアカウントに転送するようになりました。そのため、銀行のサイトにフォームを入力すると、ブラウザーはこの要求をサーバーに対して行います。The user now wants to transfer $1000 to another account, so she fills out a form on the banking site, and the browser makes this request to the server:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=12345&amount=1,000.00

この操作は副作用がある (金額トランザクションを開始する) ため、この操作を開始するために、銀行のサイトで HTTP POST の要求が選択されています。Because this operation has a side effect (it initiates a monetary transaction), the banking site has chosen to require an HTTP POST in order to initiate this operation. サーバーは、要求から認証トークンを読み取り、現在のユーザーのアカウント番号を検索し、十分な資金が存在することを確認してから、対象のアカウントにトランザクションを開始します。The server reads the authentication token from the request, looks up the current user's account number, verifies that sufficient funds exist, and then initiates the transaction into the destination account.

オンラインバンキングを完了すると、ユーザーが銀行のサイトから移動し、web 上の他の場所にアクセスします。Her online banking complete, the user navigates away from the banking site and visits other locations on the web. これらのサイトのいずれか– fabrikam.com – <iframe>内に埋め込まれたページに次のマークアップを含めます。One of those sites – fabrikam.com – includes the following markup on a page embedded within an <iframe>:

<form id="theForm" action="https://WoodgroveBank.com/DoTransfer" method="post">
    <input type="hidden" name="toAcct" value="67890" />
    <input type="hidden" name="amount" value="250.00" />
</form>
<script type="text/javascript">
    document.getElementById('theForm').submit();
</script>

これにより、ブラウザーは次の要求を行います。Which then causes the browser to make this request:

POST /DoTransfer HTTP/1.1
Host: WoodgroveBank.com
Content-Type: application/x-www-form-urlencoded
Cookie: .ASPXAUTH={authentication-token}
toAcct=67890&amount=250.00

攻撃者は、ユーザーがターゲット web サイトに有効な認証トークンを持っている可能性があるという事実を悪用しています。また、Javascript の小さなスニペットを使用して、ブラウザーがターゲットサイトへの HTTP POST を自動的に行うようにしています。The attacker is exploiting the fact that the user might still have a valid authentication token for the target web site, and she is using a small snippet of Javascript to cause the browser to make an HTTP POST to the target site automatically. 認証トークンがまだ有効である場合、銀行のサイトでは、攻撃者が選択したアカウントへの $250 の転送を開始します。If the authentication token is still valid, the banking site will initiate a transfer of $250 into the account of the attacker's choosing.

効率的でない軽減策Ineffective mitigations

上記のシナリオでは、WoodgroveBank.com が SSL 経由でアクセスされ、SSL のみの認証クッキーが攻撃を阻止するのに十分ではないという事実に注意してください。It is interesting to note that in the above scenario, the fact that WoodgroveBank.com was being accessed via SSL and had an SSL-only authentication cookie was insufficient to thwart the attack. 攻撃者は <フォーム> 要素でURI スキーム(https) を指定できます。また、これらの cookie が目的のターゲットの URI スキームと一致する限り、ブラウザーは引き続きターゲットサイトに unexpired cookie を送信します。The attacker is able to specify the URI scheme (https) in her <form> element, and the browser will continue to send unexpired cookies to the target site as long as those cookies are consistent with the URI scheme of the intended target.

信頼されたサイトのみにアクセスしても安全なオンラインに保つことができるので、ユーザーは信頼されていないサイトにアクセスしないようにする必要があります。One could argue that the user should simply not visit untrusted sites, as visiting only trusted sites is helps to remain safe online. これには真実がありますが、残念ながらこのアドバイスは常に実用的であるとは限りません。There is some truth to this, but unfortunately this advice is not always practical. ユーザーは、ローカルニュースサイト ConsolidatedMessenger を "信頼" している可能性があります。Perhaps the user "trusts" the local news site ConsolidatedMessenger. ConsolidatedMessenger.com を使用してそのサイトにアクセスしますが、そのサイトには、fabrikam.com で実行されていたものと同じコードスニペットを注入できる XSS 脆弱性があります。ConsolidatedMessenger.com and goes to visit that site instead, but that site has an XSS vulnerability which allows an attacker to inject the same snippet of code that was running on fabrikam.com.

受信要求にドメインを参照するReferer ヘッダーがあることを確認できます。You can verify that incoming requests have a Referer header referencing your domain. これにより、サードパーティのドメインから知らないうちに送信された要求を停止します。This will stop requests unwittingly submitted from a third-party domain. ただし、プライバシー上の理由からブラウザーの Referer ヘッダーを無効にするユーザーもいれば、攻撃者が特定の安全でないソフトウェアがインストールされている場合は、そのヘッダーを偽装することがあります。However, some people disable their browser's Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain insecure software installed. Referer ヘッダーの検証は、XSRF 攻撃を防ぐための安全な方法とは見なされません。Verifying the Referer header is not considered a secure approach to preventing XSRF attacks.

Web Stack Runtime XSRF の緩和Web Stack Runtime XSRF mitigations

ASP.NET Web Stack ランタイムは、シンクロナイザートークンパターンのバリエーションを使用して、XSRF 攻撃に対する防御を行います。The ASP.NET Web Stack Runtime uses a variant of the synchronizer token pattern to defend against XSRF attacks. シンクロナイザートークンパターンの一般的な形式では、2つの XSRF トークンが (認証トークンに加えて) 各 HTTP POST と共にサーバーに送信されます。1つは cookie として、もう1つはフォーム値です。The general form of the synchronizer token pattern is that two anti-XSRF tokens are submitted to the server with each HTTP POST (In addition to the authentication token): one token as a cookie, and the other as a form value. ASP.NET ランタイムによって生成されるトークン値は、攻撃者によって決定的または予測可能ではありません。The token values generated by the ASP.NET runtime are not deterministic or predictable by an attacker. トークンが送信されると、サーバーでは、両方のトークンが比較チェックに合格した場合にのみ、要求を続行できます。When the tokens are submitted, the server will allow the request to proceed only if both tokens pass a comparison check.

XSRF 要求確認セッショントークンは、HTTP クッキーとして格納され、現在、ペイロードに次の情報が含まれています。The XSRF request verification session token is stored as an HTTP cookie and currently contains the following information in its payload:

  • ランダムな128ビット識別子で構成されるセキュリティトークン。A security token, consisting of a random 128-bit identifier.
    次の図は、Internet Explorer の F12 開発者ツールで表示される XSRF request 確認セッショントークンを示しています (これは現在の実装であり、変更される可能性があります)。The following image shows the XSRF request verification session token displayed with the Internet Explorer F12 developer tools: (Note this is the current implementation and is subject, even likely, to change.)

フィールドトークン<input type="hidden" /> として格納され、ペイロードに次の情報が含まれます。The field token is stored as an <input type="hidden" /> and contains the following information in its payload:

XSRF トークンのペイロードは暗号化および署名されるので、ツールを使用してトークンを確認するときにユーザー名を表示することはできません。The payloads of the anti-XSRF tokens are encrypted and signed, so you can't view the username when using tools to examine the tokens. Web アプリケーションが ASP.NET 4.0 をターゲットにしている場合、暗号化サービスは、 MachineKey. Encodeルーチンによって提供されます。When the web application is targeting ASP.NET 4.0, cryptographic services are provided by the MachineKey.Encode routine. Web アプリケーションが ASP.NET 4.5 以降を対象としている場合、暗号化サービスは、パフォーマンス、拡張性、およびセキュリティを向上させるために、 MachineKey. Protectルーチンによって提供されます。When the web application is targeting ASP.NET 4.5 or higher, cryptographic services are provided by the MachineKey.Protect routine, which offers better performance, extensibility, and security. 詳細については、次のブログ投稿を参照してください。See the following blog posts for more details:

トークンの生成Generating the tokens

XSRF トークンを生成するには、Razor ページから MVC ビューまたは @AntiForgery.GetHtml() から@Html.AntiForgeryTokenメソッドを呼び出します。To generate the anti-XSRF tokens, call the @Html.AntiForgeryToken method from an MVC view or @AntiForgery.GetHtml() from a Razor page. ランタイムは、次の手順を実行します。The runtime will then perform the following steps:

  1. 現在の HTTP 要求に XSRF セッショントークン (XSRF cookie __RequestVerificationToken) が既に含まれている場合は、セキュリティトークンがそこから抽出されます。If the current HTTP request already contains an anti-XSRF session token (the anti-XSRF cookie __RequestVerificationToken), the security token is extracted from it. HTTP 要求に XSRF セッショントークンが含まれていない場合、またはセキュリティトークンの抽出に失敗した場合は、新しいランダムな XSRF トークンが生成されます。If the HTTP request does not contain an anti-XSRF session token or if extraction of the security token fails, a new random anti-XSRF token will be generated.
  2. 上記の手順 (1) からのセキュリティトークンと、現在ログインしているユーザーの id を使用して、XSRF フィールドトークンが生成されます。An anti-XSRF field token is generated using the security token from step (1) above and the identity of the current logged-in user. (ユーザー id を決定する方法の詳細については、以下の「 特別なサポートを使用するシナリオ 」を参照してください)。さらに、 Iアンチ Forgeryadditionaldataproviderが構成されている場合、ランタイムはそのgetadditionaldataメソッドを呼び出し、返された文字列をフィールドトークンに含めます。(For more information on determining user identity, see the Scenarios with special support section below.) Additionally, if an IAntiForgeryAdditionalDataProvider is configured, the runtime will call its GetAdditionalData method and include the returned string in the field token. (詳細については、「 構成と拡張機能 」を参照してください)。(See the Configuration and extensibility section for more information.)
  3. 手順 (1) で新しい XSRF トークンが生成された場合、それを含む新しいセッショントークンが作成され、送信 HTTP cookies コレクションに追加されます。If a new anti-XSRF token was generated in step (1), a new session token will be created to contain it and will be added to the outbound HTTP cookies collection. 手順 (2) のフィールドトークンは <input type="hidden" /> 要素にラップされ、この HTML マークアップは Html.AntiForgeryToken() または AntiForgery.GetHtml()の戻り値になります。The field token from step (2) will be wrapped in an <input type="hidden" /> element, and this HTML markup will be the return value of Html.AntiForgeryToken() or AntiForgery.GetHtml().

トークンの検証Validating the tokens

受信した XSRF トークンを検証するために、開発者は自分の MVC アクションまたはコントローラーにValidateアンチ Forgerytoken属性を含めるか、または自分の Razor ページから @AntiForgery.Validate() を呼び出します。To validate the incoming anti-XSRF tokens, the developer includes a ValidateAntiForgeryToken attribute on her MVC action or controller, or she calls @AntiForgery.Validate() from her Razor page. ランタイムは、次の手順を実行します。The runtime will perform the following steps:

  1. 受信セッショントークンとフィールドトークンが読み取られ、それぞれから抽出された XSRF トークンが読み取られます。The incoming session token and field token are read and the anti-XSRF token extracted from each. XSRF トークンは、生成ルーチンのステップごとに同一である必要があります (2)。The anti-XSRF tokens must be identical per step (2) in the generation routine.
  2. 現在のユーザーが認証されている場合、ユーザー名はフィールドトークンに格納されているユーザー名と比較されます。If the current user is authenticated, her username is compared with the username stored in the field token. ユーザー名が一致している必要があります。The usernames must match.
  3. Iアンチ Forgeryadditionaldataproviderが構成されている場合、ランタイムはvalidateadditionaldataメソッドを呼び出します。If an IAntiForgeryAdditionalDataProvider is configured, the runtime calls its ValidateAdditionalData method. メソッドはブール値trueを返す必要があります。The method must return the Boolean value true.

検証が成功した場合、要求は続行できます。If validation succeeds, the request is allowed to proceed. 検証が失敗した場合、フレームワークはHttpantiforgeryexceptionをスローします。If validation fails, the framework will throw an HttpAntiForgeryException.

エラー条件Failure conditions

ASP.NET Web Stack Runtime v2 以降、検証中にスローされるHttpantiforgeryexceptionには、問題の原因に関する詳細情報が含まれています。Starting with The ASP.NET Web Stack Runtime v2, any HttpAntiForgeryException that is thrown during validation will contain detailed information about what went wrong. 現在定義されているエラー条件は次のとおりです。The currently defined failure conditions are:

  • セッショントークンまたはフォームトークンが要求に存在しません。The session token or form token is not present in the request.
  • セッショントークンまたはフォームトークンを読み取ることができません。The session token or form token is unreadable. この原因として最も可能性が高いのは、一致しないバージョンの ASP.NET Web Stack ランタイムを実行しているファーム、または web.config の <machineKey> 要素がコンピューター間で異なるファームです。The most likely cause of this is a farm running mismatched versions of The ASP.NET Web Stack Runtime or a farm where the <machineKey> element in Web.config differs between machines. Fiddler などのツールを使用して、XSRF トークンを使用して改ざんすることで、この例外を強制的に適用することができます。You can use a tool such as Fiddler to force this exception by tampering with either anti-XSRF token.
  • セッショントークンとフィールドトークンがスワップされました。The session token and field token were swapped.
  • セッショントークンとフィールドトークンに、一致しないセキュリティトークンが含まれています。The session token and field token contain mismatched security tokens.
  • フィールドトークン内に埋め込まれているユーザー名が、現在ログインしているユーザーのユーザー名と一致しません。The username embedded within the field token does not match the current logged-in user's username.
  • Iアンチ Forgeryadditionaldataprovider. ValidateAdditionalData メソッドはfalseを返しました。The IAntiForgeryAdditionalDataProvider.ValidateAdditionalData method returned false.

また、XSRF 施設では、トークンの生成または検証中に追加のチェックを実行することもできます。これらのチェック中にエラーが発生すると、例外がスローされる可能性があります。The anti-XSRF facilities may also perform additional checking during token generation or validation, and failures during these checks may result in exceptions being thrown. 詳細については、 WIF/ACS/要求ベースの認証構成と拡張 に関するセクションを参照してください。See the WIF / ACS / claims-based authentication and Configuration and extensibility sections for more information.

特別なサポートがあるシナリオScenarios with special support

匿名認証Anonymous authentication

XSRF システムには、匿名ユーザーの特別なサポートが含まれています ここで、"anonymous" は、"anonymous" プロパティがfalseを返すユーザーとして定義されています。The anti-XSRF system contains special support for anonymous users, where "anonymous" is defined as a user where the IIdentity.IsAuthenticated property returns false. シナリオには、ログインページへの XSRF 保護の提供 (ユーザーが認証される前) と、アプリケーションがIIdentity以外のメカニズムを使用してユーザーを識別するカスタム認証スキームが含まれます。Scenarios include providing XSRF protection to the login page (before the user is authenticated) and custom authentication schemes where the application uses a mechanism other than IIdentity to identify users.

これらのシナリオをサポートするには、セッションとフィールドトークンが、ランダムに生成された128ビットの不透明な識別子であるセキュリティトークンによって結合されていることを思い出してください。To support these scenarios, recall that the session and field tokens are joined by a security token, which is a 128-bit randomly-generated opaque identifier. このセキュリティトークンは、サイトを移動するときに個々のユーザーのセッションを追跡するために使用されます。これにより、匿名識別子の目的が効果的に提供されます。This security token is used to track an individual user's session as she navigates the site, so it effectively serves the purpose of an anonymous identifier. 上記で説明した生成ルーチンと検証ルーチンのユーザー名の代わりに、空の文字列が使用されます。An empty string is used in place of the username for the generation and validation routines described above.

WIF/ACS/要求ベースの認証WIF / ACS / claims-based authentication

通常、.NET Framework に組み込まれているIIdentityクラスには、特定のアプリケーション内の特定のユーザーを一意に識別するのに十分なIIdentity.Nameのプロパティがあります。Normally, the IIdentity classes built in to the .NET Framework have the property that IIdentity.Name is sufficient to uniquely identify a particular user within a particular application. たとえば、 FormsIdentity.Nameはメンバーシップデータベースに格納されているユーザー名 (そのデータベースに依存するすべてのアプリケーションに対して一意である) を返し、 WindowsIdentity.Nameはユーザーのドメイン修飾 id を返します。For example, FormsIdentity.Name returns the username stored in the membership database (which is unique for all applications depending on that database), WindowsIdentity.Name returns the domain-qualified identity of the user, and so on. これらのシステムは認証のみを行います。また、アプリケーションに対してユーザーを識別します。These systems provide not only authentication; they also identify users to an application.

一方、クレームベースの認証では、必ずしも特定のユーザーを識別する必要はありません。Claims-based authentication, on the other hand, does not necessarily require identifying a particular user. 代わりに、 ClaimsPrincipalClaimsIdentityの種類はクレームインスタンスのセットに関連付けられています。この場合、個々の要求は "18 歳以上の年齢" や "管理者" などになります。Instead, the ClaimsPrincipal and ClaimsIdentity types are associated with a set of Claim instances, where the individual claims might be "is 18+ years of age" or "is an administrator" to anything else. ユーザーは必ずしも特定されていないため、ランタイムはこの特定のユーザーの一意の識別子としてClaimsIdentity.Nameプロパティを使用できません。Since the user hasn't necessarily been identified, the runtime cannot use the ClaimsIdentity.Name property as a unique identifier for this particular user. チームは実際の例を見てきました。 ClaimsIdentity.Namenullを返し、フレンドリ (表示) 名を返します。それ以外の場合は、ユーザーの一意の識別子として使用するのに適していない文字列を返します。The team has seen real-world examples where ClaimsIdentity.Name returns null, returns a friendly (display) name, or otherwise returns a string that isn't appropriate for use as a unique identifier for the user.

信頼性情報ベースの認証を使用する多くのデプロイでは、特にAzure Access Control Service (ACS) を使用します。Many of deployments which use claims-based authentication are using Azure Access Control Service (ACS) in particular. ACS を使用すると、開発者は個々のid プロバイダー (ADFS、Microsoft アカウントプロバイダー、yahoo! などの OpenID プロバイダーなど) を構成し、id プロバイダーは名前識別子を返すことができます。ACS allows the developer to configure individual identity providers (such as ADFS, the Microsoft Account provider, OpenID providers like Yahoo!, etc.), and the identity providers return name identifiers. これらの名前識別子には、電子メールアドレスのような個人を特定できる情報 (PII) を含めることができます。また、個人の個人識別子 (PPID) のように匿名化することもできます。These name identifiers may contain Personally Identifiable Information (PII) like an email address, or they could be anonymized like a Private Personal Identifier (PPID). タプル (id プロバイダー、名前識別子) は、サイトを参照している間、特定のユーザーに適切な追跡トークンとして十分に機能します。そのため、ASP.NET Web Stack ランタイムは、を生成するときに、ユーザー名の代わりにタプルを使用できます。XSRF のフィールドトークンを検証しています。Regardless, the tuple (identity provider, name identifier) sufficiently serves as an appropriate tracking token for a particular user while she is browsing the site, so the ASP.NET Web Stack Runtime can use the tuple in place of the username when generating and validating anti-XSRF field tokens. Id プロバイダーと名前識別子の特定の Uri は次のとおりです。The particular URIs for the identity provider and the name identifier are :

  • https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider
  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

(詳細については、このACS ドキュメントページを参照してください。)(see this ACS doc page for more info.)

トークンを生成または検証するときに、ASP.NET Web スタックランタイムは実行時に次の型にバインドします。When generating or validating a token, the ASP.NET Web Stack Runtime will at runtime try binding to the types:

  • Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (WIF SDK の場合)Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (For the WIF SDK.)
  • System.Security.Claims.ClaimsIdentity (.NET 4.5 の場合)。System.Security.Claims.ClaimsIdentity (For .NET 4.5).

これらの型が存在し、現在のユーザーのIIIIdentityがこれらの型のいずれかを実装しているかサブクラスを実装している場合、XSRF ファシリティは、トークンを生成および検証するときに、ユーザー名の代わりに (id プロバイダー、名前識別子) タプルを使用します。If these types exist, and if the current user's IIIIdentity implements or subclasses one of these types, the anti-XSRF facility will use the (identity provider, name identifier) tuple in place of the username when generating and validating the tokens. このようなタプルが存在しない場合、要求は失敗し、開発者に対して、使用中の特定の要求ベースの認証メカニズムを理解するように XSRF システムを構成する方法を説明するエラーが表示されます。If no such tuple is present, the request will fail with an error describing to the developer how to configure the anti-XSRF system to understand the particular claims-based authentication mechanism in use. 詳細については、「 構成と拡張機能 」を参照してください。See the Configuration and extensibility section for more information.

OAuth/OpenID 認証OAuth / OpenID authentication

最後に、XSRF 機能は、OAuth または OpenID 認証を使用するアプリケーションに対して特別なサポートを行います。Finally, the anti-XSRF facility has special support for applications which use OAuth or OpenID authentication. このサポートはヒューリスティックに基づいています。現在のIIdentity.Nameが http://または https://で始まる場合は、既定の stringcomparison.ordinalignorecase comparer ではなく序数の比較子を使用して、ユーザー名の比較が行われます。This support is heuristic-based: if the current IIdentity.Name begins with http:// or https://, then username comparisons will be done using an Ordinal comparer rather than the default OrdinalIgnoreCase comparer.

構成と拡張性Configuration and extensibility

場合によっては、開発者が XSRF の生成と検証の動作を厳密に制御する必要があります。Occasionally, developers may want tighter control over the anti-XSRF generation and validation behaviors. たとえば、MVC と Web ページのヘルパーの既定の動作である HTTP cookie を応答に自動的に追加することは望ましくありません。開発者は、トークンを他の場所に保存することをお勧めします。For example, perhaps the MVC and Web Pages helpers' default behavior of automatically adding HTTP cookies to the response is undesirable, and the developer may wish to persist the tokens elsewhere. これを支援するために、次の2つの Api が存在します。There exist two APIs to assist with this:

AntiForgery.GetTokens(string oldCookieToken, out string newCookieToken, out string formToken);
AntiForgery.Validate(string cookieToken, string formToken);

Gettokensメソッドは、既存の XSRF 要求確認セッショントークン (null) を入力として受け取り、新しい XSRF request 検証セッショントークンとフィールドトークンを出力として生成します。The GetTokens method takes as input an existing XSRF request verification session token (which may be null) and produces as output a new XSRF request verification session token and field token. トークンは、装飾のない単なる不透明な文字列です。インスタンスのFormtoken値は、<入力> タグにラップされません。The tokens are simply opaque strings with no decoration; the formToken value will for instance not be wrapped in an <input> tag. Newcookietoken値は null にすることができます。このエラーが発生した場合は、 Oldcookietoken値が引き続き有効であり、新しい応答クッキーを設定する必要はありません。The newCookieToken value may be null; if this occurs, then the oldCookieToken value is still valid and no new response cookie need be set. Gettokensの呼び出し元は、必要な応答クッキーを保持したり、必要なマークアップを生成したりします。Gettokensメソッド自体は、応答を副作用として変更しません。The caller of GetTokens is responsible for persisting any necessary response cookies or generating any necessary markup; the GetTokens method itself will not alter the response as a side effect. Validateメソッドは、受信セッションとフィールドトークンを受け取り、前述の検証ロジックを実行します。The Validate method takes the incoming session and field tokens and runs the aforementioned validation logic over them.

AntiForgeryConfigAntiForgeryConfig

開発者は、アプリケーション_の起動から、XSRF システムを構成できます。The developer may configure the anti-XSRF system from Application_Start. 構成はプログラムによって行います。Configuration is programmatic. 次に、静的なアンチ Forgeryconfig型のプロパティについて説明します。The properties of the static AntiForgeryConfig type are described below. クレームを使用するほとんどのユーザーは、UniqueClaimTypeIdentifier プロパティを設定します。Most users using claims will want to set the UniqueClaimTypeIdentifier property.

プロパティProperty 説明Description
AdditionalDataProviderAdditionalDataProvider トークンの生成中に追加データを提供し、トークンの検証中に追加のデータを使用するIアンチ ForgeryadditionaldataproviderAn IAntiForgeryAdditionalDataProvider that provides additional data during token generation and consumes additional data during token validation. 既定値は、null です。The default value is null. 詳細については、「 Iアンチ Forgeryadditionaldataprovider 」セクションを参照してください。For more information, see the IAntiForgeryAdditionalDataProvider section.
CookieNameCookieName XSRF のセッショントークンを格納するために使用される HTTP クッキーの名前を提供する文字列。A string that provides the name of the HTTP cookie that is used to store the anti-XSRF session token. この値が設定されていない場合、アプリケーションの展開された仮想パスに基づいて、名前が自動的に生成されます。If this value is not set, a name will be automatically generated based on the application's deployed virtual path. 既定値は、null です。The default value is null.
RequireSslRequireSsl SSL で保護されたチャネル経由で XSRF トークンを送信する必要があるかどうかを指定するブール値。A Boolean that dictates whether the anti-XSRF tokens are required to be submitted over an SSL-secured channel. この値がtrueの場合、自動的に生成される cookie には "secure" フラグが設定され、SSL 経由で送信されていない要求内から呼び出された場合、XSRF api はスローします。If this value is true, any automatically-generated cookies will have the "secure" flag set, and the anti-XSRF APIs will throw if called from within a request that is not submitted via SSL. 既定値は false です。The default value is false.
SuppressIdentityHeuristicChecksSuppressIdentityHeuristicChecks XSRF システムで、要求ベースの id のサポートを非アクティブ化するかどうかを指定するブール値。A Boolean that dictates whether the anti-XSRF system should deactivate its support for claims-based identities. この値がtrueの場合、 IIdentity.Nameはユーザーごとの一意の識別子として使用するのが適切であると想定し、 WIF/ACS/要求ベースの認証セクションで説明されているように、特殊なケースのIClaimsIdentityまたはClClaimsIdentityを試行しません。If this value is true, the system will assume that IIdentity.Name is appropriate for use as a unique per-user identifier and will not try to special-case IClaimsIdentity or ClClaimsIdentity as described in the WIF / ACS / claims-based authentication section. 既定値は false です。The default value is false.
UniqueClaimTypeIdentifierUniqueClaimTypeIdentifier 一意のユーザーごとの識別子としての使用に適した要求の種類を示す文字列。A string that indicates which claim type is appropriate for use as a unique per-user identifier. この値が設定されていて、現在のIIdentityがクレームベースの場合、システムはUniqueClaimTypeIdentifierによって指定された種類の要求を抽出しようとし、フィールドトークンを生成するときに、ユーザーのユーザー名の代わりに対応する値が使用されます。If this value is set and the current IIdentity is claims-based, the system will attempt to extract a claim of the type specified by UniqueClaimTypeIdentifier, and the corresponding value will be used in place of the user's username when generating the field token. 要求の種類が見つからない場合、システムは要求に失敗します。If the claim type is not found, the system will fail the request. 既定値はnullです。これは、ユーザーのユーザー名の代わりに、前に説明したように、システムが (id プロバイダー、名前識別子) タプルを使用する必要があることを示します。The default value is null, which indicates that the system should use the (identity provider, name identifier) tuple as previously described in place of the user's username.

IAntiForgeryAdditionalDataProviderIAntiForgeryAdditionalDataProvider

Iアンチ Forgeryadditionaldataprovider 型を使用すると、開発者は、各トークンの追加データをラウンドトリップさせることで、XSRF システムの動作を拡張できます。The IAntiForgeryAdditionalDataProvider type allows developers to extend the behavior of the anti-XSRF system by round-tripping additional data in each token. Getadditionaldataメソッドは、フィールドトークンが生成されるたびに呼び出され、戻り値は生成されたトークン内に埋め込まれます。The GetAdditionalData method is called each time a field token is generated, and the return value is embedded within the generated token. 実装者は、タイムスタンプ、nonce、またはこのメソッドからのその他の値を返すことができます。An implementer could return a timestamp, a nonce, or any other value she wishes from this method.

同様に、 Validateadditionaldataメソッドは、フィールドトークンが検証されるたびに呼び出され、トークン内に埋め込まれた "追加データ" 文字列がメソッドに渡されます。Similarly, the ValidateAdditionalData method is called each time a field token is validated, and the "additional data" string that was embedded within the token is passed to the method. 検証ルーチンは、(トークンの作成時に現在の時刻をチェックすることによって) タイムアウトを実装したり、nonce チェックルーチンやその他の必要なロジックを実装したりすることができます。The validation routine could implement a timeout (by checking the current time against the time that was stored when the token was created), a nonce checking routine, or any other desired logic.

設計上の決定とセキュリティに関する考慮事項Design decisions and security considerations

セッションとフィールドトークンをリンクするセキュリティトークンは、匿名/認証されていないユーザーを XSRF 攻撃から保護する場合にのみ、技術的には必要です。The security token that links the session and field tokens is technically only necessary when trying to protect anonymous / unauthenticated users against XSRF attacks. ユーザーが認証されると、認証トークン自体 (cookie の形式で送信された可能性があります) をシンクロナイザートークンペアの半分として使用できるようになります。When the user is authenticated, the authentication token itself (presumably submitted in the form of a cookie) could be used as one half of a synchronizer token pair. ただし、認証されていないユーザーによるログインページの保護には有効なシナリオがあります。また、認証されたユーザーであっても、常にセキュリティトークンを生成して検証することによって、XSRF の対策ロジックがより簡単になりました。However, there are valid scenarios for protecting login pages hit by unauthenticated users, and the anti-XSRF logic was made simpler by always generating and validating the security token, even for authenticated users. また、攻撃者によってフィールドトークンが侵害される可能性がある場合に、追加の保護も提供します。これにより、セッショントークンが攻撃者にとって別のハードルになる可能性があります。It also does provide some additional protection in the event that a field token is ever compromised by an attacker, as setting or guessing the session token would be another hurdle for the attacker to overcome.

複数のアプリケーションが1つのドメインでホストされている場合、開発者は注意を払う必要があります。Developers should use caution when multiple applications are hosted in a single domain. たとえば、 example1.cloudapp.netexample2.cloudapp.netは異なるホストですが、 cloudapp.net ドメイン* のすべてのホスト間には暗黙の信頼関係があります。For example, even though example1.cloudapp.net and example2.cloudapp.net are different hosts, there is an implicit trust relationship between all hosts under the *.cloudapp.net domain. この暗黙的な信頼関係により、信頼できない可能性のあるホストが互いの cookie に影響を与えることがあります (AJAX 要求を管理する同じオリジンポリシーは、必ずしも HTTP クッキーに適用されるわけではありません)。This implicit trust relationship allows potentially untrusted hosts to affect each other's cookies (the same-origin policies that govern AJAX requests do not necessarily apply to HTTP cookies). ASP.NET Web Stack ランタイムでは、ユーザー名がフィールドトークンに埋め込まれるという点が軽減されます。したがって、悪意のあるサブドメインがセッショントークンを上書きできる場合でも、ユーザーに有効なフィールドトークンを生成することはできません。The ASP.NET Web Stack Runtime provides some mitigation in that the username is embedded into the field token, so even if a malicious subdomain is able to overwrite a session token it will be unable to generate a valid field token for the user. ただし、このような環境でホストされている場合、組み込みの XSRF ルーチンは、セッションハイジャックやログイン XSRF を防ぐことはできません。However, when hosted in such an environment the built-in anti-XSRF routines still cannot defend against session hijacking or login XSRF.

現在、XSRF ルーチンはクリックジャッキングを防御するものではありません。The anti-XSRF routines currently do not defend against clickjacking. クリックジャッキングに対して自身を防御する必要があるアプリケーションは、各応答で X フレームオプション: sameorigin ヘッダーを送信することによって簡単に行うことができます。Applications that wish to defend themselves against clickjacking may easily do so by sending an X-Frame-Options: SAMEORIGIN header with each response. このヘッダーは、最近のすべてのブラウザーでサポートされています。This header is supported by all recent browsers. 詳細については、 IE ブログSDL ブログowaspを参照してください。For more information, see the IE blog, the SDL blog, and OWASP. ASP.NET Web スタックランタイムは、今後のリリースで、MVC と Web ページの XSRF ヘルパーが自動的にこのヘッダーを設定し、アプリケーションがこの攻撃に対して自動的に保護されるようにします。The ASP.NET Web Stack Runtime may in some future release make the MVC and Web Pages anti-XSRF helpers automatically set this header so that applications are automatically protected against this attack.

Web 開発者は、サイトが XSS 攻撃に対して脆弱でないことを継続的に確認する必要があります。Web developers should continue to ensure that their site is not vulnerable to XSS attacks. XSS 攻撃は非常に強力であり、悪用が成功すると、XSRF 攻撃に対して ASP.NET Web Stack Runtime 防御も破壊されます。XSS attacks are very powerful, and a successful exploit would also break the ASP.NET Web Stack Runtime defenses against XSRF attacks.

Acknowledgement (受信確認)Acknowledgment

@LeviBroderick、ASP.NET のセキュリティコードの大部分をこの情報の大部分に書いています。@LeviBroderick, who wrote much of the ASP.NET security code the bulk of this information.