Prevenzione di XSRF/CSRF in ASP.NET MVC e pagine WebXSRF/CSRF Prevention in ASP.NET MVC and Web Pages

da Rick Andersonby Rick Anderson

Richiesta intersito falsa (nota anche come XSRF o CSRF) è un attacco contro applicazioni ospitate sul web in base al quale un sito web dannoso può influenzare l'interazione tra un browser client e un sito web considerato attendibile da tale browser.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. Questi attacchi sono possibili in quanto i web browser invia i token di autenticazione automaticamente con ogni richiesta a un sito web.These attacks are made possible because web browsers will send authentication tokens automatically with every request to a web site. L'esempio canonico è un cookie di autenticazione, ad esempio, ASP. Ticket di autenticazione basata su form di NET.The canonical example is an authentication cookie, such as ASP.NET's Forms Authentication ticket. Tuttavia, siti web che utilizzano qualsiasi meccanismo di autenticazione persistente (ad esempio l'autenticazione di Windows, Basic e così via) di destinazione per questi attacchi.However, web sites which use any persistent authentication mechanism (such as Windows Authentication, Basic, and so forth) can be targeted by these attacks.

Un attacco XSRF è diverso da un attacco di phishing.An XSRF attack is distinct from a phishing attack. Gli attacchi di phishing richiedono l'interazione da parte della vittima.Phishing attacks require interaction from the victim. In un attacco di phishing, un sito web dannoso imita il sito web di destinazione e la vittima viene indotta a fornire le informazioni riservate all'autore dell'attacco.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. In un attacco XSRF non è spesso interagisce necessaria da parte della vittima.In an XSRF attack, there is often no interaction necessary from the victim. Piuttosto, l'autore dell'attacco si basa il browser invii automaticamente tutti i cookie pertinenti al sito web di destinazione.Rather, the attacker is relying on the browser automatically sending all relevant cookies to the destination web site.

Per altre informazioni, vedere la Open Web Application Security Project(OWASP) XSRF.For more information, see the Open Web Application Security Project(OWASP) XSRF.

Anatomia di un attaccoAnatomy of an attack

Per spostarsi all'interno di un attacco XSRF, prendere in considerazione un utente che si desidera eseguire alcune operazioni di banking online.To walk through an XSRF attack, consider a user who wants to perform some online banking transactions. L'utente visita prima WoodgroveBank.com e i log, a quel punto l'intestazione della risposta conterrà il cookie di autenticazione: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. }

Poiché il cookie di autenticazione è un cookie di sessione, si verrà cancellato automaticamente dal browser alla chiusura del processo del browser.Because the authentication cookie is a session cookie, it will be automatically cleared by the browser when the browser process exits. Tuttavia, fino a quel momento, il browser includerà automaticamente i cookie con ogni richiesta a WoodgroveBank.com.However, until that time, the browser will automatically include the cookie with each request to WoodgroveBank.com. A questo punto, l'utente vuole trasferire 1000 dollari per un altro account, in modo che Anna compila un modulo nel sito di servizi bancari, e il browser invia la richiesta al server: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

