Prevenire attacchi XSRF/CSRF (Cross-Site Request Forgery) in ASP.NET Core

Di Fiyaz Hasan e Rick Anderson

La falsificazione di richiesta intersito è un attacco contro le app ospitate sul Web, tramite cui un'app Web malevola può influenzare l'interazione tra un browser client e un'app Web che si fida di tale browser. Questi attacchi sono possibili perché i Web browser inviano automaticamente alcuni tipi di token di autenticazione con ogni richiesta a un sito Web. Questa forma di exploit è nota anche come attacco con un clic o guida di sessione perché l'attacco sfrutta la sessione autenticata in precedenza dell'utente. La richiesta intersito falsa è nota anche come XSRF o CSRF.

Un esempio di attacco CSRF:

1. Un utente accede a www.good-banking-site.example.com utilizzando l'autenticazione basata su form. Il server autentica l'utente e rilascia una risposta che include un'autenticazione cookie. Il sito è vulnerabile all'attacco perché considera attendibile qualsiasi richiesta ricevuta con un'autenticazione cookievalida.

2. L'utente visita un sito dannoso, www.bad-crook-site.example.com.

   Il sito dannoso, www.bad-crook-site.example.com, contiene un modulo HTML simile all'esempio seguente:

   <h1>Congratulations! You're a Winner!</h1>
   <form action="https://www.good-banking-site.example.com/api/account" method="post">
       <input type="hidden" name="Transaction" value="withdraw" />
       <input type="hidden" name="Amount" value="1000000" />
       <input type="submit" value="Click to collect your prize!" />
   </form>
   

   Si noti che il modulo action invia i dati al sito vulnerabile, non al sito dannoso. Questa è la parte "cross-site" di CSRF.

3. L'utente seleziona il pulsante invia. Il browser effettua la richiesta e include automaticamente l'autenticazione cookie per il dominio richiesto, www.good-banking-site.example.com.

4. La richiesta viene eseguita sul www.good-banking-site.example.com server con il contesto di autenticazione dell'utente e può eseguire qualsiasi azione che un utente autenticato possa eseguire.

Oltre allo scenario in cui l'utente seleziona il pulsante per inviare il modulo, il sito dannoso potrebbe:

• Eseguire uno script che invia automaticamente il modulo.
• Inviare il modulo come richiesta AJAX.
• Nascondere il modulo usando CSS.

Questi scenari alternativi non richiedono alcuna azione o input da parte dell'utente diverso da visitare inizialmente il sito dannoso.

L'uso di HTTPS non impedisce un attacco CSRF. Il sito dannoso può inviare una richiesta https://www.good-banking-site.example.com/ con la stessa facilità con cui può inviare una richiesta non sicura.

Alcuni attacchi usano endpoint che rispondono alle richieste GET, nel qual caso è possibile usare un tag immagine per eseguire l'azione. Questa forma di attacco è comune nei siti del forum che consentono immagini ma bloccano JavaScript. Le app che cambiano lo stato nelle richieste GET, in cui le variabili o le risorse vengono modificate, sono vulnerabili ad attacchi dannosi. Le richieste GET che cambiano lo stato non sono sicure. Una procedura consigliata consiste nel non modificare mai lo stato in una richiesta GET.

Gli attacchi CSRF sono possibili contro le app Web che usano cookie per l'autenticazione perché:

• I browser archivia i cookie rilasciati da un'app Web.
• I cookie archiviati includono cookie di sessione per gli utenti autenticati.
• I browser inviano tutti i cookie associati a un dominio all'app Web ogni richiesta indipendentemente dalla modalità di generazione della richiesta all'app all'interno del browser.

Tuttavia, gli attacchi CSRF non sono limitati a sfruttare i cookie. Ad esempio, anche l'autenticazione di base e digest è vulnerabile. Dopo che un utente accede con l'autenticazione di base o digest, il browser invia automaticamente le credenziali fino al termine della sessione.

