Blazor il rendering lato server rinvia la convalida anti-forgery al middleware

In ASP.NET Core 11, gli endpoint Blazor di rendering statico lato server (SSR) non convalidano più direttamente i token antifalsificazione. Si basano sul middleware antiforgery per registrare un risultato di convalida e generano token antiforgery solo quando il middleware antiforgery basato su token è presente nella pipeline.

Versione introdotta

.NET 11

Comportamento precedente

In precedenza, quando un Blazor endpoint SSR gestiva un modulo POST, l'endpoint Razor Components convalidava la richiesta stessa. Se il middleware antiforgery a monte non aveva ancora registrato un risultato, l'endpoint ha chiamato direttamente IAntiforgery per convalidare il token antiforgery della richiesta. L'endpoint inoltre generava e archiviava sempre token antiforgery per i moduli di cui veniva eseguito il rendering, indipendentemente dal fatto che app.UseAntiforgery() fosse presente o meno nella pipeline.

Di conseguenza, in un'app SSR Blazor che non chiamava app.UseAntiforgery(), gli invii dei moduli venivano comunque convalidati dall'endpoint rispetto ai token antiforgery e venivano comunque emessi token per i relativi moduli.

Nuovo comportamento

A partire da ASP.NET Core 11, l'endpoint Razor Components si basa sull'esito della protezione antifalsificazione registrato nell'elemento IAntiforgeryValidationFeature della richiesta dal middleware upstream. Per un modulo POST, restituisce 400 Bad Request solo quando il verdetto registrato non è valido e non chiama IAntiforgery più per convalidare la richiesta stessa. L'endpoint genera i token antiforgery solo quando il middleware antiforgery basato su token è stato eseguito per la richiesta; quando tale middleware non è presente, l'endpoint non genera i token.

Il verdetto può essere registrato da uno dei due componenti middleware:

• Middleware antifalsificazione basato su token che app.UseAntiforgery() aggiunge.
• Middleware automatico di protezione CSRF per richieste cross-origin, aggiunto per impostazione predefinita nelle app create con WebApplication.CreateBuilder (novità di .NET 11).

L'impatto dipende dalla configurazione dell'app:

• Le app che chiamano app.UseAntiforgery() non subiscono alcun effetto. Le richieste vengono convalidate rispetto ai token antiforgery e i token vengono generati per i moduli esattamente come in precedenza.
• Le app che non chiamano app.UseAntiforgery() sono ora protette dal middleware di protezione CSRF automatico anziché dalla convalida dei token nell'endpoint. Queste app non generano più token antiforgery per i moduli.

Tipo di cambiamento che interrompe la compatibilità

Questa modifica è una modifica funzionale.

Motivo della modifica

Il sistema antiforgery basato su token e la nuova protezione CSRF cross-origin registrano ora un singolo risultato di convalida nell'elemento condiviso IAntiforgeryValidationFeature, che i componenti che elaborano i moduli leggono per decidere se rifiutare una richiesta. Far convalidare la richiesta una seconda volta all'endpoint Razor Components duplicava tale operazione e poteva produrre un risultato diverso da quello del middleware. La generazione di token in assenza di middleware antiforgery produceva token che non venivano convalidati da nulla.

Per altre informazioni, vedere dotnet/aspnetcore#67082.

Azione consigliata

Se la tua app Blazor SSR si basa su token antiforgery, ad esempio per convalidare l'invio di moduli o per inserire token nei moduli, assicurati che chiami app.UseAntiforgery():

var app = builder.Build();

app.UseAntiforgery();

Le app che chiamano app.UseAntiforgery(), direttamente o in modo implicito tramite AddRazorComponents, non richiedono modifiche.

Se hai rimosso intenzionalmente app.UseAntiforgery() e vuoi invece affidarti alla protezione CSRF automatica tra origini diverse, non è richiesta alcuna azione. Si noti che i token antifalsificazione non vengono più generati per i form e che gli invii di form tra origini diverse vengono rifiutati in base a Sec-Fetch-Site e Origin anziché ai token. Per altre informazioni, vedere Impedire attacchi XSRF/CSRF (Cross-Site Request Forgery) in ASP.NET Core ed Eseguire la migrazione da ASP.NET Core in .NET 10 a ASP.NET Core in .NET 11.

Le API interessate

Nessuno. Nessuna superficie API pubblica modificata. La modifica influisce sul comportamento degli endpoint di rendering statico lato server Blazor e del provider dello stato antiforgery che genera token.