Richtlijnen voor bedreigingsbeperking voor ASP.NET Core Blazor statische rendering aan de serverzijde

Notitie

Dit is niet de nieuwste versie van dit artikel. Zie de .NET 9-versie van dit artikelvoor de huidige release.

Belangrijk

Deze informatie heeft betrekking op een pre-releaseproduct dat aanzienlijk kan worden gewijzigd voordat het commercieel wordt uitgebracht. Microsoft geeft geen garanties, uitdrukkelijk of impliciet, met betrekking tot de informatie die hier wordt verstrekt.

Zie de .NET 9-versie van dit artikelvoor de huidige release.

In dit artikel worden de beveiligingsoverwegingen uitgelegd waarmee ontwikkelaars rekening moeten houden bij het ontwikkelen van Blazor Web Apps met statische rendering aan de serverzijde.

Blazor combineert drie verschillende modellen in één voor het schrijven van interactieve web-apps. Traditionele rendering aan de serverzijde, een aanvraag-/antwoordmodel op basis van HTTP. Interactieve rendering aan de serverzijde, een renderingmodel op basis van SignalR. Ten slotte is client-side rendering een rendermodel op basis van WebAssembly.

Alle algemene beveiligingsoverwegingen die zijn gedefinieerd voor de interactieve renderingmodi zijn van toepassing op Blazor Web Apps wanneer er interactieve onderdelen worden weergegeven in een van de ondersteunde rendermodi. In de volgende secties worden de beveiligingsoverwegingen uitgelegd die specifiek zijn voor niet-interactieve rendering aan de serverzijde in Blazor Web Apps en de specifieke aspecten die van toepassing zijn wanneer rendermodi met elkaar communiceren.

Algemene overwegingen voor rendering aan de serverzijde

Het SSR-model (Server Side Rendering) is gebaseerd op het traditionele aanvraag-/antwoordmodel van HTTP. Daarom zijn er veelvoorkomende aandachtspunten tussen SSR en request/response HTTP. Algemene beveiligingsoverwegingen en specifieke bedreigingen moeten succesvol worden gemitigeerd. Het framework biedt ingebouwde mechanismen voor het beheren van sommige van deze bedreigingen, maar andere bedreigingen zijn specifiek voor app-code en moeten worden verwerkt door de app. Deze bedreigingen kunnen als volgt worden gecategoriseerd:

• Verificatie en autorisatie: De app moet ervoor zorgen dat de gebruiker is geverifieerd en gemachtigd voor toegang tot de app en de resources die deze beschikbaar maakt. Het framework biedt ingebouwde mechanismen voor verificatie en autorisatie, maar de app moet ervoor zorgen dat de mechanismen correct zijn geconfigureerd en gebruikt. De ingebouwde mechanismen voor verificatie en autorisatie worden behandeld in de Blazor documentatie Server beveiligingsknooppunt en in de ASP.NET Core-documentatie Security and Identity node, zodat ze hier niet worden behandeld.

• Invoervalidatie en opschoning: alle invoer die afkomstig is van een client, moet worden gevalideerd en opgeschoond voordat u deze gebruikt. Anders kan de app worden blootgesteld aan aanvallen, zoals SQL-injectie, scripts op meerdere sites, aanvraagvervalsing op meerdere sites, open omleiding en andere vormen van aanvallen. De invoer kan overal in het verzoek vandaan komen.

• Sessiebeheer: het correct beheren van gebruikerssessies is essentieel om ervoor te zorgen dat de app niet wordt blootgesteld aan aanvallen, zoals sessiefixatie, sessiekappen en andere aanvallen. Informatie die in de sessie is opgeslagen, moet goed worden beveiligd en versleuteld en de code van de app moet voorkomen dat kwaadwillende gebruikers sessies raden of bewerken.

• Foutafhandeling en logboekregistratie: De app moet ervoor zorgen dat fouten correct worden verwerkt en geregistreerd. Anders kan de app worden blootgesteld aan aanvallen, zoals openbaarmaking van informatie. Dit kan gebeuren wanneer de app gevoelige informatie retourneert in het antwoord of wanneer de app gedetailleerde foutberichten retourneert met gegevens die kunnen worden gebruikt om de app aan te vallen.