In questo contesto, la sessione fa riferimento alla sessione sul lato client durante la quale l'utente viene autenticato. Non è correlato alle sessioni lato server o al middleware della sessione ASP.NET Core.

Gli utenti possono proteggersi dalle vulnerabilità CSRF adottando precauzioni:

• Disconnettersi dalle app Web al termine dell'uso.
• Cancellare periodicamente i cookie del browser.

Tuttavia, le vulnerabilità CSRF sono fondamentalmente un problema con l'app Web, non con l'utente finale.

Nozioni fondamentali di autenticazione

Cookie-based authentication è una forma comune di autenticazione. I sistemi di autenticazione basati su token sono in continua crescita, in particolare per le applicazioni a pagina singola.

CookieAutenticazione basata su

Quando un utente esegue l'autenticazione usando il nome utente e la password, viene rilasciato un token contenente un ticket di autenticazione. Il token può essere usato per l'autenticazione e l'autorizzazione. Il token viene archiviato come oggetto cookie inviato con ogni richiesta eseguita dal client. La generazione e la convalida di questo cookie vengono eseguite con il middleware di autenticazione cookie. Il middleware serializza il principale utente in un cookie crittografato. Nelle richieste successive, il middleware convalida il cookie, ricrea il principale e assegna il principale alla proprietà HttpContext.User.

Autenticazione basata su token

Quando un utente viene autenticato, viene rilasciato un token (non un token antiforgery). Il token contiene informazioni utente sotto forma di attestazioni o di un token di riferimento che indirizza l'app allo stato utente mantenuto all'interno dell'app. Quando un utente tenta di accedere a una risorsa che richiede l'autenticazione, il token viene inviato all'app con un'intestazione di autorizzazione aggiuntiva sotto forma di Bearer token. Questo approccio rende l'applicazione senza stato. In ogni richiesta successiva, il token viene passato nella richiesta di convalida lato server. Questo token non è crittografato, ma viene codificato. Nel server il token viene decodificato per accedere alle informazioni. Per inviare il token alle richieste successive, archiviare il token nella risorsa di archiviazione locale del browser. Posizionare un token nell'archiviazione locale del browser e recuperarlo e usarlo come token di connessione fornisce protezione dagli attacchi CSRF. Tuttavia, se l'app è vulnerabile all'inserimento di script tramite XSS o un file JavaScript esterno compromesso, un cyberattacker potrebbe recuperare qualsiasi valore dall'archiviazione locale e inviarlo a se stessi. ASP.NET Core codifica tutti gli output lato server dalle variabili per impostazione predefinita, riducendo il rischio di XSS. Se si esegue l'override di questo comportamento usando Html.Raw o codice personalizzato con input non attendibile, è possibile aumentare il rischio di XSS.

Non preoccuparsi della vulnerabilità CSRF se il token viene archiviato nella risorsa di archiviazione locale del browser. CSRF è un problema quando il token viene memorizzato in un cookie. Per altre informazioni, vedere l'esempio di codice SPA relativo al problema di GitHub che aggiunge due cookie.

Più app ospitate in un dominio

Gli ambienti di hosting condivisi sono vulnerabili all'hijacking della sessione, all'accesso CSRF e ad altri attacchi.

Anche se example1.contoso.net e example2.contoso.net sono host diversi, esiste una relazione di trust implicita tra gli host nel *.contoso.net dominio. Questa relazione di trust implicita consente agli host potenzialmente non attendibili di influire sui cookie degli altri (i criteri di stessa origine che regolano le richieste AJAX non si applicano necessariamente ai cookie HTTP).

Gli attacchi che sfruttano i cookie attendibili tra app ospitate nello stesso dominio possono essere impediti non condividendo domini. Quando ogni app è ospitata nel proprio dominio, non esiste alcuna relazione di trust implicita cookie da sfruttare.

Antifalsificazione in ASP.NET Core

Avviso

ASP.NET Core implementa l'antiforgeria usando ASP.NET Core Data Protection. Lo stack di protezione dati deve essere configurato per funzionare in una server farm. Per altre informazioni, vedere Configurazione della protezione dei dati.

