Sicherheitsaspekte (Entity Framework)

In diesem Thema werden spezielle Sicherheitsaspekte hinsichtlich der Entwicklung, der Bereitstellung und der Ausführung von Entity Framework -Anwendungen beschrieben. Außerdem sollten Sie den Empfehlungen zum Erstellen sicherer .NET Framework-Anwendungen folgen. Weitere Informationen finden Sie unter Security Overview (ADO.NET).

Allgemeine Sicherheitsaspekte

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

Verwenden Sie nur vertrauenswürdige Datenquellenanbieter.

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

• Empfangen der Verbindungszeichenfolge von Entity Framework

• Übersetzen der Befehlsstruktur in die systemeigene 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.

Entity Framework behandelt 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 in Verschlüsseln von Verbindungen zu 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 Funktionen dieses neuen Features finden Sie unter Encrypting Configuration Information Using Protected Configuration.

• 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 (Entity Framework). Verwenden Sie die entsprechende Zeichenfolgengenerator-Klasse auch, um die Datenquellen-Verbindungszeichenfolge zu erstellen, die Teil der Entity Framework -Verbindungszeichenfolge ist. Informationen zu Verbindungszeichenfolgen-Generatoren für ADO.NET-Anbieter finden Sie unter Connection String Builders (ADO.NET).

Weitere Informationen finden Sie unter Protecting Connection Information (ADO.NET).

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 DML-Anweisungen zum Ändern von Daten, wie beispielsweise INSERT, UPDATE oder DELETE, nicht unterstützt, können Benutzer dennoch auf die Verbindung zur 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 Anwendung mit allen verfügbaren Berechtigungen ausgeführt wird, schränkt .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 in .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 eine Entity Framework -Anwendung benötigt:

• FileIOPermission: Write, um die angegebenen Metadatendateien zu öffnen, oder PathDiscovery, um in einem Verzeichnis nach Metadatendateien zu suchen.

• ReflectionPermission: RestrictedMemberAccess, um "LINQ to Entities"-Abfragen zu unterstützen.

• DistributedTransactionPermission: Unrestricted, um einen Eintrag in einer System.TransactionsTransaction vorzunehmen.

• SecurityPermission: SerializationFormatter, um Ausnahmen mithilfe der ISerializable-Schnittstelle zu serialisieren.

• Berechtigungen zum Öffnen einer Datenbankverbindung und zum Ausführen von Befehlen für die Datenbank, wie beispielsweise SqlClientPermission für eine SQL Server-Datenbank.

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

Installieren Sie keine nicht vertrauenswürdigen Anwendungen.

Entity Framework erzwingt keinerlei Sicherheitsberechtigungen und ruft jeden vom Benutzer ü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.

Ein Administrator muss den Schreibzugriff auf alle Dateien, in denen Konfigurationsinformationen für eine Anwendung enthalten sind, einschließlich der Dateien enterprisesec.config, security.config, machine.conf und der Anwendungskonfigurationsdatei <Anwendung>.exe.config, einschränken.

Der invariante Name des Anbieters kann in 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 (CSDL-, SSDL- und MSL-Dateien) auf die Benutzer beschränken, die das Modell oder die Zuordnungen ändern. Entity Framework benötigt zur Laufzeit nur Lesezugriff auf diese Dateien. Ein Administrator sollte außerdem den Zugriff auf Quellcodedateien der Objektebene und vorkompilierter Sichten, die durch die Entity Data Model -Tools erzeugt werden, einschränken.

Sicherheitsaspekte bei Abfragen

Folgende Sicherheitsaspekte sollten beim Abfragen eines konzeptionellen Modells beachtet werden. Diese Aspekte 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 Entity SQL -Befehlen:

  Angriffe durch Einschleusung von SQL-Befehlen können in Entity SQL ausgeführt werden, indem böswillige Eingaben für Werte vorgenommen werden, die in Abfrageprädikaten und 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, Abfrage-Generator-Methoden zur sicheren Erstellung von Entity SQL zu verwenden.

• Angriffe durch Einschleusen von LINQ to Entities :

  Obwohl das Zusammensetzen von Abfragen in LINQ to Entities möglich ist, wird dieser Vorgang über die Objektmodell-API ausgeführt. 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.

• In geschachtelten 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-Typen von Methoden zurückzugeben, die für potenziell nicht vertrauenswürdige Aufrufer verfügbar gemacht wurden:

• Der Consumer einer Abfrage, die einen IQueryable-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 geändert und eine Methode aufgerufen wird (beispielsweise .ToList()), die die Ergebnisse materialisiert.

• Da IQueryable-Abfragen ausgeführt werden, während die Ergebnisse durchlaufen werden, könnte der Consumer einer Abfrage, die einen IQueryable-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 (Entity Framework).

Verhindern Sie Verletzungen der Typsicherheit.

Wenn die Typsicherheit verletzt wird, kann 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 von 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

Folgendes sollte berücksichtigt werden, wenn Sie mit Pfaden in ASP.NET-Anwendungen arbeiten.

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

Wenn die Ersatzzeichenfolge |DataDirectory| (eingeschlossen in Pipe-Symbole) verwendet wird, überprüft ADO.NET, ob der aufgelöste Pfad unterstützt wird. Beispielsweise ist ".." hinter DataDirectory nicht zulässig. Dieselbe Überprüfung wird für die Auflösung des Stamm-Operators der Webanwendung (~) 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 Stamm-Operator (~) und die DataDirectory-Ersatzzeichenfolge aufgelöst werden, während der Laufzeit der Anwendung konstant bleiben sollten, wird der Host durch 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 die Pfadlängengrenze des Betriebssystems überschreiten. ADO.NET-Datenanbieter gewährleisten nicht die gültige Pfadlänge.

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

Konzepte

Überlegungen zur Bereitstellung (Entity Framework)
Migrationsaspekte (Entity Framework)

Weitere Ressourcen

ADO.NET Application Security