• Gegevensbeveiliging: gevoelige gegevens moeten correct worden beveiligd, waaronder app-logica bij het uitvoeren op WebAssembly, omdat deze eenvoudig kunnen worden reverse-engineered.

• Denial of Service: De app moet ervoor zorgen dat deze niet wordt blootgesteld aan aanvallen, zoals Denial of Service. Dit gebeurt bijvoorbeeld wanneer de app niet goed is beveiligd tegen beveiligingsaanvallen of wanneer een actie ertoe kan leiden dat de app te veel resources verbruikt.

Invoervalidatie en opschoning

Alle invoer die afkomstig is van de client, moet als niet-vertrouwd worden beschouwd, tenzij de gegevens zijn gegenereerd en beveiligd op de server, zoals een CSRF-token, een verificatie cookie, een sessie-id of een andere nettolading die is beveiligd met geverifieerde versleuteling.

Invoer is normaal gesproken beschikbaar voor de app via een bindingsproces, bijvoorbeeld via het [SupplyParameterFromQuery] kenmerk of [SupplyParameterFromForm] kenmerk. Voordat deze invoer wordt verwerkt, moet de app ervoor zorgen dat de gegevens geldig zijn. De app moet bijvoorbeeld bevestigen dat er geen bindingsfouten zijn opgetreden bij het toewijzen van de formuliergegevens aan een onderdeeleigenschap. Anders kan de app ongeldige gegevens verwerken.

Als de invoer wordt gebruikt om een omleiding uit te voeren, moet de app ervoor zorgen dat de invoer geldig is en dat deze niet verwijst naar een domein dat als ongeldig wordt beschouwd of naar een ongeldig subpad binnen het basispad van de app. Anders kan de app worden blootgesteld aan open omleidingsaanvallen, waarbij een cyberaanval een koppeling kan maken waarmee de gebruiker wordt omgeleid naar een schadelijke site.

Als de invoer wordt gebruikt om een databasequery uit te voeren, moet de app bevestigen dat de invoer geldig is en of de app niet wordt blootgesteld aan SQL-injectieaanvallen. Anders kan een cyberaanval een schadelijke query maken die kan worden gebruikt om gegevens uit de database te extraheren of om de database te wijzigen.

Gegevens die mogelijk afkomstig zijn van gebruikersinvoer, moeten ook worden opgeschoond voordat ze in een antwoord worden opgenomen. De invoer kan bijvoorbeeld HTML of JavaScript bevatten die kan worden gebruikt voor het uitvoeren van scriptaanvallen op meerdere sites, die kunnen worden gebruikt om gegevens van de gebruiker te extraheren of acties uit te voeren namens de gebruiker.

Het framework biedt de volgende mechanismen voor het valideren en opschonen van invoer:

• Alle afhankelijke formuliergegevens worden gevalideerd voor basis correctheid. Als een invoer niet kan worden geparseerd, meldt het bindingsproces een fout die de app kan detecteren voordat er actie wordt ondernomen met de gegevens. Het ingebouwde EditForm-onderdeel houdt hier rekening mee voordat de OnValidSubmit form callback wordt aangeroepen. Blazor vermijdt het uitvoeren van de callback als er een of meer bindingsfouten zijn.
• Het framework maakt gebruik van een antiforgery-token om te beschermen tegen vervalsingsaanvallen op meerdere sites. Zie ASP.NET Core Blazor authentication and authorization and ASP.NET Core Blazor forms overviewvoor meer informatie.

Alle invoer en machtigingen moeten worden gevalideerd op de server op het moment dat een bepaalde actie wordt uitgevoerd om ervoor te zorgen dat de gegevens geldig en nauwkeurig zijn op dat moment en dat de gebruiker de actie mag uitvoeren. Deze benadering is consistent met de beveiligingsrichtlijnen voor interactieve rendering aan de serverzijde.

Sessiebeheer

