Sicherheit von Webanwendungen zur Laufzeit

Artikel
10/22/2014

Aktualisiert: November 2007

Bei der Entwicklung einer Anwendung müssen Sie sich mit einer Reihe von Sicherheitsaspekten auseinandersetzen. Die andere Gruppe von Problemen – bei denen es sich bei der Diskussion um die Websicherheit im Allgemeinen um die wichtigeren Aspekte handelt – betreffen die Sicherheit der Anwendung bei ihrer Bereitstellung und Ausführung.

Webanwendungen ermöglichen Benutzern definitionsgemäß den Zugriff auf eine zentrale Ressource – den Webserver – und durch ihn auf andere Ressourcen, z. B. Datenbankserver. Bei Kenntnis und entsprechender Umsetzung der Sicherheitsmaßnahmen:

Schützen Sie eigene Ressourcen vor unberechtigtem Zugriff.
Schränken Sie die Zugriffsebenen nach Benutzer oder Rolle ein.
Gewährleisten Sie Datenintegrität und Vertraulichkeit, und stellen Sie eine relativ sichere Umgebung bereit, in der Benutzer sicher mit der Anwendung arbeiten können.
Legen Sie fest, auf welche Weise die Anwendung Zugriff auf beschränkte Ressourcen erhält.
Stellen Sie sicher, dass der Code der Anwendung wie beabsichtigt ausgeführt wird.

Dieses Thema enthält allgemeine Informationen, wie diese Ziele erreicht werden können, sowie Links zu weiteren Themen, in denen Sie zusätzliche Informationen über die beteiligten Technologien finden.

Sie können mithilfe der folgenden Sicherheitsfeatures dazu beitragen, die Anwendung vor unbefugtem Zugriff zu schützen:

Sicherheitsfeatures, die von Internetinformationsdiensten (IIS) als Teil der allgemeinen Webserverfunktion bereitgestellt werden. Dazu gehört Windows-Sicherheit auf Datei-, Computer- und Benutzerebene.
Sicherheit, die Sie in die ASP.NET-Anwendung einbinden können, um einen anwendungsspezifischen Zugriff bereitzustellen.

Sicherheitsprozess in ASP.NET

IIS stellt viele Sicherheitsoptionen für Websites bereit. Allerdings sind die IIS-Sicherheitsmechanismen insofern sehr allgemeiner Art, als sie für alle Anwendungen verwendet werden. Außerdem sind die IIS-Sicherheitsoptionen, z. B. die Verwendung der integrierten Windows-Sicherheit, für Ihre Anwendung wahrscheinlich nicht immer zweckmäßig. (Andererseits können Sie die integrierte Windows-Sicherheit der Einfachheit halber für Intranetanwendungen verwenden.)

Um Zugriff auf bestimmte Bereiche der Anwendung zu ermöglichen, können Sie daher die ASP.NET-Sicherheit verwenden. Die ASP.NET-Sicherheit funktioniert in Verbindung mit der IIS-Sicherheit und ergänzt sie, sodass Sie die Möglichkeit haben, Features anzupassen, beispielsweise auf welche Weise Anmeldeinformationen von Benutzern abgerufen werden.

IIS empfängt zunächst Anforderungen von Clients und führt Sicherheitstests durch, die mit IIS-Verwaltungstools für die Anwendung entwickelt wurden. Wenn die Anwendung z. B. in IIS für einen anonymen Zugriff konfiguriert ist, werden die Anmeldeinformationen von IIS nicht überprüft. Nach diesem ersten Authentifizierungstest sendet IIS die Anforderung an ASP.NET, das eine zweite Überprüfung durchführen kann. ASP.NET ermöglicht die Angabe von Zugriffsbeschränkungen in der Anwendung durch eine Reihe von Kriterien: Sie können den Zugriff auf bestimmte Seiten, bestimmte Benutzer usw. beschränken.

Authentifizierung

In der folgenden Tabelle sind die von ASP.NET unterstützten Authentifizierungsmethoden beschrieben. Einige davon überschneiden sich mit der IIS-Authentifizierung. Ausführliche Informationen finden Sie unter Authentifizierung in ASP.NET.