Poiché questa operazione ha un effetto collaterale (all'avvio di una transazione monetaria), il sito di servizi bancari ha scelto di richiedere una richiesta HTTP POST per avviare l'operazione.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. Il server legge il token di autenticazione della richiesta, Cerca il numero di account dell'utente corrente, verifica che i fondi sufficienti esiste e quindi avvia la transazione nell'account di destinazione.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.

L'utente online banking completo, l'utente visita il sito di servizi bancari e visita altri percorsi sul web.Her online banking complete, the user navigates away from the banking site and visits other locations on the web. Uno di quei siti – fabrikam.com – include il markup seguente in una pagina incorporata all'interno di un' <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>

Che a sua fa sì che il browser effettuare questa richiesta: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

L'autore dell'attacco sta sfruttando il fatto che l'utente potrebbe avere ancora un token di autenticazione valido per il sito web di destinazione e Anna Usa un piccolo frammento di codice di Javascript per fare in modo il browser apportare automaticamente una richiesta HTTP POST al sito di destinazione.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. Se il token di autenticazione è ancora valido, il sito di servizi bancari avvierà un trasferimento di $250 conto della scelta dell'utente malintenzionato.If the authentication token is still valid, the banking site will initiate a transfer of $250 into the account of the attacker's choosing.

Mitigazioni inefficaciIneffective mitigations

È interessante notare che nello scenario precedente, il fatto che WoodgroveBank.com è stato possibile accedere tramite SSL e ha un cookie di autenticazione solo SSL è stato sufficiente per contrastare l'attacco.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. L'autore dell'attacco è in grado di specificare il schema URI (https) nel proprio <form> elemento e il browser continuerà a inviare i cookie non scaduti al sito di destinazione, purché i cookie sono coerenti con l'URI schema di destinazione prevista.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.

Si potrebbe sostenere che l'utente deve semplicemente non visitare siti non attendibili, come visitato solo siti attendibili è consente di rimanere sicuri.One could argue that the user should simply not visit untrusted sites, as visiting only trusted sites is helps to remain safe online. Ecco alcuni dati reali a questo, ma purtroppo questa raccomandazione non è sempre pratica.There is some truth to this, but unfortunately this advice is not always practical. Ad esempio l'utente "considera attendibile" il sito di notizie locali ConsolidatedMessenger.Perhaps the user "trusts" the local news site ConsolidatedMessenger. Una vulnerabilità XSS che consente a un utente malintenzionato di inserire lo stesso frammento di codice che era in esecuzione in fabrikam.com ConsolidatedMessenger.com e passa alla visita che invece del sito, ma tale sito.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.

È possibile verificare che le richieste in ingresso hanno una intestazione Referer che fa riferimento il dominio.You can verify that incoming requests have a Referer header referencing your domain. L'operazione arresterà involontariamente autore richieste di un dominio di terze parti.This will stop requests unwittingly submitted from a third-party domain. Tuttavia, alcune persone disabilitare intestazione Referer del browser per motivi di privacy e gli utenti malintenzionati possono talvolta effettuare lo spoofing tale intestazione se la vittima è determinate installato software non sicuri.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. Verifica per determinare se il intestazione Referer non viene considerato un approccio sicuro per la prevenzione degli attacchi XSRF.Verifying the Referer header is not considered a secure approach to preventing XSRF attacks.

Prevenzione di XSRF Runtime Stack WebWeb Stack Runtime XSRF mitigations

ASP.NET Web Stack di Runtime Usa una variante del modello di token sincronizzatore per difendersi da attacchi XSRF.The ASP.NET Web Stack Runtime uses a variant of the synchronizer token pattern to defend against XSRF attacks. La forma generale del modello di token del programma di sincronizzazione è che due token anti-XSRF vengano inviate al server con ogni richiesta HTTP POST (oltre al token di autenticazione): un token come un cookie e l'altro come valore di modulo.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. I valori del token generati dal runtime di ASP.NET non sono deterministiche o stimabile da un utente malintenzionato.The token values generated by the ASP.NET runtime are not deterministic or predictable by an attacker. Quando vengono inviati i token, il server consentirà alla richiesta di procedere solo se entrambi i token superano un controllo di confronto.When the tokens are submitted, the server will allow the request to proceed only if both tokens pass a comparison check.

La verifica della richiesta XSRF token di sessione viene archiviato come un cookie HTTP e attualmente contiene le informazioni seguenti nel relativo payload:The XSRF request verification session token is stored as an HTTP cookie and currently contains the following information in its payload:

  • Un token di sicurezza, costituito da un identificatore casuale a 128 bit.A security token, consisting of a random 128-bit identifier.
    L'immagine seguente mostra il token di sessione XSRF richiesta verifica visualizzato con strumenti di sviluppo F12 di Internet Explorer: (questo è l'implementazione corrente di soggetto, ancora soggette a modifica.)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.)

Il token pole viene archiviato come un <input type="hidden" /> e contiene le informazioni seguenti nel relativo payload:The field token is stored as an <input type="hidden" /> and contains the following information in its payload:

I payload dei token anti-XSRF vengono crittografati e firmati, pertanto non è possibile visualizzare il nome utente quando si usano strumenti per esaminare i token.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. Quando l'applicazione web è la destinazione di ASP.NET 4.0, forniti da servizi di crittografia di machineKey routine.When the web application is targeting ASP.NET 4.0, cryptographic services are provided by the MachineKey.Encode routine. Quando l'applicazione web è destinato a ASP.NET 4.5 o versione successiva, crittografia servizi vengono forniti dal machineKey. Protect routine, che offre migliori prestazioni, estendibilità e sicurezza.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. Il seguente post di blog per altri dettagli, vedere:See the following blog posts for more details:

