Entwurfsrichtlinien für sichere Webanwendungen

Auf dieser Seite

 Modulübersicht
 Zielsetzung
 Betrifft
 Verwendung dieses Moduls
 Sicherheitsrelevante Architektur- und Entwurfsaspekte bei Webanwendungen
 Überlegungen zur Bereitstellung
 Eingabeüberprüfung
 Authentifizierung
 Autorisierung
 Konfigurationsverwaltung
 Vertrauliche Daten
 Sitzungsverwaltung
 Kryptografie
 Parametermanipulation
 Ausnahmeverwaltung
 Überwachen und Protokollieren
 Zusammenfassung der Entwurfsrichtlinien
 Zusammenfassung
 Weitere Quellen

Modulübersicht

Webanwendungen stellen Systemarchitekten, Designer und Entwickler vor eine Reihe komplexer Sicherheitsprobleme. Die sichersten und gegen Hackerangriffe bestmöglich geschützten Webanwendungen sind jene, die von Grund auf unter Berücksichtigung der Sicherheitsaspekte erstellt wurden.

Es empfiehlt sich daher, bereits während der ersten Phasen des Entwurfs solide Konstruktions- und Entwurfstechniken anzuwenden und Überlegungen zur Bereitstellung sowie Unternehmenssicherheitsrichtlinien einzubeziehen. Entsprechende Versäumnisse führen möglicherweise zu Anwendungen, die nicht ohne Gefährdung innerhalb einer bestehenden Infrastruktur bereitgestellt werden können.

Dieses Modul stellt eine Reihe von Richtlinien für eine sichere Architektur und einen sicheren Entwurf vor. Die Einteilung dieser Richtlinien orientiert sich an den üblichen Kategorien zur Kennzeichnung der Sicherheitsrisiken für Anwendungen. Diese Kategorien bezeichnen Schlüsselbereiche für die Sicherheit von Webanwendungen, in denen am häufigsten mit Fehlern zu rechnen ist.

 

Zielsetzung

Themenbereiche:

• Identifizieren der Schlüsselprobleme bei Architektur und Entwurf von sicheren Webanwendungen.

• Berücksichtigen der wesentlichen Bereitstellungsprobleme während der Entwurfsphase.

• Entwerfen von Strategien zur Verbesserung der Eingabeüberprüfung einer Webanwendung.

• Entwerfen von Mechanismen für eine sichere Authentifizierung und Sitzungsverwaltung.

• Auswählen eines geeigneten Autorisierungsmodells.

• Implementieren wirksamer Verfahren zur Kontoverwaltung und zur Sicherung von Benutzersitzungen.

• Bereitstellen von Datenschutz, Nichtablehnung, Fälschungssicherheit und Authentifizierung unter Verwendung kryptografischer Verfahren.

• Verhindern von Parametermanipulationen.

• Entwerfen von Überwachungs- und Protokollierungsstrategien.

 

Betrifft

Auch wenn diese Informationen in einem Dokument zur Sicherheit von ASP.NET-Anwendungen enthalten sind, sind sie für jeden relevant, der sich für die Entwicklung von sicheren Webanwendungen interessiert.

 

Verwendung dieses Moduls

Dieses Modul befasst sich vorrangig mit den Richtlinien und Prinzipien, die Sie beim Entwerfen einer Webanwendung befolgen sollten.

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

• Informieren Sie sich über die Gefahren, die Ihren Anwendungen drohen, damit Sie sicherstellen können, dass Ihr Entwurf diese Gefahren berücksichtigt. Lesen Sie Modul 2, "Bedrohungen und Gegenmaßnahmen", um ein besseres Verständnis für die möglichen Gefährdungen zu entwickeln. In Modul 2 werden die möglichen Bedrohungen für Webanwendungen aufgelistet. Sie sollten diese Bedrohungen bereits während der Entwurfsphase berücksichtigen.

• Verwenden Sie einen systematischen Ansatz für die Schlüsselbereiche, in denen die Anwendung anfällig für Angriffe ist. Konzentrieren Sie sich auf die Themen Bereitstellung, Eingabeüberprüfung, Authentifizierung und Autorisierung, Kryptografie und Schutz vertraulicher Daten, Konfigurations-, Sitzungs- und Ausnahmeverwaltung sowie Sicherstellen von Verantwortlichkeiten auf angemessene Überwachungs- und Protokollierungsmechanismen.

 

Sicherheitsrelevante Architektur- und Entwurfsaspekte bei Webanwendungen

Webanwendungen stellen Designer und Entwickler vor eine Vielzahl von Herausforderungen. Der statusfreie Charakter des HTTP-Protokolls bedeutet, dass die Nachverfolgung des Sitzungsstatus für jeden Benutzer in die Verantwortung der Anwendung wechselt. Als Voraussetzung hierfür muss die Anwendung in der Lage sein, die Benutzer mithilfe einer Form von Authentifizierung zu identifizieren. Da alle späteren Autorisierungsentscheidungen von der festgestellten Benutzeridentität abhängig sind, ist es von zentraler Bedeutung, dass der Authentifizierungsprozess wie auch der Mechanismus zur Handhabung von Sitzungen, mit dem authentifizierte Benutzer erkannt werden, gleichermaßen geschützt sind. Der Entwurf von sicheren Authentifizierungs- und Sitzungsverwaltungsmechanismen ist nur eine der Aufgaben von Designern und Entwicklern von Webanwendungen. Andere Herausforderungen ergeben sich aus dem Umstand, dass ein- und ausgehende Daten über öffentliche Netzwerke geleitet werden. Weitere wichtige Themen betreffen das Verhindern von Parametermanipulationen und der Preisgabe vertraulicher Daten.

In Abbildung 4.1 werden einige der wichtigsten Problembereiche dargestellt, die Sie mit sicheren Entwurfstechniken lösen müssen.

Abbildung 4.1
Sicherheitsrelevante Aufgaben beim Entwurf von Webanwendungen

Die in diesem Modul vorgestellten Entwurfsrichtlinien sind nach den Sicherheitsrisiken für Anwendungen gegliedert. Die Erfahrung lehrt, dass unzureichende Entwurfsanstrengungen in diesen Bereichen zu Sicherheitsrisiken führen. In Tabelle 4.1 werden die Risikokategorien auflistet und für jede von ihnen die möglichen Probleme benannt, die sich aus Entwurfsschwächen ergeben können.

Tabelle 4.1. Sicherheitsrisiken für Webanwendungen und mögliche Probleme, die aus mangelhaftem Entwurf resultieren können

Sicherheitsrisiko	Mögliche Probleme aufgrund von mangelhaftem Entwurf
Eingabeüberprüfung	Angriffe durch Einbetten schädlicher Zeichenfolgen in Abfragezeichenfolgen, Formularfelder, Cookies und HTTP-Header. Dies schließt die Ausführung von Befehlen, Cross-Site Scripting (XSS), SQL-Injektionen und Pufferüberlaufangriffe ein.
Authentifizierung	Vortäuschen von Identitäten, Entschlüsseln von Kennwörtern, Erweitern von Berechtigungen und unbefugter Zugriff.
Autorisierung	Zugriff auf vertrauliche oder geheime Daten sowie Manipulieren und Ausführen von unbefugten Operationen.
Konfigurationsverwaltung	Unbefugter Zugriff auf Verwaltungsschnittstellen, Fähigkeit zur Aktualisierung von Konfigurationsdaten und unbefugter Zugriff auf Benutzerkonten und Kontenprofile.
Vertrauliche Daten	Offenlegen vertraulicher Informationen und unbefugtes Ändern von Daten.
Sitzungsverwaltung	Übernahme von Sitzungen und Vortäuschen von Identitäten aufgrund abgefangener Informationen über Sitzungskennungen.
Kryptografie	Zugriff auf vertrauliche Daten und/oder Kontoinformationen.
Parametermanipulation	Pfadüberschreitung, Befehlsausführung, Umgehung von Mechanismen der Zugriffskontrolle und andere Manipulationen führen zur Offenlegung von Informationen, der Erweiterung von Berechtigungen und DoS-Angriffe (Denial of Service).
Ausnahmeverwaltung	DoS-Angriffe und Offenlegen von sicherheitsrelevanten Informationen der Systemebene.
Überwachen und Protokollieren	Versagen beim Erkennen von Anzeichen für Eindringversuche, Unfähigkeit, Benutzeraktionen zu dokumentieren, und Schwierigkeiten bei der Fehlerdiagnose.

 

Überlegungen zur Bereitstellung

Während der Phase des Anwendungsentwurfs sollten Sie die Sicherheitsrichtlinien und -verfahrensweisen Ihres Unternehmens sowie die Infrastruktur zur Bereitstellung der Anwendung überprüfen. Häufig zeichnet sich die Zielumgebung durch starre Vorgaben aus, denen der Anwendungsentwurf Rechnung tragen muss. In manchen Fällen sind Abstriche und Kompromisse beim Entwurf notwendig, da beispielsweise Protokoll- oder Portbeschränkungen oder bestimmte Bereitstellungstopologien zu berücksichtigen sind. Es empfiehlt sich, Beschränkungen dieser Art frühzeitig während der Entwurfsphase zu identifizieren, um spätere Überraschungen zu vermeiden. Dabei sollten Sie die für das Netzwerk und die Infrastruktur zuständigen Mitarbeiter einbeziehen.

In Abbildung 4.2 werden die verschiedenen Bereitstellungsaspekte dargestellt, die während der Entwurfsphase zu berücksichtigen sind.

Abbildung 4.2
Überlegungen zur Bereitstellung

Sicherheitsrichtlinien und -verfahrensweisen

Eine Sicherheitsrichtlinie legt die zulässigen Aktionen für Anwendungen und ihre Benutzer fest. Von größerer Bedeutung ist jedoch, dass sie auch Beschränkungen festlegt, die definieren, welche Vorgänge Anwendungen und Benutzer nicht durchführen dürfen. Identifizieren und nutzen Sie den durch die Sicherheitsrichtlinie Ihres Unternehmens festgelegten Rahmen während des Anwendungsentwurfs, um Verstöße gegen diese Richtlinie auszuschließen, die möglicherweise die Bereitstellung der Anwendung verhindern.

Komponenten der Netzwerkinfrastruktur

Vergewissern Sie sich, dass Sie die Netzwerkstruktur der Zielumgebung und die grundlegenden Sicherheitsanforderungen des Netzwerks (Filterregeln, Portbeschränkungen, unterstützte Protokolle usw.) verstehen.

Finden Sie heraus, auf welche Weise Firewalls und Firewallrichtlinien den Entwurf und die Bereitstellung der Anwendung beeinflussen. Möglicherweise sollen Firewalls eingesetzt werden, um mit dem Internet kommunizierende Anwendungen vom internen Netzwerk zu trennen. Vielleicht werden auch zusätzliche Firewalls vor den Datenbankserver platziert. Diese können sich auf die Kommunikationsports und folglich auf die Optionen zur Authentifizierung zwischen Webserver und Remoteanwendung sowie den Datenbankservern auswirken. So erfordert beispielsweise die Windows-Authentifizierung zusätzliche Ports.

