Sicherheitsüberlegungen (Entity Framework)

  • Artikel

In diesem Thema werden spezielle Sicherheitsaspekte hinsichtlich der Entwicklung, der Bereitstellung und der Ausführung von Entity Framework-Anwendungen beschrieben. Neben diesen Hinweisen sollten Sie auch die Empfehlungen zum Erstellen sicherer .Net Framework-Anwendungen befolgen. Weitere Informationen finden Sie unter Sicherheitsübersicht.

Allgemeine Überlegungen zur Sicherheit

Die folgenden Sicherheitsaspekte gelten für alle Anwendungen, die das Entity Framework verwenden.

Verwenden Sie nur vertrauenswürdige Datenquellenanbieter.

Um mit der Datenquelle zu kommunizieren, muss ein Anbieter wie folgt vorgehen:

  • Rufen Sie die Verbindungszeichenfolge aus dem Entity Framework ab.

  • Übersetzen der Befehlsstruktur in die native Abfragesprache der Datenquelle

  • Zusammenstellen und Zurückgeben von Resultsets

Während des Anmeldevorgangs werden Informationen auf der Grundlage des Benutzerkennworts über die Netzwerkbibliotheken der zugrunde liegenden Datenquelle an den Server übertragen. Ein böswilliger Anbieter kann Benutzeranmeldeinformationen stehlen, böswillige Abfragen generieren oder das Resultset manipulieren.

Verschlüsseln Sie die Verbindung, um vertrauliche Daten zu schützen.

Das Entity Framework verarbeitet die Datenverschlüsselung nicht direkt. Wenn Benutzer über ein öffentliches Netzwerk auf Daten zugreifen, sollte die Anwendung eine verschlüsselte Verbindung mit der Datenquelle herstellen, um die Sicherheit zu erhöhen. Weitere Informationen finden Sie in der die Sicherheit betreffenden Dokumentation für die Datenquelle. Hinsichtlich einer SQL Server-Datenquelle finden Sie Informationen unter Verschlüsseln von Verbindungen mit SQL Server.

Sichern Sie die Verbindungszeichenfolge ab.

Eines der wichtigsten Ziele beim Sichern einer Anwendung besteht darin, den Zugriff auf die Datenquelle zu schützen. Eine Verbindungszeichenfolge stellt ein potenzielles Sicherheitsrisiko dar, wenn sie nicht gesichert wird oder nicht ordnungsgemäß aufgebaut ist. Das Speichern von Verbindungsinformationen als Klartext oder das Aufbewahren dieser Informationen im Arbeitsspeicher gefährdet das gesamte System. Folgende Methoden werden zum Sichern von Verbindungszeichenfolgen empfohlen:

  • Verwenden Sie die Windows-Authentifizierung bei einer SQL Server-Datenquelle.

    Wenn Sie die Windows-Authentifizierung verwenden, um eine Verbindung mit einer SQL Server-Datenquelle herzustellen, enthält die Verbindungszeichenfolge keine Anmelde- und Kennwortinformationen.

  • Verschlüsseln Sie Konfigurationsdateiabschnitte mithilfe der geschützten Konfiguration.

    ASP.NET bietet ein als geschützte Konfiguration bezeichnetes Feature, mit dem Sie sicherheitsrelevante Informationen in einer Konfigurationsdatei verschlüsseln können. Die geschützte Konfiguration wurde zwar primär für ASP.NET entwickelt, sie kann jedoch auch zum Verschlüsseln von Konfigurationsdateiabschnitten in Windows-Anwendungen verwendet werden. Eine ausführliche Beschreibung der neuen Funktionen der geschützten Konfiguration finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

  • Speichern Sie Verbindungszeichenfolgen in gesicherten Konfigurationsdateien.

    Sie sollten Verbindungszeichenfolgen niemals in den Quellcode aufnehmen. Sie können die Verbindungszeichenfolgen in Konfigurationsdateien speichern. Damit erübrigt sich die Notwendigkeit, sie in den Code der Anwendung einzubetten. Standardmäßig speichert der Assistent für Entity Data Model Verbindungszeichenfolgen in der Anwendungskonfigurationsdatei. Sie müssen diese Datei sichern, um den nicht autorisierten Zugriff zu verhindern.

  • Verwenden Sie Verbindungszeichenfolgen-Generatoren, wenn Sie Verbindungen dynamisch erstellen.

    Wenn Sie Verbindungszeichenfolgen zur Laufzeit erstellen müssen, verwenden Sie die EntityConnectionStringBuilder-Klasse. Diese Zeichenfolgen-Generator-Klasse hilft durch Überprüfen und Versehen von ungültigen Eingabeinformationen mit Escapezeichen, Angriffe durch Einschleusen von Verbindungszeichenfolgen zu verhindern. Weitere Informationen finden Sie unter Gewusst wie: Erstellen einer EntityConnection-Verbindungszeichenfolge. Verwenden Sie die entsprechende Zeichenfolgengenerator-Klasse auch zum Erstellen der Datenquellen-Verbindungszeichenfolge, die Teil der Entity Framework-Verbindungszeichenfolge ist. Informationen zu Verbindungszeichenfolgen-Generatoren für ADO.NET-Anbieter finden Sie unter Verbindungszeichenfolgen-Generatoren.

