Sdílet prostřednictvím

Důležité informace o zabezpečení (Entity Framework)

  • Článek

Tento článek popisuje aspekty zabezpečení specifické pro vývoj, nasazení a spouštění aplikací Entity Framework. Měli byste také postupovat podle doporučení pro vytváření zabezpečených aplikací rozhraní .NET Framework. Další informace najdete v tématu Přehled zabezpečení.

Obecné aspekty zabezpečení

Následující aspekty zabezpečení platí pro všechny aplikace, které používají Entity Framework.

Použití pouze důvěryhodných poskytovatelů zdrojů dat

Pokud chcete komunikovat se zdrojem dat, musí poskytovatel udělat toto:

  • Obdrží připojovací řetězec z Entity Frameworku.
  • Přeložte strom příkazů do nativního dotazovacího jazyka zdroje dat.
  • Sestavení a vrácení sad výsledků

Během přihlašovací operace se informace založené na uživatelském heslu předávají serveru prostřednictvím síťových knihoven podkladového zdroje dat. Poskytovatel se zlými úmysly může ukrást přihlašovací údaje uživatele, generovat škodlivé dotazy nebo manipulovat se sadou výsledků.

Šifrování připojení za účelem ochrany citlivých dat

Entity Framework nezpracuje přímo šifrování dat. Pokud uživatelé přistupují k datům přes veřejnou síť, měla by vaše aplikace vytvořit šifrované připojení ke zdroji dat, aby se zvýšilo zabezpečení. Další informace najdete v dokumentaci související se zabezpečením pro váš zdroj dat.

Zabezpečení připojovací řetězec

Ochrana přístupu ke zdroji dat je jedním z nejdůležitějších cílů při zabezpečení aplikace. Připojovací řetězec představuje potenciální ohrožení zabezpečení, pokud není zabezpečené nebo je nesprávně sestavené. Když ukládáte informace o připojení ve formátu prostého textu nebo je uchováváte v paměti, riskujete ohrožení celého systému. Následující doporučené metody zabezpečení připojovací řetězec:

  • Při připojování k Azure SQL používejte spravované identity pro prostředky Azure.

    Další informace najdete v tématu Spravované identity pro prostředky Azure.

  • Použijte ověřování systému Windows s místním zdrojem dat SQL Serveru.

    Pokud se k připojení ke zdroji dat SQL Serveru používáte ověřování systému Windows, připojovací řetězec neobsahuje informace o přihlášení a hesle.

  • Zašifrujte oddíly konfiguračního souboru pomocí chráněné konfigurace.

    ASP.NET poskytuje funkci označovanou jako chráněná konfigurace, která umožňuje šifrovat citlivé informace v konfiguračním souboru. I když je primárně určená pro ASP.NET, můžete také použít chráněnou konfiguraci k šifrování oddílů konfiguračních souborů v aplikacích pro Windows.

  • Ukládat připojovací řetězec v zabezpečených konfiguračních souborech.

    Do zdrojového kódu byste nikdy neměli vkládat připojovací řetězec. Do konfiguračních souborů můžete ukládat připojovací řetězec, což eliminuje nutnost jejich vložení do kódu aplikace. Průvodce datovým modelem entity ve výchozím nastavení ukládá připojovací řetězec v konfiguračním souboru aplikace. Chcete-li zabránit neoprávněnému přístupu, musíte tento soubor zabezpečit.

  • Při dynamickém vytváření připojení používejte tvůrce připojovací řetězec.

    Pokud je nutné vytvořit připojovací řetězec za běhu, použijte EntityConnectionStringBuilder třídu. Tato třída tvůrce řetězců pomáhá zabránit útokům prostřednictvím injektáže připojovací řetězec ověřováním a únikem neplatných vstupních informací. Použijte také odpovídající třídu tvůrce řetězců k vytvoření zdroje dat připojovací řetězec, který je součástí entity Framework připojovací řetězec. Informace o tvůrcích připojovací řetězec pro poskytovatele ADO.NET naleznete v tématu Tvůrce připojovacích řetězců.