Wägen Sie in der Entwurfsphase ab, welchen Protokollen, Ports und Diensten der Zugriff von Webservern innerhalb des Perimeternetzwerks auf interne Ressourcen gewährt werden soll. Ermitteln Sie auch die vom Anwendungsentwurf als notwendig bestimmten Protokolle und Ports und analysieren Sie die möglichen Bedrohungen, die aus dem Öffnen neuer Ports und der Verwendung neuer Protokolle resultieren.

Notieren Sie alle Annahmen, die hinsichtlich der Sicherheit auf Netzwerk- und Anwendungsebene und den Zuordnungen zwischen Sicherheitsfunktionen und dafür zuständigen Komponenten getroffen wurden, und informieren Sie die zuständigen Mitarbeiter. Auf diese Weise verhindern Sie, dass Sicherheitskontrollen übersehen werden, da sowohl Entwicklungs- als auch Netzwerkteams annehmen, dass sich das jeweils andere Team mit dem entsprechenden Problem befasst. Achten Sie auf die Sicherheitsmaßnahmen, auf die sich die Anwendung als vom Netzwerk bereitgestellte Funktionalität stützt. Bedenken Sie die Implikationen einer Änderung der Netzwerkkonfiguration. Wie viel an Sicherheit geht verloren, wenn eine bestimmte Änderung am Netzwerk implementiert wird?

Bereitstellungstopologien

Die Topologie der Anwendungsbereitstellung und die Verfügbarkeit einer Remoteanwendungsschicht bilden ein Schlüsselelement des Entwurfs. Wenn Sie über eine Remoteanwendungsschicht verfügen, müssen Sie berücksichtigen, wie Sie das Netzwerk zwischen Servern sichern, um den Netzwerkverkehr gegen Abhöraktionen zu schützen und für vertrauliche Daten Datenschutz und Integrität sicherzustellen.

Auch der Fluss von Identitätsinformationen muss berücksichtigt werden. Ermitteln Sie die Konten, die zur Netzwerkauthentifizierung verwendet werden, wenn eine Anwendung eine Verbindung mit Remoteservern herstellt. Ein üblicher Ansatz besteht darin, ein mit minimalen Berechtigungen ausgestattetes Prozesskonto zu nutzen und auf dem Remoteserver ein dupliziertes (gespiegeltes) Konto mit demselben Kennwort zu erstellen. Wahlweise könnten Sie auch ein Domänenprozesskonto verwenden, das einfacher zu verwalten, jedoch komplizierter zu schützen ist, da die netzwerkweite Nutzung des Kontos nur schwer eingeschränkt werden kann. Eine zwischengeschaltete Firewall oder separate Domänen ohne Vertrauensstellungen bewirken häufig, dass der Ansatz unter Verwendung eines lokalen Kontos die einzig realisierbare Option bleibt.

Intranet, Extranet und Internet

Szenarios mit Intranet-, Extranet- und Internetanwendungen bringen jeweils eigene Herausforderungen an den Entwurf mit sich. Zu den Fragen, die Sie sich in diesem Zusammenhang stellen sollten, gehören unter anderem: Auf welche Weise soll die Identität des Aufrufers durch mehrere Anwendungsschichten an Back-End-Ressourcen weitergeleitet werden? Wo soll die Authentifizierung durchgeführt werden? Ist die Authentifizierung beim Front-End-System vertrauenswürdig und kann auf Basis dieser Authentifizierung eine vertrauenswürdige Verbindung für den Zugriff auf Back-End-Ressourcen verwendet werden? Bei Extranet-Szenarios müssen Sie außerdem bedenken, ob Sie Partnerkonten trauen können.

Weitere Informationen zu diesen und anderen szenariospezifischen Themen finden Sie in den Abschnitten "Intranet Security", "Extranet Security" und "Internet Security" des Dokuments "Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" unter der Adresse https://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

 

Eingabeüberprüfung

Die Überprüfung von Eingaben ist ein anspruchvolles Problem, dessen Lösung hauptsächlich in den Verantwortungsbereich von Anwendungsentwicklern fällt. Andererseits ist eine solide Eingabeüberprüfung eine der stärksten Verteidigungsmaßnahmen gegen die aktuellen Angriffe auf Anwendungsebene. Eine korrekte Eingabeüberprüfung erweist sich als wirksames Mittel gegen XSS-Angriffe, SQL-Injektionen, Pufferüberläufen und anderen Eingabeangriffe.

Die Überprüfung von Eingaben ist eine anspruchsvolle Aufgabe, da es keine verbindliche Antwort auf die Frage gibt, welche Merkmale eine gültige Eingabe anwendungsübergreifend oder selbst innerhalb von Anwendungen kennzeichnen. Ebenso gibt es auch keine verbindliche Definition "böswilliger" Eingaben. Es kommt hinzu, dass die Art, in der die Anwendung mit Eingaben umgeht, das Risiko des Missbrauchs beeinflusst. Werden die Daten beispielsweise gespeichert, damit sie von anderen Anwendungen genutzt werden können, oder "verbraucht" die Anwendung Eingaben von Datenquellen, die durch andere Anwendungen erstellt wurden?

Folgende Vorgehensweisen sind zur Verbesserung der Eingabeüberprüfung einer Webanwendung denkbar:

• Annahme, dass alle Eingaben in schädlicher Absicht manipuliert sind

• Zentralisieren des Lösungsansatzes

• Ergänzen der clientseitigen Überprüfung auf dem Server

• Beachten von Kanonisierungsproblemen

• Einschränken, Ablehnen und Entschärfen der Eingabe

Annahme, dass alle Eingaben in schädlicher Absicht manipuliert sind

Ausgangspunkt einer Eingabeüberprüfung ist die grundlegende Annahme, dass bis zum Beweis des Gegenteils alle Eingaben als schädlich betrachtet werden müssen. Es gilt, unabhängig davon, woher eine Eingabe stammt - sei es ein Dienst, eine Dateifreigabe, ein Benutzer oder eine Datenbank -, die Eingabe zu überprüfen, wenn die Quelle außerhalb der "Vertrauensgrenze" liegt. Angenommen, Sie rufen einen externen Webdienst auf, der als Ergebnis Zeichenfolgen zurückgibt - woher wissen Sie, dass diese Zeichenfolgen keine schädlichen Befehle transportieren? Oder betrachten Sie den Fall, dass mehrere Anwendungen in eine gemeinsam genutzte Datenbank schreiben, auf die Sie anschließend lesend zugreifen. Woher soll die Gewissheit kommen, dass die aus der Datenbank entnommenen Daten sicher sind?

Zentralisieren des Lösungsansatzes

Die Eingabeüberprüfungsstrategie ist ein Kernelement des Anwendungsentwurfs. Ein Beispiel für einen zentralisierten Ansatz ist es, allgemeinen Code aus gemeinsam genutzten Bibliotheken zur Überprüfung und Filterung von Eingaben zu verwenden. Auf diese Weise ist sichergestellt, dass Überprüfungsregeln konsistent angewendet werden. Darüber hinaus reduziert dieser Ansatz den Entwicklungsaufwand und erleichtert die zukünftige Wartung der Anwendung.

In vielen Fällen erfordern einzelne Felder eine besondere Überprüfung, beispielsweise mithilfe von speziell entwickelten regulären Ausdrucken. Allerdings ist es häufig möglich, gebräuchliche Routinen zur Überprüfung von Feldinhalten wie E-Mail-Adressen, Anschriften, Titel, Namen, postalische Adressen einschließlich Postleitzahlen usw. zu identifizieren und zu modularisieren. Dieser Ansatz wird in Abbildung 4.3 dargestellt.

Abbildung 4.3
Ein zentraler Ansatz für die Eingabeüberprüfung

Ergänzen der clientseitigen Überprüfung auf dem Server

Der Code auf dem Server sollte eine eigene Überprüfung durchführen. Denn was geschieht, wenn ein Angreifer den Client umgeht oder die Skriptroutinen auf dem Client blockiert, indem er beispielsweise JavaScript deaktiviert? Die Überprüfung auf dem Client ist sinnvoll, da sie die Anzahl der Kommunikationsvorgänge zwischen Client und Server reduziert. Sie reicht jedoch als Basis für die Sicherheit nicht aus. Die hier erforderliche Ergänzung auf dem Server ist ein Beispiel für das Prinzip der Tiefenverteidigung.

Beachten von Kanonisierungsproblemen

Daten in kanonischer Form sind Daten in weitestgehend standardisierter oder vereinfachter Form. Kanonisierung bezeichnet den Prozess, bei dem Daten in ihre kanonische Form umgewandelt werden. Dateipfade und URLs erweisen sich als besonders anfällig für Kanonisierungsprobleme, zahlreiche Sicherheitslücken sind ein direktes Ergebnis von Kanonisierungsfehlern. Betrachten Sie beispielsweise die folgende Zeichenfolge, die einen Datennamen und einen Pfad in kanonischer Form enthält.

C:\Temp\EineDatei.dat

Die folgenden Zeichenfolgen könnten ebenfalls dieselbe Datei repräsentieren.

EineDatei.dat
C:\Temp\Unterverzeichnis\..\EineDatei.dat
C:\  Temp\   EineDatei.dat
..\EineDatei.dat
C%3A%5CTemp%5CUnterverzeichnis%5C%2E%2E%5CEineDatei.dat

In der letzten Zeichenfolge des Beispiels wurden Zeichen in hexadezimaler Form angegeben:

• "%3A" steht für einen Doppelpunkt.

• "%5C" steht für einen umgekehrten Schrägstrich.

• "%2E" steht für einen Punkt.

Um Kanonisierungsprobleme zu vermeiden, sollten Sie in der Regel keine Anwendungen entwerfen, die Dateinamen als Benutzereingaben akzeptieren. Stattdessen sollten Sie alternative Entwürfe in Betracht ziehen. Sie könnten beispielsweise die Anwendung den Dateinamen für den Benutzer ermitteln lassen.

Sollte es notwendig sein, Dateinamen als Eingaben zu akzeptieren, müssen Sie sicherstellen, dass diese Eingaben der vorgeschriebenen Form genügen, bevor Sie sicherheitsrelevante Entscheidungen treffen, indem Sie beispielsweise den Zugriff auf die angegebene Datei gewähren oder verweigern.

Weitere Informationen zum Umgang mit Dateinamen und zur Durchführung von Dateieingaben und -ausgaben finden Sie in Modul 7, "Erstellen sicherer Assemblys" und Modul 8, "Codezugriffssicherheit in der Praxis" in den Abschnitten zum Thema "Dateieingabe/-ausgabe".

Einschränken, Ablehnen und Entschärfen der Eingabe

Der bevorzugte Ansatz für die Überprüfung von Eingaben besteht darin, von Beginn an die zulässigen Eingaben einzuschränken. Die Datenüberprüfung auf bekannte Datentypen, Muster und Wertebereiche ist weit einfacher als eine Suche nach bekannten unerwünschten Zeichen. Beim Entwerfen der Anwendung wissen Sie bereits, welche Eingaben die Anwendung erwartet. Der Bereich der zulässigen Daten ist in der Regel enger begrenzt als das Spektrum der potenziell schädlichen Eingaben. Möglicherweise möchten Sie jedoch im Sinne der Tiefenverteidigung zusätzlich bekannte schädliche Eingaben ablehnen und anschließend die akzeptierten Eingaben durch korrigierende Maßnahmen "entschärfen". Diese empfohlene Strategie wird in Abbildung 4.4 dargestellt.