Sessiebeheer wordt afgehandeld door het framework. Het framework maakt gebruik van een sessie cookie om de gebruikerssessie te identificeren. De sessie cookie wordt beveiligd met behulp van de ASP.NET Core Data Protection-API's. De sessie cookie is niet toegankelijk voor JavaScript-code die wordt uitgevoerd in de browser en kan niet eenvoudig worden geraden of gemanipuleerd door een gebruiker.

nl-NL: Wat betreft andere sessiegegevens, zoals gegevens die binnen services zijn opgeslagen, moeten de sessiegegevens worden opgeslagen binnen services met een bepaald bereik, aangezien scoped services uniek zijn per specifieke gebruikerssessie, in plaats van singleton-services die worden gedeeld over alle gebruikerssessies in een bepaalde procesinstantie.

Als het gaat om SSR, is er in de meeste gevallen niet veel verschil tussen scoped en tijdelijke services, omdat de levensduur van de service beperkt is tot één aanvraag. Er is een verschil in twee scenario's:

• Als de service wordt geïnjecteerd op meer dan één locatie of op verschillende tijdstippen tijdens de aanvraag.
• Als de service kan worden gebruikt in een interactieve servercontext, waarbij de service meerdere weergaven overleeft en het essentieel is dat de service is gericht op de gebruikerssessie.

Foutafhandeling en logboekregistratie

Het framework biedt ingebouwde logboekregistratie voor de app op frameworkniveau. Het framework registreert belangrijke gebeurtenissen, zoals wanneer het antivervalsingstoken voor een formulier niet kan worden gevalideerd, wanneer de weergave van een hoofdcomponent begint en wanneer een actie wordt uitgevoerd. De app is verantwoordelijk voor het vastleggen van andere gebeurtenissen die belangrijk kunnen zijn om vast te leggen.

Het framework biedt ingebouwde foutafhandeling voor de app op frameworkniveau. Het framework behandelt fouten die optreden tijdens het renderen van een component en gebruikt het foutrand-mechanisme om een vriendelijke foutmelding weer te geven, of laat de fout doorgaan naar de middleware voor het afhandelen van uitzonderingen, die is geconfigureerd om de foutpagina weer te geven.

Fouten die optreden tijdens het streamen van rendering nadat het antwoord naar de client is verzonden, worden in het laatste antwoord weergegeven als een algemeen foutbericht. Details over de oorzaak van de fout worden alleen tijdens de ontwikkeling opgenomen.

ASP.NET Core Gegevensbescherming

Het framework biedt mechanismen voor het beveiligen van gevoelige informatie voor een bepaalde gebruikerssessie en zorgt ervoor dat de ingebouwde onderdelen deze mechanismen gebruiken om gevoelige informatie te beveiligen, zoals het beveiligen van gebruikersidentiteiten bij het gebruik van cookie-verificatie. Buiten scenario's die door het framework worden verwerkt, is ontwikkelaarscode verantwoordelijk voor het beveiligen van andere app-specifieke informatie. De meest voorkomende manier om dit te doen, is via de ASP.NET DP-API's (Core Data Protection) of een andere vorm van versleuteling. In de regel is de app verantwoordelijk voor:

• Zorg ervoor dat een gebruiker de persoonlijke gegevens van een andere gebruiker niet kan inspecteren of wijzigen.
• Zorg ervoor dat een gebruiker geen gebruikersgegevens van een andere gebruiker kan wijzigen, zoals een interne id.

Wat DP betreft, moet u duidelijk begrijpen waar de code wordt uitgevoerd. Voor de statische server-side rendering (statische SSR) en interactieve server-side rendering (interactieve SSR) wordt code opgeslagen op de server en wordt de client nooit bereikt. Voor de interactieve webassembly-weergavemodus bereikt de app-code altijd de client. Dit betekent dat gevoelige informatie die in de app-code is opgeslagen, beschikbaar is voor iedereen met toegang tot de app. Verdoofing en andere vergelijkbare technieken om de code te beveiligen, is niet effectief. Zodra de code de client heeft bereikt, kan deze reverse-engineering worden uitgevoerd om de gevoelige informatie te extraheren.

