Vägledning för hotminimering för statisk ASP.NET Core Blazor återgivning på serversidan

Anmärkning

Det här är inte den senaste versionen av den här artikeln. Den aktuella versionen finns i .NET 10-versionen av den här artikeln.

I den här artikeln beskrivs de säkerhetsöverväganden som utvecklare bör ta hänsyn till när de utvecklar Blazor Web Apps med statisk återgivning på serversidan.

Blazor kombinerar tre olika modeller i en för att skriva interaktiva webbappar. Traditionell återgivning på serversidan, som är en modell för begäran/svar baserat på HTTP. Interaktiv återgivning på serversidan, som är en återgivningsmodell baserad på SignalR. Slutligen återgivning på klientsidan, som är en återgivningsmodell baserad på WebAssembly.

Alla allmänna säkerhetsöverväganden som definierats för interaktiva återgivningslägen gäller för Blazor Web Apps när det finns interaktiva komponenter som återges i något av de återgivningslägen som stöds. I följande avsnitt beskrivs de säkerhetsöverväganden som är specifika för icke-interaktiv återgivning på serversidan i Blazor Web Apps och de specifika aspekter som gäller när återgivningslägen interagerar med varandra.

Allmänna överväganden för återgivning på serversidan

Modellen för återgivning på serversidan (SSR) baseras på den traditionella modellen för begäran/svar för HTTP. Därför finns det gemensamma problemområden mellan SSR och HTTP för begäran/svar. Allmänna säkerhetsöverväganden och specifika hot måste framgångsrikt hanteras. Ramverket innehåller inbyggda mekanismer för att hantera vissa av dessa hot, men andra hot är specifika för appkod och måste hanteras av appen. Dessa hot kan kategoriseras på följande sätt:

• Autentisering och auktorisering: Appen måste se till att användaren autentiseras och har behörighet att komma åt appen och de resurser den exponerar. Ramverket innehåller inbyggda mekanismer för autentisering och auktorisering, men appen måste se till att mekanismerna är korrekt konfigurerade och används. De inbyggda mekanismerna för autentisering och auktorisering beskrivs i dokumentationensBlazorserversäkerhetsnod och i ASP.NET Core-dokumentationens Säkerhet och Identity nod, så de beskrivs inte här.

• Validering och sanering av indata: Alla indata som kommer från en klient måste verifieras och saneras innan de används. Annars kan appen exponeras för attacker, till exempel SQL-inmatning, skript för flera platser, förfalskning av begäranden mellan platser, öppen omdirigering och andra former av attacker. Indata kan komma var som helst i begäran.

• Sessionshantering: Korrekt hantering av användarsessioner är viktigt för att säkerställa att appen inte exponeras för attacker, till exempel sessionskorrigering, sessionskapning och andra attacker. Information som lagras i sessionen måste skyddas och krypteras korrekt, och appens kod måste förhindra att en obehörig användare gissar eller manipulerar sessioner.

• Felhantering och loggning: Appen måste se till att fel hanteras och loggas korrekt. Annars kan appen exponeras för attacker, till exempel avslöjande av information. Detta kan inträffa när appen returnerar känslig information i svaret eller när appen returnerar detaljerade felmeddelanden med data som kan användas för att attackera appen.

• Dataskydd: Känsliga data måste skyddas korrekt, vilket inkluderar applogik när de körs på WebAssembly, eftersom de enkelt kan bakåtkompileras.

• Tjänsteavbrott: Appen måste se till att den inte utsätts för attacker, till exempel tjänsteavbrott. Detta inträffar till exempel när appen inte är korrekt skyddad mot råstyrkeattacker eller när en åtgärd kan göra att appen förbrukar för många resurser.

Validering och sanering av indata

Alla indata som kommer från klienten måste betraktas som obetrodda om inte informationen genererades och skyddades på servern, till exempel en CSRF-token, en autentisering cookie, en sessionsidentifierare eller någon annan nyttolast som skyddas med autentiserad kryptering.

Indata är normalt tillgängliga för appen via en bindningsprocess, till exempel via [SupplyParameterFromQuery] attributet eller [SupplyParameterFromForm] attributet. Innan du bearbetar dessa indata måste appen se till att data är giltiga. Appen måste till exempel bekräfta att det inte fanns några bindningsfel när formulärdata mappades till en komponentegenskap. Annars kan appen bearbeta ogiltiga data.