Il middleware antiforgery viene aggiunto al contenitore di Dependency Injection quando viene chiamata una delle API seguenti in Program.cs:

• AddMvc
• MapRazorPages
• MapControllerRoute
• AddRazorComponents

Per ulteriori informazioni, vedere Antiforgery con API minime.

FormTagHelper inserisce token antifalsificazione negli elementi del modulo HTML. Il seguente markup in un file Razor genera automaticamente token anti-contraffazione.

<form method="post">
    <!-- ... -->
</form>

Analogamente, IHtmlHelper.BeginForm genera token antifalsificazione per impostazione predefinita se il metodo del form non è GET.

La generazione automatica di token antiforgery per gli elementi del modulo HTML si verifica quando il <form> tag contiene l'attributo method="post" e uno dei seguenti è true:

• L'attributo action è vuoto (action="").
• L'attributo action non viene fornito (<form method="post">).

La generazione automatica di token antiforgery per gli elementi del modulo HTML può essere disabilitata:

• Disabilitare in modo esplicito i token antifalsificazione con l'attributo asp-antiforgery:

  <form method="post" asp-antiforgery="false">
      <!-- ... -->
  </form>
  

• L'elemento del modulo è disattivato dagli helper tag usando il simbolo di disattivazione esplicita per gli helper tag:

  <!form method="post">
      <!-- ... -->
  </!form>
  

• Rimuovere l'oggetto FormTagHelper dalla visualizzazione. L'oggetto FormTagHelper può essere rimosso da una visualizzazione aggiungendo la direttiva seguente alla visualizzazione Razor.

  @removeTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.FormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers
  

Nota

Razor Le pagine vengono protette automaticamente da XSRF/CSRF. Per altre informazioni, vedere XSRF/CSRF e Razor Pages.

L'approccio più comune alla protezione dagli attacchi CSRF consiste nell'usare lo schema token di sincronizzazione (STP). STP viene usato quando l'utente richiede una pagina con dati del modulo:

1. Il server invia un token associato all'identità dell'utente corrente al client.
2. Il client invia il token al server per la verifica.
3. Se il server riceve un token che non corrisponde all'identità dell'utente autenticato, la richiesta viene rifiutata.

Il token è univoco e imprevedibile. Il token può essere usato anche per garantire una sequenziazione corretta di una serie di richieste ( ad esempio, verificando la sequenza di richiesta di: pagina 1 > pagina 2 > pagina 3). Tutti i form nei modelli di ASP.NET Core MVC e nelle pagine Razor generano token antiforgery. La coppia di esempi di visualizzazione seguente genera token antiforgery:

<form asp-action="Index" asp-controller="Home" method="post">
    <!-- ... -->
</form>

@using (Html.BeginForm("Index", "Home"))
{
    <!-- ... -->
}

Aggiungere in modo esplicito un token antiforgery a un elemento <form> senza usare Tag Helper con l'helper HTML @Html.AntiForgeryToken.

<form asp-action="Index" asp-controller="Home" method="post">
    @Html.AntiForgeryToken()

    <!-- ... -->
</form>

In ognuno dei casi precedenti, ASP.NET Core aggiunge un campo modulo nascosto simile all'esempio seguente:

<input name="__RequestVerificationToken" type="hidden" value="CfDJ8NrAkS ... s2-m9Yw">

ASP.NET Core include tre filtri per l'uso di token antiforgery:

• ValidateAntiForgeryToken
• AutoValidateAntiforgeryToken
• IgnoreAntiforgeryToken

Anticontraffazione con AddControllers

La chiamata AddControllers non attiva i token antiforgery. AddControllersWithViews deve essere chiamato per ottenere il supporto integrato per i token antiforgery.

Più schede del browser e modello di token del programma di sincronizzazione

Non sono supportate più schede aperte con accesso come utenti diversi o una anonima.

