Dela via

Säkerhetsöverväganden (Entity Framework)

  • Artikel

I den här artikeln beskrivs säkerhetsöverväganden som är specifika för utveckling, distribution och körning av Entity Framework-program. Du bör också följa rekommendationerna för att skapa säkra .NET Framework-program. Mer information finns i Säkerhetsöversikt.

Allmänna säkerhetsöverväganden

Följande säkerhetsöverväganden gäller för alla program som använder Entity Framework.

Använd endast betrodda datakällaprovidrar

För att kommunicera med datakällan måste en provider göra följande:

  • Ta emot niska veze från Entity Framework.
  • Översätt kommandoträdet till datakällans interna frågespråk.
  • Montera och returnera resultatuppsättningar.

Under inloggningen skickas information som baseras på användarlösenordet till servern via nätverksbiblioteken för den underliggande datakällan. En illasinnad provider kan stjäla användarautentiseringsuppgifter, generera skadliga frågor eller manipulera resultatuppsättningen.

Kryptera anslutningen för att skydda känsliga data

Entity Framework hanterar inte datakryptering direkt. Om användarna får åtkomst till data via ett offentligt nätverk bör programmet upprätta en krypterad anslutning till datakällan för att öka säkerheten. Mer information finns i säkerhetsrelaterad dokumentation för din datakälla.

Skydda niska veze

Att skydda åtkomsten till din datakälla är ett av de viktigaste målen när du skyddar ett program. En niska veze utgör en potentiell säkerhetsrisk om den inte är skyddad eller om den är felaktigt konstruerad. När du lagrar anslutningsinformation i oformaterad text eller bevarar den i minnet riskerar du att äventyra hela systemet. Följande är de rekommenderade metoderna för att skydda niska veze:

  • Använd hanterade identiteter för Azure-resurser när du ansluter till Azure SQL.

    Mer information finns i Hanterade identiteter för Azure-resurser.

  • Använd Windows-autentisering med en lokal SQL Server-datakälla.

    När du använder Windows-autentisering för att ansluta till en SQL Server-datakälla innehåller niska veze inte inloggnings- och lösenordsinformation.

  • Kryptera konfigurationsfilavsnitt med hjälp av skyddad konfiguration.

    ASP.NET innehåller en funktion som kallas skyddad konfiguration som gör att du kan kryptera känslig information i en konfigurationsfil. Även om den främst är utformad för ASP.NET kan du också använda skyddad konfiguration för att kryptera delar av konfigurationsfiler i Windows-program.

  • Lagra niska veze i skyddade konfigurationsfiler.

    Du bör aldrig bädda in niska veze i källkoden. Du kan lagra niska veze i konfigurationsfiler, vilket eliminerar behovet av att bädda in dem i programmets kod. Som standard lagrar guiden Entitetsdatamodell niska veze i programkonfigurationsfilen. Du måste skydda den här filen för att förhindra obehörig åtkomst.

  • Använd niska veze byggare när du skapar anslutningar dynamiskt.

    Om du måste skapa niska veze vid körning använder du EntityConnectionStringBuilder klassen . Den här strängbyggarklassen hjälper till att förhindra niska veze inmatningsattacker genom att validera och undvika ogiltig indatainformation. Använd också lämplig strängbyggareklass för att konstruera datakällan niska veze som ingår i Entity Framework-niska veze. Information om niska veze byggare för ADO.NET providers finns i Anslutningssträngsbyggare.

Mer information finns i Skydda anslutningsinformation.

Exponera inte en EntityConnection för ej betrodda användare

Ett EntityConnection objekt exponerar den underliggande anslutningens niska veze. En användare med åtkomst till ett EntityConnection objekt kan också ändra den ConnectionState underliggande anslutningen. Klassen EntityConnection är inte trådsäker.

Skicka inte anslutningar utanför säkerhetskontexten

När en anslutning har upprättats får du inte skicka den utanför säkerhetskontexten. En tråd med behörighet att öppna en anslutning bör till exempel inte lagra anslutningen på en global plats. Om anslutningen är tillgänglig på en global plats kan en annan skadlig tråd använda den öppna anslutningen utan att uttryckligen bevilja den behörigheten.

Tänk på att inloggningsinformation och lösenord kan vara synliga i en minnesdump

När datakällans inloggnings- och lösenordsinformation anges i niska veze bevaras den här informationen i minnet tills skräpinsamlingen återtar resurserna. Detta gör det omöjligt att avgöra när en lösenordssträng inte längre finns i minnet. Om ett program kraschar kan en minnesdumpfil innehålla känslig säkerhetsinformation, och användaren som kör programmet och alla användare med administrativ åtkomst till datorn kan visa minnesdumpfilen. Använd Windows-autentisering för anslutningar till Microsoft SQL Server.