Další informace naleznete v tématu Ochrana informací o připojení.

Nezpřístupňujte entityConnection nedůvěryhodným uživatelům.

Objekt EntityConnection zveřejňuje připojovací řetězec podkladového připojení. Uživatel s přístupem k objektu EntityConnection může také změnit ConnectionState základní připojení. Třída EntityConnection není bezpečná pro přístup z více vláken.

Nepředávejte připojení mimo kontext zabezpečení

Po navázání připojení ho nesmíte předat mimo kontext zabezpečení. Například jedno vlákno s oprávněním k otevření připojení by nemělo ukládat připojení do globálního umístění. Pokud je připojení dostupné v globálním umístění, může otevřené připojení používat jiné škodlivé vlákno bez toho, aby mu toto oprávnění bylo explicitně uděleno.

Mějte na paměti, že přihlašovací informace a hesla můžou být viditelné v výpisu paměti.

Pokud jsou informace o přihlášení ke zdroji dat a heslo zadané v připojovací řetězec, budou tyto informace zachovány v paměti, dokud uvolňování paměti nevymačká prostředky. To znemožňuje určit, kdy už řetězec hesla není v paměti. Pokud dojde k chybovému ukončení aplikace, může soubor výpisu paměti obsahovat citlivé informace o zabezpečení a uživatel, který aplikaci spouští, a jakýkoli uživatel s přístupem správce k počítači může zobrazit soubor s výpisem paměti. Pro připojení k Microsoft SQL Serveru použijte ověřování systému Windows.

Udělte uživatelům pouze potřebná oprávnění ve zdroji dat.

Správce zdroje dat by měl uživatelům udělit pouze potřebná oprávnění. I když Entity SQL nepodporuje příkazy DML, které upravují data, jako jsou INSERT, UPDATE nebo DELETE, mohou uživatelé stále přistupovat k připojení ke zdroji dat. Uživatel se zlými úmysly může toto připojení použít ke spouštění příkazů DML v nativním jazyce zdroje dat.

Spouštění aplikací s minimálními oprávněními

Pokud povolíte, aby spravovaná aplikace běžela s úplným oprávněním důvěryhodnosti, rozhraní .NET Framework neomezuje přístup aplikace k vašemu počítači. To může ve vaší aplikaci umožnit ohrožení zabezpečení, které by mohlo ohrozit celý systém. Pokud chcete používat zabezpečení přístupu kódu a další mechanismy zabezpečení v rozhraní .NET Framework, měli byste spouštět aplikace pomocí částečných oprávnění důvěryhodnosti a s minimální sadou oprávnění, která jsou potřebná k povolení fungování aplikace. Následující přístupová oprávnění ke kódu jsou minimální oprávnění, která vaše aplikace Entity Framework potřebuje:

Další informace najdete v tématu Zabezpečení přístupu kódu a ADO.NET.

Neinstalovat nedůvěryhodné aplikace

Entity Framework nevynucuje žádná oprávnění zabezpečení a vyvolá veškerý kód objektu dat zadaný uživatelem v procesu bez ohledu na to, jestli je důvěryhodný nebo ne. Ujistěte se, že úložiště dat a aplikace provádí ověřování a autorizaci klienta.

Omezení přístupu ke všem konfiguračním souborům

Správce musí omezit přístup k zápisu do všech souborů, které určují konfiguraci aplikace, včetně souborů enterprisesec.config, security.config, machine.conf a aplikace> konfiguračního souboru <aplikace.exe.config.

Invariantní název zprostředkovatele je možné upravit v souboru app.config. Klientská aplikace musí převzít odpovědnost za přístup k podkladovému poskytovateli prostřednictvím standardního modelu továrny zprostředkovatele pomocí silného názvu.

Omezení oprávnění k modelu a souborům mapování