Authentifizierungstyp	Beschreibung
Anonymer Zugriff	Für Anwendungen, bei denen unbekannte Benutzer Anforderungen stellen (in der Regel öffentliche Webanwendungen). Überschneidung mit IIS.
Basis- und Digestauthentifizierung	(IIS-Sicherheitsoption) Bei diesem Szenario werden Benutzer ohne Anmeldeinformationen zur Angabe eines Benutzernamens und eines Kennworts aufgefordert.
Integrierte Windows-Sicherheit (auch als NTLM-Sicherheit bezeichnet)	(IIS-Sicherheitsoption) Wenn der Benutzer, der die Anforderung stellt, bereits in einem Windows-basierten Netzwerk authentifiziert wurde, kann IIS die Anmeldeinformationen des Benutzers weitergeben, wenn er Zugriff auf eine Ressource anfordert.
Zertifikatauthentifizierung	(IIS-Sicherheitsoption) Bei diesem Szenario besitzt entweder der Server oder der Client ein Zertifikat – eine digitale Identifizierung –, die von einer anderen Quelle stammt. Die dem Clientzertifikat zugeordnete Identität wird an ASP.NET weitergegeben.
Kerberos	(IIS-Sicherheitsoption) Das Kerberos-Authentifizierungsprotokoll definiert die Interaktionen zwischen einem Client und einem Netzauthentifizierungsdienst, der als Key Distribution Center (KDC) bezeichnet wird. Windows 2000 und 2003 implementieren auf jedem Domänencontroller einen KDC als Authentifizierungsdienst.
Windows-Authentifizierung	(ASP.NET-Sicherheitsoption) Ist in die vorher aufgelisteten IIS-Sicherheitsoptionen integriert. ASP.NET nimmt das von IIS erstellte Sicherheitstoken an und macht es als WindowsPrincipal-Objekt verfügbar, das als Wert der User-Eigenschaft des aktuellen HttpContext festgelegt wurde.
Formularauthentifizierung	(ASP.NET-Sicherheitsoption) Wenn ein Benutzer authentifiziert werden muss, leitet ASP.NET die Anforderung an eine von Ihnen angegebene Seite um. Diese Seite enthält in der Regel ein Formular, das Informationen über den Benutzernamen liefert. (Um zusätzliche Sicherheit zu gewährleisten, können Sie das Formular mithilfe des HTTPS-Protokolls austauschen.) Wenn die Anwendung die Formularinformationen empfängt, kann sie eine anwendungsspezifische Überprüfung der Benutzeranmeldeinformationen durchführen. Ein wichtiger Punkt ist der, dass Sie, anders als bei IIS, die Kontrolle über den Authentifizierungsprozess haben und Sie somit angeben können, wie das Formular aussieht und wie die Benutzerinformationen gespeichert werden sollen. Wenn ein Benutzer erfolgreich authentifiziert wurde, gibt ASP.NET ein verschlüsseltes Cookie mit einem Token aus, das den Benutzer bei nachfolgenden Zugriffen identifiziert.

Die Formularauthentifizierung ist für ASP.NET-Anwendungen im öffentlichen Internet die einfachste Wahl, weil Sie dadurch das Vorgehen bei der Benutzerauthentifizierung stark beeinflussen können und andererseits die Authentifizierung in einem Token auf dem Browser speichern können.

Ausführliche Informationen zur IIS-Sicherheit finden Sie in den Themen zur Zugriffssteuerung im Windows Server TechCenter for IIS auf der Microsoft TechNet-Website. Weitere Informationen zur ASP.NET-Authentifizierung finden Sie unter Authentifizierung in ASP.NET.

Ausführliche Informationen zum Verwenden der Formularauthentifizierung mit Protokollübergang und beschränkter Delegierung in einer Windows Server 2003-Domänenumgebung finden Sie in Kerberos Protocol Transition and Constrained Delegation.

Autorisierung

Wenn die Webanwendung ausgeführt wird, ruft sie Ressourcen vom Webserver und häufig auch von anderen Prozessen ab, wie beispielsweise einer Datenbank. Der ASP.NET-Prozess wird in einem Benutzerkontext ausgeführt, der bestimmt, wie die Anwendung diese Ressourcen abruft. Der ASP.NET-Prozess wird unter Windows 2000 und Windows XP Professional Edition als spezieller Benutzer mit dem Namen ASPNET (Standard) ausgeführt. Unter Windows 2003 wird er für die ASP.NET-Anwendung als Identität des Anwendungspools ausgeführt (standardmäßig das lokale NETZWERKDIENST-Konto). Diese Konten werden mit eingeschränkten Berechtigungen ausgeführt. Sie können für den ASP.NET-Prozess einen anderen Benutzerkontext angeben, beispielsweise das lokale SYSTEM-Konto (dadurch wird die Anwendung im Administratorkontext ausgeführt) oder den eines anderen Benutzers, dessen Anmeldeinformationen Sie explizit angeben, obwohl dies nicht empfehlenswert ist.