Abbildung 4.4
Strategie zur Eingabeüberprüfung: Einschränken, Ablehnen und Entschärfen der Eingabe

Um eine wirksame Strategie zur Eingabeüberprüfung zu entwerfen, sollten Sie sich der folgenden Verfahrensregeln und deren Wechselwirkungen bewusst sein:

• Einschränken der Eingabe

• Überprüfen der Daten auf Typ, Länge, Format und Wertebereich

• Ablehnen bekannter schädlicher Eingaben

• Entschärfen der Eingabe

Einschränken der Eingabe

Die Einschränkung von Eingaben zielt darauf ab, unschädliche Daten zuzulassen. Dies ist der bevorzugte Ansatz. Der Grundgedanke besteht darin, einen Filter für akzeptable Eingaben zu definieren, der diese auf Typ-, Längen-, Format- und Wertebereichvorgaben hin überprüft. Definieren Sie, welche Eingabe für die Felder der Anwendung akzeptiert werden, und erzwingen Sie die Einhaltung dieser Vorgaben. Lehnen Sie alles andere als schädlich ab.

Die Einschränkung von Eingaben kann es erforderlich machen, Zeichensätze auf dem Server einzurichten, damit Sie auf lokalisierte Versionen der kanonischen Form zurückgreifen können.

Überprüfen der Daten auf Typ, Länge, Format und Wertebereich

Verwenden Sie nach Möglichkeit für alle Eingabedaten eine strenge Typprüfung, beispielsweise in den Klassen für die Manipulation und Verarbeitung der Eingabedaten sowie in den Datenzugriffsroutinen. Es empfiehlt sich, parametrisierte gespeicherte Prozeduren für den Datenzugriff zu verwenden, um die Vorteile einer strengen Typprüfung für Eingabefelder zu nutzen.

Felder zur Eingabe von Zeichenfolgen sollten außerdem einer Längenüberprüfung und häufig auch einer Formatüberprüfung unterzogen werden. Dies betrifft beispielsweise Postleitzahlen, PIN-Angaben zur Benutzeridentifizierung und ähnliche Eingaben mit klar definierten Formaten, die mithilfe regulärer Ausdrücke überprüft werden können. Eine gründliche Überprüfung entspricht nicht nur guter Programmierpraxis, sondern erschwert es auch einem Angreifer, Sicherheitslücken im Code auszunutzen. Möglicherweise schafft es der Angreifer, die Hürde der Typprüfung zu überwinden, doch die Längenprüfung kann es ihm erschweren, seinen bevorzugten Angriff zum Erfolg zu führen.

Ablehnen bekannter schädlicher Eingaben

Lehnen Sie "schädliche" Daten ab, verlassen Sie sich allerdings nicht vollständig auf diesen Ansatz. Für sich allein ist dieser Ansatz in der Regel weniger wirksam als das zuvor beschriebene Verfahren mit der Festlegung der zulässigen Eingaben. Am besten ist es daher, beide Ansätze zu kombinieren. Das Ablehnen schädlicher Daten setzt voraus, dass die Anwendung alle Varianten schädlicher Eingaben kennt. Denken Sie daran, dass es mehr als ein Verfahren zur Darstellung von Zeichen gibt. Auch dies spricht dafür, den Ansatz der "zulässigen" Daten zu bevorzugen.

Zwar ist das Ablehnen von Daten für bereits installierte Anwendungen und in Situationen nützlich, in denen wesentliche Änderungen zuviel Aufwand bedeuten. Jedoch ist dieser Ansatz nicht so zuverlässig wie sein Gegenstück, da schädliche Daten (beispielsweise Zeichenmuster, die zur Identifizierung von üblichen Angriffen verwendet werden können) nicht konstant bleiben. Die Kriterien für gültige Daten bleiben konstant, jedoch kann sich das Spektrum schädlicher Daten im Laufe der Zeit durchaus ändern.

Entschärfen der Eingabe

Das Entschärfen dient zum Schützen von potenziell gefährlichen Daten. Diese Maßnahmen können hilfreich sein, wenn der Bereich der zulässigen Eingaben nicht gewährleisten kann, dass die eingegebenen Daten auch sicher sind. Das Entschärfen schließt eine Vielzahl unterschiedlicher Methoden ein, beispielsweise das Entfernen einer Null am Ende einer vom Benutzer eingegebenen Zeichenfolge oder das Maskieren von Werten mit Escapezeichen, damit diese als Literale behandelt werden.

Eine andere verbreitete Technik zur Entschärfung von Eingaben in Webanwendungen besteht darin, Daten mithilfe einer URL- oder HTML-Codierung zu "verpacken" und als Textkonstante statt als ausführbares Skript zu behandeln. HtmlEncode-Methoden kommentieren HTML-Zeichen, während UrlEncode-Methoden einen URL in eine gültige URI-Anfrage umcodieren.

Praktische Anwendung

Im Folgenden werden Beispiele gegeben, welche die Verwendung der genannten Ansätze anhand von üblichen Eingabefeldern illustrieren:

• Feld "Nachname". Dieses Feld ist ein gutes Beispiel für einen Fall, in dem sich die Beschränkung von Eingaben als angemessenes Verfahren erweist. Bei diesem Feld könnten Sie Zeichenfolgendaten im Bereich der ASCII-Zeichen A-Z und a-z und darüber hinaus auch das Bindestrichzeichen sowie einfache typografische Anführungszeichen (die für SQL nicht von Bedeutung sind) zulassen, um Namen wie "O'Dell" zu handhaben. Außerdem könnten Sie die Länge auf den längsten erwarteten Wert begrenzen.

• Feld "Menge". Auch hierfür bietet sich die Beschränkung der Eingaben an. Hier könnten Sie eine einfache Typ- und Wertebereichsbeschränkung verwenden. Sie könnten beispielsweise festlegen, dass Eingabedaten positive ganzzahlige Werte im Bereich zwischen 0 und 1000 sein müssen.

• Freitextfeld. Beispiele hierfür sind Kommentarfelder in Diskussionsforen. Bei Feldern dieser Art könnten Sie Buchstaben und Leerzeichen sowie übliche Zeichen wie Anführungszeichen, Kommas und Bindestriche zulassen. Nicht im zulässigen Zeichensatz enthalten sind Kleiner-als- und Größer-als-Zeichen, eckige und geschweifte Klammern.

  Einige Anwendungen könnten es Benutzern gestatten, den Text mithilfe eines begrenzten Satzes von Skriptzeichen (beispielsweise "<b>" für Fettdruck und "<i>" für Kursivschrift) zu bearbeiten oder sogar einen Link zu einem gewünschten URL einzufügen. Sofern der Text einen URL enthält, sollte die Eingabeüberprüfung den entsprechenden Wert codieren, damit er als URL behandelt wird.

  Weitere Informationen zur Überprüfung von Freitextfeldern finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente" unter "Eingabeüberprüfung".

• Eine vorhandene Webanwendung ohne Überprüfung von Benutzereingaben . Im Idealfall überprüft eine Anwendung jedes Feld und jeden Eingabepunkt auf zulässige Eingaben. Wenn Sie jedoch mit einer vorhandenen Anwendung arbeiten, die keine Überprüfung von Benutzereingaben durchführt, müssen Sie zunächst auf Behelfsmaßnahmen zurückgreifen, um das Risiko zu mildern, bis Sie in der Lage sind, die Eingabeüberprüfungsstrategie der Anwendung zu ändern. Obwohl keine der beiden folgenden Methoden eine sichere Handhabung von Eingabedaten gewährleistet, da diese davon abhängt, woher die Daten stammen und wie sie von der Anwendung verarbeitet werden, kommen sie in der aktuellen Praxis als Sofortbehelf für schnelle Verbesserungen der Sicherheit zum Einsatz:

  • HTML-Codierung und URL-Codierung von Benutzereingaben bei der Rückübertragung zum Client. Diese Methode setzt voraus, dass keine Eingaben als HTML-Text behandelt und alle Ausgaben in geschützter Form zurückgeschrieben werden. Hier handelt es sich um echte Bereinigungsmaßnahmen.

  • Zurückweisen schädlicher Skriptzeichen. Diese Methode ist ein Anwendungsfall des Prinzips der Zurückweisung bekannter schädlicher Eingaben. Sie beruht darauf, dass Eingaben nach Vorgabe eines konfigurierbaren Satzes von schädlichen Zeichen zurückgewiesen werden. Wie bereits erläutert, besteht das Problem bei diesem Ansatz darin, dass schädliche Daten eine Frage des Kontexts sind.

Weitere Informationen und Beispiele zur Codierung von Eingaben mithilfe regulärer Ausdrücke und ASP.NET-Überprüfungssteuerelementen finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente" unter "Eingabeüberprüfung".

 

Authentifizierung

Authentifizierung bezeichnet den Prozess, mit dem die Identität eines Aufrufers ermittelt wird. Bei diesem Prozess sind drei Aspekte zu berücksichtigen:

• Identifizieren der Stellen innerhalb der Anwendung, an denen eine Authentifizierung erforderlich ist. Üblicherweise wird eine Authentifizierung immer dann erforderlich, wenn eine Vertrauensgrenze überschritten wird. Vertrauensgrenzen schließen in der Regel Assemblys, Prozesse und Hosts ein.

• Überprüfen der Identität der aufrufenden Instanz. Benutzer authentifizieren sich im Regelfall mithilfe von Benutzernamen und Kennwörtern.

• Identifizieren des Benutzers bei späteren Anfragen. Dies erfordert eine Art von Authentifizierungstoken.

Viele Webanwendungen authentifizieren Benutzer mithilfe eines Kennwortmechanismus, bei dem die Benutzer über ein HTML-Formular einen Benutzernamen und ein Kennwort eingeben. In diesem Zusammenhang sind unter anderem folgende Probleme und Fragen zu berücksichtigen:

• Werden Benutzernamen und Kennwörter als unverschlüsselter Klartext über einen unsicheren Kanal gesendet? In diesem Fall kann ein Angreifer mithilfe von Software zur Netzwerküberwachung den Netzwerkverkehr abfangen, um an die Sicherheitsinformationen zu gelangen. Die Gegenmaßnahme besteht darin, den Kommunikationskanal durch Verwendung des SSL-Protokolls (Secure Socket Layer) zu schützen.

• Wie werden die Sicherheitsinformationen gespeichert? Wenn Sie Benutzernamen und Kennwörter als Klartext (in einer Datei oder Datenbank) speichern, ist der Ärger vorprogrammiert. Bedenken Sie nur den Fall, dass bei einem unzureichend konfigurierten Anwendungsverzeichnis ein Angreifer darauf zugreift, nach der Datei sucht, ihren Inhalt herunterlädt oder ein neues privilegiertes Anmeldekonto einrichtet. Oder ein frustrierter Administrator bringt sich in den Besitz der Datenbank mit Ihren Benutzernamen und Kennwörtern.

