Blazor El renderizado del lado del servidor delega la validación de antifalsificación en el middleware

En ASP.NET Core 11, los puntos de conexión con representación estática del lado servidor (SSR) de Blazor ya no validan por sí mismos los tokens antifalsificación. Se basan en el middleware de antifalsificación para registrar el resultado de una validación y generan tokens de antifalsificación solo cuando el middleware de antifalsificación basado en tokens está presente en la canalización.

Versión introducida

.NET 11

Comportamiento anterior

Anteriormente, cuando un Blazor punto de conexión de SSR controló un formulario POST, el Razor punto de conexión Componentes validó la propia solicitud. Si el middleware antifalsificación ascendente aún no había registrado ningún resultado, el punto de conexión llamaba directamente a IAntiforgery para validar el token antifalsificación de la solicitud. El punto de conexión también generaba y almacenaba siempre los tokens antifalsificación para los formularios representados, independientemente de que app.UseAntiforgery() estuviera o no en la canalización.

Como resultado, una aplicación SSR Blazor que no invocaba app.UseAntiforgery() seguía teniendo sus envíos de formularios validados con tokens antifalsificación por el endpoint, y seguía emitiendo tokens para sus formularios.

Nuevo comportamiento

A partir de ASP.NET Core 11, el punto de conexión de Componentes Razor confía en el veredicto antifalsificación que el middleware ascendente registró en la interfaz IAntiforgeryValidationFeature de la solicitud. Para un formulario POST, solo devuelve 400 Bad Request cuando el veredicto registrado no es válido y ya no llama IAntiforgery a para validar la propia solicitud. El extremo genera tokens de antifalsificación solo cuando el middleware de antifalsificación basado en tokens se ejecutó al procesar la solicitud; cuando ese middleware no está presente, el extremo omite generar tokens.

El veredicto se puede registrar mediante cualquiera de los dos componentes de middleware:

  • El middleware antifalsificación basado en tokens que app.UseAntiforgery() añade.
  • El middleware de protección CSRF entre orígenes automática que se inserta de forma predeterminada en las aplicaciones creadas con WebApplication.CreateBuilder (novedad en .NET 11).

El impacto depende de la configuración de la aplicación:

  • Las aplicaciones que llaman app.UseAntiforgery() no se ven afectadas. Las solicitudes se validan con tokens antiforgería y los tokens se generan para formularios, exactamente como antes.
  • Las aplicaciones que no invocan app.UseAntiforgery() ahora están protegidas por el middleware de protección CSRF automática en lugar de por la validación de tokens en el endpoint. Estas aplicaciones ya no emiten tokens antiforgería para sus formularios.

Tipo de cambio disruptivo

Este es un cambio de comportamiento.

Motivo del cambio

El sistema antifalsificación basado en tokens y la nueva protección CSRF entre distintos orígenes ahora registran un único resultado de validación en el elemento compartido IAntiforgeryValidationFeature, que leen los componentes que procesan formularios para decidir si rechazan una solicitud. Hacer que el punto de conexión de Razor Componentes validara la solicitud por segunda vez duplicaba ese trabajo y podía producir un resultado distinto del del middleware. La generación de tokens cuando no había ningún middleware antifalsificación generaba tokens que nada validaba.

Para obtener más información, vea dotnet/aspnetcore#67082.

Si su aplicación SSR Blazor depende de tokens antifalsificación —por ejemplo, para validar envíos de formularios o para insertar tokens en formularios—, asegúrese de que llama a app.UseAntiforgery():

var app = builder.Build();

app.UseAntiforgery();

Las aplicaciones que llaman a app.UseAntiforgery(), directa o implícitamente a través de AddRazorComponents, no requieren cambios.

Si ha quitado app.UseAntiforgery() intencionadamente y desea usar la protección CSRF entre orígenes automática en su lugar, no se requiere ninguna acción. Tenga en cuenta que ya no se generan tokens antifalsificación para sus formularios, y que los envíos de formularios entre orígenes se rechazan en función de Sec-Fetch-Site y Origin, en lugar de los tokens. Para obtener más información, vea Evitar ataques de falsificación de solicitudes entre sitios (XSRF/CSRF) en ASP.NET Core y Migrar de ASP.NET Core en .NET 10 a ASP.NET Core en .NET 11.

Las APIs afectadas

Ninguna. No ha cambiado ninguna superficie de API pública. El cambio afecta al comportamiento de los puntos de conexión de representación estática del lado servidor de Blazor y del proveedor de estado antifalsificación que genera los tokens.

  • Last updated on