Blazor o processamento no lado do servidor delega a validação antifalsificação ao middleware

No ASP.NET Core 11, Blazor os endpoints estáticos para renderização no lado do servidor (SSR) deixaram de validar, por si próprios, os tokens de contrafalsificação. Eles dependem do middleware antifalsificação para registar um resultado de validação e geram tokens antifalsificação apenas quando o middleware antifalsificação baseado em tokens está presente no pipeline.

Versão introduzida

.NET 11

Comportamento anterior

Anteriormente, quando um Blazor endpoint SSR tratava de um formulário POST, o Razor endpoint Components validava o próprio pedido. Se o middleware de contrafalsificação anterior ainda não tivesse registado previamente um resultado, o endpoint invocava diretamente IAntiforgery para validar o token de contrafalsificação do pedido. O endpoint também gerava e armazenava sempre tokens de antifalsificação para formulários processados, independentemente de app.UseAntiforgery() estar ou não no pipeline.

Como resultado, uma Blazor aplicação SSR que não chamava app.UseAntiforgery() continuava a ter as submissões dos seus formulários validadas pelo endpoint com base em tokens antifalsificação, e continuava a gerar tokens para os seus formulários.

Novo comportamento

A partir do ASP.NET Core 11, o Razor endpoint Componentes confia no veredicto antifalsificação registado no pedido IAntiforgeryValidationFeature pelo middleware upstream. Para um formulário POST, só retorna 400 Bad Request quando o veredicto registado é inválido e já não chama IAntiforgery para validar o pedido em si. O endpoint gera tokens de proteção antifalsificação apenas quando o middleware antifalsificação baseado em tokens foi executado para esse pedido; quando esse middleware não está presente, o endpoint omite a geração de tokens.

O veredicto pode ser registado por um de dois componentes do middleware:

  • O middleware de proteção antifalsificação baseado em tokens que app.UseAntiforgery() adiciona.
  • O middleware automático de proteção CSRF entre origens injetado por predefinição nas aplicações criadas com WebApplication.CreateBuilder (novo no .NET 11).

O impacto depende da configuração da aplicação:

  • As aplicações que chamam app.UseAntiforgery() não são afetadas. Os pedidos são validados com base em tokens antifraude, e os tokens são gerados para formulários, exatamente como antes.
  • As aplicações que não chamam app.UseAntiforgery() estão agora protegidas pelo middleware de proteção CSRF automática, em vez de através da validação de token no ponto final. Estas aplicações já não emitem tokens antifalsificação para os seus formulários.

Tipo de mudança disruptiva

Esta mudança é uma mudança comportamental.

Motivo da mudança

O sistema antifalsificação baseado em tokens e a nova proteção CSRF entre origens registam agora um único resultado de validação no elemento partilhado IAntiforgeryValidationFeature, que os componentes que processam o formulário leem para decidir se devem rejeitar um pedido. Fazer o Razor endpoint Components validar o pedido uma segunda vez duplicou esse trabalho e podia produzir um resultado diferente do do middleware. A geração de tokens quando não estava presente nenhum middleware de antifalsificação produzia tokens que não eram validados por nada.

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

Se a sua Blazor aplicação com SSR depender de tokens anti-falsificação — por exemplo, para validar submissões de formulários ou para inserir tokens em formulários — certifique-se de que chama app.UseAntiforgery():

var app = builder.Build();

app.UseAntiforgery();

As aplicações que chamam app.UseAntiforgery(), direta ou implicitamente através de AddRazorComponents, não requerem alterações.

Se removeste app.UseAntiforgery() intencionalmente e quiseres confiar na proteção CSRF automática de origem cruzada, não é necessária qualquer ação. Tenha em atenção que os tokens de proteção antifalsificação já não são gerados para os seus formulários e que as submissões de formulários entre origens são rejeitadas com base em Sec-Fetch-Site e Origin, em vez de nesses tokens. Para mais informações, consulte Prevenir ataques de falsificação de pedidos 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 pública de API foi alterada. A alteração afeta o comportamento dos Blazor endpoints estáticos de renderização do lado do servidor e do fornecedor de estado antifalsificação que gera tokens.

  • Last updated on