• Wie werden die Sicherheitsinformationen überprüft? Es gibt keine Notwendigkeit, Benutzerkennwörter zu speichern, wenn ihr einziger Zweck darin besteht, sich zu vergewissern, dass der Benutzer das Kennwort kennt. Stattdessen genügt es, einen Prüfwert in Form eines Hashwerts zu speichern und diesen unter Verwendung der Benutzereingabe während des Anmeldevorgangs neu zu berechnen. Um das Risiko von Wörterbuchangriffen gegen die gespeicherten Sicherheitsinformationen zu mildern, sollten Sie sichere Kennwörter verwenden und den Hashwert des Kennworts mit einem nach dem Zufallsprinzip erzeugten Wert kombinieren.

• Wie wird der authentifizierte Benutzer nach der ersten Anmeldung identifiziert? Für diesen Zweck ist eine Form von Authentifizierungsticket erforderlich, beispielsweise ein Authentifizierungs-Cookie. Wie wird dieses Cookie geschützt? Wenn es über einen unsicheren Kanal gesendet wird, kann ein Angreifer das Cookie abfangen und für den Zugriff auf die Anwendung nutzen. Ein gestohlenes Authentifizierungs-Cookie bedeutet eine gestohlene Lizenz zur Anmeldung.

Folgende Vorgehensweisen können zur Verbesserung der Authentifizierung einer Webanwendung verwendet werden:

• Trennen von öffentlichen und eingeschränkten Bereichen

• Verwenden von Kontosperrungsrichtlinien für Endbenutzerkonten

• Unterstützen der Verwendung von Zeitlimits für Kennwörter

• Erhalten der Fähigkeit, Konten zu deaktivieren

• Vermeiden der Speicherung von Kennwörtern im Benutzerspeicher

• Verwendung sicherer Kennwörter

• Senden von verschlüsselten Kennwörtern über das Netzwerk

• Schützen von Authentifizierungscookies

Trennen von öffentlichen und eingeschränkten Bereichen

Jeder Benutzer kann anonym auf den öffentlichen Bereich einer Website zugreifen. Umgekehrt sind eingeschränkte Bereiche nur bestimmten Benutzern zugänglich, die sich gegenüber der Website authentifizieren müssen. Betrachten Sie den Fall einer Vertriebswebsite. Sie können den Produktkatalog anonym durchsuchen. Wenn Sie dem Warenkorb Artikel hinzufügen, identifiziert die Anwendung Sie mithilfe einer Sitzungskennung. Wenn Sie schließlich eine Bestellung absenden, wird dieser Vorgang mithilfe einer sicheren Transaktion durchgeführt. Dies erfordert einen Anmeldevorgang, damit Sie Ihre Transaktion über SSL authentifizieren.

Indem Sie eine Website in öffentliche und eingeschränkte Bereiche aufteilen, können Sie separate Regeln für die Authentifizierung und Autorisierung auf die gesamte Website anwenden und auf diese Weise den Einsatz von SLL begrenzen. Beim Entwerfen der Website sollten Sie darauf achten, die Verwendung von SSL auf diejenigen Bereiche zu beschränken, die einen authentifizierten Zugriff erfordern, um unnötige Leistungsabstriche zu vermeiden, die mit der Nutzung von SSL einhergehen.

Verwenden von Kontosperrungsrichtlinien für Endbenutzerkonten

Deaktivieren Sie Endbenutzerkonten oder schreiben Sie entsprechende Ereignismeldungen in eine Protokolldatei, wenn eine Reihe von Anmeldeversuchen fehlgeschlagen ist. Bei Verwendung der Windows-Authentifizierung (beispielsweise NTLM oder Kerberos-Protokoll) können diese Richtlinien automatisch vom Betriebssystem konfiguriert und angewendet werden. Bei der Formularauthentifizierung sind diese Richtlinien eine Funktion der Anwendung und müssen in den Anwendungsentwurf integriert werden.

In diesem Fall ist sorgfältig darauf zu achten, dass die Kontosperrungsrichtlinien nicht für DoS-Angriffe (Denial of Service) missbraucht werden können. So sollten beispielsweise wohlbekannte Dienstkonten wie IUSR_MACHINENAME durch benutzerdefinierte Kontennamen ersetzt werden, um einen Angreifer, der in den Besitz des Namens des IIS-Webservers (Internet Information Services) gelangt, daran zu hindern, dieses wichtige Konto zu sperren.

Unterstützen der Verwendung von Zeitlimits für Kennwörter

Kennwörter sollten nicht statisch sein, sondern vielmehr als Teil der routinemäßigen Kennwortverwaltung auf der Basis von Gültigkeitszeiträumen geändert werden. Sie sollten erwägen, ob Sie diesen Mechanismus während des Anwendungsentwurfs zur Verfügung stellen möchten.

Erhalten der Fähigkeit, Konten zu deaktivieren

Ist das System gefährdet, kann die Fähigkeit, gezielt Sicherheitsinformationen ungültig zu machen oder Konten zu deaktivieren, weitere Angriffe verhindern.

Vermeiden der Speicherung von Kennwörtern im Benutzerspeicher

Wenn Sie Kennwörter überprüfen müssen, ist es nicht erforderlich, die Kennwörter zu speichern. Speichern Sie stattdessen einen einmal verwendbaren Hashwert und berechnen Sie dann den Hashwert unter Verwendung der vom Benutzer eingegebenen Kennwörter neu. Um das Risiko von Wörterbuchangriffen gegen den Benutzerspeicher zu mildern, sollten Sie sichere Kennwörter verwenden und den Hashwert des Kennworts mit einem nach dem Zufallsprinzip erzeugten Wert kombinieren.

Verwendung sicherer Kennwörter

Machen Sie es Angreifern nicht so einfach, Kennwörter zu entschlüsseln. Es sind diesbezüglich zahlreiche Richtlinien bekannt. Eine der üblichen Praktiken besteht darin, eine Mindestanzahl von acht Zeichen sowie eine Kombination aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen zu fordern. Unabhängig davon, ob Sie diese Regel durch die gegebene Plattform selbst oder durch eine selbst entwickelte Überprüfung erzwingen, ist dieser Schritt notwendig, um Brute-Force-Angriffen zu begegnen, bei denen der Angreifer versucht, durch systematisches Ausprobieren ein Kennwort zu entschlüsseln. Es empfiehlt sich, reguläre Ausdrücke zur Überprüfung sicherer Kennwörter zu verwenden.

Beispiele für reguläre Ausdrücke als Hilfsmittel zur Kennwortüberprüfung finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente" unter "Eingabeüberprüfung".

Senden von verschlüsselten Kennwörtern über das Netzwerk

Im Klartext über ein Netzwerk gesendete Kennwörter sind durch Abhörangriffe gefährdet. Um dieser Bedrohung zu begegnen, müssen Sie den Kommunikationskanal schützen, indem Sie den Netzwerkverkehr beispielsweise mit SSL verschlüsseln.

Schützen von Authentifizierungs-Cookies

Ein gestohlenes Authentifizierungs-Cookie ist eine gestohlene Anmeldung. Schützen Sie Authentifizierungstickets mithilfe von Verschlüsselung und sicheren Kommunikationskanälen. Sie sollten auch das Zeitintervall begrenzen, innerhalb dessen ein Authentifizierungsticket gültig bleibt, um der Spoofing-Bedrohung zu begegnen, die sich aus Replay-Angriffen ergeben kann, bei denen sich ein Angreifer des Cookies bemächtigt und mit seiner Hilfe unbefugten Zugriff zur Website verschafft. Eine Verkürzung des Zeitlimits des Cookies verhindert keine Replay-Angriffe, beschränkt jedoch den Zeitraum, der einem Angreifer zur Verfügung steht, um mithilfe des gestohlenen Cookies auf die Website zuzugreifen.

 

Autorisierung

Durch Autorisierung wird festgelegt, welche Vorgänge die authentifizierte Instanz durchführen und auf welche Ressourcen sie zugreifen darf. Ungeeignete oder schwache Autorisierung führt zur Offenlegung von Informationen und zu unbefugten Änderungen von Daten. Tiefenverteidigung ist das sicherheitstechnische Schlüsselprinzip, das Sie der Autorisierungsstrategie einer Anwendung zugrunde legen müssen.

Folgende Vorgehensweisen dienen zur Verbesserung der Autorisierung einer Webanwendung:

• Verwenden mehrerer Gatekeeper

• Beschränken des Benutzerzugriffs auf Systemressourcen

• Berücksichtigen der Autorisierungsgranularität

Verwenden mehrerer Gatekeeper

Auf dem Server besteht die Möglichkeit, mithilfe von IPSec-Richtlinien Beschränkungen für die Kommunikation zwischen Servern bereitzustellen. Eine IPSec-Richtlinie könnte beispielsweise festlegen, dass jeder Host außer einem benannten Webserver daran gehindert wird, eine Verbindung mit einem Datenbankserver herzustellen. Webberechtigungen und IP-/DNS-Beschränkungen (Internet Protocol/Domain Name System) werden vom IIS zur Verfügung gestellt. IIS-Webberechtigungen betreffen benutzerunabhängig alle Ressourcen, die über HTTP angefordert werden. Sie bieten keinen Schutz, wenn es einem Angreifer gelingt, sich beim Server anzumelden. Mit NTFS-Berechtigungen ist es möglich, Zugriffssteuerungslisten für einzelne Benutzer festzulegen. Darüber hinaus stehen ASP.NET URL-Autorisierung und Dateiautorisierung zusammen mit Prinzipalberechtigungs-Anforderungen zur Verfügung. Durch geeignete Kombination dieser Gatekeeper können Sie eine effektive Autorisierungsstrategie entwickeln.

Beschränken des Benutzerzugriffs auf Systemressourcen

Systemressourcen schließen Dateien, Ordner, Registrierungsschlüssel, Active Directory-Objekte, Datenbankobjekte, Ereignisprotokolle usw. ein. Definieren Sie mithilfe von Windows-Zugriffssteuerungslisten (ACLs), welche Benutzer auf welche Ressourcen zugreifen und welche Arten von Operationen sie durchführen können. Achten Sie insbesondere auf anonyme Internet-Benutzerkonten. Blockieren Sie diese mithilfe von ACLs für Ressourcen, die explizit den Zugriff durch anonyme Benutzer verweigern.

Weitere Informationen zum Blockieren anonymer Internet-Benutzerkonten mithilfe von Windows-ACLs finden Sie in Modul 16, "Schützen des Webservers".

Berücksichtigen der Autorisierungsgranularität

Es gibt drei verbreitete Autorisierungsmodelle mit jeweils variierenden Graden an Granularität und Skalierbarkeit.

Der Ansatz mit der höchsten Granularität beruht auf dem Identitätswechsel. Der Ressourcenzugriff erfolgt im Sicherheitskontext des Benutzers. Windows-ACLs für die geschützten Ressourcen (in der Regel Dateien oder Tabellen oder beides) legen fest, ob der Benutzer auf die Ressource zugreifen darf. Wenn eine Anwendung hauptsächlich den Zugriff auf benutzerspezifische Ressourcen ermöglicht, mag dieser Ansatz triftig sein. Er bietet den zusätzlichen Vorteil, dass Überwachungsfunktionen auf Betriebssystemebene auf allen Ebenen der Anwendung durchgeführt werden können, da der ursprüngliche Sicherheitskontext des Benutzers auf Betriebssystemebene zirkuliert und für den Ressourcenzugriff verwendet wird. Allerdings krankt der Ansatz an der schlechten Anwendungs-Skalierbarkeit, da ein wirksames Verbindungs-Pooling für den Datenbankzugriff nicht möglich ist. Aus diesem Grund ist dieser Ansatz am häufigsten bei Anwendungen zu finden, die in einem Intranet begrenzten Umfangs eingesetzt werden. Das Identitätswechselmodell ist in Abbildung 4.5 illustriert.