Configurare l'antifalsificazione con AntiforgeryOptions

Personalizzare AntiforgeryOptions nel file Program dell'app

builder.Services.AddAntiforgery(options =>
{
    // Set Cookie properties using CookieBuilder properties†.
    options.FormFieldName = "AntiforgeryFieldname";
    options.HeaderName = "X-CSRF-TOKEN-HEADERNAME";
    options.SuppressXFrameOptionsHeader = false;
});

Impostare le proprietà antiforgery cookie usando le proprietà della classe CookieBuilder, come illustrato nella tabella seguente.

Opzione	Descrizione
Cookie	Stabilisce le impostazioni utilizzate per creare i cookie antifalsificazione.
FormFieldName	Nome del campo modulo nascosto utilizzato dal sistema antiforgery per eseguire il rendering dei token antiforgery nelle visualizzazioni.
HeaderName	Il nome dell'intestazione utilizzata dal sistema anti-forgery. Se null, il sistema considera solo i dati del modulo.
SuppressXFrameOptionsHeader	Specifica se eliminare la generazione dell'intestazione X-Frame-Options . Per impostazione predefinita, l'intestazione viene generata con il valore "SAMEORIGIN". Il valore predefinito è false.

Alcuni browser non consentono agli endpoint non sicuri di impostare cookie con un flag "sicuro" o sovrascrivere i cookie il cui flag "sicuro" è impostato (per altre informazioni, vedere Deprecate modification of 'secure' cookies from non-secure origin). Poiché la combinazione di endpoint sicuri e non sicuri è uno scenario comune nelle app, ASP.NET Core alleggerisce la restrizione sulla politica di sicurezza per alcuni cookie, come l'antiforgery cookie, impostando il cookie di SecurePolicy su CookieSecurePolicy.None. Anche se un utente malintenzionato ruba un'antiforgeria , deve anche rubare il token antiforgery cookieche viene in genere inviato tramite un campo modulo (più comune) o un'intestazione di richiesta separata (meno comune) più l'autenticazione cookie. I cookie correlati all'autenticazione o all'autorizzazione usano criteri più efficaci rispetto CookieSecurePolicy.Nonea .