Generazione di tokenGenerating the tokens

Per generare i token anti-XSRF, chiamare il @Html.AntiForgeryToken metodo da una visualizzazione MVC o @AntiForgery.GetHtml() da una pagina Razor.To generate the anti-XSRF tokens, call the @Html.AntiForgeryToken method from an MVC view or @AntiForgery.GetHtml() from a Razor page. Il runtime eseguirà quindi i passaggi seguenti:The runtime will then perform the following steps:

  1. Se la richiesta HTTP corrente contiene già un token di sessione di anti-XSRF (il cookie di anti-XSRF _ _RequestVerificationToken), il token di sicurezza verrà estratti da quest'ultimo.If the current HTTP request already contains an anti-XSRF session token (the anti-XSRF cookie __RequestVerificationToken), the security token is extracted from it. Se la richiesta HTTP non contiene un token di sessione di anti-XSRF o estrazione del token di sicurezza non riesce, verrà generato un nuovo token anti-XSRF casuale.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. Un token di anti-XSRF campo viene generato usando il token di sicurezza dal passaggio (1) e l'identità dell'utente corrente ha eseguito l'accesso.An anti-XSRF field token is generated using the security token from step (1) above and the identity of the current logged-in user. (Per altre informazioni su come determinare l'identità dell'utente, vedere la scenari con un supporto speciale sezione riportata di seguito.) Inoltre, se un' IAntiForgeryAdditionalDataProvider è configurato, il runtime chiama relativo GetAdditionalData (metodo) e includere la stringa restituita nel token di campo.(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. (Vedere la Configuration ed estendibilità sezione per altre informazioni.)(See the Configuration and extensibility section for more information.)
  3. Se un nuovo token anti-XSRF è stato generato nel passaggio (1), un nuovo token di sessione per contenerlo verrà creato e verrà aggiunto all'insieme di cookie HTTP in uscita.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. Il token del campo ottenuto nel passaggio (2) verrà eseguito in un' <input type="hidden" /> elemento e il markup HTML sarà il valore restituito di Html.AntiForgeryToken() o 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().

Convalida i tokenValidating the tokens

Per convalidare il token anti-XSRF in ingresso, lo sviluppatore include un' ValidateAntiForgeryToken attributo sul suo azione MVC o controller oppure digita @AntiForgery.Validate() dalla propria pagina Razor.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. Il runtime eseguirà i passaggi seguenti:The runtime will perform the following steps:

  1. Il token di sessione in ingresso e un token di campo vengono letti e il token anti-XSRF estratti da ognuna.The incoming session token and field token are read and the anti-XSRF token extracted from each. I token anti-XSRF devono essere identici per ogni passaggio (2) nella routine di generazione.The anti-XSRF tokens must be identical per step (2) in the generation routine.
  2. Se l'utente corrente è autenticato, il suo nome utente viene confrontato con il nome utente archiviato nel token di campo.If the current user is authenticated, her username is compared with the username stored in the field token. I nomi utente devono corrispondere.The usernames must match.
  3. Se un' IAntiForgeryAdditionalDataProvider configurato, il runtime chiama relativo ValidateAdditionalData (metodo).If an IAntiForgeryAdditionalDataProvider is configured, the runtime calls its ValidateAdditionalData method. Il metodo deve restituire il valore booleano true.The method must return the Boolean value true.

Se la convalida ha esito positivo, la richiesta può continuare.If validation succeeds, the request is allowed to proceed. Se la convalida non riesce, il framework genera una HttpAntiForgeryException.If validation fails, the framework will throw an HttpAntiForgeryException.

Condizioni di erroreFailure conditions