Abbildung 4.5
Das Identitätswechselmodell ermöglicht auf den Endbenutzer bezogene Autorisierungsgranularität

Der Ansatz mit der gröbsten Granularität, jedoch auch der höchsten Skalierbarkeit, verwendet für den Ressourcenzugriff die Prozessidentität der Anwendung. Dieser Ansatz unterstützt zwar das Pooling von Datenverbindungen, jedoch bedeutet er, dass die der Anwendungsidentität in der Datenbank gewährten Berechtigungen allgemein gelten, also ungeachtet der Identität des ursprünglichen Benutzerss. Die primäre Autorisierung wird innerhalb der mittleren logischen Schicht der Anwendung mithilfe von Rollen durchgeführt, die Benutzer mit identischen Berechtigungen innerhalb der Anwendung zu Gruppen zusammenfassen. Der Zugriff auf Klassen und Methoden wird auf der Grundlage der Rollenmitgliedschaft des Aufrufers beschränkt. Um den Abruf von Daten pro Benutzer zu unterstützen, besteht ein übliches Verfahren darin, eine Identitätsspalte in die Datenbanktabellen einzufügen und die Nutzung der abgerufenen Daten unter Verwendung von Abfrageparametern zu beschränken. Unter diesen Vorgaben können Sie beispielsweise auf Anwendungsebene (nicht auf Betriebssystemebene) die Identität des ursprünglichen Benutzers über die Parameter von gespeicherten Prozeduren an die Datenbank übergeben und Abfragen der folgenden Art formulieren:

SELECT Feld1, Feld2, Feld3 FROM Tabelle1 WHERE {Suchkriterien} AND 
Benutzername = @originalCallerUserName

Dieser Ansatz wird als Modell des vertrauenswürdigen Subsystems bzw. gelegentlich auch als Modell des vertrauenswürdigen Servers bezeichnet. In Abbildung 4.6 wird dieses Modell dagestellt.

Abbildung 4.6
Das Modell des vertrauenswürdigen Subsystems unterstützt das Pooling von Datenbankverbindungen

Als dritte Möglichkeit bietet sich an, einen begrenzten Satz von Identitäten für den Ressourcenzugriff zu verwenden und dabei die Rollenmitgliedschaft des Aufrufers zugrunde zu legen. Dieser Ansatz entspricht tatsächlich einer Mischung von Elementen der beiden zuvor beschriebenen Modelle. Die Zuordnung zwischen Aufrufern und Rollen erfolgt in der mittleren logischen Anwendungsschicht, und der Zugriff auf Klassen und Methoden wird auf der Grundlage der Rollenmitgliedschaft beschränkt. Spätere Ressourcenzugriffe werden unter Verwendung eines begrenzten Satzes von Identitäten durchgeführt, die auf Basis der Rollenmitgliedschaft des aktuellen Aufrufers festgelegt werden. Der Vorteil dieses Ansatzes besteht darin, dass separaten Anmeldungen bei der Datenbank Berechtigungen zugewiesen werden können und das Verbindungs-Pooling dennoch weiterhin wirksam mit mehreren Verbindungs-Pools genutzt werden kann. Allerdings hat dieser Vorteil seinen Preis, da das Erstellen mehrerer Thread-Zugriffstoken, die zur Einrichtung unterschiedlicher Sicherheitskontexte für den nachgeordneten Ressourcenzugriff unter Verwendung der Windows-Authentifizierung verwendet werden, einen Vorgang darstellt, der privilegierte Prozesskonten erfordert. Dies widerspricht dem Prinzip der geringsten Berechtigungen. Das hybride Modell mit mehreren Identitäten vertrauenswürdiger Dienste für spätere Ressourcenzugriffe wird in Abbildung 4.7 dargestellt.

Abbildung 4.7
Hybrides Modell

 

Konfigurationsverwaltung

Die Funktionalität der Konfigurationsverwaltung einer Anwendung sollte sorgfältig überlegt sein. Die meisten Anwendungen erfordern Schnittstellen, die es Inhalts-Entwicklern, Operatoren und Administratoren ermöglichen, die Anwendung zu konfigurieren und verschiedene Objekte, wie Webseiteninhalte, Benutzerkonten, Informationen von Benutzerprofilen und Datenbank-Verbindungszeichenfolgen, zu verwalten. Wie werden diese Verwaltungsschnittstellen geschützt, wenn die Remoteverwaltung unterstützt wird? Die Folgen einer Verletzung der Sicherheit einer Verwaltungsschnittstelle können gravierend sein, da der Angreifer häufig erfolgreich Administratorrechte erlangt und auf diese Weise direkten Zugriff auf die gesamte Website erhält.

Folgende Vorgehensweisen können zur Verbesserung der Sicherheit für die Konfigurationsverwaltung einer Webanwendung verwendet werden:

• Schützen der Verwaltungsschnittstellen

• Schützen der Konfigurationsspeicher

• Verwalten von getrennten Verwaltungsberechtigungen

• Verwenden von Prozess- und Dienstkonten mit geringsten Berechtigungen

Schützen der Verwaltungsschnittstellen

Es ist wichtig, dass die Funktionalität der Konfigurationsverwaltung nur autorisierten Operatoren und Administratoren zugänglich ist. Ein wesentliches Element zur Realisierung dieses Ziels ist es, eine strenge Authentifizierung für alle Verwaltungsschnittstellen zu erzwingen, beispielsweise durch Zertifikate.

Sie sollten nach Möglichkeit den Einsatz der Remoteverwaltung begrenzen oder völlig verhindern und dafür sorgen, dass sich Administratoren lokal anmelden. Wenn die Unterstützung der Remoteverwaltung erforderlich ist, sollten Sie aufgrund des vertraulichen Charakters der über die Verwaltungsschnittstellen übermittelten Daten verschlüsselte Kanäle verwenden, indem Sie beispielsweise auf die SSL- oder VPN-Technologie zurückgreifen. Außerdem empfiehlt es sich, die Remoteverwaltung auf Computer des internen Netzwerks zu beschränken, um die erwähnten Risiken weiter einzudämmen.

Schützen der Konfigurationsspeicher

Textbasierte Konfigurationsdateien, die Registrierung und Datenbanken sind übliche Optionen zur Speicherung von Konfigurationsdaten einer Anwendung. Vermeiden Sie nach Möglichkeit, mit Konfigurationsdateien zu arbeiten, die im webbasierten Speicher der Anwendung abgelegt sind, um mögliche Serverkonfigurationsrisiken zu verhindern, die zum Download von Konfigurationsdateien führen können. Unabhängig vom gewählten Ansatz sollen Sie immer den Zugriff auf den Konfigurationsspeicher schützen, beispielsweise durch die Verwendung von Windows-ACLs oder Datenbankberechtigungen. Vermeiden Sie es außerdem, geheime Informationen, wie Datenbank-Verbindungszeichenfolgen oder Anmeldeinformationen für Konten, im Klartext zu speichern. Schützen Sie diese Objekte durch Verschlüsselung und beschränken Sie anschließend den Zugriff auf den Registrierungsschlüssel, die Datei oder die Tabelle, in dem oder der die verschlüsselten Daten enthalten sind.

Verwalten von getrennten Verwaltungsberechtigungen

Wenn die Funktionalität, welche von der Konfigurationsverwaltung einer Anwendung unterstützt wird, in Abhängigkeit von der Rolle des Administrators variiert, bietet es sich an, jede Rolle einzeln entsprechend ihrer Funktionalität zu autorisieren. So sollte beispielsweise die für das Aktualisieren der statischen Inhalte einer Website verantwortliche Person nicht berechtigt sein, das Kreditlimit eines Kunden zu ändern.

Verwenden von Prozess- und Dienstkonten mit geringsten Berechtigungen

Ein wichtiger Aspekt der Anwendungskonfiguration betrifft die zur Ausführung des Webserverprozesses verwendeten Prozesskonten und die Dienstkonten für den Zugriff auf nachgeordnete Ressourcen und Systeme. Stellen Sie sicher, dass diese Konten mit geringsten Berechtigungen eingerichtet sind. Wenn ein Angreifer erfolgreich die Kontrolle über einen Prozess gewinnt, sollte die Prozessidentität nur über sehr beschränkten Zugriff auf das Dateisystem und andere Systemressourcen verfügen, um den möglichen Schaden zu begrenzen.

 

Vertrauliche Daten

Anwendungen, die mit privaten Benutzerdaten (Kreditkartennummern, medizinischen Daten usw.) arbeiten, sollten besondere Schritte unternehmen, um sicherzustellen, dass diese Daten geschützt sind und unverändert bleiben. Darüber hinaus müssen geheime Informationen, die von der Anwendungsimplementierung genutzt werden, beispielsweise Kennwörter und Datenbank-Verbindungszeichenfolgen, ebenfalls geschützt werden. Die Sicherheit vertraulicher Daten ist ein Problem, solange die Daten in permanentem Speicher abgelegt sind und über das Netzwerk ausgetauscht werden.

Geheime Daten

Zu den geheimen Daten zählen unter anderem Kennwörter, Datenbank-Verbindungszeichenfolgen und Kreditkartennummern. Folgende Vorgehensweisen können zur Verbesserung der Sicherheit bei der Handhabung geheimer Daten durch eine Webanwendung verwendet werden:

• Vermeiden der Speicherung von geheimen Daten

• Vermeiden der Speicherung von geheimen Daten im Code

• Vermeiden der Speicherung von Datenbankverbindungen, Kennwörtern oder Schlüsseln im Klartext

• Vermeiden der Speicherung von geheimen Daten in der lokalen Sicherheitsinstanz

• Verschlüsseln von geheimen Daten mit DPAPI

Vermeiden der Speicherung von geheimen Daten

Es ist unmöglich, geheime Daten durch ein Programm vollständig sicher zu speichern. Jeder Administrator, der physischen Zugang zum Server hat, kann auf die Daten zugreifen. Beispielsweise ist es nicht erforderlich, ein Kennwort oder ähnliches direkt zu speichern, wenn Sie nur überprüfen müssen, ob ein Benutzer diese Kennwort kennt. In diesem Fall können Sie einen Hashwert speichern, der das Kennwort repräsentiert, den Hashwert des vom Benutzer eingegebenen Kennworts berechnen, die Werte vergleichen und dadurch überprüfen, ob der Benutzer das richtige Kennwort eingegeben hat.

Vermeiden der Speicherung von geheimen Daten im Code

Speichern Sie keine geheimen Informationen direkt im Code. Selbst wenn der Quellcode nicht auf dem Webserver offen gelegt wird, besteht die Möglichkeit, Zeichenfolgenkonstanten aus den kompilierten ausführbaren Dateien zu extrahieren. Über eine unzureichend geschützte Konfiguration kann ein Angreifer die Programmdatei abrufen.

Vermeiden der Speicherung von Datenbankverbindungen, Kennwörtern oder Schlüsseln im Klartext