Facoltativamente, è possibile proteggere l'antiforgeria cookie in ambienti nonDevelopment usando SSL (Secure Sockets Layer), solo su HTTPS, con l'impostazione della proprietà seguente AntiforgeryOptions.Cookie nel file dell'app Program :

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddAntiforgery(o =>
    {
        o.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Per ulteriori informazioni, vedere CookieAuthenticationOptions.

Generare token antiforgery con IAntiforgery

IAntiforgery fornisce l'API per configurare le funzionalità antiforgery. IAntiforgery può essere richiesto in Program.cs tramite WebApplication.Services. L'esempio seguente utilizza un middleware collegato alla pagina iniziale dell'app per generare un token antifrode e inviarlo nella risposta come cookie:

app.UseRouting();

app.UseAuthorization();

var antiforgery = app.Services.GetRequiredService<IAntiforgery>();

app.Use((context, next) =>
{
    var requestPath = context.Request.Path.Value;

    if (string.Equals(requestPath, "/", StringComparison.OrdinalIgnoreCase)
        || string.Equals(requestPath, "/index.html", StringComparison.OrdinalIgnoreCase))
    {
        var tokenSet = antiforgery.GetAndStoreTokens(context);
        context.Response.Cookies.Append("XSRF-TOKEN", tokenSet.RequestToken!,
            new CookieOptions { HttpOnly = false });
    }

    return next(context);
});

Nell'esempio precedente viene impostato un cookie denominato XSRF-TOKEN. Il client può leggere questo cookie e specificarne il valore come intestazione collegata alle richieste AJAX. Ad esempio, Angular include la protezione XSRF integrata che legge un cookie denominato XSRF-TOKEN per impostazione predefinita.

Richiedi convalida antifalsificazione

Il filtro di azione ValidateAntiForgeryToken può essere applicato a una singola azione, a un controller o a livello globale. Le richieste effettuate alle azioni con questo filtro applicato vengono bloccate a meno che la richiesta non includa un token antiforgery valido:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Index()
{
    // ...

    return RedirectToAction();
}

L'attributo ValidateAntiForgeryToken richiede un token per le richieste ai metodi di azione contrassegnati, incluse le richieste HTTP GET. Se l'attributo ValidateAntiForgeryToken viene applicato attraverso i controller dell'app, può essere sovrascritto con l'attributo IgnoreAntiforgeryToken.

Convalidare automaticamente i token antiforgery solo per metodi HTTP non sicuri

Anziché applicare l'attributo ValidateAntiForgeryToken a livello generale per poi eseguirne l'override con gli attributi IgnoreAntiforgeryToken, è possibile usare l'attributo AutoValidateAntiforgeryToken. Questo attributo funziona in modo identico all'attributo ValidateAntiForgeryToken , ad eccezione del fatto che non richiede token per le richieste effettuate usando i metodi HTTP seguenti:

• GET
• HEAD
• OPZIONI
• TRACE

È consigliabile l'uso di AutoValidateAntiforgeryToken in modo ampio per scenari non API. Questo attributo garantisce che le azioni POST siano protette per impostazione predefinita. L'alternativa consiste nell'ignorare i token antiforgery per impostazione predefinita, a meno che ValidateAntiForgeryToken venga applicato ai singoli metodi di azione. In questo scenario è più probabile che un metodo di azione POST venga lasciato non protetto per errore, lasciando l'app vulnerabile agli attacchi CSRF. Tutti i POST devono inviare il token antiforgery.

Le API non hanno un meccanismo automatico per l'invio dellacookie parte non del token. L'implementazione dipende probabilmente dall'implementazione del codice client. Di seguito sono riportati alcuni esempi:

Esempio a livello di classe:

[AutoValidateAntiforgeryToken]
public class HomeController : Controller

Esempio globale:

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
});

Sovrascrivere gli attributi antiforgery globali o del controller

Il filtro IgnoreAntiforgeryToken viene usato per eliminare la necessità di un token antiforgery per una determinata azione (o controller). Quando applicato, questo filtro sovrascrive i filtri ValidateAntiForgeryToken e AutoValidateAntiforgeryToken specificati ad un livello superiore (a livello globale o in un controller).

[IgnoreAntiforgeryToken]
public IActionResult IndexOverride()
{
    // ...

    return RedirectToAction();
}

Aggiornare i token dopo l'autenticazione

I token devono essere aggiornati dopo l'autenticazione dell'utente reindirizzando l'utente a una pagina di visualizzazione o Razor pagine.

JavaScript, AJAX e SPA

Nelle app tradizionali basate su HTML, i token antiforgery vengono passati al server tramite campi modulo nascosti. Nelle app moderne basate su JavaScript e nelle applicazioni a pagina singola, molte richieste vengono effettuate programmaticamente. Queste richieste AJAX possono usare altre tecniche, ad esempio intestazioni di richiesta o cookie, per inviare il token.

Se i cookie vengono usati per archiviare i token di autenticazione e per autenticare le richieste API nel server, CSRF è un potenziale problema. Se l'archiviazione locale viene usata per archiviare il token, la vulnerabilità CSRF potrebbe essere mitigata perché i valori dell'archiviazione locale non vengono inviati automaticamente al server con ogni richiesta. L'uso dell'archiviazione locale per archiviare il token antiforgery nel client e inviare il token come intestazione di richiesta è un approccio consigliato.

Blazor

Per ulteriori informazioni, vedere autenticazione e autorizzazione di ASP.NET CoreBlazor.

JavaScript

Usando JavaScript con visualizzazioni, il token può essere creato usando un servizio dall'interno della visualizzazione. Inserire il IAntiforgery servizio nella visualizzazione e chiamare GetAndStoreTokens:

@inject Microsoft.AspNetCore.Antiforgery.IAntiforgery Antiforgery

