Sichern des Datenzugriffs

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.

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.

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

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.

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:

  Kopieren

  <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 (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:

  Kopieren

  <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.

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.

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.

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&gt;) 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.

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.

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.

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.