Om indata används för att utföra en omdirigering måste appen se till att indata är giltiga och att de inte pekar på en domän som anses vara ogiltig eller till en ogiltig undersökväg i appens bassökväg. Annars kan appen exponeras för öppna omdirigeringsattacker, där en cyberattacker kan skapa en länk som omdirigerar användaren till en skadlig webbplats.

Om indata används för att utföra en databasfråga måste appen bekräfta att indata är giltiga och att den inte exponerar appen för SQL-inmatningsattacker. Annars kan en cyberattacker skapa en skadlig fråga som kan användas för att extrahera information från databasen eller för att ändra databasen.

Data som kan ha kommit från användarindata måste också saneras innan de tas med i ett svar. Indata kan till exempel innehålla HTML eller JavaScript som kan användas för att utföra skriptattacker mellan webbplatser, som kan användas för att extrahera information från användaren eller för att utföra åtgärder för användarens räkning.

Ramverket innehåller följande mekanismer för att hjälpa till med validering och sanering av indata:

• Alla bundna formulärdata verifieras för grundläggande korrekthet. Om indata inte kan parsas rapporterar bindningsprocessen ett fel som appen kan identifiera innan någon åtgärd vidtas med data. Den inbyggda EditForm komponenten tar hänsyn till detta innan man anropar OnValidSubmit formulärets callback. Blazor undviker att köra återanropet om det finns ett eller flera bindningsfel.
• Ramverket använder en antiforgery-token för att skydda mot förfalskningsattacker mellan webbplatser. Mer information finns i översikten över ASP.NET Core Blazor-autentisering och auktorisering och ASP.NET Core Blazor-formulär.

Alla indata och behörigheter måste verifieras på servern vid tidpunkten för att utföra en viss åtgärd för att säkerställa att data är giltiga och korrekta vid den tidpunkten och att användaren får utföra åtgärden. Den här metoden överensstämmer med den säkerhetsvägledning som tillhandahålls för interaktiv återgivning på serversidan.

Sessionshantering

Sessionshantering hanteras av ramverket. Ramverket använder en session cookie för att identifiera användarsessionen. Sessionen cookie skyddas med hjälp av API:erna för ASP.NET Core Data Protection. Sessionen cookie är inte tillgänglig för JavaScript-kod som körs i webbläsaren och den kan inte lätt gissas eller manipuleras av en användare.

När det gäller andra sessionsdata, till exempel data som lagras i tjänster, bör sessionsdata lagras inom begränsade tjänster, eftersom begränsade tjänster är unika per en viss användarsession, i stället för singleton-tjänster som delas mellan alla användarsessioner i en viss processinstans.

När det gäller SSR är det inte mycket skillnad mellan begränsade och tillfälliga tjänster i de flesta fall, eftersom tjänstens livslängd är begränsad till en enda begäran. Det finns en skillnad i två scenarier:

• Om tjänsten matas in på mer än en plats eller vid olika tidpunkter under begäran.
• Om tjänsten kan användas i en interaktiv serverkontext, där den överlever flera renderingar, och det är grundläggande att tjänsten är begränsad till användarsessionen.

Felhantering och loggning

Ramverket tillhandahåller inbyggd loggning för appen på ramverksnivå. Ramverket loggar viktiga händelser, till exempel när ett antiforgery-token för ett formulär misslyckas att validera, när en rotkomponent börjar renderas och när en åtgärd skickas. Appen ansvarar för att logga andra händelser som kan vara viktiga att registrera.

Ramverket tillhandahåller inbyggd felhantering för appen på ramverksnivå. Ramverket hanterar fel som inträffar under återgivningen av en komponent och använder antingen mekanismen för felgräns för att visa ett användarvänligt felmeddelande eller låter felet bubbla upp till undantagshanteringsmellanprogrammet, som är konfigurerat för att återge felsidan.

Fel som uppstår under återgivning av direktuppspelning när svaret har börjat skickas till klienten visas i det slutliga svaret som ett allmänt felmeddelande. Information om orsaken till felet ingår endast under utvecklingen.

ASP.NET Core Dataskydd