Vermeiden Sie es, geheime Informationen, wie Datenbankverbindungszeichenfolgen, Kennwörter und Schlüssel, im Klartextformat zu speichern. Nutzen Sie Verschlüsselung, und speichern Sie die verschlüsselten Zeichenfolgen.

Vermeiden der Speicherung von geheimen Daten in der lokalen Sicherheitsinstanz

Eine Speicherung in der lokalen Sicherheitsinstanz (LSA, Local Security Authority) sollte vermieden werden, da die Anwendung für den Zugriff Administratorrechte benötigt. Dies verletzt das sicherheitstechnische Kernprinzip, nur mit den geringsten Berechtigungen zu arbeiten. Außerdem kann die LSA geheime Daten nur in einer beschränkten Anzahl von Plätzen speichern. Einen besseren Ansatz stellt die Verwendung von DPAPI dar, die in Microsoft Windows® 2000 und höheren Versionen des Betriebssystems zur Verfügung steht.

Verschlüsseln von geheimen Daten mit DPAPI

Speichern Sie geheime Daten, beispielsweise Datenbank-Verbindungszeichenfolgen oder Anmeldeinformationen für Dienstkonten, mit DPAPI. Der Hauptvorteil bei der Verwendung von DPAPI besteht darin, dass die Verwaltung des Verschlüsselungs- bzw. Entschlüsselungsschlüssels in den Händen der Systemumgebung liegt und kein Problem der Anwendung darstellt. Der Schlüssel wird in Abhängigkeit von den an die DPAPI-Funktionen übergebenen Parametern einem Windows-Benutzerkonto oder einem bestimmten Computer zugeordnet.

DPAPI eignet sich sehr gut zum Verschlüsseln von Informationen, die manuell wiederhergestellt werden können, wenn die Hauptschlüssel verloren gehen. Ein solcher Verlust kann beispielsweise eintreten, wenn ein beschädigter Server eine Neuinstallation des Betriebssystems erfordert. Daten, die nicht wiederhergestellt werden können, da deren Klartextwert (beispielsweise die Einzelheiten einer Kundenkreditkarte) nicht bekannt sind, erfordern einen anderen Ansatz, der herkömmliche, auf symmetrischen Schlüsseln basierende, kryptografische Verfahren wie Dreifach-DES verwendet.

Weitere Informationen zur Verwendung von DPAPI durch Webanwendungen finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Webseiten und -Steuerelemente".

Vertrauliche Daten einzelner Benutzer

Vertrauliche Daten wie Anmeldeinformationen und private Daten auf Anwendungsebene wie Kreditkartennummern und Nummern von Bankkonten müssen geschützt werden. Die Schlüsselelemente dabei sind Datenschutz durch Verschlüsselung und Datenintegrität mit Nachrichtenauthentifizierungscodes.

Folgende Vorgehensweisen können zur Verbesserung der Sicherheit für die vertraulichen Daten einzelner Benutzer einer Webanwendung verwendet werden:

• Abrufen von vertraulichen Daten bei Bedarf

• Verschlüsseln der Daten oder Schützen des Kommunikationskanals

• Vermeiden der Speicherung von vertraulichen Daten in permanenten Cookies

• Vermeiden der Übermittlung von vertraulichen Daten mit dem HTTP-GET-Protokoll

Abrufen von vertraulichen Daten bei Bedarf

Der bevorzugte Ansatz ist es, vertrauliche Daten nur bei Bedarf abzurufen, statt diese permanent zu speichern oder im Cache zwischenzuspeichern. Beispielsweise rufen Sie die verschlüsselten geheimen Daten ab, wenn diese erforderlich sind, entschlüsseln und verwenden sie, und löschen anschließend den Speicher (die Variable), in dem die Daten im Klartext enthalten waren. Bei Leistungsproblemen sollten Sie folgende Optionen in Betracht ziehen:

• Zwischenspeichern der verschlüsselten geheimen Daten.

• Zwischenspeichern der nicht verschlüsselten geheimen Daten.

Zwischenspeichern der verschlüsselten geheimen Daten

Rufen Sie die geheimen Informationen beim Laden der Anwendung ab und legen Sie die verschlüsselten Daten in einem Zwischenspeicher ab, um sie bei Verwendung durch die Anwendung zu entschlüsseln. Löschen Sie die Klartextkopie, sobald diese nicht mehr benötigt wird. Dieser Ansatz vermeidet Zugriffe auf den Datenspeicher für die einzelnen Anforderungen.

Zwischenspeichern der nicht verschlüsselten geheimen Daten

Mit dieser Option vermeiden Sie den Mehraufwand, der sich aus dem mehrfachen Entschlüsseln der geheimen Daten ergibt, und speichern eine Klartextkopie der Daten im Arbeitsspeicher. Dieser Ansatz bietet die geringste Sicherheit, jedoch eine optimale Leistung. Vergleichen Sie die Leistungen der anderen Ansätze, bevor Sie annehmen, dass der Leistungsgewinn das zusätzliche Sicherheitsrisiko wert ist.

Verschlüsseln der Daten oder Schützen des Kommunikationskanals

Wenn Sie vertrauliche Daten über das Netzwerk an einen Client senden, sollten Sie die Daten verschlüsseln oder den Übertragungsweg schützen. Eine übliche Technik ist es, SSL für die Verbindungen zwischen Clients und Webserver zu verwenden. Es wird zunehmend üblich, Verbindungen zwischen Servern mit IPSec zu schützen. Für den Schutz vertraulicher Daten, die verschiedene, zwischengeschaltete Instanzen (beispielsweise SOAP-Nachrichten des Webdienstes) passieren, sollten Sie eine Verschlüsselung auf Nachrichtenebene verwenden.

Vermeiden der Speicherung von vertraulichen Daten in permanenten Cookies

Vertrauliche Daten sollten nicht in permanenten Cookies gespeichert werden. Wenn Sie Daten im Klartext speichern, kann der Endbenutzer die Daten lesen und modifizieren. Bei einer Verschlüsselung der Daten kann die Verwaltung der Schlüssel zu einem Problem werden. Angenommen, das Zeitlimit des zur Verschlüsselung der Daten im Cookie verwendeten Schlüssels ist abgelaufen und der Schlüssel wurde ungültig. In diesem Fall kann der neue Schlüssel das permanente Cookie, das der Browser vom Client weitergeleitet hat, nicht entschlüsseln.

Vermeiden der Übermittlung von vertraulichen Daten mit dem HTTP-GET-Protokoll

Sie sollten es vermeiden, vertrauliche Daten mithilfe des HTTP-GET-Protokolls zu speichern, da dieses Protokoll zur Übermittlung der Daten Abfragezeichenfolgen verwendet. In Abfragezeichenfolgen enthaltene vertrauliche Daten können nicht geschützt werden. Außerdem werden Abfragezeichenfolgen häufig vom Server protokolliert.

 

Sitzungsverwaltung

Webanwendungen verwenden das statusfreie HTTP-Protokoll. Daher ist die Sitzungsverwaltung eine Angelegenheit, die auf Anwendungsebene behandelt werden muss. Die Sicherheit von Sitzungen ist von wesentlicher Bedeutung für die Gesamtsicherheit einer Anwendung.

Folgende Vorgehensweisen können zur Verbesserung der Sicherheit für die Sitzungsverwaltung einer Webanwendung verwendet werden:

• Schützen von Sitzungsauthentifizierungscookies mit SSL

• Verschlüsseln des Inhalts der Authentifizierungs-Cookies

• Begrenzen der Lebensdauer von Sitzungen

• Schützen des Sitzungsstatus vor nicht autorisiertem Zugriff

Schützen von Sitzungsauthentifizierungscookies mit SSL

Übermitteln Sie Authentifizierungs-Cookies nicht über normale HTTP-Verbindungen. Aktivieren Sie für Authentifizierungscookies die Eigenschaft Secure des Cookies, um Browser anzuweisen, Cookies nur über HTTPS-Verbindungen an den Server zurückzusenden. Weitere Informationen finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente".

Verschlüsseln des Inhalts der Authentifizierungs-Cookies

Verschlüsseln Sie den Inhalt eines Cookies auch dann, wenn Sie SSL verwenden. Damit hindern Sie einen Angreifer daran, den Inhalt des Cookies anzuzeigen oder zu ändern, wenn er versucht, das Cookie durch einen XSS-Angriff zu stehlen. In diesem Fall könnte der Angreifer das Cookie weiterhin für den Zugriff auf die Anwendung nutzen, dies allerdings nur innerhalb des für das Cookie definierten Gültigkeitzeitraums.

Begrenzen der Lebensdauer von Sitzungen

Verkürzen Sie die Lebensdauer von Sitzungen, um das Risiko von Sitzungsübernahmen und Replay-Angriffen zu mildern. Je kürzer eine Sitzung, desto weniger Zeit bleibt einem Angreifer, sich in den Besitz des Cookies zu bringen und dieses für den Zugriff auf die Anwendung zu verwenden.

Schützen des Sitzungsstatus vor nicht autorisiertem Zugriff

Überlegen Sie, wie der Sitzungsstatus gespeichert werden sollte. Um eine optimale Leistung zu erreichen, können Sie den Sitzungsstatus im Prozessadressraum der Webanwendung speichern. Jedoch ist durch diesen Ansatz die Skalierbarkeit beschränkt und er hat Auswirkungen in Webserverfarm-Szenarios, in denen verschiedene Anfragen eines Benutzers nicht immer vom selben Server behandelt werden. Für ein solches Szenario ist ein prozessexterner Statusspeicher auf einem dedizierten Server oder ein permanenter Statusspeicher in einer gemeinsam genutzten Datenbank erforderlich. ASP.NET unterstützt alle drei Optionen.

Um das Abhörrisiko zu mildern, sollten Sie die Netzwerkverbindung zwischen der Webanwendung und dem Statusspeicher mit IPSec oder SSL schützen. Berücksichtigen Sie auch, wie die Webanwendung durch den Statusspeicher authentifiziert werden soll. Verwenden Sie nach Möglichkeit immer die Windows-Authentifizierung, um die Klartextübermittlung von Authentifizierungsinformationen über das Netzwerk zu vermeiden und die Vorteile der sicheren Kontenrichtlinien von Windows zu nutzen.

 

Kryptografie

Kryptografie bietet in ihrer grundlegenden Form die folgenden Möglichkeiten:

• Datenschutz (Vertraulichkeit). Dieser Dienst gewährleistet die Vertraulichkeit von geheimen Informationen.

• Nichtablehnung (Authentizität). Dieser Dienst stellt sicher, dass ein Benutzer das Senden einer bestimmten Nachricht nicht leugnen kann.

• Fälschungssicherheit (Integrität). Dieser Dienst verhindert das Ändern von Daten.

• Authentifizierung. Dieser Dienst bestätigt die Identität des Absenders einer Nachricht.

Webanwendungen verwenden Kryptografie häufig, um Daten in permanenten Speichern oder während der Übermittlung über Netzwerke zu schützen. Folgende Vorgehensweisen können zur Verbesserung der Sicherheit einer Webanwendung durch Kryptografie verwendet werden:

• Vermeiden der Entwicklung von eigenen kryptografischen Verfahren

• Zeitnahes Speichern von unverschlüsselten Daten beim Algorithmus

• Verwenden des richtigen Algorithmus und der richtigen Schlüsselgröße

• Schützen der Verschlüsselungsschlüssel

