Sichern des Datenzugriffs

Artikel
10/22/2014

Aktualisiert: November 2007

Der Zugriff auf Daten ist Bestandteil der meisten ASP.NET-Webanwendungen. Viele Anwendungen sammeln Daten, die gespeichert werden sollen, in einer Datenbank oder einer Datei. Die zu speichernden Daten basieren oft auf Informationen von Benutzern. Sie sollten aus folgenden Gründen besonderes Augenmerk auf die Sicherheitsbelange rund um den Datenzugriff richten: Die ursprünglichen Daten können aus nicht vertrauenswürdigen Quellen stammen, die Informationen werden in einem dauerhaften Format gespeichert und um sicherzugehen, dass nur autorisierte Benutzer direkten Zugang zu Ihrer Datenquelle haben. Die Informationen in diesem Thema beschreiben optimale Vorgehensweisen, mit denen Sie die Sicherheit beim Datenzugriff in Ihrer ASP.NET-Webanwendung verbessern können.

Die Sicherheit der Anwendung kann zum einen durch solche optimalen Vorgehensweisen bei Codierung und Konfiguration verbessert werden. Zum anderen ist ebenfalls wichtig, dass Sie den Webserver auf dem aktuellsten Stand halten und immer die neuesten Sicherheitsupdates für Microsoft Windows und Internetinformationsdienste (IIS) installieren. Das gilt ebenso für Sicherheitsupdates für Microsoft SQL Server und andere Datenquellensoftware.

Ausführlichere Informationen über bewährte Vorgehensweisen für das Schreiben von sicherem Code und zur Sicherung von Anwendungen finden Sie in dem Buch "Writing Secure Code" von Michael Howard und David LeBlanc. Auch die Website Microsoft Patterns and Practices stellt auf diesem Gebiet eine verlässliche Informationsquelle dar.

Sichern des Zugriffs auf eine Datenquelle

Die folgenden Abschnitte enthalten Informationen zur Absicherung verschiedener Aspekte des Datenzugriffs.

Verbindungszeichenfolgen

Für die Verbindung mit einer Datenbank ist eine Verbindungszeichenfolge erforderlich. Da Verbindungszeichenfolgen vertrauliche Daten enthalten können, sollten folgende Richtlinien beachtet werden:

Speichern Sie Verbindungszeichenfolgen nicht in einer Seite. Vermeiden Sie beispielsweise, Verbindungszeichenfolgen als deklarative Eigenschaften des SqlDataSource-Steuerelements oder anderer Datenquellensteuerelemente festzulegen. Speichern Sie stattdessen Verbindungszeichenfolgen in der Datei Web.config der Site. Ein Beispiel finden Sie unter Gewusst wie: Sichern von Verbindungszeichenfolgen bei der Verwendung von Datenquellensteuerelementen.
Speichern Sie Verbindungszeichenfolgen nicht als Nur-Text. Damit die Verbindung zum Datenbankserver sicher bleibt, sollten die Verbindungszeichenfolgeninformationen in der Konfiguration mithilfe von geschützter Konfiguration verschlüsselt werden. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

Herstellen von Verbindungen zu SQL Server mithilfe der integrierten Sicherheit

Stellen Sie Verbindungen zu einer Instanz von SQL Server möglichst mithilfe der integrierten Sicherheit her. Vermeiden Sie die explizite Verwendung eines Benutzernamens und Kennworts. Dadurch wird vermieden, dass die Verbindungszeichenfolge gefährdet wird und die Benutzer-ID sowie das Kennwort offen gelegt werden.

Sie sollten sicherstellen, dass die Identität des Prozesses, der ASP.NET ausführt (z. B. der Anwendungspool), das Standardprozesskonto oder ein eingeschränktes Benutzerkonto ist. Weitere Informationen finden Sie unter Identitätswechsel in ASP.NET.