Správce musí omezit přístup k zápisu do souborů modelu a mapování (.edmx, .csdl, .ssdl a .msl) jenom na uživatele, kteří model nebo mapování upravují. Entity Framework vyžaduje přístup jen pro čtení k těmto souborům za běhu. Správce by měl také omezit přístup k vrstvě objektů a předem zkompilovaným souborům zdrojového kódu, které jsou generovány nástroji Entity Data Model.

Důležité informace o zabezpečení pro dotazy

Při dotazování konceptuálního modelu platí následující aspekty zabezpečení. Tyto aspekty platí pro dotazy Entity SQL využívající EntityClient a dotazy na objekty pomocí metod LINQ, Entity SQL a tvůrce dotazů.

Prevence útoků prostřednictvím injektáže SQL

Aplikace často provádějí externí vstup (od uživatele nebo jiného externího agenta) a provádějí akce na základě daného vstupu. Jakýkoli vstup, který je přímo nebo nepřímo odvozen od uživatele nebo externího agenta, může mít obsah, který používá syntaxi cílového jazyka k provádění neoprávněných akcí. Pokud je cílovým jazykem jazyk SQL (Structured Query Language) (SQL), například Transact-SQL, tato manipulace se označuje jako útok prostřednictvím injektáže SQL. Uživatel se zlými úmysly může vkládat příkazy přímo do dotazu a vyhodit tabulku databáze, způsobit odepření služby nebo jinak změnit povahu prováděné operace.

  • Útoky prostřednictvím injektáže entity SQL:

    Útoky prostřednictvím injektáže SQL je možné provádět v Entity SQL tak, že do hodnot používaných v predikáte dotazu a v názvech parametrů zadáte škodlivý vstup. Abyste se vyhnuli riziku injektáže SQL, neměli byste nikdy kombinovat uživatelský vstup s textem příkazu Entity SQL.

    Dotazy Entity SQL přijímají parametry všude, kde jsou literály přijímány. Místo vkládání literálů z externího agenta přímo do dotazu byste měli použít parametrizované dotazy. Měli byste také zvážit použití metod tvůrce dotazů k bezpečnému vytvoření Entity SQL.

  • Útoky prostřednictvím injektáže LINQ to Entities:

    I když je v LINQ to Entities možné složení dotazů, provádí se prostřednictvím rozhraní API objektového modelu. Na rozdíl od dotazů Entity SQL se dotazy LINQ to Entities nevykládají pomocí manipulace s řetězci nebo zřetězení a nejsou náchylné k tradičním útokům prostřednictvím injektáže SQL.

Zabránit velmi velkým sadám výsledků

Velmi velká sada výsledků může způsobit vypnutí klientského systému, pokud klient provádí operace, které spotřebovávají prostředky úměrné velikosti sady výsledků. Neočekávaně velké sady výsledků mohou nastat za následujících podmínek:

  • V dotazech na velkou databázi, která neobsahuje odpovídající podmínky filtru.
  • V dotazech, které vytvářejí kartézské spojení na serveru.
  • Vnořených dotazech Entity SQL.

Při přijetí uživatelského vstupu je nutné zajistit, aby vstup nemohl způsobit, že sady výsledků budou větší než to, co systém dokáže zpracovat. K omezení velikosti sady výsledků můžete také použít metodu Take v LINQ to Entities nebo operátor LIMIT v Entity SQL.

Vyhněte se vrácení výsledků IQueryable při vystavení metod potenciálně nedůvěryhodným volajícím

