Absichern der ASP.NET-Konfiguration

Artikel
10/22/2014

Aktualisiert: November 2007

Mit der von ASP.NET bereitgestellten Funktionalität lassen sich ein kompletter Server, eine ASP.NET-Anwendung und einzelne Seiten in den Unterverzeichnissen einer Anwendung konfigurieren. Zu den konfigurierbaren Features gehören Authentifizierungsmodi, Seitenzwischenspeicherung, Compileroptionen, benutzerdefinierte Fehler, Debug- und Ablaufverfolgungsoptionen usw. In diesem Thema wird beschrieben, wie beim Konfigurieren lokaler oder Remote-ASP.NET-Anwendungen die Sicherheit der Konfigurationsfeatures durch bewährte Vorgehensweisen optimiert werden kann. Weitere Informationen über das Absichern anderer Features von ASP.NET finden Sie in den im Abschnitt Siehe auch aufgeführten Themen.

Die Sicherheit der Anwendung kann zum einen durch die empfohlenen Vorgehensweisen für Konfiguration und Codeerstellung erhöht werden. Zum anderen ist wichtig, dass Sie den Anwendungsserver auf dem aktuellen Stand halten und immer die neuesten Sicherheitsupdates für Microsoft Windows und Microsoft Internetinformationsdienste (IIS) installieren. Dies gilt ebenso für Updates von Microsoft SQL Server und andere Mitgliedschaftsdatenquellen.

Ausführliche Informationen über empfohlene Vorgehensweisen zum Schreiben von sicherem Code und zum Absichern von Anwendungen finden Sie in dem Buch "Writing Secure Code" von Michael Howard und David LeBlanc sowie in den Anweisungen unter Microsoft Patterns and Practices.

Wichtiger Hinweis:
Das ASP.NET-Konfigurationssystem konfiguriert nur ASP.NET-Ressourcen und -Features. Verwenden Sie die Konfigurationsfeatures von IIS, um ASP.NET-fremde Ressourcen zu konfigurieren. Weitere Informationen über das Konfigurieren von IIS finden Sie unter Working with the Metabase (IIS 6.0) und IIS Metabase Property Reference.

Sicherheit von Konfigurationsdateien

In der folgenden Tabelle sind die Zugriffssteuerungslisten (Access Control Lists, ACLs) aufgeführt, die standardmäßig in der Datei Machine.config und der Stammdatei Web.config festgelegt werden. Beide Dateien befinden sich im Verzeichnis %SystemRoot%\Microsoft.NET\Framework\Version\CONFIG. Diese ACLs werden auch im Verzeichnis selbst festgelegt, enthalten jedoch für die Gruppe Hauptbenutzer Berechtigungen zum Ändern. Das Verzeichnis ist schreibgeschützt.

Windows-Konto	Berechtigungen
Administratoren	Vollzugriff
ASP.NET-Computerkonto (<server>\ASPNET)	Lesen und Ausführen
IIS_WPG (<server>\IIS_WPG)	Lesen und Ausführen
LOKALER DIENST	Lesen und Ausführen
NETZWERKDIENST	Lesen und Ausführen
Hauptbenutzer (<server>\Power Users)	Ändern
SYSTEM	Vollzugriff
Benutzer (<server>\Users)	Lesen und Ausführen

In der folgenden Tabelle sind die ACLs aufgelistet, die Sie für die Dateien Web.config sowie für die in configSource-Attributen aufgeführten Dateien festlegen sollten.

Windows-Konto	Berechtigungen
Administratoren	Vollzugriff
IIS_WPG (<server>\IIS_WPG)	Lesen und Ausführen
INTERAKTIV	Lesezugriff
Internetgastkonto (<server>\IUSR_<server>)	Lesezugriff
NETZWERK	Lesezugriff
NETZWERKDIENST	Lesezugriff
SYSTEM	Vollzugriff
Benutzer (<server>\Users)	Lesen und Ausführen
ASP.NET-Websiteverwaltungs-Tool-Konto	Speziell

Das ASP.NET-Konfigurationssystem berücksichtigt die für Konfigurationsdateien festgelegten ACLs unabhängig davon, auf welche Weise die Konfigurationseinstellungen bearbeitet werden. Weitere Informationen finden Sie unter Bearbeiten von ASP.NET-Konfigurationsdateien.

Absichern von Konfigurationswerten

Wenn vertrauliche Informationen in der Konfigurationsdatei einer Anwendung gespeichert werden, müssen Sie die vertraulichen Werte mithilfe der geschützten Konfiguration verschlüsseln. Zu den besonders vertraulichen Informationen gehören die Verschlüsselungsschlüssel, die im machineKey-Konfigurationselement gespeichert sind, und die Verbindungszeichenfolgen für eine Datenquelle, die im connectionStrings-Konfigurationselement gespeichert sind. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