@{
    ViewData["Title"] = "JavaScript";

    var requestToken = Antiforgery.GetAndStoreTokens(Context).RequestToken;
}

<input id="RequestVerificationToken" type="hidden" value="@requestToken" />

<button id="button" class="btn btn-primary">Submit with Token</button>
<div id="result" class="mt-2"></div>

@section Scripts {
<script>
    document.addEventListener("DOMContentLoaded", () => {
        const resultElement = document.getElementById("result");

        document.getElementById("button").addEventListener("click", async () => {

            const response = await fetch("@Url.Action("FetchEndpoint")", {
                method: "POST",
                headers: {
                    RequestVerificationToken:
                        document.getElementById("RequestVerificationToken").value
                }
            });

            if (response.ok) {
                resultElement.innerText = await response.text();
            } else {
                resultElement.innerText = `Request Failed: ${response.status}`
            }
        });
    });
</script>
}

L'esempio precedente usa JavaScript per leggere il valore del campo nascosto per l'intestazione POST AJAX.

Questo approccio elimina la necessità di gestire direttamente l'impostazione dei cookie dal server o di leggerli dal client. Tuttavia, quando non è possibile inserire il servizio IAntiforgery, utilizzare JavaScript per accedere ai token nei cookie.

• I token di accesso in una richiesta aggiuntiva al server, di solito in genere same-origin.
• Utilizzare il contenuto di cookie per creare un'intestazione con il valore del token.

Supponendo che lo script invii il token in un'intestazione di richiesta denominata X-XSRF-TOKEN, configurare il servizio antiforgery per cercare l'intestazione X-XSRF-TOKEN :

builder.Services.AddAntiforgery(options => options.HeaderName = "X-XSRF-TOKEN");

L'esempio seguente aggiunge un endpoint protetto che scrive il token di richiesta in un codice JavaScript leggibile cookie:

app.UseAuthorization();
app.MapGet("antiforgery/token", (IAntiforgery forgeryService, HttpContext context) =>
{
    var tokens = forgeryService.GetAndStoreTokens(context);
    context.Response.Cookies.Append("XSRF-TOKEN", tokens.RequestToken!,
            new CookieOptions { HttpOnly = false });

    return Results.Ok();
}).RequireAuthorization();

L'esempio seguente usa JavaScript per effettuare una richiesta AJAX per ottenere il token e effettuare un'altra richiesta con l'intestazione appropriata:

var response = await fetch("/antiforgery/token", {
    method: "GET",
    headers: { "Authorization": authorizationToken }
});

if (response.ok) {
    // https://developer.mozilla.org/docs/web/api/document/cookie
    const xsrfToken = document.cookie
        .split("; ")
        .find(row => row.startsWith("XSRF-TOKEN="))
        .split("=")[1];

    response = await fetch("/JavaScript/FetchEndpoint", {
        method: "POST",
        headers: { "X-XSRF-TOKEN": xsrfToken, "Authorization": authorizationToken }
    });

    if (response.ok) {
        resultElement.innerText = await response.text();
    } else {
        resultElement.innerText = `Request Failed: ${response.status}`
    }
} else {    
    resultElement.innerText = `Request Failed: ${response.status}`
}

Nota

Quando il token antiforgery viene fornito sia nell'intestazione della richiesta che nel contenuto del modulo, viene convalidato solo il token nell'intestazione.

Antiforgery con API minime

Chiama AddAntiforgery e UseAntiforgery(IApplicationBuilder) per registrare i servizi antiforgery in DI. I token antiforgery vengono usati per mitigare attacchi di falsificazione della richiesta tra siti.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

app.MapGet("/", () => "Hello World!");

app.Run();

Il middleware antiforgery:

• Non interrompe l'esecuzione del resto della pipeline di richiesta.
• Imposta il IAntiforgeryValidationFeature nella HttpContext.Features della richiesta corrente.

Il token antiforgery viene convalidato solo se:

