Delen via

Beveiligingsoverwegingen (Entity Framework)

  • Artikel

In dit artikel worden beveiligingsoverwegingen beschreven die specifiek zijn voor het ontwikkelen, implementeren en uitvoeren van Entity Framework-toepassingen. U moet ook aanbevelingen volgen voor het maken van beveiligde .NET Framework-toepassingen. Zie Beveiligingsoverzicht voor meer informatie.

Algemene beveiligingsoverwegingen

De volgende beveiligingsoverwegingen zijn van toepassing op alle toepassingen die gebruikmaken van Entity Framework.

Alleen vertrouwde gegevensbronproviders gebruiken

Als u wilt communiceren met de gegevensbron, moet een provider het volgende doen:

  • De verbindingsreeks ontvangen van Entity Framework.
  • Vertaal de opdrachtstructuur naar de systeemeigen querytaal van de gegevensbron.
  • Resultatensets samenstellen en retourneren.

Tijdens de aanmeldingsbewerking wordt informatie die is gebaseerd op het gebruikerswachtwoord doorgegeven aan de server via de netwerkbibliotheken van de onderliggende gegevensbron. Een kwaadwillende provider kan gebruikersreferenties stelen, schadelijke query's genereren of knoeien met de resultatenset.

Uw verbinding versleutelen om gevoelige gegevens te beveiligen

Entity Framework verwerkt gegevensversleuteling niet rechtstreeks. Als gebruikers toegang hebben tot gegevens via een openbaar netwerk, moet uw toepassing een versleutelde verbinding met de gegevensbron tot stand brengen om de beveiliging te verbeteren. Zie de beveiligingsdocumentatie voor uw gegevensbron voor meer informatie.

De verbindingsreeks beveiligen

Het beveiligen van de toegang tot uw gegevensbron is een van de belangrijkste doelen bij het beveiligen van een toepassing. Een verbindingsreeks geeft een potentieel beveiligingsprobleem weer als deze niet is beveiligd of als deze onjuist is samengesteld. Wanneer u verbindingsgegevens opslaat in tekst zonder opmaak of in het geheugen opslaat, loopt u het risico dat uw hele systeem in gevaar komt. Hier volgen de aanbevolen methoden voor het beveiligen van verbindingsreeks s:

  • Gebruik beheerde identiteiten voor Azure-resources wanneer u verbinding maakt met Azure SQL.

    Zie Beheerde identiteiten voor Azure-resources voor meer informatie.

  • Gebruik Windows-verificatie met een on-premises SQL Server-gegevensbron.

    Wanneer u Windows-verificatie gebruikt om verbinding te maken met een SQL Server-gegevensbron, bevat de verbindingsreeks geen aanmeldings- en wachtwoordgegevens.

  • Secties van configuratiebestanden versleutelen met behulp van beveiligde configuratie.

    ASP.NET biedt een functie met de naam beveiligde configuratie waarmee u gevoelige informatie in een configuratiebestand kunt versleutelen. Hoewel u voornamelijk ontworpen bent voor ASP.NET, kunt u ook beveiligde configuratie gebruiken om secties van configuratiebestanden in Windows-toepassingen te versleutelen.

  • Sla verbindingsreeks s op in beveiligde configuratiebestanden.

    Sluit nooit verbindingsreeks s in uw broncode in. U kunt verbindingsreeks opslaan in configuratiebestanden, waardoor u ze niet meer hoeft in te sluiten in de code van uw toepassing. De wizard Entiteitsgegevensmodel slaat standaard verbindingsreeks s op in het configuratiebestand van de toepassing. U moet dit bestand beveiligen om onbevoegde toegang te voorkomen.

  • Gebruik verbindingsreeks opbouwfuncties bij het dynamisch maken van verbindingen.

    Als u tijdens runtime verbindingsreeks s moet maken, gebruikt u de EntityConnectionStringBuilder klasse. Deze klasse tekenreeksbouwer helpt verbindingsreeks injectieaanvallen te voorkomen door ongeldige invoergegevens te valideren en te ontsnappen. Gebruik ook de juiste opbouwklasse voor tekenreeksen om de gegevensbron te maken verbindingsreeks die deel uitmaakt van het Entity Framework-verbindingsreeks. Zie Opbouwfuncties voor verbindingsreeksen voor informatie over verbindingsreeks opbouwfuncties voor ADO.NET providers.

