Blazor Le rendu côté serveur reporte la validation anti-contrefaçon au middleware

Dans ASP.NET Core 11, Blazor les points de terminaison de rendu statique côté serveur (SSR) ne valident plus directement les jetons antiforgery. Ils s’appuient sur le middleware antiforgery pour enregistrer un résultat de validation et génèrent des jetons antiforgery uniquement lorsque le middleware antiforgery basé sur les jetons est présent dans le pipeline.

Version introduite

.NET 11

Comportement antérieur

Auparavant, lorsqu’un Blazor point de terminaison SSR a géré un formulaire POST, le Razor point de terminaison Components a validé la requête elle-même. Si le middleware antiforgery en amont n’avait pas encore enregistré de résultat, le point de terminaison appelait directement IAntiforgery pour valider le jeton antiforgery de la requête. Le point de terminaison générait et stockait également toujours des jetons anti-contrefaçon pour les formulaires rendus, que app.UseAntiforgery() soit ou non présent dans le pipeline.

Par conséquent, une application SSR Blazor qui n’a pas appelé app.UseAntiforgery() voyait toujours ses soumissions de formulaire validées au niveau du point de terminaison par rapport aux jetons antiforgery, et émettait toujours des jetons pour ses formulaires.

Nouveau comportement

À compter d’ASP.NET Core 11, le point de terminaison Components Razor se fie au verdict antiforgery enregistré sur le IAntiforgeryValidationFeature de la requête par un middleware en amont. Pour un formulaire POST, il retourne 400 Bad Request uniquement lorsque le verdict enregistré n’est pas valide et qu’il n’appelle IAntiforgery plus pour valider la requête elle-même. Le point de terminaison génère des jetons antiforgery uniquement lorsque le middleware antiforgery basé sur les jetons a été exécuté pour la requête ; quand ce middleware n’est pas présent, le point de terminaison ignore la génération de jetons.

Le verdict peut être enregistré par l’un des deux composants du middleware :

  • Middleware de protection contre les antiforgery de requêtes basé sur des jetons ajouté par app.UseAntiforgery().
  • Middleware de protection CSRF inter-origines automatique qui est injecté par défaut dans les applications créées avec WebApplication.CreateBuilder (nouveauté de .NET 11).

L’impact dépend de la configuration de l’application :

  • Les applications qui appellent app.UseAntiforgery() ne sont pas affectées. Les requêtes sont validées à l’aide de jetons anti‑falsification, et des jetons sont générés pour les formulaires, exactement comme auparavant.
  • Les applications qui n’appellent pas app.UseAntiforgery() sont désormais protégées par le middleware de protection CSRF automatique plutôt que par la validation du jeton au niveau du point de terminaison. Ces applications n’émettent plus de jetons antiforgery pour leurs formulaires.

Type de changement cassant

Ce changement est un changement de comportement.

Raison du changement

Le système antiforgery basé sur les jetons et la nouvelle protection CSRF inter-origines enregistrent désormais un résultat de validation unique sur le composant partagé IAntiforgeryValidationFeature, que les composants consommant des formulaires lisent pour décider s’il faut rejeter une demande. Le fait que le point de terminaison Components Razor valide la requête une deuxième fois a dupliqué ce travail et pouvait produire un résultat différent de celui du middleware. La génération de jetons en l’absence de middleware antifalsification produisait des jetons que rien ne validait.

Pour plus d’informations, consultez dotnet/aspnetcore#67082.

Si votre Blazor application SSR s’appuie sur des jetons anti‑falsification — par exemple, pour valider les soumissions de formulaires ou pour insérer des jetons dans les formulaires — assurez-vous qu’elle appelle app.UseAntiforgery():

var app = builder.Build();

app.UseAntiforgery();

Les applications qui appellent app.UseAntiforgery()directement ou implicitement via AddRazorComponents, ne nécessitent aucune modification.

Si vous avez intentionnellement supprimé app.UseAntiforgery() et que vous souhaitez vous appuyer sur la protection CSRF d’origine croisée automatique à la place, aucune action n’est requise. Sachez que les jetons anti-contrefaçon ne sont plus générés pour vos formulaires, et que les envois de formulaires entre origines différentes sont rejetés en fonction de Sec-Fetch-Site et de Origin, plutôt que des jetons. Pour plus d’informations, consultez Empêcher les attaques XSRF/CSRF (Cross-Site Request Forgery) dans ASP.NET Core et Migrer de ASP.NET Core dans .NET 10 à ASP.NET Core dans .NET 11.

API affectées

Aucun. Aucune surface d’API publique n’a changé. Cette modification affecte le comportement des points de terminaison de rendu statique côté serveur Blazor et du fournisseur d’état antiforgery qui génère des jetons.

  • Last updated on