Inizia con il Runtime di Stack Web ASP.NET v2, qualsiasi HttpAntiForgeryException che viene generata un'eccezione durante la convalida conterrà informazioni dettagliate sulle cause dell'errore.Starting with The ASP.NET Web Stack Runtime v2, any HttpAntiForgeryException that is thrown during validation will contain detailed information about what went wrong. Le condizioni di errore attualmente definiti sono:The currently defined failure conditions are:

  • Il token di sessione o un token del form non è presente nella richiesta.The session token or form token is not present in the request.
  • Il token di sessione o un token del form è illeggibile.The session token or form token is unreadable. La causa più probabile di questo oggetto è una farm che eseguono versioni non corrispondenti di The ASP.NET Web Stack di Runtime o in una farm in cui il <machineKey> in Web. config è diverso tra i computer.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. È possibile utilizzare uno strumento come Fiddler per forzare questa eccezione, la manomissione di uno dei due token anti-XSRF.You can use a tool such as Fiddler to force this exception by tampering with either anti-XSRF token.
  • Il token di sessione e token pole sono stati scambiati.The session token and field token were swapped.
  • Il token di sessione e token pole contengono i token di sicurezza non corrispondenti.The session token and field token contain mismatched security tokens.
  • Il nome utente incorporato all'interno del token di campo non corrisponde a username ha eseguito l'accesso dell'utente corrente.The username embedded within the field token does not match the current logged-in user's username.
  • Il IAntiForgeryAdditionalDataProvider.ValidateAdditionalData metodo restituito false.The IAntiForgeryAdditionalDataProvider.ValidateAdditionalData method returned false.

Le funzionalità di anti-XSRF possono anche eseguire controlli aggiuntivi durante la generazione di token o la convalida e la generazione di eccezioni possono verificarsi errori durante questi controlli.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. Vedere la WIF / ACS / basata su attestazioni authentication e Configuration ed estendibilità sezioni per ulteriori informazioni.See the WIF / ACS / claims-based authentication and Configuration and extensibility sections for more information.

Scenari con un supporto specialeScenarios with special support

Autenticazione anonimaAnonymous authentication

