Blazor a renderização no lado do servidor delega a validação contra falsificação ao middleware

No ASP.NET Core 11, os Blazor ponto de extremidade de renderização estática no servidor (SSR) não validam mais os próprios tokens antifalsificação. Eles dependem do middleware de proteção contra falsificação para registrar o resultado da validação e geram tokens de proteção contra falsificação somente quando o middleware de proteção contra falsificação baseado em tokens está presente no pipeline.

Versão introduzida

.NET 11

Comportamento anterior

Anteriormente, quando um endpoint SSR Blazor processava um POST de formulário, o endpoint de Componentes Razor validava a própria solicitação. Se o middleware de antifalsificação anterior ainda não tivesse registrado um resultado, o endpoint chamaria IAntiforgery diretamente para validar o token de antifalsificação da solicitação. O ponto de extremidade também sempre gerou e armazenou tokens antifalsificação para formulários renderizados, independentemente de app.UseAntiforgery() estar ou não no pipeline.

Como resultado, um aplicativo SSR Blazor que não chamou app.UseAntiforgery() ainda tinha os seus envios de formulário validados em relação aos tokens antifalsificação pelo ponto de extremidade e ainda emitia tokens para seus formulários.

Novo comportamento

A partir do ASP.NET Core 11, o ponto de extremidade de Razor Components confia no veredicto de antifalsificação registrado no IAntiforgeryValidationFeature da solicitação pelo middleware upstream. Para um formulário POST, ele retorna 400 Bad Request somente quando o veredicto registrado é inválido e não chama IAntiforgery mais para validar a solicitação em si. O endpoint gera tokens de antifalsificação somente quando o middleware de antifalsificação baseado em token foi executado para a solicitação; quando esse middleware não está presente, o endpoint ignora a geração do token.

O veredicto pode ser registrado por qualquer um dos dois componentes de middleware:

  • O middleware antifalsificação baseado em tokens que app.UseAntiforgery() adiciona.
  • O middleware de proteção automática contra CSRF entre origens, injetado por padrão em aplicativos criados com WebApplication.CreateBuilder (novo no .NET 11).

O impacto depende da configuração do aplicativo:

  • Os aplicativos que chamam app.UseAntiforgery() não são afetados. As solicitações são validadas com base em tokens antifalsificação, e os tokens são gerados para formulários, exatamente como antes.
  • Os aplicativos que não chamam app.UseAntiforgery() agora são protegidos pelo middleware automático de proteção contra CSRF, em vez da validação de token no ponto de extremidade. Esses aplicativos não geram mais tokens antifalsificação para seus formulários.

Tipo de mudança disruptiva

Esta é uma alteração comportamental.

Motivo da alteração

O sistema antifalsificação baseado em tokens e a nova proteção CSRF entre origens agora registram um único resultado de validação no IAntiforgeryValidationFeature compartilhado, que os componentes que processam formulários usam para decidir se devem rejeitar uma solicitação. Fazer com que o endpoint de Razor Componentes validasse a solicitação uma segunda vez duplicava esse trabalho e poderia produzir um resultado diferente do produzido pelo middleware. A geração de tokens quando não havia nenhum middleware de antifalsificação presente produzia tokens que nada podia validar.

Para obter mais informações, consulte dotnet/aspnetcore#67082.

Se o aplicativo SSR Blazor depender de tokens antifalsificação, por exemplo, para validar envios de formulário ou para inserir tokens em formulários, certifique-se de que ele chama app.UseAntiforgery():

var app = builder.Build();

app.UseAntiforgery();

Os aplicativos que chamam app.UseAntiforgery(), direta ou implicitamente por meio AddRazorComponents, não exigem alterações.

Se você removeu app.UseAntiforgery() intencionalmente e deseja contar com a proteção CSRF de origem cruzada automática, nenhuma ação será necessária. Esteja ciente de que os tokens antifalsificação não são mais gerados para seus formulários, e os envios de formulários entre origens são rejeitados com base em Sec-Fetch-Site e Origin, em vez de em tokens. Para obter mais informações, consulte Impedir ataques de falsificação de solicitação entre sites (XSRF/CSRF) no ASP.NET Core e Migrar do ASP.NET Core no .NET 10 para o ASP.NET Core no .NET 11.

APIs afetadas

Nenhum. Nenhuma superfície de API pública foi alterada. A alteração afeta o comportamento dos pontos de extremidade de renderização estática no servidor de Blazor e do provedor de estado antifalsificação que gera tokens.

  • Last updated on