Zie Verbindingsgegevens beveiligen voor meer informatie.

Een EntityConnection niet beschikbaar maken voor niet-vertrouwde gebruikers

Een EntityConnection object toont de verbindingsreeks van de onderliggende verbinding. Een gebruiker met toegang tot een EntityConnection object kan ook de ConnectionState onderliggende verbinding wijzigen. De EntityConnection klasse is niet thread-veilig.

Geen verbindingen doorgeven buiten de beveiligingscontext

Nadat een verbinding tot stand is gebracht, mag u deze niet doorgeven buiten de beveiligingscontext. Eén thread met machtigingen voor het openen van een verbinding mag de verbinding bijvoorbeeld niet opslaan op een globale locatie. Als de verbinding beschikbaar is op een globale locatie, kan een andere schadelijke thread de open verbinding gebruiken zonder dat die machtiging expliciet aan de verbinding is verleend.

Houd er rekening mee dat aanmeldingsgegevens en wachtwoorden mogelijk zichtbaar zijn in een geheugendump

Wanneer aanmeldings- en wachtwoordgegevens van de gegevensbron worden opgegeven in de verbindingsreeks, wordt deze informatie in het geheugen bewaard totdat de garbagecollection de resources terugvordert. Dit maakt het onmogelijk om te bepalen wanneer een wachtwoordtekenreeks niet meer in het geheugen staat. Als een toepassing vastloopt, kan een geheugendumpbestand gevoelige beveiligingsgegevens bevatten en kan de gebruiker die de toepassing uitvoert en elke gebruiker met beheerderstoegang tot de computer het geheugendumpbestand weergeven. Gebruik Windows-verificatie voor verbindingen met Microsoft SQL Server.

Gebruikers alleen de benodigde machtigingen verlenen in de gegevensbron

Een gegevensbronbeheerder mag alleen de benodigde machtigingen verlenen aan gebruikers. Hoewel Entity SQL geen DML-instructies ondersteunt die gegevens wijzigen, zoals INSERT, UPDATE of DELETE, hebben gebruikers nog steeds toegang tot de verbinding met de gegevensbron. Een kwaadwillende gebruiker kan deze verbinding gebruiken om DML-instructies uit te voeren in de systeemeigen taal van de gegevensbron.

Toepassingen uitvoeren met de minimale machtigingen

Wanneer u een beheerde toepassing toestaat uit te voeren met een machtiging voor volledig vertrouwen, beperkt .NET Framework de toegang van de toepassing tot uw computer niet. Hierdoor kan een beveiligingsprobleem in uw toepassing het hele systeem in gevaar brengen. Als u codetoegangsbeveiliging en andere beveiligingsmechanismen in .NET Framework wilt gebruiken, moet u toepassingen uitvoeren met behulp van gedeeltelijke vertrouwensmachtigingen en met de minimale set machtigingen die nodig zijn om de toepassing in staat te stellen te functioneren. De volgende machtigingen voor codetoegang zijn de minimale machtigingen die uw Entity Framework-toepassing nodig heeft:

Zie Code Access Security en ADO.NET voor meer informatie.

Niet-vertrouwde toepassingen niet installeren

Entity Framework dwingt geen beveiligingsmachtigingen af en roept eventuele door de gebruiker geleverde gegevensobjectcode aan, ongeacht of deze wordt vertrouwd of niet. Zorg ervoor dat verificatie en autorisatie van de client wordt uitgevoerd door het gegevensarchief en door uw toepassing.

Toegang tot alle configuratiebestanden beperken

Een beheerder moet schrijftoegang beperken tot alle bestanden die de configuratie voor een toepassing opgeven, met inbegrip van enterpriseec.config, security.config, machine.conf en de toepassing voor het configuratiebestand <van de toepassing>.exe.config.

De invariante naam van de provider kan worden gewijzigd in de app.config. De clienttoepassing moet verantwoordelijk zijn voor toegang tot de onderliggende provider via het standaardproviderfactorymodel met behulp van een sterke naam.

Machtigingen beperken tot het model en toewijzingsbestanden