Weitere Informationen finden Sie unter Protecting Connection Information (Schützen von Verbindungsinformationen).

Machen Sie keine EntityConnection für nicht vertrauenswürdige Benutzer verfügbar.

Ein EntityConnection-Objekt macht die Verbindungszeichenfolge der zugrunde liegenden Verbindung verfügbar. Ein Benutzer mit Zugriff auf ein EntityConnection-Objekt kann auch den ConnectionState der zugrunde liegenden Verbindung ändern. Die EntityConnection-Klasse ist nicht threadsicher.

Übergeben Sie Verbindungen nicht außerhalb des Sicherheitskontexts.

Nachdem eine Verbindung hergestellt wurde, dürfen Sie diese nicht außerhalb des Sicherheitskontexts übergeben. Ein Thread, der über die Berechtigung zum Öffnen einer Verbindung verfügt, sollte die Verbindung nicht an einem globalen Speicherort speichern. Wenn die Verbindung an einem globalen Speicherort zur Verfügung steht, kann ein bösartiger Thread die offene Verbindung verwenden, ohne dass diesem die Berechtigung dazu explizit gewährt wurde.

Beachten Sie, dass Anmeldeinformationen und Kennwörter möglicherweise in einem Speicherabbild sichtbar sind.

Wenn Anmelde- und Kennwortinformationen für die Datenquelle in der Verbindungszeichenfolge übergeben werden, bleiben diese Informationen im Arbeitsspeicher erhalten, bis die Garbage Collection die Ressourcen wieder freigibt. Dies macht es unmöglich, festzustellen, wann sich eine Kennwortzeichenfolge nicht mehr im Arbeitsspeicher befindet. Wenn eine Anwendung abstürzt, kann eine Speicherabbilddatei vertrauliche Informationen enthalten, die der Benutzer der Anwendung und jeder Benutzer mit Administratorzugriffsrechten für den Computer anzeigen kann. Verwenden Sie die Windows-Authentifizierung für Verbindungen mit Microsoft SQL Server.

Gewähren Sie Benutzern nur die notwendigen Berechtigungen für die Datenquelle.

Ein Datenquellenadministrator sollte Benutzern nur die notwendigen Berechtigungen gewähren. Auch wenn Entity SQL keine DML-Anweisungen zum Ändern von Daten unterstützt (wie beispielsweise INSERT, UPDATE oder DELETE), können Benutzer*innen dennoch auf die Verbindung mit der Datenquelle zugreifen. Ein böswilliger Benutzer könnte diese Verbindung verwenden, um DML-Anweisungen in der systemeigenen Sprache der Datenquelle auszuführen.

Führen Sie Anwendungen mit den minimalen Berechtigungen aus.