In der ASP.NET-Anwendung können Sie angeben, dass verschiedene Benutzer autorisierten Zugriff auf verschiedene Ressourcen haben. Wenn die Anwendung mit der Windows-Authentifizierung arbeitet, können Sie für den Zugriff auf bestimmte Dateien oder Ordner auf dem Server Windows-Berechtigungen festlegen.

Alternativ dazu können Sie die URL-basierte Autorisierung verwenden, bei der die Autorisierung nach verschiedenen Kriterien gewährt oder abgelehnt werden kann:

Bestimmte Benutzer, oder Identitäten, die auf den vom Benutzer bereitgestellten Anmeldeinformationen basieren.
Rollen, bei denen es sich um Entitäten handelt; diese Entitäten sind so definiert, dass mehrere Benutzer Privilegien auf der Basis einer allgemeinen Rolle oder Funktion gemeinsam nutzen können.
Verben, bei denen es sich um HTTP-Prozesse (z. B. GET und POST) für den Zugriff auf Anwendungsteile handelt.

Sie können z. B. angeben, dass alle Benutzer Seiten aus der Anwendung abrufen (das GET-Verb durchführen) können, aber nur bestimmte Benutzer Seiten in der Anwendung bereitstellen dürfen. Genauso könnten Sie angeben, dass alle Benutzer Seiten abrufen können, dass aber bestimmte Rollen keine Seiten bereitstellen dürfen.

Sie können URL-Autorisierung für die Anwendung als Ganzes oder auf Verzeichnisbasis erteilen. So könnten z. B. alle Benutzer zum Anzeigen von Seiten in einem öffentlichen Verzeichnis berechtigt sein, bestimmte Seiten aber in einem anderen Verzeichnis enthalten sein, für das nur bestimmte Benutzer autorisiert sind.

Hinweis:
Standardmäßig unterliegen statische Dateien wie Bilder und Stylesheets nicht der ASP.NET-Autorisierung, wenn sie durch IIS bereitgestellt werden. Mithilfe der IIS-Sicherheitsfeatures können Sie den Zugriff auf statische Dateien beschränken, wenn Sie nicht möchten, dass alle Benutzer auf die Dateien zugreifen können. Wenn Sie ASP.NET Development Server zum Testen der ASP.NET-Anwendung verwenden, werden Sie ein anderes Verhalten beobachten, weil statische Dateien der ASP.NET-Autorisierung unterliegen and anonymen Benutzern nicht verfügbar gemacht werden, wenn der anonyme Zugriff auf diese Dateien deaktiviert ist. Alternativ können Sie den Erweiterungen von statischen Dateinamen in IIS die ASP.NET ISAPI-Erweiterung zuordnen. In diesem Fall gelten die ASP.NET-Autorisierungsregeln.

Standardmäßig unterliegen statische Dateien wie Bilder und Stylesheets nicht der ASP.NET-Autorisierung, wenn sie durch IIS bereitgestellt werden. Mithilfe der IIS-Sicherheitsfeatures können Sie den Zugriff auf statische Dateien beschränken, wenn Sie nicht möchten, dass alle Benutzer auf die Dateien zugreifen können. Wenn Sie ASP.NET Development Server zum Testen der ASP.NET-Anwendung verwenden, werden Sie ein anderes Verhalten beobachten, weil statische Dateien der ASP.NET-Autorisierung unterliegen and anonymen Benutzern nicht verfügbar gemacht werden, wenn der anonyme Zugriff auf diese Dateien deaktiviert ist. Alternativ können Sie den Erweiterungen von statischen Dateinamen in IIS die ASP.NET ISAPI-Erweiterung zuordnen. In diesem Fall gelten die ASP.NET-Autorisierungsregeln.

Weitere Informationen finden Sie unter ASP.NET-Autorisierung und Grundlegende Sicherheitshinweise für Webanwendungen.

ASP.NET-Konfigurationsdateien