Vyhněte se vracení IQueryable<T> typů z metod, které jsou vystaveny potenciálně nedůvěryhodným volajícím z následujících důvodů:

  • Příjemce dotazu, který zveřejňuje IQueryable<T> typ, by mohl volat metody ve výsledku, které zpřístupňují zabezpečená data nebo zvětšují velikost sady výsledků. Představte si například následující podpis metody:

    public IQueryable<Customer> GetCustomer(int customerId)

    Příjemce tohoto dotazu by mohl volat .Include("Orders") vrácená IQueryable<Customer> data, aby načetl data, která dotaz neměl v úmyslu zveřejnit. Tomu se můžete vyhnout změnou návratového typu metody na IEnumerable<T> metodu (například .ToList()), která materializuje výsledky.

  • Vzhledem k tomu IQueryable<T> , že se dotazy provádějí při iterated výsledků, může příjemce dotazu, který zveřejňuje IQueryable<T> typ, zachytit výjimky, které jsou vyvolány. Výjimky můžou obsahovat informace, které nejsou určené pro příjemce.

Důležité informace o zabezpečení pro entity

Při generování a práci s typy entit platí následující aspekty zabezpečení.

Nesdílejte objekt ObjectContext mezi doménami aplikací

Sdílení s více než jednou doménou ObjectContext aplikace může zveřejnit informace v připojovací řetězec. Místo toho byste měli přenést serializované objekty nebo grafy objektů do druhé domény aplikace a pak tyto objekty připojit k ObjectContext dané doméně aplikace. Další informace naleznete v tématu Serializace objektů.

Prevence porušení bezpečnosti typů

Pokud je porušena bezpečnost typů, Entity Framework nemůže zaručit integritu dat v objektech. K narušení bezpečnosti typů může dojít v případě, že povolíte spuštění nedůvěryhodných aplikací s úplným zabezpečením přístupu ke kódu důvěryhodnosti.

Zpracování výjimek

Přístup k metodám a vlastnostem ObjectContext v rámci bloku try-catch Zachytávání výjimek brání neošetřeným výjimkám v informacích ObjectStateManager o modelu nebo modelu (například názvů tabulek) uživatelům vaší aplikace.

Důležité informace o zabezpečení pro aplikace ASP.NET

Při práci s cestami v aplikacích ASP.NET byste měli zvážit následující skutečnosti.

Ověření, jestli hostitel provádí kontroly cest

|DataDirectory| Pokud se použije náhradní řetězec (uzavřený v symbolech kanálu), ADO.NET ověří, že je podporovaná přeložená cesta. Například "." není povolen za DataDirectory. Stejná kontrola překladu kořenového operátoru webové aplikace (~) provádí proces hostující ASP.NET. Služba IIS provádí tuto kontrolu; Hostitelé kromě služby IIS však nemusí ověřit, zda je přeložená cesta podporována. Měli byste znát chování hostitele, na kterém nasazujete aplikaci Entity Framework.

Nevytvárejte předpoklady o vyřešených názvech cest

I když hodnoty, na které by kořenový operátor (~) a DataDirectory řetězec nahrazení měly zůstat konstantní během modulu runtime aplikace, Entity Framework neomezí hostitele na úpravu těchto hodnot.

Ověření délky cesty před nasazením

Před nasazením aplikace Entity Framework byste měli zajistit, aby hodnoty kořenového operátoru (~) a DataDirectory náhradního řetězce nepřekračovaly limity délky cesty v operačním systému. ADO.NET poskytovatelé dat nezajistí, aby délka cesty byla v mezích platných limitů.

Důležité informace o zabezpečení pro metadata ADO.NET

Při generování a práci se soubory modelu a mapování platí následující aspekty zabezpečení.

Nezpřístupňujte citlivé informace prostřednictvím protokolování

ADO.NET součásti služby metadat nezaobíjely žádné soukromé informace. Pokud jsou výsledky, které nelze vrátit z důvodu omezení přístupu, systémy pro správu databází a systémy souborů by měly místo vyvolání výjimky, která by mohla obsahovat citlivé informace, vrátit nulové výsledky.

Nepřijímají objekty MetadataWorkspace z nedůvěryhodných zdrojů

Aplikace by neměly přijímat instance třídy z nedůvěryhodných MetadataWorkspace zdrojů. Místo toho byste měli explicitně vytvořit a naplnit pracovní prostor z takového zdroje.

Viz také