Wenn Sie zulassen, dass eine verwaltete Anwendung mit allen verfügbaren Berechtigungen ausgeführt wird, schränkt das .NET Framework den Zugriff der Anwendung auf Ihren Computer nicht ein. Dies kann zu einer Sicherheitslücke in der Anwendung führen, durch die das gesamte System gefährdet werden kann. Um Codezugriffssicherheit und andere Sicherheitsmechanismen im .NET Framework verwenden zu können, sollten Sie Anwendungen mit Berechtigungen für teilweise Vertrauenswürdigkeit und mit den für die ordnungsgemäße Funktion der Anwendung minimal erforderlichen Berechtigungen ausführen. Die folgenden Codezugriffsberechtigungen sind die minimalen Berechtigungen, die Ihre Entity Framework-Anwendung benötigt:

Weitere Informationen finden Sie unter Code Access Security and ADO.NET.

Installieren Sie keine nicht vertrauenswürdigen Anwendungen.

Das Entity Framework erzwingt keinerlei Sicherheitsberechtigungen und ruft jeden von Benutzer*innen übergebenen Datenobjektcode während der Verarbeitung auf, unabhängig davon, ob dieser vertrauenswürdig ist oder nicht. Stellen Sie sicher, dass die Authentifizierung und die Autorisierung des Clients durch den Datenspeicher und Ihre Anwendung erfolgen.

Schränken Sie den Zugriff auf alle Konfigurationsdateien ein.

Administrator*innen müssen den Schreibzugriff auf alle Dateien, in denen Konfigurationsinformationen für eine Anwendung enthalten sind, einschränken. Dazu zählen die Dateien „enterprisesec.config“, „security.config“, „machine.conf“ und die Anwendungskonfigurationsdatei „<anwendung>.exe.config“.

Der Invariantenname des Anbieters kann in der Datei „app.config“ geändert werden. Die Clientanwendung ist für den Zugriff auf den zugrunde liegenden Anbieter über das Anbieterfactory-Standardmodell unter Verwendung eines starken Namens zuständig.

Schränken Sie die Zugriffsberechtigungen auf die Modell- und Zuordnungsdateien ein.

Ein Administrator muss den Schreibzugriff auf die Modell- und Zuordnungsdateien (EDMX-, CSDL-, SSDL- und MSL-Dateien) auf die Benutzer beschränken, die das Modell oder die Zuordnungen ändern. Das Entity Framework benötigt zur Laufzeit nur Lesezugriff auf diese Dateien. Administrator*innen sollten außerdem den Zugriff auf Quellcodedateien der Objektebene und vorkompilierter Sichten einschränken, die durch die Entity Data Model-Tools generiert werden.

Sicherheitsaspekte bei Abfragen

Folgende Sicherheitsaspekte sollten beim Abfragen eines konzeptionellen Modells beachtet werden. Diese Überlegungen gelten für Entity SQL-Abfragen, die EntityClient verwenden, und für Objektabfragen mithilfe von LINQ-, Entity SQL- und Abfrage-Generator-Methoden.

Verhindern Sie Angriffe durch Einschleusung von SQL-Befehlen.

Anwendungen verwenden häufig externe Eingaben (eines Benutzers oder eines anderen externen Agenten) und führen entsprechend dieser Eingaben Aktionen aus. Jede direkt oder indirekt vom Benutzer oder einem externen Agenten stammende Eingabe kann über Inhalt verfügen, der die Syntax der Zielsprache nutzt, um nicht autorisierte Aktionen auszuführen. Wenn es sich bei der Zielsprache um eine strukturierte Abfragesprache (Structured Query Language, SQL) wie beispielsweise Transact-SQL handelt, wird diese Manipulation als Angriff durch Einschleusung von SQL-Befehlen (SQL Injection) bezeichnet. Ein böswilliger Benutzer kann Befehle direkt in Abfragen einschleusen und eine Datenbanktabelle löschen, einen Denial-of-Service-Angriff verursachen oder auf andere Art und Weise die auszuführende Operation ändern.

  • Angriffe durch Einschleusung von SQL-Befehlen in Entity SQL:

    Angriffe durch Einschleusung von SQL-Befehlen können in Entity SQL ausgeführt werden, indem schädliche Eingaben für Werte vorgenommen werden, die in einem Abfrageprädikat und in Parameternamen verwendet werden. Um das Risiko von Angriffen durch Einschleusung von SQL-Befehlen zu vermeiden, sollten Sie niemals Benutzereingaben mit Entity SQL-Befehlstext kombinieren.

    Entity SQL-Abfragen akzeptieren Parameter an allen Stellen, an denen Literale akzeptiert werden. Sie sollten parametrisierte Abfragen verwenden, anstatt Literale von einem externen Agenten direkt in die Abfrage einzufügen. Erwägen Sie auch den Einsatz von Abfrage-Generator-Methoden zur sicheren Erstellung von Entity SQL.

  • Angriffe durch Einschleusung von SQL-Befehlen in LINQ to Entities:

    Die Abfrageerstellung in LINQ to Entities ist zwar möglich, erfolgt aber über die Objektmodell-API. Im Gegensatz zu Entity SQL-Abfragen werden LINQ to Entities-Abfragen nicht durch Zeichenfolgenbearbeitung oder -verkettung erstellt und sind nicht anfällig gegenüber herkömmlichen Angriffen durch Einschleusung von SQL-Befehlen.