Mit den Einstellungen in einer Web.config-Datei werden ASP.NET-Sicherheitsoptionen eingerichtet. Sie können vordefinierte Elemente für verschiedene Sicherheitsoptionen in die Datei einfügen, einschließlich Abschnitte für Authentifizierung und Autorisierung. Die relevanten Abschnitte der Datei Web.config könnten wie folgt aussehen.

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

Die Anwendung kann mehrere Konfigurationsdateien enthalten. Im Standardverzeichnis der Anwendung gibt es standardmäßig eine Konfigurationsdatei, die die Sicherheit für die Anwendung als Ganzes angibt; das bedeutet, dass die Sicherheitseinstellungen von Unterordnern geerbt werden. Sie können jedoch auch Konfigurationsdateien in einzelnen Ordnern erstellen, um Sicherheitseinstellungen für den betreffenden Ordner anzugeben.

Weitere Informationen finden Sie unter ASP.NET-Architektur.

Sicherheit von XML-Webdiensten

XML-Webdienste mit ASMX-Dateien werden als Webanwendungen mit ASP.NET ausgeführt und verwenden daher dasselbe Sicherheitsmodell wie jede andere ASP.NET-Anwendung. Ein XML-Webdienst könnte somit z. B. für die Standardauthentifizierung oder die integrierte Windows-Sicherheit konfiguriert sein.

Wenn Sie zur Entwurfszeit versuchen, einen Verweis auf einen XML-Webdienst hinzuzufügen – d. h. wenn Sie die Discoverydokumente des XML-Webdiensts anfordern – führt der XML-Webdienst die Standardauthentifizierung der Webanwendung entsprechend der Konfiguration durch. Wenn der XML-Webdienst z. B. für die Standardauthentifizierung konfiguriert ist, erwartet er vom anfordernden Client einen Benutzernamen und ein Kennwort. Wenn der XML-Webdienst z. B. mit einer Standardauthentifizierung arbeitet, werden Sie über das Dialogfeld Webverweis hinzufügen zur Angabe von Anmeldeinformationen aufgefordert.

Wenn Sie eine Anwendung erstellen, die Aufrufe an einen XML-Webdienst enthält, müssen Sie sicherstellen, dass Sie vor dem Aufruf über die erforderlichen Anmeldeinformationen verfügen, da der Aufruf sonst fehlschlägt. Zur Laufzeit können Sie Anmeldeinformationen an den XML-Webdienst übergeben. Legen Sie dazu die Credentials-Eigenschaft des clientseitigen Objekts fest, das den XML-Webdienst darstellt, bevor Sie seine Methoden aufrufen.

Da andere ASP.NET-Sicherheitsoptionen möglicherweise nicht flexibel genug sind, kann der XML-Webdienst eine benutzerdefinierte Authentifizierungslösung implementieren, bei der Anmeldeinformationen in SOAP-Header übergeben werden. Bei dieser Lösung werden Anmeldeinformationen in einen optionalen Teil der Meldung übergeben, die zwischen Client und Server ausgetauscht wird. Anschließend können Sie ein benutzerdefiniertes HTTP-Modul schreiben (durch Implementieren der IHttpModule-Schnittstelle), das die Informationen im Header erkennen und Ihren Authentifizierungscode aufrufen kann.

Wie bei anderen ASP.NET-Anwendungen könnte der XML-Webdienst bestimmte rollenbasierte Autorisierungen implementieren, um den Zugriff auf spezifische Teile der Anwendung einzuschränken.

Ausführliche Informationen finden Sie unter Infrastruktur von XML-Webdiensten und Sichern von mit ASP.NET erstellten XML-Webdiensten.

Herstellen von Datenintegrität und Vertraulichkeit

Authentifizierung und Autorisierung geben an, wer ihre Benutzer sind und auf welche Ressourcen sie zugreifen können. Diese Sicherheitsfeatures sollen hauptsächlich dazu beitragen, die Webanwendung vor der Verwendung durch Unbefugte zu schützen.

Allerdings gibt es noch einen weiteren Sicherheitsaspekt. Dieser soll ebenfalls dazu beitragen, die Informationen der Benutzer zu schützen und ihnen die Sicherheit zu geben, vertrauliche Informationen mit Ihnen austauschen zu können. Wenn die Anwendung die Benutzer zur Angabe von Kreditkarten- oder anderen Kontonummern, persönlichen Informationen oder vertraulichen Daten auffordert, müssen Sie ihnen eine Möglichkeit bereitstellen, diese Informationen sicher zu übermitteln.

