Blazor server-side rendering laat antiforgery-validatie over aan middleware

In ASP.NET Core 11 Blazor valideren statische SSR-eindpunten (Server Side Rendering) zelf geen antiforgerytokens meer. Ze zijn afhankelijk van de antiforgery-middleware om een validatieresultaat vast te leggen en genereren alleen antiforgerytokens wanneer de op tokens gebaseerde antiforgery-middleware aanwezig is in de pijplijn.

Geïntroduceerde versie

.NET 11

Vorig gedrag

Voorheen valideerde het Blazor Components-eindpunt het verzoek zelf wanneer een POST SSR-eindpunt een formulier Razor verwerkte. Als de hogerop in de pijplijn geplaatste antiforgery-middleware nog niet eerder een resultaat had geregistreerd, riep het eindpunt IAntiforgery rechtstreeks aan om het antiforgery-token van het verzoek te valideren. Het eindpunt genereerde ook altijd anti-vervalsingstokens en sloeg deze op voor gerenderde formulieren, ongeacht of app.UseAntiforgery() al dan niet deel uitmaakte van de pijplijn.

Als gevolg daarvan werden in een Blazor SSR-app die app.UseAntiforgery() niet aanriep de formulierverzendingen nog steeds door het eindpunt gevalideerd aan de hand van antivervalsingstokens, en werden er nog steeds tokens gegenereerd voor de formulieren.

Nieuw gedrag

Vanaf ASP.NET Core 11 vertrouwt het eindpunt voor Razor-onderdelen op het antiforgery-oordeel dat door eerder in de pijplijn uitgevoerde middleware in de IAntiforgeryValidationFeature van de aanvraag is vastgelegd. Voor een formulier POST retourneert het alleen 400 Bad Request wanneer de vastgelegde beoordeling ongeldig is, en roept het niet langer IAntiforgery aan om het verzoek zelf te valideren. Het eindpunt genereert alleen antivervalsingstokens wanneer de op tokens gebaseerde antiforgery-middleware voor de aanvraag werd uitgevoerd; wanneer deze middleware niet aanwezig is, wordt het genereren van tokens overgeslagen door het eindpunt.

De uitspraak kan worden vastgelegd door een van de twee middlewareonderdelen:

• De op tokens gebaseerde antiforgery-middleware die app.UseAntiforgery() toevoegt.
• De middleware voor automatische CSRF-beveiliging van verschillende herkomsten die standaard wordt geïnjecteerd in apps die zijn gebouwd met WebApplication.CreateBuilder (nieuw in .NET 11).

De impact is afhankelijk van de configuratie van de app:

• Apps die app.UseAntiforgery() aanroepen, worden niet beïnvloed. Aanvragen worden gevalideerd op basis van antivervalsingstokens en tokens worden gegenereerd voor formulieren, precies zoals voorheen.
• Apps die app.UseAntiforgery() niet aanroepen, worden nu beschermd door de middleware voor automatische CSRF-beveiliging in plaats van door tokenvalidatie in het eindpunt. Deze apps verzenden geen antiforgerytokens meer voor hun formulieren.

Type van brekende verandering

Deze wijziging is een gedragswijziging.

Reden voor wijziging

Het op tokens gebaseerde antiforgery-systeem en de nieuwe cross-origin-CSRF-beveiliging leggen nu één validatieresultaat vast op de gedeelde IAntiforgeryValidationFeature, die door onderdelen die formulieren verwerken wordt gelezen om te bepalen of een verzoek moet worden afgewezen. Door het Razor Components-eindpunt het verzoek een tweede keer te laten valideren, werd dat werk gedupliceerd en kon dit een resultaat opleveren dat afweek van dat van de middleware. Het genereren van tokens wanneer er geen antiforgery-middleware aanwezig was, leverde tokens op die door niets werden gevalideerd.

Zie dotnet/aspnetcore#67082 voor meer informatie.

Aanbevolen actie

Als uw Blazor SSR-app afhankelijk is van anti-vervalsingstokens — bijvoorbeeld om formulierinzendingen te valideren of tokens in formulieren op te nemen — zorg er dan voor dat deze app.UseAntiforgery() aanroept:

var app = builder.Build();

app.UseAntiforgery();

Apps die app.UseAntiforgery() rechtstreeks of impliciet via AddRazorComponents aanroepen, vereisen geen wijzigingen.

Als u opzettelijk hebt verwijderd app.UseAntiforgery() en wilt vertrouwen op de automatische CSRF-beveiliging van meerdere oorsprongen, is er geen actie vereist. Houd er rekening mee dat er niet langer antiforgery-tokens voor uw formulieren worden gegenereerd en dat formulierverzendingen van andere origins worden geweigerd op basis van Sec-Fetch-Site en Origin in plaats van op tokens. Zie Cross-Site Request Forgery-aanvallen (XSRF/CSRF) voorkomen in ASP.NET Core en Migreren van ASP.NET Core in .NET 10 naar ASP.NET Core in .NET 11 voor meer informatie.

Betreffende API's

None. Er is geen openbaar API-oppervlak gewijzigd. De wijziging is van invloed op het gedrag van Blazor statische eindpunten voor rendering aan de serverzijde en de antiforgerystatusprovider waarmee tokens worden gegenereerd.