Dienstweigering

Op serverniveau biedt het framework limieten voor aanvraag-/antwoordparameters, zoals de maximale grootte van de aanvraag en de headergrootte. Wat de app-code betreft, definieert het Blazor-systeem voor formuliertoewijzing limieten die vergelijkbaar zijn met de limieten die zijn gedefinieerd door het MVC-modelbindingsysteem.

• Limiet voor het maximum aantal fouten.
• Beperk de maximale recursiediepte voor de binder.
• Limiet voor het maximum aantal elementen dat in een verzameling is gebonden.

Daarnaast zijn er limieten gedefinieerd voor het formulier, zoals de maximale grootte van de formuliersleutel en waardegrootte en het maximum aantal vermeldingen.

Over het algemeen moet de app evalueren wanneer er een kans is dat een aanvraag een asymmetrische hoeveelheid werk activeert door de server. Voorbeelden hiervan zijn wanneer de gebruiker een aanvraag verzendt die wordt geparameteriseerd door N en de server een bewerking uitvoert die N keer zo duur is, waarbij N een parameter is die een gebruiker beheert en voor onbepaalde tijd kan groeien. Normaal gesproken moet de app een limiet opleggen aan het maximum N dat de app bereid is om te verwerken of ervoor te zorgen dat elke bewerking minder, gelijk of duurder is dan de aanvraag met een constante factor.

Dit aspect heeft meer te maken met het verschil in groei tussen het werk dat de client uitvoert en het werk dat de server uitvoert dan met een specifieke vergelijking van 1→N. Een client kan bijvoorbeeld een werkitem indienen (elementen invoegen in een lijst) dat N eenheden nodig heeft voor de uitvoering, maar de server heeft N² nodig voor verwerking (omdat het misschien iets heel naïefs doet). Het is het verschil tussen N en N² dat belangrijk is.

Als zodanig is er een limiet voor het aantal werk dat de server moet willen doen, wat specifiek is voor de app. Dit aspect is van toepassing op workloads aan de serverzijde, omdat de resources zich op de server bevinden, maar in de meeste gevallen niet noodzakelijkerwijs van toepassing is op WebAssembly-workloads op de client.

Het andere belangrijke aspect is dat dit niet alleen gereserveerd is voor CPU-tijd. Het is ook van toepassing op alle resources, zoals geheugen, netwerk en ruimte op schijf.

Voor WebAssembly-workloads is er meestal weinig bezorgdheid over de hoeveelheid werk die de client uitvoert, omdat de client normaal gesproken wordt beperkt door de resources die beschikbaar zijn op de client. Er zijn echter enkele scenario's waarbij de client mogelijk wordt beïnvloed, als een app bijvoorbeeld gegevens van andere gebruikers weergeeft en één gebruiker gegevens kan toevoegen aan het systeem waarmee de clients die de gegevens weergeven, een hoeveelheid werk kunnen uitvoeren die niet evenredig is met de hoeveelheid gegevens die door de gebruiker is toegevoegd.

Aanbevolen (niet-volledige) controlelijst

• Zorg ervoor dat de gebruiker is geverifieerd en gemachtigd voor toegang tot de app en de resources die deze beschikbaar maakt.
• Valideer en saneer alle invoer die afkomstig is van een client voordat u deze gebruikt.
• Beheer gebruikerssessies op de juiste manier om ervoor te zorgen dat de status niet per ongeluk wordt gedeeld tussen gebruikers.
• Fouten correct afhandelen en loggen om te voorkomen dat gevoelige informatie wordt blootgelegd.
• Meld belangrijke gebeurtenissen in de app aan om potentiële problemen te identificeren en controleacties te controleren die door gebruikers worden uitgevoerd.
• Gevoelige informatie beveiligen met behulp van de ASP.NET Core Data Protection-API's of een van de beschikbare onderdelen (Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage, PersistentComponentState).
• Zorg ervoor dat de app de resources begrijpt die door een bepaalde aanvraag kunnen worden gebruikt en dat er limieten gelden om Denial of Service-aanvallen te voorkomen.