In Szenarios, in denen mehrere Websites eine Verbindung mit verschiedenen SQL Server-Datenbanken herstellen, erweist sich der Einsatz der integrierten Sicherheit möglicherweise als unpraktisch. In Webhostingsites wird z. B. jedem Kunden für gewöhnlich eine eigene SQL Server-Datenbank zugewiesen, während alle Benutzer auf den Webserver anonym zugreifen. In solchen Fällen ist die Verwendung expliziter Anmeldeinformationen für die Verbindung zu einer Instanz von SQL Server erforderlich. Die Anmeldeinformationen müssen in sicherer Weise gespeichert werden. Eine Beschreibung dazu finden Sie unter Verbindungszeichenfolgen.

SQL Server-Datenbankberechtigungen

Der Benutzer-ID, die für die Verbindung zu den SQL Server-Datenbanken Ihrer Anwendung verwendet wird, sollten nur minimale Berechtigungen zugewiesen werden.

Beschränken von SQL-Operationen

Datengebundene Steuerelemente unterstützen eine Vielzahl von Datenoperationen: Auswählen, Einfügen, Löschen und Aktualisieren von Datenbanksätzen. Sie sollten die Datensteuerelemente so konfigurieren, dass ihre Funktionalität sich auf das für die Seite bzw. die Anwendung erforderliche Minimum beschränkt. Wenn beispielsweise ein Steuerelement Benutzern das Löschen von Daten nicht erlauben soll, sollte das Datenquellensteuerelement keine Löschabfrage enthalten, und Löschen sollte im Steuerelement nicht aktiviert sein.

SQL Server Express Edition

Für die Verbindung zu einer SQL Server Express Edition-Datenbank (MDF-Datei) benötigt ein Prozess Administratorrechte. Dadurch sind SQL Server Express Edition-Datenbanken für Produktionswebsites grundsätzlich unbrauchbar, da der ASP.NET-Prozess keine Administratorrechte hat (und auch nicht haben sollte). Verwenden Sie deshalb SQL Server Express Edition-Datenbanken nur unter folgenden Umständen:

Als Testdatenbank bei der Entwicklung Ihrer Webanwendung. Zum Bereitstellen Ihrer Anwendung kann die Datenbank von der SQL Server Express Edition auf eine Produktionsinstanz von SQL Server übertragen werden.
In einer Website, die mit Identitätswechsel arbeitet, und in der Sie die Berechtigungen des imitierten Benutzers kontrollieren können. In der Praxis empfiehlt sich diese Vorgehensweise nur für Anwendungen, die in einem lokalen Netzwerk laufen, nicht aber für öffentliche Websites.
Speichern Sie die MDF-Datei im Ordner App_Data der Site, da der Inhalt dieses Ordners nicht an direkte HTTP-Anforderungen zurückgegeben wird. Darüber hinaus sollten Sie ASP.NET in IIS und dem HttpForbiddenHandler in ASP.NET die Erweiterung .mdf zuordnen. Dies geschieht mithilfe des folgenden Elements in der Datei Web.config der Site:
```
<httpHandlers>
  <add verb="*" path="*.mdf" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Informationen zur Zuordnung einer Dateinamenerweiterung zu ASP.NET in IIS finden Sie unter Gewusst wie: Registrieren von HTTP-Handlern.

Microsoft Access-Datenbanken

Microsoft Access-Datenbanken (MDB-Dateien) verfügen über weniger Sicherheitsfeatures als SQL Server-Datenbanken. Access-Datenbanken werden nicht für Produktionswebsites empfohlen. Sollten Sie aus irgendwelchen Gründen trotzdem eine MDB-Datei als Teil Ihrer Webanwendung verwenden, befolgen Sie diese Richtlinien:

Speichern Sie die MDB-Datei im Ordner App_Data Ihrer Site, da der Inhalt dieses Ordners nicht an direkte HTTP-Anforderungen zurückgegeben wird. Darüber hinaus sollten Sie ASP.NET in IIS und dem HttpForbiddenHandler in ASP.NET die Erweiterung .mdb zuordnen. Dies geschieht mithilfe des folgenden Elements in der Datei Web.config der Site:
```
<httpHandlers>
  <add verb="*" path="*.mdb" type="System.Web.HttpForbiddenHandler" />