Schützen von Schlüsselcontainern für die Konfigurationsverschlüsselung

Ein wesentlicher Aspekt bei der Verwendung eines Verschlüsselungsschlüssels ist der Schutz der Datei, in der der Schlüssel gespeichert wird. (Diese Datei wird auch als Container bezeichnet.) Sie müssen immer die Schutzebene beachten, die dem Container zugeordnet ist. Beachten Sie, dass der Container als reguläre Datei des Betriebssystems gespeichert wird und der Zugriff auf den Verschlüsselungsschlüssel durch die ACLs für die Datei gesteuert wird. Die ACLs können von dem Ordner geerbt werden, in dem die Datei erstellt wurde. Schlüsselcontainer mit dem lokalen Computer als Gültigkeitsbereich (useMachineContainer"true") werden unter %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys in einem verborgenen Ordner gespeichert.

Standardmäßig verfügt der Benutzer, der den Schlüsselcontainer erstellt hat, über uneingeschränkten Zugriff auf den Schlüssel. Der Zugriff anderer Benutzer (einschließlich der Gruppe Administratoren) auf den Container hängt von den ACLs ab, die für den Container festgelegt sind. Anderen Benutzern kann mithilfe des –pa-Schalters des ASP.NET IIS-Registrierungstools (ASP.NET IIS-Registrierungstool (Aspnet_regiis.exe)) Zugriff auf den Container gewährt werden. Für die Verschlüsselung oder Entschlüsselung mit dem angegebenen Schlüssel müssen Benutzer über die erforderlichen Zugriffsberechtigungen für den Schlüsselcontainer verfügen.

In einigen Fällen kann ein Benutzer ohne Administratorrechte dennoch einen Verschlüsselungsschlüssel erstellen. Dies ist möglich, wenn eine Anwendung eine Konfigurationsverschlüsselung anfordert und kein Schlüssel vorhanden ist. Wenn kein Container vorhanden ist, wird ein Container erstellt und eine Verschlüsselung ausgeführt.

In diesem Fall erstellt .NET Framework den erforderlichen Schlüssel und den zugehörigen Container mit den ACLs des aktuellen Benutzers. Ein mögliches Problem besteht darin, dass einem Benutzer mit Administratorrechten der Zugriff auf den Container des Verschlüsselungsschlüssels verweigert werden kann. Administratoren können wieder auf den Schlüssel zugreifen, indem sie den Besitz der physikalischen Datei für den oben erwähnten Ordner übernehmen. Die vorgeschlagenen Richtlinien erfordern einen Benutzer mit Administratorrechten, um die erforderlichen Schlüssel zu erstellen, bevor sie verwendet werden, sodass sie nicht zum Zeitpunkt der Verschlüsselung erstellt werden müssen.

Absichern der Konfiguration in Umgebungen mit gemeinsamen Hostservern

In Umgebungen mit gemeinsamen Hostservern können böswillige Benutzer Konfigurationseinstellungen potenziell ändern, indem sie die Konfigurationsdateien direkt, über die Konfigurations-APIs oder über sonstige Verwaltungs- und Konfigurationstools bearbeiten. Sie können Änderungen an Ihrer Anwendungskonfiguration verhindern, indem Sie Konfigurationsabschnitte sperren. Fügen Sie dazu der Datei Machine.config oder einer beliebigen Konfigurationsdatei, die in der Hierarchie höher steht als die zu beschränkende Konfigurationsdatei, location-Elemente hinzu. Das location-Element wird verwendet, um für untergeordnete Konfigurationsdateien Änderungen an den Einstellungen zu verhindern. Weitere Informationen finden Sie unter Gewusst wie: Sperren von ASP.NET-Konfigurationseinstellungen und unter Gewusst wie: Konfigurieren von bestimmten Verzeichnissen mit Standorteinstellungen.

Remotekonfiguration

Die Remotekonfiguration ist standardmäßig deaktiviert. Bei aktivierter Remotekonfiguration wird der Benutzer auf DCOM-Ebene authentifiziert, und nur lokale Administratoren erhalten Lese- und Schreibzugriff auf Konfigurationsdaten. Weitere Informationen hierzu finden Sie unter Bearbeiten von ASP.NET-Remotekonfigurationsdateien.

Benutzerdefinierte Konfigurationsanbieter

Unabhängig vom Sicherheitstoken des aktuellen Benutzers wird der benutzerdefinierte Abschnittshandlercode unter Verwendung der Anmeldeinformationen des Hostprozesskontos ausgeführt. Bei Webszenarios ist dies unter Windows 2000 und Windows XP das <Server>\ASPNET-Konto, unter Windows Server 2003 das NETZWERKDIENST-Konto oder ein explizit konfiguriertes Benutzerkonto. Bei Clientszenarios ist dies die Identität des Prozesses, der gerade ausgeführt wird.