Verhindern Sie sehr umfangreiche Resultsets.

Ein sehr umfangreiches Resultset kann dazu führen, dass das Clientsystem heruntergefahren wird, wenn der Client Vorgänge ausführt, die Ressourcen proportional zum Umfang des Resultsets ausführt. Unerwartet große Resultsets können unter den folgenden Bedingungen auftreten:

  • In Abfragen an eine große Datenbank, die keine entsprechenden Filterbedingungen enthalten.

  • In Abfragen, die kartesische Verknüpfungen auf dem Server erstellen.

  • Geschachtelte Entity SQL-Abfragen.

Wenn Sie Benutzereingaben akzeptieren, müssen Sie sicherstellen, dass die Eingaben keine Resultsets verursachen können, die umfangreicher sind als die Datenmengen, die das System verarbeiten kann. Sie können auch die Take-Methode in LINQ to Entities oder den LIMIT-Operator in Entity SQL verwenden, um die Größe des Resultsets zu begrenzen.

Vermeiden Sie es, IQueryable-Ergebnisse zurückzugeben, wenn Sie Methoden für potenziell nicht vertrauenswürdige Aufrufer verfügbar machen.

Vermeiden Sie es aus den folgenden Gründen, IQueryable<T>-Typen von Methoden zurückzugeben, die für potenziell nicht vertrauenswürdige Aufrufer verfügbar gemacht wurden:

  • Der Consumer einer Abfrage, die einen IQueryable<T>-Typ verfügbar macht, könnte mit dem Ergebnis Methoden aufrufen, die sichere Daten verfügbar machen oder die Größe des Resultsets erhöhen. Betrachten Sie beispielsweise die folgende Methodensignatur:

    public IQueryable<Customer> GetCustomer(int customerId)

    Ein Consumer dieser Abfrage könnte .Include("Orders") für den zurückgegebenen IQueryable<Customer> aufrufen, um Daten abrufen, die durch die Abfrage nicht verfügbar gemacht werden sollten. Dies kann vermieden werden, indem der Rückgabetyp der Methode in IEnumerable<T> geändert und eine Methode aufgerufen wird (beispielsweise .ToList()), die die Ergebnisse materialisiert.

  • Da IQueryable<T>-Abfragen ausgeführt werden, während die Ergebnisse durchlaufen werden, könnte der Consumer einer Abfrage, die einen IQueryable<T>-Typ verfügbar macht, eventuell ausgelöste Ausnahmen abfangen. Ausnahmen könnten Informationen enthalten, die nicht für den Consumer bestimmt sind.

Sicherheitsaspekte bei Entitäten

Die folgenden Sicherheitsaspekte gelten, wenn Sie Entitätstypen generieren und mit Entitätstypen arbeiten.

Geben Sie einen ObjectContext nicht über Anwendungsdomänen hinweg frei.