Een beheerder moet schrijftoegang tot het model beperken en toewijzingsbestanden (.edmx, .csdl, .ssdl en .msl) beperken tot alleen gebruikers die het model of de toewijzingen wijzigen. Entity Framework vereist alleen leestoegang tot deze bestanden tijdens runtime. Een beheerder moet ook de toegang tot objectlaag en vooraf gecompileerde broncodebestanden beperken die worden gegenereerd door de hulpprogramma's voor entiteitsgegevensmodellen.

Beveiligingsoverwegingen voor query's

De volgende beveiligingsoverwegingen zijn van toepassing bij het uitvoeren van query's op een conceptueel model. Deze overwegingen zijn van toepassing op Entity SQL-query's met behulp van EntityClient en objectquery's met behulp van LINQ-, Entity SQL- en opbouwmethoden voor query's.

SQL-injectieaanvallen voorkomen

Toepassingen voeren vaak externe invoer uit (van een gebruiker of een andere externe agent) en voeren acties uit op basis van die invoer. Invoer die rechtstreeks of indirect is afgeleid van de gebruiker of een externe agent, kan inhoud bevatten die gebruikmaakt van de syntaxis van de doeltaal om onbevoegde acties uit te voeren. Wanneer de doeltaal een Structured Query Language (SQL) is, zoals Transact-SQL, wordt deze manipulatie een SQL-injectieaanval genoemd. Een kwaadwillende gebruiker kan opdrachten rechtstreeks in de query injecteren en een databasetabel verwijderen, een Denial of Service veroorzaken of de aard van de bewerking wijzigen die wordt uitgevoerd.

  • Entiteit SQL-injectieaanvallen:

    SQL-injectieaanvallen kunnen worden uitgevoerd in Entity SQL door schadelijke invoer te leveren aan waarden die worden gebruikt in een querypredicaat en in parameternamen. Om het risico van SQL-injectie te voorkomen, moet u gebruikersinvoer nooit combineren met entiteits-SQL-opdrachttekst.

    Entiteits-SQL-query's accepteren parameters overal waar letterlijke waarden worden geaccepteerd. U moet geparameteriseerde query's gebruiken in plaats van letterlijke waarden van een externe agent rechtstreeks in de query te injecteren. U moet ook overwegen om methoden voor opbouwfuncties voor query's te gebruiken om Entiteit SQL veilig te maken.

  • LINQ naar entiteiten injectieaanvallen:

    Hoewel querysamenstelling mogelijk is in LINQ naar entiteiten, wordt deze uitgevoerd via de objectmodel-API. In tegenstelling tot Entiteit SQL-query's worden LINQ-naar-entiteiten-query's niet samengesteld met behulp van tekenreeksmanipulatie of samenvoeging, en zijn ze niet vatbaar voor traditionele SQL-injectieaanvallen.

Zeer grote resultatensets voorkomen

Een zeer grote resultatenset kan ertoe leiden dat het clientsysteem wordt afgesloten als de client bewerkingen uitvoert die resources verbruiken evenredig met de grootte van de resultatenset. Onverwacht grote resultatensets kunnen zich onder de volgende omstandigheden voordoen:

  • In query's voor een grote database die geen geschikte filtervoorwaarden bevat.
  • In query's waarmee Cartesische joins op de server worden gemaakt.
  • In geneste Entiteit SQL-query's.

Wanneer u gebruikersinvoer accepteert, moet u ervoor zorgen dat de invoer niet kan leiden tot resultatensets die groter worden dan wat het systeem kan verwerken. U kunt de Take methode in LINQ ook gebruiken voor entiteiten of de operator LIMIT in Entity SQL om de grootte van de resultatenset te beperken.

Vermijd het retourneren van IQueryable-resultaten bij het blootstellen van methoden aan mogelijk niet-vertrouwde bellers

Vermijd het retourneren IQueryable<T> van typen van methoden die om de volgende redenen worden blootgesteld aan mogelijk niet-vertrouwde bellers:

  • Een consument van een query die een IQueryable<T> type beschikbaar maakt, kan methoden aanroepen voor het resultaat waarmee beveiligde gegevens worden weergegeven of de grootte van de resultatenset vergroten. Denk bijvoorbeeld aan de volgende methodehandtekening:

    public IQueryable<Customer> GetCustomer(int customerId)

    Een consument van deze query kan de geretourneerde IQueryable<Customer> query aanroepen .Include("Orders") om gegevens op te halen die de query niet wilde beschikbaar maken. Dit kan worden vermeden door het retourtype van de methode te wijzigen en een methode aan te IEnumerable<T> roepen (zoals .ToList()) die de resultaten materialiseert.

  • Omdat IQueryable<T> query's worden uitgevoerd wanneer de resultaten worden ge curseerd, kan een consument van een query die een IQueryable<T> type beschikbaar maakt, uitzonderingen ondervangen die worden gegenereerd. Uitzonderingen kunnen informatie bevatten die niet bedoeld is voor de consument.