Bevor ein benutzerdefinierter Konfigurationsabschnittshandler aufgerufen wird und der Aufruf für .NET Framework keinerlei Vertrauenswürdigkeit besitzt, legt das Konfigurationssystem Berechtigungen fest. Der Aufruf wird mit dem Berechtigungssatz der Anwendung ausgeführt. Das ASP.NET-Konfigurationssystem behandelt das Verzeichnis %SystemRoot%\Microsoft.NET\Framework\Version\CONFIG als vertrauenswürdig, nicht jedoch Verzeichnisse, die sich weiter unten in der Hierarchie befinden.

Ein benutzerdefinierter Konfigurationsabschnittshandler muss Forderungsattribute für die Codezugriffssicherheit (CAS, Code Access Security) festlegen, um Berechtigungen zu erhalten. Weitere Informationen finden Sie unter ASP.NET-Codezugriffssicherheit oder Grundlagen der Codezugriffssicherheit.

Aktivieren einer Dateisperre für eine Konfigurationsdatei

Konfigurationsdateien können nur gesperrt werden, wenn mehrere Versuche unternommen wurden, sie zu speichern oder ein Dateihandle zu öffnen. Bösartige Benutzer können versuchen, die Datei Machine.config oder die Stammdatei Web.config zu sperren. Hierzu ist jedoch die volle Vertrauenswürdigkeit erforderlich, die in ASP.NET standardmäßig deaktiviert ist.

Lesen beliebiger Dateien mithilfe der Konfigurations-API

Die Klassen der Konfigurations-API können nur Verzeichnisse lesen, die Teil der Anwendungsdomäne sind, und nur Dateien, die über die Dateinamenerweiterung .config verfügen.

IIS-Metabasiseinstellungen gelten für ASP.NET-Anforderungen

Wenn IIS eine Anforderung für eine ASP.NET-Anwendung erhält, gelten die IIS-Metabasiseinstellungen für die ASP.NET-Anwendung, unabhängig von den ASP.NET-Konfigurationseinstellungen für die Anwendung. Diese Einschränkung kann dazu führen, dass ASP.NET-Anwendungen keinen Zugriff durch die Benutzer zulassen oder über weniger restriktive Sicherheitseinstellungen verfügen.

Wenn z. B. die Sicherheitseinstellungen in der IIS-Metabasis so festgelegt sind, dass Seitenzugriff nur authentifizierten Benutzern gewährt wird, die Sicherheitseinstellungen der Datei Web.config jedoch anonymen Zugriff zulassen, wird anonymen Benutzern der Zugriff auf die Site verweigert. Um dieses Problem zu beheben, konfigurieren Sie die Webanwendung im IIS-Manager so, dass anonyme Benutzer zugelassen werden.

Informationen über das Absichern von IIS-Features finden Sie unter Security in IIS 6.0.

Fehlermeldungen und Ereignisse

In den folgenden Abschnitten wird erläutert, wie Sie potenzielle Sicherheitsrisiken minimieren, die durch unerwartete Fehlermeldungen und Ereignisse entstehen können.

Ausnahmen

So verhindern Sie, dass vertrauliche Informationen unerwünschten Quellen verfügbar gemacht werden: Konfigurieren Sie die Anwendung so, dass entweder keine ausführlichen Fehlermeldungen angezeigt werden oder nur dann ausführliche Fehlermeldungen angezeigt werden, wenn der Webserver der Client ist. Weitere Informationen hierzu finden Sie unter customErrors-Element (ASP.NET-Einstellungsschema).

Ereignisprotokoll

Wenn der Server Windows Server 2003 ausführt, können Sie die Sicherheit der Anwendung verbessern, indem Sie das Ereignisprotokoll absichern. Außerdem verhindert die Festlegung von Parametern im Ereignisprotokoll bzgl. Größe, Beibehaltung und weiterer Features, dass ein indirekter Denial-of-Service-Angriff ausgeführt werden kann. Weitere Informationen zur Konfiguration von Ereignisprotokollen erhalten Sie, indem Sie in Windows-Hilfe und Support nach "Ereignisanzeige" suchen.

Systemüberwachung

Erfolgreiche und fehlgeschlagene Anmeldeversuche werden mit dem ASP.NET-Systemüberwachungsfeature protokolliert. In der Standardkonfigurationseinstellung werden demnach bei fehlgeschlagenen Anmeldeversuchen der Benutzername und andere Diagnoseinformationen im Anwendung-Ereignisprotokoll aufgezeichnet. Stellen Sie sicher, dass der Zugriff auf das Ereignisprotokoll eingeschränkt ist, damit diese Informationen vertraulich bleiben.