Mithilfe der SSL-Verschlüsselung (Secure Sockets Layer) in IIS können Sie verschlüsselte Informationen mit dem HTTPS-Protokoll austauschen. SSL bietet Verschlüsselung in beiden Richtungen: Ihre Informationen werden verschlüsselt an den Benutzer übertragen, und der Benutzer stellt der Anwendung ebenfalls verschlüsselte Informationen zur Verfügung.

Festlegen von SSL und Verschlüsselung

Zur Verwendung von SSL und Verschlüsselung müssen Sie sich ein Serverzertifikat für Ihr Unternehmen oder Ihre Identität besorgen. Das Zertifikat ist eine digitale Signatur, die Ihre Site so kennzeichnet, dass kein Identitätswechsel vorgenommen werden kann. Für (öffentliche) Internet-Anwendungen erhalten Sie ein Serverzertifikat von einer anerkannten Zertifizierungsstelle. Für private (Intranet-) Anwendungen können Sie selbst ein Serverzertifikat ausgeben. Dies ist z. B. sinnvoll, wenn Sie eine interne Anwendung, beispielsweise eine persönliche Website sichern möchten.

Das Serverzertifikat ermöglicht auch das Herstellen von SSL-verschlüsselten Verbindungen mit den Browserbenutzern. SSL verwendet ein Verschlüsselungsverfahren mit dem Namen Verschlüsselung mit öffentlichen Schlüsseln. Bei dieser Form der Verschlüsselung gibt es zwei Schlüssel: einen öffentlichen Schlüssel, der zum Verschlüsseln der Daten verwendet wird, und einen privaten Schlüssel, der geheim bleibt und zum Entschlüsseln der Informationen dient, die mit dem öffentlichen Schlüssel verschlüsselt wurden. Das Ihnen vorliegende Serverzertifikat enthält einen privaten Schlüssel. Wenn Benutzer mit SSL arbeiten möchten, sendet die Anwendung das Zertifikat und den öffentlichen Schlüssel zum Browser. Browser und Server verwenden anschließend den öffentlichen Schlüssel, um einen verschlüsselten Informationsaustausch durchzuführen.

Hinweis:
Bei Verwendung von SSL muss der Browser einen Verschlüsselungsschlüssel unterstützen, der mindestens 40 Bits lang ist. Diese Anforderung ist bei den meisten Browsern erfüllt. Allerdings wird diese Schlüssellänge nicht als sicher betrachtet. Sie können die Anwendung in IIS optional so konfigurieren, dass nur SSL-Verbindungen mit einem 128-Bit-Schlüssel zulässig sind.

Sobald Sie ein Serverzertifikat erhalten haben, können Sie Benutzer zur Verwendung von SSL anweisen, indem Sie https:// als Präfix für das Abrufen und Bereitstellen von Webseiten angeben müssen. Die Website kann in IIS auch so konfiguriert werden, dass nur HTTPS-Verbindungen akzeptiert werden. IIS und Browser verwenden für den Informationsaustausch automatisch einen verschlüsselten Kanal.

Ausführliche Informationen zum Verwenden von SSL finden Sie im Artikel Q307267, "SO WIRD'S GEMACHT: Sicherheit der XML-Webdienste durch SSL" in der Microsoft Knowledge Base. Informationen zur Verschlüsselung finden Sie unter Übersicht über Kryptografie. Informationen zu Zertifikaten und zum Konfigurieren von SSL finden Sie im Windows Server TechCenter for IIS auf der Microsoft TechNet-Website.

Verwenden der .NET-Codesicherheit

Ein letzter Aspekt in Bezug auf die Sicherheit besteht darin, dass Sie Maßnahmen ergreifen müssen, um den Anwendungscode vor Missbrauch zu schützen, wenn er versehentlich in einem falschen Kontext ausgeführt oder mit böswillige Absicht verwendet wird. Da ASP.NET ein Bestandteil von .NET Framework ist, können Sie mithilfe der Codezugriffssicherheit auch Berechtigungen einrichten, durch die festgelegt ist, welche Vorgänge durch Code ausgeführt werden dürfen. Informationen hierzu finden Sie unter Codezugriffssicherheit.

Siehe auch

Konzepte

Grundlegende Sicherheitshinweise für Webanwendungen

Freigeben über