Ramverket erbjuder mekanismer för att skydda känslig information för en viss användarsession och ser till att de inbyggda komponenterna använder dessa mekanismer för att skydda känslig information, till exempel att skydda användaridentitet när autentisering används cookie . Förutom scenarier som hanteras av ramverket ansvarar utvecklarkoden för att skydda annan appspecifik information. Det vanligaste sättet att göra detta är via API:er för ASP.NET Core Data Protection (DP) eller någon annan form av kryptering. Som en allmän regel ansvarar appen för:

• Se till att en användare inte kan inspektera eller ändra den privata informationen för en annan användare.
• Se till att en användare inte kan ändra användardata för en annan användare, till exempel en intern identifierare.

När det gäller DP måste du tydligt förstå var koden körs. För statisk återgivning på serversidan (statisk SSR) och interaktiv återgivning på serversidan (interaktiv SSR) lagras koden på servern och når aldrig klienten. För interaktiv WebAssembly-återgivningsläge når appkoden alltid klienten, vilket innebär att all känslig information som lagras i appkoden är tillgänglig för alla som har åtkomst till appen. Fördunkling och annan liknande teknik för att "skydda" koden är inte effektiv. När koden når klienten kan den bakåtkompileras för att extrahera känslig information.

Tjänsteförnekelse

På servernivå innehåller ramverket gränser för parametrar för begäran/svar, till exempel den maximala storleken på begäran och rubrikstorleken. När det gäller appkod Blazordefinierar "s formulärmappningssystem gränser som liknar de som definieras av MVC-modellbindningssystemet:

• Begränsa det maximala antalet fel.
• Begränsa det maximala rekursionsdjupet för bindemedlet.
• Begränsa det maximala antalet element som är bundna i en samling.

Dessutom finns det gränser som definierats för formuläret, till exempel den maximala storleken på formulärnyckeln och värdestorleken och det maximala antalet poster.

I allmänhet måste appen utvärdera när det finns en chans att en begäran utlöser en asymmetrisk mängd arbete av servern. Exempel på detta är när användaren skickar en begäran som parametriseras av N och servern utför en åtgärd som svar som är N gånger så dyr, där N är en parameter som en användare styr och kan växa på obestämd tid. Normalt måste appen antingen införa en gräns för det maximala N som den är villig att bearbeta eller se till att en åtgärd antingen är mindre, lika med eller dyrare än begäran av en konstant faktor.

Den här aspekten har mer att göra med skillnaden i tillväxt mellan det arbete som klienten utför och det arbete som servern utför än med en specifik 1→N-jämförelse. En klient kan till exempel skicka ett arbetsobjekt (infoga element i en lista) som tar N tid att utföra, men servern behöver N² för att bearbeta (eftersom den kanske gör något mycket naivt). Det är skillnaden mellan N och N² som är viktig.

Därför finns det en gräns för hur mycket arbete servern måste vara villig att göra, vilket är specifikt för appen. Den här aspekten gäller för arbetsbelastningar på serversidan eftersom resurserna finns på servern, men inte nödvändigtvis gäller för WebAssembly-arbetsbelastningar på klienten i de flesta fall.

Den andra viktiga aspekten är att detta inte bara är reserverat för CPU-tid. Det gäller även för alla resurser, till exempel minne, nätverk och utrymme på disken.

För WebAssembly-arbetsbelastningar är det vanligtvis lite oro över mängden arbete som klienten utför, eftersom klienten normalt begränsas av de resurser som är tillgängliga på klienten. Det finns dock vissa scenarier där klienten kan påverkas, om till exempel en app visar data från andra användare och en användare kan lägga till data i systemet som tvingar klienterna som visar data att utföra en mängd arbete som inte är proportionella mot mängden data som läggs till av användaren.

Rekommenderad (ej fullständig) kontrolllista

• Se till att användaren autentiseras och har behörighet att komma åt appen och de resurser som den exponerar.
• Verifiera och sanera alla indata som kommer från en klient innan du använder den.
• Hantera användarsessioner korrekt för att säkerställa att tillståndet inte delas av misstag mellan användare.
• Hantera och logga fel korrekt för att undvika att exponera känslig information.
• Logga viktiga händelser i appen för att identifiera potentiella problem och granskningsåtgärder som utförs av användare.
• Skydda känslig information med hjälp av api:erna för ASP.NET Core Data Protection eller någon av de tillgängliga komponenterna (Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState).
• Se till att appen förstår de resurser som kan användas av en viss begäran och har begränsningar för att undvika överbelastningsattacker.