Bevilja endast användare de behörigheter som krävs i datakällan

En datakällaadministratör bör endast bevilja de behörigheter som krävs till användarna. Även om Entity SQL inte stöder DML-instruktioner som ändrar data, till exempel INSERT, UPDATE eller DELETE, kan användarna fortfarande komma åt anslutningen till datakällan. En obehörig användare kan använda den här anslutningen för att köra DML-instruktioner på datakällans inbyggda språk.

Köra program med minsta möjliga behörighet

När du tillåter att ett hanterat program körs med fullständig förtroendebehörighet begränsar .NET Framework inte programmets åtkomst till datorn. Detta kan göra det möjligt för en säkerhetsrisk i ditt program att kompromettera hela systemet. Om du vill använda kodåtkomstsäkerhet och andra säkerhetsmekanismer i .NET Framework bör du köra program med hjälp av behörigheter med partiellt förtroende och med den minsta uppsättning behörigheter som krävs för att programmet ska fungera. Följande behörigheter för kodåtkomst är de lägsta behörigheter som ditt Entity Framework-program behöver:

Mer information finns i Kodåtkomstsäkerhet och ADO.NET.

Installera inte program som inte är betrodda

Entity Framework tillämpar inga säkerhetsbehörigheter och anropar all dataobjektkod som tillhandahålls av användaren oavsett om den är betrodd eller inte. Se till att autentisering och auktorisering av klienten utförs av datalagret och av ditt program.

Begränsa åtkomsten till alla konfigurationsfiler

En administratör måste begränsa skrivåtkomsten till alla filer som anger konfiguration för ett program, inklusive till enterprisesec.config, security.config, machine.conf och programkonfigurationsfilprogrammet<>.exe.config.

Providerns invarianta namn kan ändras i app.config. Klientprogrammet måste ta ansvar för att få åtkomst till den underliggande providern via standardproviderns fabriksmodell med hjälp av ett starkt namn.

Begränsa behörigheter till modellen och mappningsfiler

En administratör måste begränsa skrivåtkomsten till modellen och mappningsfilerna (.edmx, .csdl, .ssdl och .msl) till endast användare som ändrar modellen eller mappningarna. Entity Framework kräver endast läsbehörighet till dessa filer vid körning. En administratör bör också begränsa åtkomsten till objektskikt och förkompilerade vy källkodsfiler som genereras av entitetsdatamodellverktygen.

Säkerhetsöverväganden för frågor

Följande säkerhetsöverväganden gäller när du kör frågor mot en konceptuell modell. Dessa överväganden gäller för entitets-SQL-frågor med EntityClient och för objektfrågor med linq-, entitets-SQL- och frågebyggaremetoder.

Förhindra SQL-inmatningsattacker

Program tar ofta externa indata (från en användare eller en annan extern agent) och utför åtgärder baserat på dessa indata. Alla indata som direkt eller indirekt härleds från användaren eller en extern agent kan ha innehåll som använder syntaxen för målspråket för att utföra obehöriga åtgärder. När målspråket är ett SQL (Structured Query Language), till exempel Transact-SQL, kallas den här manipulationen för en SQL-inmatningsattack. En obehörig användare kan mata in kommandon direkt i frågan och släppa en databastabell, orsaka överbelastning eller på annat sätt ändra typen av åtgärd som utförs.

  • Sql-inmatningsattacker för entitet:

    SQL-inmatningsattacker kan utföras i Entitets-SQL genom att ange skadliga indata till värden som används i en frågepredikat och i parameternamn. För att undvika risken för SQL-inmatning bör du aldrig kombinera användarindata med entitets-SQL-kommandotext.

    Entitets-SQL-frågor accepterar parametrar överallt där literaler accepteras. Du bör använda parametriserade frågor i stället för att mata in literaler från en extern agent direkt i frågan. Du bör också överväga att använda frågeverktygets metoder för att på ett säkert sätt konstruera entitets-SQL.

  • LINQ-till-entitetsinmatningsattacker:

    Även om frågesammansättning är möjlig i LINQ till entiteter utförs den via objektmodell-API:et. Till skillnad från SQL-frågor för entiteter består LINQ till entitetsfrågor inte av strängmanipulering eller sammanfogning, och de är inte mottagliga för traditionella SQL-inmatningsattacker.

Förhindra mycket stora resultatuppsättningar