</httpHandlers>
```
Informationen zur Zuordnung einer Dateinamenerweiterung zu ASP.NET in IIS finden Sie unter Gewusst wie: Registrieren von HTTP-Handlern.
Geben Sie den Benutzerkonten, die Lese- und Schreibzugriff auf die MDB-Datei haben sollen, die entsprechenden Rechte. Falls die Website anonymen Zugriff unterstützt, handelt es sich dabei in der Regel um das lokale ASPNET-Benutzerkonto oder das NETWORK SERVICE-Konto. Da Access für das Sperren eine LDB-Datei erstellen muss, benötigt das Benutzerkonto Schreibberechtigungen für den Ordner, der die MDB-Datei enthält.
Verwenden Sie für das Verbinden mit einer kennwortgeschützten Datenbank nicht das AccessDataSource-Steuerelement, weil das AccessDataSource-Steuerelement die Weitergabe von Anmeldeinformationen nicht unterstützt. Verwenden Sie stattdessen das SqlDataSource-Steuerelement mit dem ODBC-Anbieter, und übergeben Sie die Anmeldeinformationen in der Verbindungszeichenfolge. Schützen Sie dabei die Verbindungszeichenfolge, wie es in diesem Thema unter Verbindungszeichenfolgen beschrieben ist.

XML-Dateien

Wenn Sie Daten in einer XML-Datei speichern, muss die XML-Datei im Ordner App_Data der Website abgelegt werden, da der Inhalt dieses Ordners nicht als Anwort auf direkte HTTP-Anforderungen zurückgegeben wird.

Schutz vor böswilligen Benutzereingaben

Falls Ihre Anwendung Benutzereingaben zulässt, sollten Sie sicherstellen, dass die Eingaben keinen schädlichen Inhalt enthalten, der Ihre Anwendung gefährdet. Folgende Angriffe können durch böswillige Benutzereingaben ausgelöst werden:

Script-Injection Ein Script-Injection-Angriff ist der Versuch, ein ausführbares Skript an Ihre Anwendung zu senden, mit der Absicht, es von anderen Benutzern ausführen zu lassen. Bei einem typischen Script-Injection-Angriff wird Skript an eine Seite gesendet, die dieses in einer Datenbank speichert. Die Daten werden dann von einem anderen Benutzer angezeigt, der unwissentlich den Code ausführt.
SQL-Injection Bei einem SQL-Injection-Angriff wird versucht, die Datenbank (und potenziell den Computer, auf dem sie ausgeführt wird) zu gefährden. Dazu werden SQL-Befehle erstellt, die anstelle von oder zusätzlich zu den Befehlen ausgeführt werden, die Sie in Ihre Anwendung integriert haben.

Allgemeine Richtlinien

Beachten Sie die folgenden Richtlinien bei allen Benutzereingaben:

Verwenden Sie, wann immer möglich, Validierungssteuerelemente zur Beschränkung von Benutzereingaben auf zulässige Werte.
Stellen Sie vor der Ausführung des Servercodes stets sicher, dass der Wert der IsValid-Eigenschaft true ist. Ist dieser Wert false, dann bedeutet dies, dass die Überprüfung durch mindestens ein Validierungssteuerelement fehlgeschlagen ist.
Führen Sie stets eine serverseitige Validierung aus. Dies sollte selbst dann geschehen, wenn der Browser eine clientseitige Validierung ausführt, um sich vor Benutzern zu schützen, die die clientseitige Validierung umgehen. Dies gilt besonders für CustomValidator-Steuerelemente. Verwenden Sie nicht nur clientseitige Validierungslogik.
Validieren Sie Benutzereingaben immer erneut in der Geschäftsebene Ihrer Anwendung. Verlassen Sie sich nicht darauf, dass der aufrufende Prozess sichere Daten bereitstellt. Fügen Sie z. B. bei der Verwendung des ObjectDataSource-Steuerelements redundante Validierungen und Codierungen in das Objekt ein, das die Datenaktualisierungen durchführt.

Script-Injection

Beachten Sie diese Richtlinien zur Vermeidung von Script-Injection-Angriffen:

Codieren Sie Benutzereingaben mit der HtmlEncode-Methode. Diese konvertiert HTML in seine Textdarstellung (aus <b> wird beispielsweise &ltb>) und verhindert die Ausführung des Markup im Browser.
Wenn Sie Parameterobjekte für die Übergabe von Benutzereingaben an eine Abfrage verwenden, fügen Sie Handler für die Vorabfrageereignisse des Datenquellensteuerelements hinzu, und führen Sie die Codierung in diesen Ereignissen durch. Behandeln Sie z. B. das Inserting-Ereignis des SqlDataSource-Steuerelements, und codieren Sie in dem Ereignis den Parameterwert vor der Ausführung der Abfrage.
Wenn Sie das GridView-Steuerelement mit gebundenen Feldern verwenden, legen Sie die HtmlEncode-Eigenschaft des BoundField-Objekts auf true fest. Dadurch werden Benutzereingaben vom GridView-Steuerelement codiert, wenn die Zeile im Bearbeitungsmodus ist.
Für Steuerelemente mit Bearbeitungsmodus sollten Sie Vorlagen verwenden. Die Steuerelemente GridView, DetailsView, FormView, DataList und Login können beispielsweise bearbeitbare Textfelder anzeigen. Mit Ausnahme des GridView-Steuerelements (siehe vorherigen Punkt) werden Benutzereingaben von diesen Steuerelementen jedoch nicht automatisch validiert oder als HTML codiert. Deshalb sollten Sie für diese Steuerelemente Vorlagen erstellen. Fügen Sie dann in die Vorlage ein Eingabesteuerelement ein (z. B. ein TextBox-Steuerelement), und fügen Sie ein Validierungssteuerelement hinzu. Außerdem sollten Sie den Wert des Steuerelements nach dem Extrahieren codieren.

SQL-Injection

Beachten Sie diese Richtlinien zur Vermeidung von SQL-Injection-Angriffen:

Erstellen Sie SQL-Befehle nicht durch Verkettung von Zeichenfolgen. Dies gilt besonders für Zeichenfolgen, die Eingaben von Benutzern enthalten. Verwenden Sie stattdessen parametrisierte Abfragen oder gespeicherte Prozeduren.
Beim Erstellen von parametrisierten Abfragen verwenden Sie Parameterobjekte, um die Werte für die Parameter festzulegen. Ausführliche Informationen zu diesem Thema finden Sie unter Verwenden von Parametern mit dem SqlDataSource-Steuerelement und Verwenden von Parametern für Datenquellen-Steuerelemente.

Verschlüsseln von Ansichtszustandsdaten

Datengebundene Steuerelemente wie das GridView-Steuerelement müssen gelegentlich Informationen speichern, die als vertraulich gelten. Das GridView-Steuerelement kann z. B. eine Schlüsselliste in der DataKeys-Eigenschaft speichern, selbst wenn diese Informationen nicht angezeigt werden. Zwischen Roundtrips speichert das Steuerelement die Informationen im Ansichtszustand.

Ansichtszustandsinformationen werden mit den Seiteninhalten codiert und gespeichert und können decodiert und unerwünschten Quellen verfügbar gemacht werden. Wenn Sie vertrauliche Informationen im Ansichtszustand speichern müssen, können Sie die Ansichtszustandsdaten von der Seite verschlüsseln lassen. Zur Verschlüsselung der Daten legen Sie die ViewStateEncryptionMode-Eigenschaft der Seite auf true fest.

Zwischenspeichern

Es empfiehlt sich, keine vertraulichen Informationen im Cache-Objekt zu speichern, wenn der Clientidentitätswechsel aktiviert ist und die Ergebnisse der Datenquelle auf Basis der Clientidentität abgerufen werden. Wenn die Zwischenspeicherung aktiviert ist, können die zwischengespeicherten Daten eines einzelnen Benutzers von allen Benutzern eingesehen werden. Es besteht die Gefahr, dass vertrauliche Informationen unerwünschten Quellen verfügbar gemacht werden. Der Clientidentitätswechsel ist aktiviert, wenn das impersonate-Attribut des identity-Konfigurationselements auf true festgelegt und die anonyme Identifikation auf dem Webserver für die Anwendung deaktiviert ist.

Freigeben über