Säkerhet i Blazor: 12 saker att kontrollera före driftsättning

De flesta säkerhetsincidenter i affärsapplikationer är inte sofistikerade. En nyckel i repositoryt, en token som aldrig går ut, en skärm som döljer en knapp men inte handlingen bakom den. Blazor har vettiga standardinställningar, men gör att gränssnittskod och serverkod ser nästan likadana ut, och det är just där de enkla misstagen gömmer sig.

Här är tolv kontroller som är värda att gå igenom innan en Blazor-applikation driftsätts, eller före nästa revision. Vissa gäller överallt, andra bara för ett visst renderingsläge.

Överallt

1. Behörighet hör hemma i tjänsten, inte bara i gränssnittet

AuthorizeView avgör vad användaren ser. Den avgör inte vad användaren får göra.

<AuthorizeView Roles="Finance">
    <button @onclick="() => Payments.ApproveAsync(payment.Id, user)">Approve payment</button>
</AuthorizeView>

Att dölja knappen är bra användarupplevelse, men skyddet måste finnas i metoden som gör jobbet, så att det gäller oavsett vilken skärm, vilket API eller vilken framtida utvecklare som anropar den:

public sealed class PaymentService(IAuthorizationService authorization, PaymentRepository payments)
{
    public async Task ApproveAsync(int paymentId, ClaimsPrincipal user)
    {
        var result = await authorization.AuthorizeAsync(user, "ApprovePayments");
        if (!result.Succeeded)
            throw new UnauthorizedAccessException();

        await payments.ApproveAsync(paymentId);
    }
}

Sidor skyddas med @attribute [Authorize], känsliga handlingar med en policy i tjänsten. Båda, inte det ena eller det andra. Samma regel gäller för en AI-assistent i applikationen.

2. Inga hemligheter i repositoryt

Anslutningssträngar, API-nycklar och certifikat hör hemma i Azure Key Vault eller i hostingmiljöns inställningar, och lokalt i Secret Manager, inte i appsettings.json. Om en nyckel någon gång har checkats in räcker det inte att ta bort den, eftersom den finns kvar i git-historiken. Den måste bytas ut.

3. Tokens och nycklar som går ut

API-nycklar utan utgångsdatum och sessioner som varar i månader är en öppen dörr som ingen minns. Varje nyckel behöver en ägare, ett utgångsdatum och ett sätt att återkallas.

4. Kända sårbarheter i NuGet-paket

Sedan .NET 8 SDK varnar NuGet vid återställning för paket med kända sårbarheter. De varningarna får inte tystas och glömmas. För äldre applikationer visar vårt kostnadsfria verktyg för .NET Framework-migrering vilka av dina paket som har kända sårbarheter.

5. Rå HTML bara från betrodda källor

Blazor kodar allt det visar, så att text som en användare skriver inte kan bli ett skript. Undantaget är MarkupString, som visar HTML som den är. Om den HTML:en kommer från användare, e-post eller externa system måste den saneras först.

6. Detaljerade fel bara under utveckling

DetailedErrors skickar hela felet med detaljer till webbläsaren. På en utvecklares dator är det användbart, i produktion en present till en angripare. I produktion får användaren ett kort meddelande, och detaljerna går till loggen, till exempel till Application Insights.

7. Gränser för inloggning och tunga operationer

Inloggning, lösenordsåterställning och exporter som belastar databasen hårt behöver en gräns för hur många anrop en användare eller adress får skicka. ASP.NET Core har det inbyggt med AddRateLimiter.

8. Säkerhetshuvuden och CSP

En Content Security Policy talar om för webbläsaren vilka skript den får köra. Blazor har egna krav: en WebAssembly-applikation behöver wasm-unsafe-eval i policyn. Sätt policyn medvetet och testa den, i stället för att utelämna den för att ”något slutade fungera”.

Statiska formulär

9. Skydd mot förfalskade anrop (antiforgery)

I en Blazor Web App skyddas formulär som renderas på servern mot cross-site request forgery när applikationen anropar app.UseAntiforgery(). EditForm lägger till token själv, medan ett vanligt HTML-<form> behöver komponenten <AntiforgeryToken />.

Interactive Server

10. Höj inte anslutningsgränserna i blindo

Med Interactive Server håller varje användare en anslutning och minne på servern. Blazor har gränser för meddelandestorlek och för hur mycket som buffras per användare, och att höja dem ”för att en uppladdning misslyckades” öppnar för att servern kan tömmas på resurser. Stora filer hör hemma i en separat uppladdning, inte i ett enda jättemeddelande. Hur minnet per användare summeras beskriver artikeln om långsamma Blazor-applikationer.

WebAssembly

11. Inget hemligt i klienten

Allt en WebAssembly-applikation innehåller laddas ner till webbläsaren: koden, konfigurationen och biblioteken. Microsoft är tydliga med att anslutningssträngar, nycklar, lösenord och privat kod aldrig får finnas där. Behörighetskontroller i webbläsaren kan kringgås, så varje API måste kontrollera behörigheterna på servern igen.

12. Tokens stannar på servern

Åtkomsttokens i webbläsarens lokala lagring är ett lätt mål. Microsofts rekommenderade upplägg för Blazor Web Apps är mönstret Backend for Frontend: servern håller tokens och pratar med API:erna, och webbläsaren får bara en säker cookie.

Checklistan i en tabell

#	Kontroll	Gäller för
1	Behörighet i tjänster, inte bara i gränssnittet	Överallt
2	Inga hemligheter i repositoryt	Överallt
3	Nycklar och tokens som går ut	Överallt
4	Inga kända sårbarheter i NuGet-paket	Överallt
5	MarkupString bara för betrodd HTML	Överallt
6	Detaljerade fel avstängda i produktion	Överallt
7	Gränser för inloggning och tunga operationer	Överallt
8	Medveten CSP och säkerhetshuvuden	Överallt
9	Antiforgery för formulär	Statiska formulär
10	Anslutningsgränserna ligger kvar	Interactive Server
11	Inget hemligt i klienten	WebAssembly
12	Tokens på servern (BFF)	WebAssembly

Vilket renderingsläge som passar vilken skärm och vad det betyder för säkerheten beskriver vi i Blazor Server vs WebAssembly vs Auto.

Så arbetar vi

Vi granskar Blazor- och .NET-applikationer mot just den här listan och åtgärdar det vi hittar, från behörighet som bara fanns i gränssnittet till nycklar som hamnat i repositoryt. Du får en prioriterad lista över riskerna, från det som bör åtgärdas den här veckan till det som kan vänta. Mer om vårt arbete med Blazor, och första steget är ett kostnadsfritt samtal på 30 minuter.

Källor

• ASP.NET Core Blazor authentication and authorization, Microsoft Learn
• Secure ASP.NET Core Blazor WebAssembly, Microsoft Learn
• Threat mitigation for interactive server-side rendering, Microsoft Learn
• Secure a Blazor Web App with OpenID Connect, Microsoft Learn
• Content Security Policy for Blazor, Microsoft Learn
• Blazor forms and antiforgery, Microsoft Learn
• Handle errors in Blazor apps, Microsoft Learn
• Rate limiting middleware, Microsoft Learn
• Auditing NuGet packages for security vulnerabilities, Microsoft Learn