En mycket stor resultatuppsättning kan leda till att klientsystemet stängs av om klienten utför åtgärder som förbrukar resurser som är proportionella mot resultatuppsättningens storlek. Oväntat stora resultatuppsättningar kan inträffa under följande förhållanden:

  • I frågor mot en stor databas som inte innehåller lämpliga filtervillkor.
  • I frågor som skapar kartesiska kopplingar på servern.
  • I kapslade SQL-frågor för entitet.

När du accepterar användarindata måste du se till att indata inte kan leda till att resultatuppsättningarna blir större än vad systemet kan hantera. Du kan också använda Take metoden i LINQ till entiteter eller LIMIT-operatorn i Entity SQL för att begränsa storleken på resultatuppsättningen.

Undvik att returnera IQueryable-resultat när du exponerar metoder för potentiellt ej betrodda uppringare

Undvik att IQueryable<T> returnera typer från metoder som exponeras för potentiellt ej betrodda anropare av följande skäl:

  • En användare av en fråga som exponerar en IQueryable<T> typ kan anropa metoder för resultatet som exponerar säkra data eller ökar storleken på resultatuppsättningen. Tänk till exempel på följande metodsignatur:

    public IQueryable<Customer> GetCustomer(int customerId)

    En användare av den här frågan kan anropa .Include("Orders") den returnerade IQueryable<Customer> för att hämta data som frågan inte har för avsikt att exponera. Detta kan undvikas genom att ändra returtypen för metoden till IEnumerable<T> och anropa en metod (till exempel ) som .ToList()materialiserar resultatet.

  • Eftersom IQueryable<T> frågor körs när resultatet itereras över kan en konsument av en fråga som exponerar en IQueryable<T> typ fånga undantag som genereras. Undantag kan innehålla information som inte är avsedd för konsumenten.

Säkerhetsöverväganden för entiteter

Följande säkerhetsöverväganden gäller när du genererar och arbetar med entitetstyper.

Dela inte en ObjectContext mellan programdomäner

Om du delar en ObjectContext med fler än en programdomän kan information visas i niska veze. I stället bör du överföra serialiserade objekt eller objektdiagram till den andra programdomänen och sedan koppla objekten till en ObjectContext i den programdomänen. Mer information finns i Serialisera objekt.

Förhindra säkerhetsöverträdelser av typen

Om typsäkerheten överträds kan Entity Framework inte garantera dataintegriteten i objekt. Typsäkerhetsöverträdelser kan inträffa om du tillåter att program som inte är betrodda körs med kodåtkomstsäkerhet med fullständigt förtroende.

Hantera undantag

Åtkomstmetoder och egenskaper för en ObjectContext i ett try-catch-block. Att fånga undantag förhindrar ohanterade undantag från att exponera poster i eller modellinformationen ObjectStateManager (till exempel tabellnamn) för användare av ditt program.

Säkerhetsöverväganden för ASP.NET program

Du bör tänka på följande när du arbetar med sökvägar i ASP.NET program.

Kontrollera om värden utför sökvägskontroller

När ersättningssträngen |DataDirectory| (omgiven av pipe-symboler) används verifierar ADO.NET att den lösta sökvägen stöds. Till exempel är ".." inte tillåtet bakom DataDirectory. Samma kontroll för att matcha rotoperatorn för webbprogram (~) utförs av processen som är värd för ASP.NET. IIS utför den här kontrollen. Andra värdar än IIS kanske dock inte verifierar att den lösta sökvägen stöds. Du bör känna till beteendet för värden som du distribuerar ett Entity Framework-program på.

Gör inte antaganden om lösta sökvägsnamn

Även om värdena som rotoperatorn (~) och ersättningssträngen DataDirectory matchar ska förbli konstanta under programmets körning, begränsar Entity Framework inte värden från att ändra dessa värden.

Kontrollera sökvägslängden före distributionen

Innan du distribuerar ett Entity Framework-program bör du se till att värdena för rotoperatorn (~) och DataDirectory ersättningssträngen inte överskrider gränserna för sökvägslängden i operativsystemet. ADO.NET dataprovidrar ser inte till att sökvägens längd ligger inom giltiga gränser.

Säkerhetsöverväganden för ADO.NET metadata

Följande säkerhetsöverväganden gäller när du genererar och arbetar med modell- och mappningsfiler.

Exponera inte känslig information via loggning

ADO.NET metadatatjänstkomponenter loggar ingen privat information. Om det finns resultat som inte kan returneras på grund av åtkomstbegränsningar bör databashanteringssystem och filsystem returnera noll resultat i stället för att skapa ett undantag som kan innehålla känslig information.

Acceptera inte MetadataWorkspace-objekt från ej betrodda källor

Program bör inte acceptera instanser av MetadataWorkspace klassen från ej betrodda källor. I stället bör du uttryckligen skapa och fylla i en arbetsyta från en sådan källa.

Se även