Vermeiden der Entwicklung von eigenen kryptografischen Verfahren

Die erfolgreiche Entwicklung kryptografischer Algorithmen und Routinen ist bekanntermaßen ein schwieriges Unterfangen. Aus diesem Grund sollten Sie die erprobten und bewährten kryptografischen Dienste der Plattform nutzen. Dies schließt das .NET Framework und das zugrunde liegende Betriebssystem ein. Vermeiden Sie es, eigene Implementierungen zu entwickeln, da diese häufig nur schwachen Schutz bieten.

Zeitnahes Speichern von unverschlüsselten Daten beim Algorithmus

Wenn Sie Klartext an einen Algorithmus übergeben, rufen Sie die Daten erst ab, wenn diese erforderlich sind, und speichern Sie diese in möglichst wenigen Variablen.

Verwenden des richtigen Algorithmus und der richtigen Schlüsselgröße

Es muss sichergestellt sein, dass Sie für jede Aufgabe den richtigen Algorithmus auswählen und darauf achten, eine Schlüsselgröße zu verwenden, die einen ausreichenden Grad an Sicherheit bietet. Größere Schlüssel erhöhen in der Regel die Sicherheit. Die folgende Liste fasst die wichtigen Algorithmen und die von ihnen verwendeten Schlüsselgrößen zusammen:

• DES (Data Encryption Standard), 64-Bit-Schlüssel (8 Byte)

• Dreifach-DES, 128-Bit- oder 192-Bit-Schlüssel (16 oder 24 Byte)

• Rijndael 128, 256-Bit-Schlüssel (16 bis 32 Byte)

• RSA 384, 16.384-Bit-Schlüssel (48 bis 2.048 Byte)

Zur Verschlüsselung großer Datenmengen sollten Sie den symmetrischen Verschlüsselungsalgorithmus Dreifach-DES verwenden. Für eine langsamere und stärkere Verschlüsselung großer Datenmengen empfiehlt sich die Verwendung des Rijndael-Verfahrens. Zur Verschlüsselung von Daten, die eher für kürzere Zeiträume gespeichert werden sollen, können Sie einen schnelleren, jedoch schwächeren Algorithmus wie DES in Betracht ziehen. Digitale Signaturen sollten mit dem RSA- (Rivest, Shamir und Adleman) oder dem DSA-Verfahren (Digital Signature Algorithm) verschlüsselt werden. Für das Hashing eignet sich der SHA 1.0-Algorithmus (Secure Hash Algorithm). Für verschlüsselte Hashwerte ist HMAC SHA 1.0 (Hash-based Message Authentication Code) zu verwenden.

Schützen der Verschlüsselungsschlüssel

Ein Verschlüsselungsschlüssel ist eine geheime Zahl, die als Eingabe für Verschlüsselungs- und Entschlüsselungsprozesse verwendet wird. Damit verschlüsselte Daten sicher bleiben, müssen Sie den Schlüssel schützen. Wenn sich ein Angreifer Zugriff auf den Entschlüsselungsschlüssel verschafft, ist der Schutz Ihrer verschlüsselten Daten nicht länger gewährleistet.

Folgende Vorgehensweisen können dazu verwendet werden, Verschlüsselungsschlüssel besser zu schützen.

• Vermeiden eigener Schlüsselverwaltung mit DPAPI

• Regelmäßiges Wechseln der Schlüssel

Vermeiden eigener Schlüsselverwaltung mit DPAPI

Wie bereits erwähnt, ist einer der wesentlichen Vorteile von DPAPI, dass das Problem der Schlüsselverwaltung vom Betriebssystem gelöst wird. Der von DPAPI verwendete Schlüssel wird von dem Kennwort abgeleitet, das mit dem Prozesskonto verknüpft ist, welches die DPAPI-Funktionen aufruft. Durch die Verwendung von DPAPI verlagern Sie also die Last der Schlüsselverwaltung auf das Betriebssystem.

Regelmäßiges Wechseln der Schlüssel

Generell wächst die Wahrscheinlichkeit, dass ein statisches Geheimnis im Laufe der Zeit enttarnt wird. In diesem Zusammenhang sind folgende Fragen zu beachten: Haben Sie es irgendwo schriftlich festgehalten? Gibt es Änderungen (Stellenwechsel, Verlassen des Unternehmens) beim verantwortlichen Personal, das für die Verwaltung der geheimen Daten zuständig ist? Vermeiden Sie einen zu häufigen Gebrauch von Schlüsseln.

 

Parametermanipulation

Bei Angriffen durch Parametermanipulation modifiziert der Angreifer die zwischen einem Client und der Webanwendung zirkulierenden Daten. Dabei kann es sich um Daten handeln, die mithilfe von Abfragezeichenfolgen, Formularfeldern, Cookies oder in HTTP-Headern gesendet werden. Folgende Vorgehensweisen können dazu verwendet werden, eine Webanwendung vor Parametermanipulationen zu schützen:

• Verschlüsseln von sicherheitsrelevanten Cookie-Statusinformationen

• Sicherstellen, dass Benutzer die Prüfmechanismen nicht umgehen

• Überprüfen aller Werte, die vom Client gesendet werden

• Misstrauen der Informationen in HTTP-Headern

Verschlüsseln von sicherheitsrelevanten Cookie-Statusinformationen

Cookies können vertrauliche Daten (wie Sitzungskennungen) oder Daten enthalten, die für den Autorisierungsvorgang auf dem Server verwendet werden. Diese Art von Daten schützen Sie vor unbefugter Manipulation, indem Sie kryptografische Verfahren einsetzen, um den Inhalt des Cookies zu verschlüsseln.

Sicherstellen, dass Benutzer die Prüfmechanismen nicht umgehen

Stellen Sie sicher, dass Benutzer die Prüfmechanismen nicht umgehen, indem sie Parameter entsprechend manipulieren. URL-Parameter können von Endbenutzern im Adressfeld des Browsers modifiziert werden. Beispiel: Der URL http://www.<IhreSite>/<IhreAnwendung>/sessionId=10 enthält den Wert 10, der durch eine Zufallszahl ersetzt werden kann, um andere Ausgaben zu empfangen. Vergewissern Sie sich, dass Sie Modifikationen dieser Art im Code auf dem Server überprüfen, nicht im JavaScript-Code auf dem Client, da dieser im Browser deaktiviert werden kann.

Überprüfen aller Werte, die vom Client gesendet werden

Beschränken Sie die Felder, in die der Benutzer Werte eingeben oder deren Inhalt er ändern kann, und überprüfen Sie alle Werte, die vom Client stammen. Wenn Sie Formularfelder mit vordefinierten Werten verwenden, können diese möglicherweise durch die Benutzer geändert und übermittelt werden, um unterschiedliche Ergebnisse zu empfangen. Achten Sie darauf, nach Möglichkeit nur unschädliche Werte zuzulassen. Wenn ein Eingabefeld beispielsweise zur Aufnahme von Länderinformationen dient, sollten nur Postleitzahlen als Eingaben zugelassen sein.

Misstrauen der Informationen in HTTP-Headern

HTTP-Header werden zu Beginn der Übermittlung von HTTP-Anfragen und -Antworten gesendet. In einer Webanwendung sollten keine sicherheitsrelevanten Entscheidungen aufgrund von Informationen aus HTTP-Headern getroffen werden, da es für Angreifer sehr einfach ist, diese Header zu manipulieren. Beispiel: Das Header-Feld referer enthält den URL der Webseite, von der aus die Anfrage gestartet wurde. Treffen Sie keine Sicherheitsentscheidungen aufgrund des Wertes im Feld referer, um beispielsweise zu ermitteln, ob die Anfrage von einer Seite stammt, die von der Webanwendung erstellt wurde, da der Inhalt dieses Feldes gefälscht sein kann.

 

Ausnahmeverwaltung

Eine sichere Ausnahmeverwaltung kann dabei helfen, bestimmte DoS-Angriffe auf Anwendungsebene zu verhindern. Zudem vermeidet sie, dass wertvolle Systeminformationen mit großem Nutzen für potenzielle Angreifer an den Client zurückgegeben werden. Ohne eine hinreichende Ausnahmeverwaltung kann es geschehen, dass Informationen wie Einzelheiten eines Datenbankschemas, Betriebssystemversionen, Daten der Stapelablaufverfolgung, Dateinamen und Pfadinformationen sowie andere nützliche Daten an den Client zurückgesendet werden.

Ein sinnvoller Ansatz besteht darin, eine zentrale Lösung für die Ausnahmeverwaltung und Protokollierung zu entwerfen und Hooks zur Verfügung zu stellen, die eine Verbindung zur Ausnahmeverwaltung ermöglichen, um Systemadministratoren bei der Instrumentierung und zentralen Überwachung zu helfen.

Folgende Vorgehensweisen können dazu verwendet werden, die Ausnahmeverwaltung einer Webanwendung besser zu schützen:

• Vermeiden der Verbreitung von Informationen zum Client

• Protokollieren ausführlicher Fehlermeldungen

• Abfangen von Ausnahmen

Vermeiden der Verbreitung von Informationen zum Client

Beim Auftreten eines Fehlers sollten Sie darauf achten, keine Informationen offen zu legen, die zu einer Sicherheitslücke führen. Vermeiden Sie beispielsweise die Offenlegung von Einzelheiten der Stapelablaufverfolgung, da diese bei Verwendung von Debugversionen der Anwendung Funktionsnamen und Zeilennummern enthalten können. (Derartige Versionen sollten auf Produktionsservern nicht zum Einsatz kommen.) Stattdessen sollten Sie allgemeine Fehlermeldungen an den Client zurückgeben.

Protokollieren ausführlicher Fehlermeldungen

Schreiben Sie ausführliche Fehlermeldungen in das Fehlerprotokoll. Die Benutzer eines Dienstes oder einer Anwendung sollten nur minimale Informationen empfangen, beispielsweise eine allgemeine Fehlermeldung und eine kundenbezogene Fehlerprotokollkennung, die anschließend zur Identifizierung der ausführlichen Meldung in den Ereignisprotokollen verwenden werden kann. Stellen Sie sicher, dass keine Kennwörter oder andere vertrauliche Daten protokolliert werden.

Abfangen von Ausnahmen

Verwenden Sie eine strukturierte (hierarchische) Ausnahmeverwaltung, und sorgen Sie dafür, dass die Software Ausnahmebedingungen abfängt. Auf diese Weise verhindern Sie, dass die Anwendung in einem inkonsistentem Zustand belassen wird, der zur Offenlegung von Informationen führen kann. Außerdem helfen diese Maßnahmen beim Schutz der Anwendung vor DoS-Angriffen. Legen Sie fest, auf welche Weise Ausnahmen innerhalb der Anwendung weitergeleitet werden sollen, und berücksichtigen Sie insbesondere die Vorgänge an den Außengrenzen der Anwendung.

Weitere Informationen zum Entwerfen und Implementieren eines Gerüsts zur Ausnahmeverwaltung für .NET-Anwendungen finden Sie im MSDN-Artikel "Exception Management Architecture Guide" unter der Adresse https://msdn.microsoft.com/library/en-us/dnbda/html/exceptdotnet.asp.

 

Überwachen und Protokollieren