• L'endpoint contiene i metadati che implementano IAntiforgeryMetadata in cui RequiresValidation=true.
• Il metodo HTTP associato all'endpoint è un metodo HTTP pertinente di tipo POST, PUT o PATCH.
• La richiesta è associata a un endpoint valido.

Il middleware antiforgery non interrompe la pipeline delle richieste. Il codice endpoint viene sempre eseguito, anche se la convalida del token non riesce. Per osservare il risultato della convalida del token, risolvere IAntiforgeryValidationFeature da HttpContext.Features e controllarne la proprietà IsValid o la proprietà Error per i dettagli dell'errore. Questo approccio è utile quando gli endpoint richiedono una gestione personalizzata per la convalida antiforgery non riuscita.

Nota: se abilitato manualmente, il middleware antiforgery deve essere eseguito dopo il middleware di autenticazione e autorizzazione per impedire la lettura dei dati del modulo quando l'utente non è autenticato.

Per impostazione predefinita, le Minimal APIs che accettano i dati del modulo richiedono la convalida del token antiforgery e non vengono eseguite prima che il codice dell'applicazione venga eseguito se la convalida antiforgery non è riuscita.

Si consideri il metodo seguente GenerateForm :

public static string GenerateForm(string action, 
    AntiforgeryTokenSet token, bool UseToken=true)
{
    string tokenInput = "";
    if (UseToken)
    {
        tokenInput = $@"<input name=""{token.FormFieldName}""
                         type=""hidden"" value=""{token.RequestToken}"" />";
    }

    return $@"
    <html><body>
        <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
            {tokenInput}
            <input type=""text"" name=""name"" />
            <input type=""date"" name=""dueDate"" />
            <input type=""checkbox"" name=""isCompleted"" />
            <input type=""submit"" />
        </form>
    </body></html>
";
}

Il codice precedente ha tre argomenti, l'azione, il token antiforgery e un bool che indica se il token deve essere usato.

Si consideri l'esempio seguente:

using Microsoft.AspNetCore.Antiforgery;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

// Pass token
app.MapGet("/", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo", token), "text/html");
});

// Don't pass a token, fails
app.MapGet("/SkipToken", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo",token, false ), "text/html");
});

// Post to /todo2. DisableAntiforgery on that endpoint so no token needed.
app.MapGet("/DisableAntiforgery", (HttpContext context, IAntiforgery antiforgery) =>
{
    var token = antiforgery.GetAndStoreTokens(context);
    return Results.Content(MyHtml.GenerateForm("/todo2", token, false), "text/html");
});

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

app.Run();