Beveiligingsoverwegingen voor entiteiten

De volgende beveiligingsoverwegingen zijn van toepassing bij het genereren en werken met entiteitstypen.

Een ObjectContext niet delen tussen toepassingsdomeinen

Het delen van een ObjectContext domein met meer dan één toepassing kan informatie beschikbaar maken in de verbindingsreeks. In plaats daarvan moet u geserialiseerde objecten of objectgrafieken overdragen naar het andere toepassingsdomein en deze objecten vervolgens koppelen aan een ObjectContext in dat toepassingsdomein. Zie Objecten serialiseren voor meer informatie.

Schendingen van typeveiligheid voorkomen

Als de veiligheid van het type wordt geschonden, kan Entity Framework de integriteit van gegevens in objecten niet garanderen. Beveiligingsschendingen van het type kunnen optreden als u niet-vertrouwde toepassingen toestaat om te worden uitgevoerd met volledige beveiliging van codetoegang.

Uitzonderingen verwerken

Toegang tot methoden en eigenschappen van een ObjectContext in een try-catch-blok. Als u uitzonderingen onderscheppen, voorkomt u dat niet-verwerkte uitzonderingen vermeldingen in de gegevens van het ObjectStateManager model (zoals tabelnamen) zichtbaar maken voor gebruikers van uw toepassing.

Beveiligingsoverwegingen voor ASP.NET-toepassingen

Houd rekening met het volgende wanneer u met paden in ASP.NET toepassingen werkt.

Controleer of uw host padcontroles uitvoert

Wanneer de |DataDirectory| vervangingstekenreeks (tussen pijpsymbolen) wordt gebruikt, ADO.NET controleert of het opgeloste pad wordt ondersteund. Bijvoorbeeld: '.' is niet toegestaan achter DataDirectory. Dezelfde controle voor het omzetten van de hoofdoperator van de webtoepassing (~) wordt uitgevoerd door het proces dat als host fungeert voor ASP.NET. IIS voert deze controle uit; andere hosts dan IIS kunnen echter niet controleren of het opgeloste pad wordt ondersteund. U moet weten wat het gedrag is van de host waarop u een Entity Framework-toepassing implementeert.

Veronderstellingen over opgeloste padnamen niet maken

Hoewel de waarden waarnaar de hoofdoperator (~) en de DataDirectory vervangingstekenreeks moeten worden omgezet, constant moeten blijven tijdens de runtime van de toepassing, beperkt Entity Framework de host niet tot het wijzigen van deze waarden.

De padlengte controleren vóór de implementatie

Voordat u een Entity Framework-toepassing implementeert, moet u ervoor zorgen dat de waarden van de hoofdoperator (~) en DataDirectory vervangingstekenreeks niet groter zijn dan de limieten van de padlengte in het besturingssysteem. ADO.NET gegevensproviders zorgen er niet voor dat de padlengte binnen geldige limieten valt.

Beveiligingsoverwegingen voor ADO.NET metagegevens

De volgende beveiligingsoverwegingen zijn van toepassing bij het genereren en werken met model- en toewijzingsbestanden.

Gevoelige informatie niet beschikbaar maken via logboekregistratie

ADO.NET metagegevensserviceonderdelen registreren geen persoonlijke gegevens. Als er resultaten zijn die niet kunnen worden geretourneerd vanwege toegangsbeperkingen, moeten databasebeheersystemen en bestandssystemen nul resultaten retourneren in plaats van een uitzondering te genereren die gevoelige informatie kan bevatten.

MetadataWorkspace-objecten van niet-vertrouwde bronnen niet accepteren

Toepassingen mogen geen exemplaren van de MetadataWorkspace klasse accepteren van niet-vertrouwde bronnen. In plaats daarvan moet u expliciet een werkruimte maken en vullen vanuit een dergelijke bron.

Zie ook