Sie sollten Aktivitäten auf allen Ebenen der Anwendung überwachen und protokollieren. Protokolle sind nützlich, wenn es darum geht, verdächtige Aktivitäten zu entdecken. Sie bieten häufig frühe Anzeichen für einen umfassenden Angriff und helfen bei der Behandlung von Bedrohungen durch Ablehnungen, also der Möglichkeit, dass Benutzer ihre Aktionen verweigern. Protokolldateien können bei juristischen Auseinandersetzungen erforderlich sein, um das Fehlverhalten von Personen nachzuweisen. Generell erweisen sich Überwachungsmaßnahmen als besonders überzeugend, wenn die Protokollmeldungen zur gleichen Zeit erzeugt werden, zu der der Ressourcenzugriff erfolgt, und von denselben Routinen, die auf die Ressource zugreifen.

Folgende Vorgehensweisen können zur Verbesserung der Sicherheit einer Webanwendung verwendet werden:

• Überwachen und Protokollieren von Zugriffen auf allen Anwendungsebenen

• Berücksichtigen des Flusses der Identitätsinformationen

• Protokollieren von Schlüsselereignissen

• Schützen von Protokolldateien

• Regelmäßiges Sichern und Analysieren der Protokolldateien

Überwachen und Protokollieren von Zugriffen in allen Anwendungsschichten

Überwachen und protokollieren Sie Zugriffe auf allen Ebenen der Anwendung, um dem Ziel der Nichtablehnung zuzuarbeiten. Verwenden Sie eine Kombination aus Protokollierung auf Anwendungsebene und plattformeigenen Überwachungsfunktionen (beispielsweise den entsprechenden Funktionen von Windows, IIS und SQL Server).

Berücksichtigen des Flusses der Identitätsinformationen

Beachten Sie, wie die Anwendung die Identität von aufrufenden Instanzen zwischen mehreren Ebenen der Anwendung weiterleitet. Dabei haben Sie zwei grundlegende Optionen zur Auswahl. Sie können die Identität des Benutzers auf Betriebssystemebene unter Verwendung der Delegierungsfunktion des Kerberos-Protokolls zirkulieren lassen. Dies ermöglicht Ihnen eine Überwachung auf Betriebssystemebene. Der Nachteil dieses Ansatzes: Er beeinträchtigt die Skalierbarkeit, da er ein effektives Pooling von Datenbankverbindungen innerhalb der mittleren Schicht ausschließt. Wahlweise können Sie die Identität des Aufrufers auch auf Anwendungsebene zirkulieren lassen und vertrauenswürdige Identitäten verwenden, um auf Back-End-Ressourcen zuzugreifen. Bei diesem Ansatz müssen Sie der mittleren Schicht vertrauen, und er birgt ein potenzielles Risiko hinsichtlich der Ablehnungen. Sie sollten Überwachungsprotokolle innerhalb der mittleren Schicht erzeugen, die zu Back-End-Überwachungsdaten in Beziehung gesetzt werden können. Zu diesem Zweck muss die Synchronisierung der Serveruhren sichergestellt sein. Microsoft Windows 2000 und Active Directory erledigen dies automatisch für Sie.

Protokollieren von Schlüsselereignissen

Zu den Typen von Ereignissen, die protokolliert werden sollten, gehören erfolgreiche und fehlgeschlagene Anmeldeversuche, Änderungen an Daten, der Abruf von Daten, Vorgänge der Netzwerkkommunikation und Verwaltungsfunktionen (beispielsweise das Aktivieren oder Deaktivieren der Protokollierung). Protokolleinträge sollten den Zeitpunkt des Ereignisses, den Ort des Auftretens einschließlich des Computernamens, die Identität des aktuellen Benutzers, die Identität des Prozesses, der das Ereignis ausgelöst hat, und eine ausführliche Beschreibung des Ereignisses enthalten.

Schützen von Protokolldateien

Schützen Sie die Protokolldateien mithilfe von Windows-ACLs, und beschränken Sie den Zugriff auf die Dateien. Dies erschwert es Angreifern, den Inhalt von Protokolldateien zu verfälschen, um ihre Spuren zu verwischen. Minimieren Sie die Anzahl der Personen, die die Protokolldateien bearbeiten dürfen. Autorisieren Sie den Zugriff nur für hochgradig vertrauenswürdige Konten, beispielsweise von Administratoren.

Regelmäßiges Sichern und Analysieren der Protokolldateien

Die Protokollierung von Aktivitäten bietet keinen Nutzen, wenn die Protokolldateien nicht analysiert werden. Protokolldateien sollten regelmäßig von Produktionsservern entfernt werden. Die Häufigkeit des Entfernens richtet sich nach dem Umfang der Anwendungsaktivitäten. Ihr Entwurf sollte berücksichtigen, auf welche Weise die Protokolldateien abgerufen und zu Analysezwecken auf Offlineserver verschoben werden. Alle zu diesem Zweck auf dem Webserver zusätzlich geöffneten Protokolle und Ports müssen zuverlässig blockiert werden.

 

Zusammenfassung der Entwurfsrichtlinien

In Tabelle 4.1 werden die in diesem Modul vorgestellten Entwurfsrichtlinien zusammengefasst und nach den Sicherheitsrisiken für Anwendungen gegliedert.

Tabelle 4.1. Entwurfsrichtlinien für sichere Webanwendungen

Risikokategorie	Richtlinien
Eingabeüberprüfung	Vertrauen Sie keinen Eingaben, erwägen Sie eine zentrale Eingabeüberprüfung. Verlassen Sie sich nicht auf Überprüfungen auf dem Client. Achten Sie sorgfältig auf Kanonisierungsprobleme. Verbessern Sie die Sicherheit durch Beschränkung, Zurückweisung und Bereinigung der Eingaben Überprüfen Sie Eingaben auf Typ, Länge, Format und Wertebereich.
Authentifizierung	Unterteilen Sie die Website in einen anonymen, einen identifizierten und einen authentifizierten Bereich. Verwenden Sie sichere Kennwörter. Unterstützen Sie die Verwendung von Zeitlimits für Kennwörter und die Fähigkeit zur Deaktivierung von Konten. Speichern Sie keine Sicherheitsinformationen (verwenden Sie stattdessen einmal verwendbare Hashwerte in Kombination mit Zufallszahlen). Verschlüsseln Sie Kommunikationskanäle, um Authentifizierungstoken zu schützen. Übermitteln Sie Authentifizierungs-Cookies für Formulare nur über HTTPS-Verbindungen.
Autorisierung	Verwenden Sie nur Konten mit geringsten Berechtigungen. Berücksichtigen Sie die Autorisierungsgranularität. Erzwingen Sie die Trennung von Berechtigungen. Beschränken Sie den Benutzerzugriff auf Systemressourcen.
Konfigurationsverwaltung	Verwenden Sie Prozess- und Dienstkonten mit geringsten Berechtigungen. Speichern Sie Sicherheitsinformationen nicht im Klartext. Verwenden Sie eine strenge Authentifizierung und Autorisierung für Verwaltungsschnittstellen. Verwenden Sie nicht die LSA. Schützen Sie den zur Remoteverwaltung verwendeten Kommunikationskanal. Vermeiden Sie es, vertrauliche Daten im webbasierten Speicher abzulegen.
Vertrauliche Daten	Vermeiden Sie es, geheime Informationen zu speichern. Verschlüsseln Sie vertrauliche Daten während der Netzwerkübertragung. Schützen Sie die Kommunikationskanäle. Stellen Sie strenge Zugriffskontrollen für Speicherorte zur Aufnahme vertraulicher Daten zur Verfügung. Speichern Sie vertrauliche Daten nicht in permanenten Cookies. Übermitteln Sie keine vertraulichen Daten mit dem HTTP-GET-Protokoll.
Sitzungsverwaltung	Begrenzen Sie die Lebensdauer von Sitzungen. Schützen Sie die Kommunikationskanäle. Verschlüsseln Sie den Inhalt der Authentifizierungs-Cookies. Schützen Sie den Sitzungsstatus vor unbefugtem Zugriff.
Kryptografie	Entwickeln Sie keine eigenen kryptografischen Verfahren. Verwenden Sie erprobte und bewährte Plattformfunktionen. Halten Sie unverschlüsselte Daten nahe beim Algorithmus. Wählen Sie den passenden Algorithmus und die richtige Schlüsselgröße aus. Verwenden Sie DPAPI, um sich eine eigene Schlüsselverwaltung zu ersparen. Wechseln Sie die Schlüssel in periodischen Abständen. Speichern Sie die Schlüssel an einem Speicherort mit beschränktem Zugriff.
Parametermanipulation	Verschlüsseln Sie sicherheitsrelevante Cookie-Statusinformationen. Vertrauen Sie keinen Feldern, die der Client manipulieren kann (Abfragezeichenfolgen, Formularfelder, Cookies oder HTTP-Header). Überprüfen Sie alle Werte, die vom Client gesendet werden.
Ausnahmeverwaltung	Verwenden Sie eine strukturierte Ausnahmeverwaltung. Legen Sie keine sicherheitsrelevanten Informationen der Anwendungsimplementierung offen. Protokollieren Sie keine privaten Daten wie Kennwörter. Erwägen Sie die Implementierung eines Gerüsts für eine zentrale Ausnahmeverwaltung.
Überwachen und Protokollieren	Identifizieren Sie böswilliges Verhalten. Informieren Sie sich, woran Sie normalen, unschädlichen Netzwerkverkehr erkennen können. Überwachen und protokollieren Sie Aktivitäten über alle Anwendungsschichten hinweg. Schützen Sie den Zugriff auf Protokolldateien. Erstellen Sie Sicherheitskopien der Protokolldateien und analysieren Sie diese regelmäßig.

 

Zusammenfassung

Das Kriterium der Sicherheit sollte jede Phase des Produktentwicklungszyklus durchdringen und ein Schwerpunkt des Anwendungsentwurfs sein. Widmen Sie dem Entwurf einer zuverlässigen Authentifizierungs- und Autorisierungsstrategie besondere Aufmerksamkeit. Bedenken Sie auch, dass die Mehrheit der Angriffe auf Anwendungsebene vor allem auf böswillig manipulierte Eingabedaten und eine unzureichende Eingabeüberprüfung der Anwendung setzt. Die in diesem Modul beschriebene Anleitung soll Ihnen dabei helfen, die hier vorgestellten und andere anspruchsvolle Aspekte des Entwurfs und der Erstellung sicherer Webanwendungen erfolgreich zu bewältigen.

 

Weitere Quellen

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Dieses Handbuch ist der zweite Band einer Reihe von Handbüchern, die Kunden dabei helfen soll, die Sicherheit ihrer Webanwendungen zu verbessern. Weitere Informationen zu Architektur, Entwurf, Erstellung und Konfiguration von Lösungen für die Authentifizierung, Autorisierung und sichere Kommunikation zwischen den Schichten einer verteilten Webanwendung finden Sie im Dokument "patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" unter der Adresse https://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

• MSDN-Artikel "Security Models for ASP.NET Applications" unter der Adresse https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch02.asp?frame=true.

• MSDN-Artikel "Designing Authentication and Authorization" unter der Adresse https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch03.asp?frame=true.

• "Prüfliste: Architektur- und Entwurfsüberprüfung" im Abschnitt "Prüfliste" dieses Handbuchs.