class Todo
{
    public required string Name { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime DueDate { get; set; }
}

public static class MyHtml
{
    public static string GenerateForm(string action, 
        AntiforgeryTokenSet token, bool UseToken=true)
    {
        string tokenInput = "";
        if (UseToken)
        {
            tokenInput = $@"<input name=""{token.FormFieldName}""
                             type=""hidden"" value=""{token.RequestToken}"" />";
        }

        return $@"
        <html><body>
            <form action=""{action}"" method=""POST"" enctype=""multipart/form-data"">
                {tokenInput}
                <input type=""text"" name=""name"" />
                <input type=""date"" name=""dueDate"" />
                <input type=""checkbox"" name=""isCompleted"" />
                <input type=""submit"" />
            </form>
        </body></html>
    ";
    }
}

Nel codice precedente, invia a:

• /todo richiede un token antiforgery valido.
• /todo2 non richiedono un token antiforgery valido quando DisableAntiforgery è chiamato.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Avviso

La chiamata .DisableAntiforgery() disabilita la protezione CSRF (Cross-Site Request Forgery) per l'endpoint. Questa operazione deve essere usata solo quando un endpoint non è vulnerabile agli attacchi CSRF, ad esempio:

• Endpoint che non sono chiamabili da un browser (ad esempio, API interne)
• Endpoint protetti con autenticazione noncookie basata (ad esempio, token di connessione o chiavi API)
• Endpoint interni o dell'infrastruttura che non dipendono dai cookie utente

Non disabilitare la convalida antifrode per gli endpoint accessibili dal browser che si basano sui cookie per l'autenticazione o che elaborano i dati dei moduli inviati dagli utenti, in quanto espone l'applicazione agli attacchi CSRF.

Esegui un POST a:

• /todo dal modulo generato dall'endpoint / ha esito positivo perché il token antiforgery è valido.
• /todo dal modulo generato da /SkipToken fallisce perché l'antifalsificazione non è inclusa.
• /todo2 dal modulo generato dall'endpoint ha esito positivo perché l'antiforgery /DisableAntiforgery non è obbligatorio.

app.MapPost("/todo", ([FromForm] Todo todo) => Results.Ok(todo));

app.MapPost("/todo2", ([FromForm] Todo todo) => Results.Ok(todo))
                                                .DisableAntiforgery();

Quando un modulo viene inviato senza un token antiforgery valido:

• Nell'ambiente Development viene generata un'eccezione.
• Nell'ambiente Production viene registrato un messaggio.

Limitazioni dei metodi HTTP e interazione con HttpMethodOverrideMiddleware

Per il percorso antiforgery basato su middleware, AntiforgeryMiddleware e UseAntiforgery() convalidano i token antiforgery solo per le richieste HTTP POST, PUT e PATCH. Altri metodi HTTP, ad esempio DELETE, non vengono convalidati automaticamente.

Per convalidare i token antiforgery per altri metodi HTTP, risolvere IAntiforgery dal contenitore DI e chiamare ValidateRequestAsync o IsRequestValidAsync esplicitamente:

app.MapDelete("/item/{id}", async (int id, IAntiforgery antiforgery, HttpContext context) =>
{
    await antiforgery.ValidateRequestAsync(context);
    // Process the DELETE request
});

Avviso

Quando HttpMethodOverrideMiddleware è configurato con FormFieldName (modalità campo del modulo) e posizionato prima di AntiforgeryMiddleware, è possibile forzare una richiesta POST a DELETE (o a un altro metodo non convalidato). Poiché AntiforgeryMiddleware convalida solo POST, PUT e PATCH, la richiesta sottoposta a override ignora la convalida antiforgery.

Per proteggere questi endpoint:

• È preferibile posizionare HttpMethodOverrideMiddleware dopo la convalida anti-contraffazione quando la pipeline lo consente.
• Evitare sovrascritture dei campi del modulo per gli endpoint che si basano sulla convalida anti-contraffazione.
• Se l'override del campo del modulo deve essere applicato per primo, convalidare esplicitamente il token antiforgery usando IAntiforgery.ValidateRequestAsync.

Per informazioni dettagliate sulla configurazione, vedere ASP.NET Core middleware.

autenticazione Windows e i cookie antifalsificazione

Quando si usa l'autenticazione di Windows, gli endpoint dell'applicazione devono essere protetti dagli attacchi CSRF nello stesso modo usato per i cookie. Il browser invia in modo implicito il contesto di autenticazione al server e agli endpoint devono essere protetti dagli attacchi CSRF.

Estendere il sistema anti-contraffazione

Il tipo IAntiforgeryAdditionalDataProvider permette agli sviluppatori di espandere il comportamento del sistema anti-CSRF trasferendo dati aggiuntivi in ogni token. Il GetAdditionalData metodo viene chiamato ogni volta che viene generato un token di campo e il valore restituito viene incorporato all'interno del token generato. Un implementatore può restituire un timestamp, un nonce o qualsiasi altro valore e quindi chiamare ValidateAdditionalData per convalidare questi dati quando il token viene convalidato. Il nome utente del client è già incorporato nei token generati, quindi non è necessario includere queste informazioni. Se un token include dati supplementari ma non IAntiForgeryAdditionalDataProvider è configurato, i dati supplementari non vengono convalidati.

Risorse aggiuntive

• Ospitare ASP.NET Core in una web farm