Il sistema di anti-XSRF contiene un supporto speciale per gli utenti anonimi, dove "anonymous" è definito come un utente in cui il IIdentity restituisce proprietà 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. Gli scenari includono la protezione XSRF alla pagina di accesso (prima che l'utente viene autenticato) e gli schemi di autenticazione personalizzata in cui l'applicazione usa un meccanismo diverso da IIdentity per identificare gli utenti.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.

Per supportare questi scenari, è importante ricordare che i token di sessione e campo vengono uniti mediante un token di sicurezza, ovvero un identificatore opaco a 128 bit generato in modo casuale.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. Questo token di sicurezza viene usato per tenere traccia della sessione di un singolo utente come Anna passa il sito, in modo che svolge in modo efficace la funzione di un identificatore anonimo.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. Una stringa vuota viene usata al posto del nome utente per le routine di convalida e generazione descritte in precedenza.An empty string is used in place of the username for the generation and validation routines described above.

WIF / ACS / basata su attestazioni autenticazioneWIF / ACS / claims-based authentication

In genere, il IIdentity classi incorporate .NET Framework dispongono della proprietà che IIdentity.Name è sufficiente per identificare in modo univoco un utente specifico all'interno di una determinata applicazione.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. Ad esempio, FormsIdentity.Name restituisce il nome utente archiviato nel database delle appartenenze (che è univoco per tutte le applicazioni a seconda di quel database), WindowsIdentity.Name restituisce il identità di dominio completo dell'utente e così via.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. Questi sistemi forniscono non solo l'autenticazione. sono inoltre identificare agli utenti di un'applicazione.These systems provide not only authentication; they also identify users to an application.

L'autenticazione basata su attestazioni, d'altra parte, non necessariamente richiedono l'identificazione di un determinato utente.Claims-based authentication, on the other hand, does not necessarily require identifying a particular user. Al contrario, il ClaimsPrincipal e ClaimsIdentity tipi sono associati a un set di attestazione istanze, in cui le singole attestazioni potrebbero essere "is 18 anni di età" o " è un amministratore"in un account.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. Poiché l'utente non ha necessariamente stato identificato, il runtime non è possibile usare la ClaimsIdentity.Name proprietà come un identificatore univoco per questo utente specifico.Since the user hasn't necessarily been identified, the runtime cannot use the ClaimsIdentity.Name property as a unique identifier for this particular user. Il team ha riscontrato esempi reali in cui ClaimsIdentity.Name restituisce null, restituisce un nome descrittivo (display) o in caso contrario, restituisce una stringa che non è appropriata per l'utilizzo come un identificatore univoco per l'utente.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.

Molte delle distribuzioni che usano l'autenticazione basata su attestazioni usano Azure Access Control Service (ACS) in particolare.Many of deployments which use claims-based authentication are using Azure Access Control Service (ACS) in particular. Servizio contenitore di AZURE consente allo sviluppatore di configurare singole provider di identità (ad esempio ad FS, il provider di Account Microsoft, OpenID provider, ad esempio Yahoo!, e così via), e restituiscono i provider di identità denominare gli identificatori.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. Questi identificatori del nome possono contenere informazioni identificabili personalmente (PII), ad esempio un indirizzo di posta elettronica o potrebbe essere resi anonimi, ad esempio una personale privato identificatore (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). Indipendentemente da ciò, la tupla (provider di identità, identificatore nome) sufficientemente funge da un token di rilevamento appropriato per un determinato utente mentre Anna durante l'esplorazione del sito, in modo che il Runtime di ASP.NET Web Stack può utilizzare la tupla al posto del nome utente durante la generazione e la convalida dei token di campo anti-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. Gli URI specifico per il provider di identità e l'identificatore del nome sono:The particular URIs for the identity provider and the name identifier are :

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

(vedere questo pagina di documentazione di ACS per altre informazioni.)(see this ACS doc page for more info.)

Durante la generazione o la convalida un token, il Runtime di ASP.NET Web Stack in fase di runtime tenterà di associazione ai tipi: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 (Per il SDK WIF.)Microsoft.IdentityModel.Claims.IClaimsIdentity, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 (For the WIF SDK.)
  • System.Security.Claims.ClaimsIdentity (Per .NET 4.5).System.Security.Claims.ClaimsIdentity (For .NET 4.5).

In presenza di questi tipi e se l'utente corrente IIIIdentity implementa o alle sottoclassi uno di questi tipi, la funzionalità di anti-XSRF userà (provider di identità, identificatore nome) tuple anziché il nome utente durante la generazione e convalida i token.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. Se non è presente alcun tale tupla, la richiesta avrà esito negativo con un errore che descrive allo sviluppatore di come configurare il sistema di anti-XSRF per comprendere il meccanismo di autenticazione basata sulle attestazioni specifico in uso.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. Vedere le Configuration ed estendibilità sezione per altre informazioni.See the Configuration and extensibility section for more information.

OAuth / OpenID autenticazioneOAuth / OpenID authentication

Infine, la funzionalità di anti-XSRF include uno speciale supporto per le applicazioni che usano l'autenticazione OAuth o OpenID.Finally, the anti-XSRF facility has special support for applications which use OAuth or OpenID authentication. Questo supporto è basato sull'approccio euristico: se l'oggetto corrente IIdentity.Name inizi con http:// o https://, quindi i confronti di nome utente verranno eseguiti usando un operatore di confronto ordinale anziché l'operatore di confronto OrdinalIgnoreCase.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.

Configurazione ed estendibilitàConfiguration and extensibility

In alcuni casi, gli sviluppatori potrebbe essere necessario un controllo sulla generazione di anti-XSRF e i comportamenti di convalida.Occasionally, developers may want tighter control over the anti-XSRF generation and validation behaviors. Ad esempio, il comportamento predefinito degli helper MVC e pagine Web di aggiungendo automaticamente i cookie HTTP alla risposta è probabilmente indesiderato e lo sviluppatore può essere utile rendere persistenti i token in un' posizione.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. Esistono due API per agevolare questo:There exist two APIs to assist with this:

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

Il GetTokens metodo accetta come input un XSRF richiesta verifica sessione token esistente (che può essere null) e produce come output un nuovo token della sessione verifica XSRF richiesta e token pole.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. I token sono stringhe opache semplicemente senza decorazioni; il formToken valore, ad esempio non verrà racchiusi un <input> tag.The tokens are simply opaque strings with no decoration; the formToken value will for instance not be wrapped in an <input> tag. Il newCookieToken valore può essere null; in tal caso, il oldCookieToken valore sia ancora valido e nessun nuovo cookie di risposta debba essere impostata.The newCookieToken value may be null; if this occurs, then the oldCookieToken value is still valid and no new response cookie need be set. Il chiamante GetTokens è responsabile della persistenza di tutti i cookie di risposta necessarie o la generazione di alcun markup necessarie; le GetTokens metodo di stesso non modificherà la risposta come un effetto collaterale.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. Il Validate metodo accetta la sessione in ingresso e campo dei token e si esegue la logica di convalida menzionati in precedenza su di essi.The Validate method takes the incoming session and field tokens and runs the aforementioned validation logic over them.

AntiForgeryConfigAntiForgeryConfig

Lo sviluppatore può configurare il sistema di anti-XSRF dall'applicazione_Start.The developer may configure the anti-XSRF system from Application_Start. La configurazione è a livello di codice.Configuration is programmatic. Le proprietà di statica AntiForgeryConfig tipo sono descritti di seguito.The properties of the static AntiForgeryConfig type are described below. La maggior parte degli utenti che usano attestazioni saranno possibile impostare la proprietà UniqueClaimTypeIdentifier.Most users using claims will want to set the UniqueClaimTypeIdentifier property.

PropertyProperty DescrizioneDescription
AdditionalDataProviderAdditionalDataProvider Un' IAntiForgeryAdditionalDataProvider che fornisce dati aggiuntivi durante la generazione di token e utilizza i dati aggiuntivi durante la convalida del token.An IAntiForgeryAdditionalDataProvider that provides additional data during token generation and consumes additional data during token validation. Il valore predefinito è null.The default value is null. Per altre informazioni, vedere la IAntiForgeryAdditionalDataProvider sezione.For more information, see the IAntiForgeryAdditionalDataProvider section.
CookieNameCookieName Stringa che specifica il nome del cookie HTTP a cui viene usato per archiviare il token di sessione di anti-XSRF.A string that provides the name of the HTTP cookie that is used to store the anti-XSRF session token. Se questo valore non è impostato, verrà generato un nome da automaticamente in base al percorso virtuale distribuito dell'applicazione.If this value is not set, a name will be automatically generated based on the application's deployed virtual path. Il valore predefinito è null.The default value is null.
RequireSslRequireSsl Valore booleano che determina se il token anti-XSRF sono necessarie da inviare tramite un canale protetto con SSL.A Boolean that dictates whether the anti-XSRF tokens are required to be submitted over an SSL-secured channel. Se questo valore è true, qualsiasi cookie generato automaticamente verranno impostato il flag "secure" e le API di anti-XSRF genererà se chiamato dall'interno di una richiesta che non viene inviata tramite SSL.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. Il valore predefinito è false.The default value is false.
SuppressIdentityHeuristicChecksSuppressIdentityHeuristicChecks Valore booleano che determina se il sistema di anti-XSRF verrà disattivato il supporto per identità basate sulle attestazioni.A Boolean that dictates whether the anti-XSRF system should deactivate its support for claims-based identities. Se questo valore è true, il sistema presupporrà che IIdentity.Name può essere usata come identificatore utente univoco e non proverà a caso speciale IClaimsIdentityoppure ClClaimsIdentity come descritto nel WIF / ACS / basata su attestazioni autenticazione sezione.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. Il valore predefinito è false.The default value is false.
UniqueClaimTypeIdentifierUniqueClaimTypeIdentifier Una stringa che indica il tipo di attestazione che può essere usata come identificatore univoco per ogni utente.A string that indicates which claim type is appropriate for use as a unique per-user identifier. Se questo valore viene impostato e l'oggetto corrente IIdentity basata sulle attestazioni, il sistema tenterà di estrarre un'attestazione del tipo specificata da UniqueClaimTypeIdentifier, e verrà usato il valore corrispondente al posto di nome utente dell'utente durante la generazione del token di campo.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. Se il tipo di attestazione non viene trovato, il sistema avrà esito negativo della richiesta.If the claim type is not found, the system will fail the request. Il valore predefinito è null, che indica che il sistema deve utilizzare (provider di identità, identificatore nome) tupla come descritto in precedenza al posto di nome utente dell'utente.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

Il IAntiForgeryAdditionalDataProvider tipo consente agli sviluppatori di estendere il comportamento del sistema anti-XSRF, i dati aggiuntivi di andata e ritorno in ogni token.The IAntiForgeryAdditionalDataProvider type allows developers to extend the behavior of the anti-XSRF system by round-tripping additional data in each token. Il GetAdditionalData viene chiamato ogni volta che viene generato un token di campo e il valore restituito è incorporato all'interno del token generato.The GetAdditionalData method is called each time a field token is generated, and the return value is embedded within the generated token. Un implementatore potrebbe restituire un timestamp, un parametro nonce o qualsiasi altro valore che Anna vuole che da questo metodo.An implementer could return a timestamp, a nonce, or any other value she wishes from this method.

Analogamente, il ValidateAdditionalData viene chiamato ogni volta che viene convalidato un token di campo e la stringa "dati aggiuntivi" che è stata incorporata all'interno del token viene passata al metodo.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. La routine di convalida è stato possibile implementare un timeout (controllando l'ora corrente con l'ora in cui è stato archiviato quando è stato creato il token), un controllo della routine o qualsiasi altro parametro nonce desiderate per la logica.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.

Decisioni di progettazione e considerazioni sulla sicurezzaDesign decisions and security considerations

Il token di sicurezza che collega i token di sessione e il campo è tecnicamente necessario solo quando si tenta di proteggere gli utenti anonimi o autenticati da attacchi 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. Quando l'utente è autenticato, il token di autenticazione stesso (presumibilmente inviati sotto forma di cookie) può essere utilizzato come una coppia di metà di una sincronizzazione del token.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. Tuttavia, esistono scenari validi per la protezione delle pagine di accesso, l'hit testing, gli utenti non autenticati e la logica di anti-XSRF è stata resa più semplice da sempre la generazione e la convalida del token di sicurezza, anche per gli utenti autenticati.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. È inoltre fornire un livello di protezione aggiuntiva nel caso in cui un token di campo viene danneggiato da un utente malintenzionato, come l'impostazione o un'ipotesi che il token di sessione sarebbe un altro ostacolo per l'utente malintenzionato superare.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.

Gli sviluppatori devono prestare attenzione quando più applicazioni sono ospitate in un singolo dominio.Developers should use caution when multiple applications are hosted in a single domain. Ad esempio, anche se example1.cloudapp.net e example2.cloudapp.net sono diversi host, c'è una relazione di trust implicita tra tutti gli host sotto il *. cloudapp.net dominio.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. Questa relazione di trust implicita consente agli host potenzialmente non attendibili a hanno effetto sui cookie reciproci (lo stessa origine che regolano le richieste AJAX non vengono necessariamente applicati criteri per i cookie 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). Il Runtime di ASP.NET Web Stack fornisce alcuni mitigazione in quanto il nome utente viene incorporato nel token di campo, in modo che anche se un sottodominio dannoso è in grado di sovrascrivere un token di sessione non sarà in grado di generare un token di campo valido per l'utente.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. Tuttavia, quando ospitati in tale ambiente le routine incorporato anti-XSRF ancora non è possibile difendersi dal Hijack della sessione o account di accesso XSRF.However, when hosted in such an environment the built-in anti-XSRF routines still cannot defend against session hijacking or login XSRF.

Le routine di anti-XSRF attualmente non difendersi clickjacking.The anti-XSRF routines currently do not defend against clickjacking. Le applicazioni che intendo a difendersi contro il clickjacking possono farlo facilmente tramite l'invio di un X-Frame-Options: intestazione SAMEORIGIN con ogni risposta.Applications that wish to defend themselves against clickjacking may easily do so by sending an X-Frame-Options: SAMEORIGIN header with each response. Questa intestazione è supportata da tutti i browser recenti.This header is supported by all recent browsers. Per altre informazioni, vedere la blog di IE, il blog SDL, e OWASP.For more information, see the IE blog, the SDL blog, and OWASP. Il Runtime di ASP.NET Web Stack può in alcuni assicurarsi delle prossime versioni MVC e gli helper di anti-XSRF pagine Web questa intestazione viene impostata automaticamente in modo che le applicazioni vengano protetti automaticamente da questi attacchi.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.

Gli sviluppatori Web devono continuare ad assicurarsi che il sito non sia vulnerabile ad attacchi XSS.Web developers should continue to ensure that their site is not vulnerable to XSS attacks. Gli attacchi XSS sono molto potenti, e se l'attacco riesce anche interromperebbe il Runtime di ASP.NET Web Stack difese contro gli attacchi XSRF.XSS attacks are very powerful, and a successful exploit would also break the ASP.NET Web Stack Runtime defenses against XSRF attacks.

RiconoscimentoAcknowledgment

@LeviBroderick, che ha scritto gran parte del codice di protezione ASP.NET la maggior parte di queste informazioni.@LeviBroderick, who wrote much of the ASP.NET security code the bulk of this information.