Einen ObjectContext für mehr als eine Anwendungsdomäne freizugeben macht möglicherweise Informationen in der Verbindungszeichenfolge verfügbar. Stattdessen sollten Sie serialisierte Objekte oder Objektdiagramme an die andere Anwendungsdomäne übertragen und dann diese Objekte einem ObjectContext in der Anwendungsdomäne anfügen. Weitere Informationen finden Sie unter Serialisieren von Objekten.

Verhindern Sie Verletzungen der Typsicherheit.

Wenn die Typsicherheit verletzt wird, kann das Entity Framework die Integrität der Daten in Objekten nicht garantieren. Verletzungen der Typsicherheit könnten auftreten, wenn Sie zulassen, dass nicht vertrauenswürdige Anwendungen mit voll vertrauenswürdiger Codezugriffssicherheit ausgeführt werden.

Behandeln Sie Ausnahmen.

Greifen Sie auf die Methoden und Eigenschaften von ObjectContext innerhalb eines try-catch-Blocks zu. Das Abfangen von Ausnahmen verhindert, dass nicht behandelte Ausnahmen Benutzern der Anwendung Einträge im ObjectStateManager oder Modellinformationen (beispielsweise Tabellennamen), verfügbar machen.

Sicherheitsaspekte für ASP.NET-Anwendungen

Wenn Sie mit Pfaden in ASP.NET-Anwendungen arbeiten, sollten Sie Folgendes beachten.

Überprüfen Sie, ob der Host Pfadprüfungen ausführt.

Wenn die Ersatzzeichenfolge |DataDirectory| (eingeschlossen in senkrechte Striche) verwendet wird, überprüft ADO.NET, ob der aufgelöste Pfad unterstützt wird. Beispielsweise ist ".." hinter DataDirectory nicht zulässig. Dieselbe Überprüfung für die Auflösung des Stammoperators der Webanwendung (~) wird durch den Prozess ausgeführt, der ASP.NET hostet. IIS führt diese Überprüfung aus. Andere Hosts als IIS können möglicherweise nicht überprüfen, ob der aufgelöste Pfad unterstützt wird. Sie sollten das Verhalten des Hosts kennen, auf dem Sie eine Entity Framework-Anwendung bereitstellen.

Gehen Sie nicht von Annahmen über aufgelöste Pfadnamen aus.

Obwohl die Werte, in die der Stammoperator (~) und die DataDirectory-Ersatzzeichenfolge aufgelöst werden, während der Laufzeit der Anwendung konstant bleiben sollten, wird der Host durch das Entity Framework nicht daran gehindert, diese Werte zu ändern.

Überprüfen Sie die Pfadlänge vor der Bereitstellung.

Stellen Sie vor der Bereitstellung einer Entity Framework-Anwendung sicher, dass die Werte des Stammoperators (~) und der DataDirectory-Ersatzzeichenfolge nicht den Grenzwert des Betriebssystems für die Pfadlänge überschreiten. ADO.NET-Datenanbieter gewährleisten nicht, dass die Pfadlänge innerhalb der Grenzwerte liegt.

Sicherheitsaspekte für ADO.NET-Metadaten

Wenn Sie Modell- und Zuordnungsdateien erzeugen und mit ihnen arbeiten, berücksichtigen Sie Folgendes hinsichtlich der Sicherheit:

Machen Sie vertrauliche Informationen nicht durch Protokollierung verfügbar.

ADO.NET-Metadaten-Dienstkomponenten protokollieren keine privaten Informationen. Wenn Ergebnisse aufgrund von Zugriffsbeschränkungen nicht zurückgegeben werden können, sollten Datenbankmanagementsysteme und Dateisysteme Ergebnisse mit dem Wert Null zurückgeben, statt eine Ausnahme auszulösen, die vertrauliche Informationen enthalten könnte.

Akzeptieren Sie keine "MetadataWorkspace"-Objekte von nicht vertrauenswürdigen Quellen.

Anwendungen sollten keine Instanzen der MetadataWorkspace-Klasse von nicht vertrauenswürdigen Quellen akzeptieren. Stattdessen sollten Sie einen Arbeitsbereich explizit erstellen und aus so einer Quelle füllen.

Siehe auch