Freigeben über

Sicherheitsüberprüfung der Architektur und des Entwurfs

  • Artikel

* * *

Auf dieser Seite

Modulübersicht Modulübersicht
Zielsetzung Zielsetzung
Betrifft Betrifft
Verwendung dieses Moduls Verwendung dieses Moduls
Der Prozess der Architektur- und Entwurfsüberprüfung Der Prozess der Architektur- und Entwurfsüberprüfung
Überlegungen zur Bereitstellung und Infrastruktur Überlegungen zur Bereitstellung und Infrastruktur
Eingabeüberprüfung Eingabeüberprüfung
Authentifizierung Authentifizierung
Autorisierung Autorisierung
Konfigurationsverwaltung Konfigurationsverwaltung
Vertrauliche Daten Vertrauliche Daten
Sitzungsverwaltung Sitzungsverwaltung
Kryptografie Kryptografie
Parametermanipulation Parametermanipulation
Ausnahmeverwaltung Ausnahmeverwaltung
Überwachen und Protokollieren Überwachen und Protokollieren
Zusammenfassung Zusammenfassung
Weitere Informationen Weitere Informationen

Modulübersicht

Zum Erstellen einer sicheren Webanwendung sind eine geeignete Architektur und ein angemessener Entwurf erforderlich. Kosten und Aufwand zum nachträglichen Einpassen von Sicherheitsmerkmalen sind zu hoch. Eine Architektur- und Entwurfsüberprüfung unterstützt Sie bei der Gültigkeitsprüfung der sicherheitsrelevanten Entwurfsmerkmale einer Anwendung vor Eintritt in die Entwicklungsphase. Auf diese Weise können Sie potenzielle Sicherheitslücken feststellen und beheben, bevor Sie ausgenutzt werden und die Behebung zu technischen Nachbearbeitungen in größerem Umfang führt.

In diesem Modul werden Ihnen die Fragen vorgestellt, nach denen Sie sich bei der Durchführung einer gründlichen Prüfung Ihres Architekturentwurfs richten sollten. Auch wenn Sie Ihre Anwendung bereits erstellt haben, sollten Sie dieses Modul lesen, um die Konzepte, Prinzipien und Techniken zu überdenken, die Sie bei der Anwendungsentwicklung zugrunde gelegt haben.

 

Zielsetzung

Themenbereiche:

  • Fragen, die bei einer gründlichen Überprüfung Ihres Architekturentwurfs gestellt werden sollten.

  • Analysieren der Architektur und des Entwurfs der Webanwendung.

  • Entwickeln und Verbessern Ihrer aktuellen Vorgehensweisen bei Sicherheitsüberprüfungen.

  • Erstellen eines Prozesses zum Beheben von Sicherheitslücken während der Entwurfsphase.

  • Wichtige Sicherheitserwägungen bei Bereitstellung und Infrastruktur von Anwendungen.

  • Sicherstellen einer reibungslosen und sicheren Bereitstellung von Webanwendungen.

 

Betrifft

Webanwendungen

 

Verwendung dieses Moduls

Empfehlungen für eine erfolgreiche Arbeit mit diesem Modul:

  • Integrieren Sie eine Sicherheitsüberprüfung in den Architektur-Entwurfsprozess. Beginnen Sie schnellstmöglich und überprüfen Sie Entwurfsänderungen anhand der in diesem Modul beschriebenen Schritte.

  • Entwickeln Sie Ihre Sicherheitsüberprüfung. In diesem Modul werden Fragen vorgestellt, die Sie zur Erhöhung der Sicherheit eines Entwurfs stellen können. Um die Überprüfung abzuschließen, müssen Sie möglicherweise außerdem zusätzliche Kriterien einführen, die spezifisch an Ihrer Anwendung ausgerichtet sind.

  • Lernen Sie potenzielle Bedrohungen kennen. In Modul 2, "Bedrohungen und Gegenmaßnahmen", sind die Bedrohungen aufgeführt, denen die verschiedenen Komponenten und Ebenen ausgesetzt sind, aus denen eine Anwendung besteht. Sie müssen mit diesen Bedrohungen vertraut sein, um anhand der Ergebnisse Ihrer Überprüfung Verbesserungen vornehmen zu können.

 

Der Prozess der Architektur- und Entwurfsüberprüfung

Bei der Architektur- und Entwurfsüberprüfung werden Architektur und Entwurf unter Sicherheitsgesichtspunkten analysiert. Wenn Sie den Entwurf gerade abgeschlossen haben, können Sie bei diesem Prozess die Entwurfsdokumentation zu Rate ziehen. Unabhängig davon, wie umfassend die Entwurfsdokumentation ist, müssen Sie die Anwendung gliedern und wichtige Elemente identifizieren, einschließlich Vertrauensgrenzen, Datenfluss, Einstiegspunkte und privilegiertem Code. Sie müssen außerdem die physische Bereitstellungskonfiguration der Anwendung kennen. Achten Sie auf die Entwurfsansätze für diese Bereiche, in denen Sicherheitslücken am häufigsten auftreten. Diese Bereiche werden im vorliegenden Handbuch als Kategorien der Anwendungssicherheitslücken bezeichnet.

Ziehen Sie folgende Aspekte in Betracht, wenn Sie die Architektur und den Entwurf Ihrer Anwendung überprüfen:

  • Bereitstellung und Infrastruktur. Überprüfen Sie den Entwurf Ihrer Anwendung in Bezug auf die Zielumgebung, in der diese bereitgestellt werden soll, sowie auf die damit verbundenen Sicherheitsrichtlinien. Berücksichtigen Sie auch die Beschränkungen durch die Sicherheit der zugrunde liegenden Infrastrukturebene.

  • Anwendungsarchitektur und -entwurf. Überprüfen Sie den Ansatz für entscheidende Bereiche der Anwendung wie Authentifizierung, Autorisierung, Eingabeüberprüfung, Ausnahmeverwaltung und andere. Sie können die Kategorien der Anwendungssicherheitslücken zur Orientierung verwenden, um sicherzustellen, dass bei der Überprüfung keine wichtigen Bereiche ausgelassen werden.

  • Komponentenanalyse. Sie bewegen sich durch die logischen Schichten der Anwendung und untersuchen die Sicherheit von ASP.NET-Webseiten und -Steuerelementen, Webdiensten, bedienten Komponenten, Microsoft .NET-Remoting, Datenzugriffscode und anderen Elementen.

In Abbildung 5.1 wird dieser dreifache Ansatz zum Überprüfungsprozess dargestellt.

Anwendungsüberprüfung

Abbildung 5.1
Anwendungsüberprüfung

Im restlichen Teil dieses Moduls werden die wichtigsten Erwägungen und anstehenden Fragen während der Überprüfung jedes einzelnen dieser Bereiche beschrieben.

 

Überlegungen zur Bereitstellung und Infrastruktur

Untersuchen Sie die Sicherheitseinstellungen, die durch das zugrunde liegende Netzwerk und die Host-Infrastruktur der Anwendung zur Verfügung gestellt werden, sowie etwaige Beschränkungen durch die Zielumgebung. Berücksichtigen Sie auch die Bereitstellungstopologie und die Auswirkungen von Anwendungsservern der mittleren Schicht, Perimeterzonen und internen Firewalls auf Ihren Entwurf.

Ermitteln Sie anhand der folgenden Fragen potenzielle Probleme bei Bereitstellung und Infrastruktur:

  • Bietet das Netzwerk eine sichere Kommunikation?

  • Umfasst die Bereitstellungstopologie eine interne Firewall?

  • Umfasst die Bereitstellungstopologie einen Remoteanwendungsserver?

  • Welche Beschränkungen entstehen durch die Infrastruktursicherheit?

  • Haben Sie Webfarmprobleme berücksichtigt?

  • Welche Vertrauensstufen werden von der Zielumgebung unterstützt?

Bietet das Netzwerk eine sichere Kommunikation?

Die Daten sind am meisten gefährdet, wenn Sie zwischen einem Client und einem Server oder von einem Server auf einen anderen übertragen werden. Wie geschützt sollen die Daten sein? Sind Sie rechtlich verantwortlich für Kundendaten?

Während die Anwendung der Behandlung und sicheren Umwandlung von Daten vor der Übertragung dient, sind Integrität und Datenschutz der Daten während der Übertragung vom Netzwerk abhängig. Verwenden Sie einen angemessenen Verschlüsselungsalgorithmus, wenn die Daten geschützt werden sollen. Stellen Sie zusätzlich sicher, dass Ihre Netzwerkgeräte geschützt sind, da sie der Beibehaltung der Netzwerkintegrität dienen.

Umfasst die Bereitstellungstopologie eine interne Firewall?

Wenn der Webserver durch eine interne Firewall von einem Anwendungsserver oder einem Datenbankserver getrennt ist, können Sie anhand der folgenden Fragen feststellen, ob dies in Ihrem Entwurf berücksichtigt wird:

  • Wie wird der Webserver durch nachgeschaltete Server authentifiziert?

    Wenn Sie Domänenkonten und Windows-Authentifizierung verwenden, werden die erforderlichen Ports von der Firewall geöffnet? Falls nicht, oder wenn der Webserver und der nachgeordnete Server sich in verschiedenen Domänen befinden, können Sie gespiegelte lokale Konten verwenden. Beispielsweise können Sie das lokale ASPNET-Konto mit der geringsten Berechtigung duplizieren, das zum Ausführen der Webanwendung auf dem Datenbankserver verwendet wird.

  • Verwenden Sie verteilte Transaktionen?

    Werden durch den Webserver verteilte Transaktionen über die Dienste von Microsoft Distributed Transaction Coordinator (DTC) initiiert, werden die erforderlichen Ports für die DTC-Kommunikation geöffnet?

    Weitere Informationen über die Verwendung von DTC über eine Firewall finden Sie im Microsoft Knowledge Base-Artikel 250367, "INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall" unter:
    https://support.microsoft.com/default.aspx?scid=kb;en-us;Q250367.

Umfasst die Bereitstellungstopologie einen Remoteanwendungsserver?

Überprüfen Sie die folgenden Punkte, wenn die Bereitstellungstopologie eine physisch entfernte mittlere Schicht umfasst:

  • Verwenden Sie Enterprise Services?
    Falls ja, haben Sie den DCOM-Portbereich eingeschränkt und werden diese Ports durch eine interne Firewall geöffnet?

    Hinweis: In einigen Szenarien ist die Verwendung eines Webdiensts auf der mittleren Schicht als Front-End für die Enterprise Services-Anwendung die beste Wahl. Bei diesem Ansatz kann der Webserver mit dem Anwendungsserver unter Verwendung von SOAP (Simple Object Access Protocol) über Port 80 kommunizieren.

    Weitere Informationen hierzu finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:

  • Verwenden Sie .NET-Remoting?
    Remoting wurde für die Verwendung in Szenarien mit vertrauenswürdigen Servern konzipiert. Unterstützt das Netzwerk eine IPSec-Richtlinie, durch die man nur über den Webserver auf Ihre Remotekomponenten der mittleren Schicht zugreifen kann? Werden die Remotekomponenten von ASP.NET verwaltet, um Authentifizierung und Autorisierung zu unterstützen?

  • Verwenden Sie Webdienste?
    Falls ja, wie wird die Webanwendung durch Webdienste der mittleren Schicht authentifiziert? Werden von der Webanwendung Anmeldeinformationen auf dem Webdienst-Proxyserver konfiguriert, so dass der Webserver vom Webdienst authentifiziert werden kann? Falls nicht, wie wird der Aufrufer vom Webdienst identifiziert?

Welche Beschränkungen werden von der Infrastruktursicherheit auferlegt?

Enthält Ihr Entwurf Annahmen, die durch Beschränkungen der Infrastruktursicherheit außer Kraft gesetzt werden? Durch die Sicherheitsbeschränkungen können beispielsweise Kompromisse beim Entwurf erforderlich sein, die auf der Verfügbarkeit der erforderlichen Dienste, Protokolle oder Benutzerrechte basieren. Überprüfen Sie die folgenden Punkte:

  • Werden Dienste oder Protokolle vorausgesetzt, die möglicherweise nicht verfügbar sind?
    Dienste und Protokolle, die in Entwicklungs- und Testumgebungen vorhanden sind, sind in der Produktionsumgebung möglicherweise nicht verfügbar. Setzen Sie sich mit dem für die Infrastruktursicherheit verantwortlichen Team in Verbindung, um die Beschränkungen und Anforderungen kennen zu lernen.

  • Werden Konten mit weit reichenden Berechtigungen vorausgesetzt?
    Für den Entwurf sollten Prozesse, Dienste und Benutzerkonten mit den geringsten Berechtigungen verwendet werden. Führen Sie Vorgänge aus, die umfassende Berechtigungen erfordern und möglicherweise nicht gestattet werden?

    Müssen von Ihrer Anwendung beispielsweise Identitätswechseltoken erstellt werden, um Dienstidentitäten für den Ressourcenzugriff zu erstellen? Dazu ist die Berechtigung "Einsetzen als Teil des Betriebssystems" erforderlich, die Webserver-Prozessen nicht erteilt werden sollte, da hier ein erhöhtes Sicherheitsrisiko besteht. Wenn diese Funktion erforderlich ist, sollten die höheren Berechtigungen im Entwurf abgeschottet sein, zum Beispiel in einer "Out-of-Process" Enterprise Services-Anwendung.

Haben Sie Webfarmprobleme berücksichtigt?

Wenn Ihre Anwendung in einer Webfarm bereitgestellt wird, können Sie keine Vermutungen darüber anstellen, von welchem Server der Farm die Clientanfragen verarbeitet werden. Aufeinander folgende Anfragen desselben Clients können von verschiedenen Servern beantwortet werden. Aus diesem Grund müssen Sie folgende Aspekte berücksichtigen:

  • Wie verwalten Sie den Sitzungsstatus?
    In einer Webfarm können Sie den Sitzungsstatus nicht auf dem Webserver verwalten. Stattdessen muss der Entwurf einen Remote-Statusspeicher auf einem Server umfassen, auf den alle Webserver der Farm zugreifen. Weitere Informationen finden Sie unter "Sitzungsverwaltung" weiter unten in diesem Modul.

  • Verwenden Sie computerspezifische Verschlüsselungsschlüssel?
    Wenn Sie Daten auf einer freigegebenen Datenquelle, z. B. einer Datenbank, verschlüsseln, müssen die Schlüssel auf allen Computern der Farm identisch sein. Vergewissern Sie sich, dass der Entwurf keine computergebundenen Verschlüsselungsmechanismen verlangt.

  • Verwenden Sie Formularauthentifizierung oder geschützten Anzeigestatus?
    Wenn ja, sind Sie auf die Einstellungen des <Computerschlüssels> angewiesen. In einer Webfarm müssen Sie auf allen Servern allgemeine Schlüssel verwenden.

  • Verwenden Sie SSL (Secure Socket Layer)?
    Wenn Sie SSL zur Verschlüsselung des Datenverkehrs zwischen Browser und Webserver verwenden, an welcher Stelle wird die SSL-Verbindung beendet? Zu den Optionen gehören der Webserver, ein Webserver mit Beschleunigerkarte oder ein Lastenausgleicher mit Beschleunigerkarte. Das Beenden der SSL-Sitzung an einem Lastenausgleicher mit Beschleunigerkarte ist normalerweise am leistungsstärksten, besonders bei Sites mit vielen Verbindungen.

    Wenn Sie SSL am Lastenausgleicher beenden, wird der Netzwerkverkehr vom Lastenausgleicher zum Webserver nicht verschlüsselt. Das bedeutet, dass Angreifer potenziell mit einem Sniffer auf den Netzwerkverkehr zugreifen können, nachdem die Daten entschlüsselt wurden und die Daten zwischen Lastenausgleicher und Webserver übertragen werden. Sie können diese Bedrohung dadurch vermeiden, dass Sie entweder die physische Sicherung der Webserver-Umgebung sicherstellen oder indem Sie die über IPSec-Richtlinien verfügbare Verschlüsselung der Transportschicht für den Schutz interner Verbindungen des Datenzentrums verwenden.

Welche Vertrauensstufen werden von der Zielumgebung unterstützt?

Die Vertrauensstufe für die Codezugriffssicherheit der Zielumgebung legt die Ressourcen fest, auf die der Code zugreifen kann, sowie die privilegierten Vorgänge, die er ausführen darf. Überprüfen Sie die Vertrauensstufe der Zielumgebung. Wenn die Webanwendung vollständig vertrauenswürdig ausgeführt werden kann, kann der Code je nach Sicherheit des Betriebssystems auf alle Ressourcen zugreifen.

Wenn Ihre Webanwendungen mit niedrigerer Vertrauensstufe ausgeführt werden müssen, werden hierdurch die Arten von Ressourcen und privilegierten Vorgängen eingeschränkt, die vom Code ausgeführt werden können. In teilweise vertrauenswürdigen Szenarien sollte der privilegierte Code im Entwurf kontrolliert ausgeführt werden. Außerdem sollten Sie separate Assemblys verwenden, um den privilegierten Code zu isolieren. Dadurch konfiguriert der privilegierte Code getrennt vom Rest der Anwendung und erhält die notwendigen zusätzlichen Codezugriffsberechtigungen.

Weitere Informationen hierzu finden Sie in Modul 9, "Verwenden der Codezugriffssicherheit mit ASP.NET".

Hinweis: Vertrauensstufen sind häufig ein Problem, wenn Sie die Anwendung auf einem freigegebenen Server bereitstellen möchten, oder wenn die Anwendung von einem Host-Unternehmen ausgeführt wird. In diesen Fällen überprüfen Sie die Sicherheitsrichtlinien und ermitteln, welche Vertrauensstufen dort für Webanwendungen gewährleistet sind.

 

Eingabeüberprüfung

Untersuchen Sie, wie die Anwendung Eingaben auf Gültigkeit prüft, da viele Angriffe auf Webanwendungen über absichtlich fehlerhafte Eingabedaten ausgeführt werden. SQL-Injektion, Cross-Site Skripting (XSS), Pufferüberlauf, Code-Injektion und zahlreiche weitere Dienstverweigerungs- und Rechteerweiterungsangriffe machen sich eine ungenügende Eingabeüberprüfung zunutze. In Tabelle 5.1 werden die häufigsten Sicherheitslücken bei der Eingabeüberprüfung genannt.

Tabelle 5.1. Häufige Sicherheitslücken bei der Eingabeüberprüfung

Sicherheitslücken

Auswirkungen

Nicht geprüfte Eingabe bei der Ausgabe von HTML (Hypertext Markup Language)

Die Anwendung ist anfällig für XSS-Angriffe.

Nicht geprüfte Eingabe zum Erzeugen von SQL-Abfragen

Die Anwendung ist anfällig für SQL-Injektionen.

Vertrauen auf Gültigkeitsprüfung auf dem Client

Die Clientprüfung lässt sich einfach umgehen.

Verwendung von Eingabedateinamen, URLs oder Benutzernamen für Sicherheitsentscheidungen

Die Anwendung ist anfällig für Kanonisierungsfehler, dies führt zu Sicherheitsmängeln.

Anwendungsfilter für schädliche Eingaben

Diese Aufgabe ist sehr schwer zu bewältigen, da eine Unzahl potenziell schädlicher Eingaben möglich sind. Eingaben sollten von der Anwendung beschränkt, zurückgewiesen und unschädlich gemacht werden.

Stellen Sie sich folgende Fragen, die Ihnen beim Erkennen potenzieller Sicherheitsprobleme bei der Eingabeüberprüfung dienlich sein können:

  • Wie wird die Eingabe überprüft?

  • Was geschieht mit den Eingaben?

Wie wird die Eingabe überprüft?

Welcher Ansatz zur Eingabeüberprüfung ist in Ihrem Entwurf vorgesehen? Zunächst sollte im Entwurf eine Strategie vorgegeben werden. Jegliche Eingaben, die die Anwendung erhält, sollten beschränkt, zurückgewiesen und unschädlich gemacht werden können. Das Beschränken der Eingaben ist der beste Ansatz, da die Überprüfung von Daten auf bekannte und gültige Typen, Muster und Bereiche sehr viel einfacher ist als eine Prüfung der Daten auf bekannte unerwünschte Zeichen. Bei einer Strategie der Tiefenverteidigung sollten auch bekannte schädliche Eingaben zurückgewiesen und Eingaben unschädlich gemacht werden.

Die folgenden Fragen können Sie beim Ermitteln potenzieller Sicherheitslücken unterstützen:

  • Kennen Sie Ihre Einstiegspunkte?
    Stellen Sie sicher, dass im Entwurf die Einstiegspunkte der Anwendung angegeben sind, damit Sie verfolgen können, was in einzelnen Eingabefeldern vor sich geht. Berücksichtigen Sie Eingaben über Webseiten, Eingaben in Komponenten und Webdiensten sowie Eingaben von Datenbanken.

  • Kennen Sie Ihre Vertrauensgrenzen?
    Es ist nicht immer eine Eingabeüberprüfung erforderlich, wenn die Eingabe von einer vertrauenswürdigen Quelle innerhalb Ihrer Vertrauensgrenzen stammt. Sie ist jedoch als obligatorisch zu betrachten, wenn die Eingabe aus nicht vertrauenswürdigen Quellen stammt.

  • Werden Eingaben von Webseiten überprüft?
    Sie sollten den Endbenutzer nicht als eine vertrauenswürdige Datenquelle betrachten. Stellen Sie sicher, dass normale und ausgeblendete Formularfelder, Abfragezeichenfolgen und Cookies überprüft werden.

  • Werden Argumente überprüft, die an Komponenten oder Webdienste weitergeleitet werden?
    Der einzige Fall, in dem es möglicherweise sicher sein könnte, dies nicht zu tun, ist beim Empfang von Daten innerhalb der aktuellen Vertrauensgrenzen. Bei einer Tiefenverteidigungsstrategie werden jedoch mehrere Prüfungsebenen empfohlen.

  • Werden Daten geprüft, die aus einer Datenbank abgerufen werden?
    Auch diese Art von Eingaben sollte geprüft werden, besonders wenn Daten aus anderen Anwendungen in die Datenbank geschrieben werden. Versuchen Sie nicht einzuschätzen, wie gründlich die Eingabeüberprüfung der anderen Anwendung ist.

  • Verfolgen Sie einen zentralisierten Ansatz?
    Untersuchen Sie bei häufig verwendeten Arten von Eingabefeldern, ob allgemeine Prüf- und Filterbibliotheken verwendet werden, um sicherzustellen, dass die Gültigkeitsregeln konsistent angewendet werden.

  • Setzen Sie eine Gültigkeitsprüfung auf dem Client voraus?
    Unterlassen Sie das. Prüfungen auf dem Client können verwendet werden, um den Datenverkehr zum und vom Server zu verringern. Jedoch sollten Sie sich davon keine größere Sicherheit versprechen, da sie einfach zu umgehen sind. Alle Eingaben müssen auf dem Server überprüft werden.

Was geschieht mit den Eingaben?

Überprüfen Sie, wie Ihre Anwendung mit Eingaben umgeht, da verschiedene Arten der Verarbeitung zu unterschiedlichen Sicherheitslücken führen können. Wenn Sie beispielsweise Eingaben von SQL-Abfragen verwenden, ist die Anwendung potenziell anfällig für eine SQL-Injektion.

Die folgenden Fragen können Sie beim Ermitteln potenzieller Sicherheitslücken unterstützen:

  • Ist die Anwendung anfällig für Kanonisierungsprobleme?
    Überprüfen Sie, ob die Anwendung Namen auf Grundlage von Eingaben verwendet, um Sicherheitsentscheidungen zu treffen. Werden Benutzernamen, Dateinamen oder URLs akzeptiert? Solche Eingaben sind berüchtigt für Kanonisierungsfehler, da diese Namen auf sehr verschiedene Arten dargestellt werden können. Wenn Ihre Anwendung solche Namen als Eingabe akzeptiert, überprüfen Sie ihre Gültigkeit und die Umwandlung in eine kanonische Darstellung, bevor sie verarbeitet werden.

  • Ist die Anwendung anfällig für SQL-Injektion?
    Achten Sie besonders auf Eingabefelder, die zur Formulierung einer SQL-Datenbankabfrage verwendet werden. Überprüfen Sie, ob diese Felder angemessen auf Art, Format, Länge und Bereich geprüft werden. Überprüfen Sie ebenfalls, wie die Abfragen erstellt werden. Wenn Sie parametrisierte gespeicherte Prozeduren verwenden, werden die Eingabeparameter als Literalwerte und nicht als ausführbarer Code behandelt. Dies mindert das Risiko erheblich.

  • Ist die Anwendung anfällig gegenüber XSS-Angriffen?
    Wenn Sie Eingabefelder in die HTML-Ausgabe einbinden, könnte dies einen Schwachpunkt für XSS darstellen. Überprüfen Sie, dass die Eingabe geprüft und die Ausgabe codiert wird. Achten Sie besonders darauf, wie Eingabefelder verarbeitet werden, die einen Bereich von HTML-Zeichen akzeptieren.

 

Authentifizierung

Untersuchen Sie, wie Benutzer in der Anwendung authentifiziert werden, an welcher Stelle eine Authentifizierung erfolgt und wie die Sicherheit der Benutzerinformationen beim Speichern und bei der Übertragung im Netzwerk gewährleistet wird. Durch Sicherheitslücken bei der Authentifizierung kann die Anwendung anfällig für Spoofing- und Wörterbuchangriffe, Sitzungsübernahmen und andere Übergriffe werden. In Tabelle 5.2 werden die häufigsten Sicherheitslücken bei der Authentifizierung genannt.

Tabelle 5.2 Häufige Sicherheitslücken bei der Authentifizierung

Sicherheitslücken

Auswirkungen

Schwache Kennwörter

Das Risiko von erkannten Kennwörtern und Wörterbuchangriffen steigt.

Klartextinformationen in Konfigurationsdateien

Insider mit Zugriff auf den Server oder Angreifer, die Sicherheitslücken des Hosts zum Herunterladen der Konfigurationsdatei ausnutzen, erhalten unmittelbaren Zugriff auf die Anmeldeinformationen.

Übertragen von Klartextinformationen im Netzwerk

Angreifer können das Netzwerk überwachen, um Authentifizierungsdaten zu stehlen und Identitäten vorzutäuschen.

Konten mit zu umfassenden Berechtigungen

Die Risiken eines Prozesses oder einer Kontokompromittierung steigen.

Lange Sitzungen

Das Risiko von Sitzungsübernahmen steigt.

Vermischen von Personalisierung und Authentifizierung

Personalisierungsdaten werden an permanente Cookies angepasst. Authentifizierungs-Cookies sollten nicht beibehalten werden.

Stellen Sie anhand folgender Fragen potenzielle Sicherheitslücken der Authentifizierungsmethode Ihrer Anwendung fest:

  • Trennen Sie öffentlichen und eingeschränkten Zugriff?

  • Haben Sie die Dienstkonto-Anforderungen ermittelt?

  • Wie werden Benutzer authentifiziert?

  • Wie wird die Authentifizierung bei der Datenbank durchgeführt?

  • Erzwingen Sie starke Kontenverwaltungsverfahren?

Trennen Sie öffentlichen und eingeschränkten Zugriff?

Wenn die Anwendung öffentliche Bereiche anbietet, die keine Authentifizierung erfordern, und eingeschränkte Bereiche, die eine Authentifizierung erfordern, untersuchen Sie, wie Ihr Entwurf zwischen beiden unterscheidet. Sie sollten separate Unterordner für eingeschränkte Seiten und Ressourcen verwenden und diese in Internet Information Services (IIS) sichern, indem Sie eine SSL-Verschlüsselung für diese Unterordner fordern. Mit diesem Ansatz sind vertrauliche Daten geschützt und Authentifizierungs-Cookies, die SSL verwenden, werden nur für die entsprechenden Bereiche der Site benötigt. Sie vermeiden so den zusätzlichen Leistungsaufwand, den die Verwendung von SSL für die ganze Site mit sich bringen würde.

Haben Sie die Dienstkonto-Anforderungen ermittelt?

Beim Entwurf sollte der Bereich der Dienstkonten erkannt werden, der erforderlich ist, um eine Verbindung zu verschiedenen Ressourcen wie Datenbanken, Verzeichnisdiensten und anderen Arten von entfernten Netzwerkressourcen herzustellen. Stellen Sie sicher, dass der Entwurf kein einzelnes, hoch privilegiertes Konto mit ausreichenden Rechten erfordert, um eine Verbindung zu den verschiedenen Ressourcenarten herzustellen.

  • Erfordert der Entwurf Konten mit geringsten Berechtigungen?
    Haben Sie festgestellt, welche Ressourcen und Vorgänge welche Berechtigungen erfordern? Überprüfen Sie, dass im Entwurf genau festgelegt ist, welche Berechtigungen jedes Konto erfordert, um seine spezifische Funktion zu erfüllen, und verwenden Sie stets Konten mit den geringsten Berechtigungen.

  • Müssen in der Anwendung Dienstkonteninformationen erhalten bleiben?
    Stellen Sie in diesem Fall sicher, dass die Informationen verschlüsselt sind und an einem Speicherort mit Zugangsbeschränkung aufbewahrt werden, beispielsweise ein Registrierungsschlüssel mit eingeschränkter Zugriffssteuerungsliste (ACL).

Wie werden Benutzer authentifiziert?

Überprüfen Sie die folgenden Aspekte bei der Authentifizierung eines Benutzers. Welche Aspekte zutreffen, ist von der Art der Authentifizierung abhängig, die im Entwurf verwendet wird.

  • Werden Klartextinformationen über das Netzwerk gesendet?
    Wenn Sie Formular- oder Standardauthentifizierung, Webdienste und Anmeldeinformationen in SOAP-Headern verwenden, müssen die Daten bei der Übertragung immer mit SSL geschützt werden.

  • Implementieren Sie einen eigenen Benutzerspeicher?
    Wenn ja, überprüfen Sie wo und wie die Benutzerinformationen gespeichert werden. Es wird häufig der Fehler gemacht, Kennwörter in Klartext oder verschlüsselt zusammen mit den Benutzerinformationen zu speichern. Sie sollten stattdessen zur Verifizierung einen Kennwort-Hashwert speichern.

    Wenn Sie die Anmeldeinformationen anhand eines SQL Server-Benutzerspeichers überprüfen, achten Sie besonders auf die eingegebenen Benutzernamen und Kennwörter. Überprüfen Sie diese auf schädliche Injektionen von SQL-Zeichen.

  • Verwenden Sie Formularauthentifizierung?
    Wenn ja, sollten Sie SSL nicht nur zum Schützen der Anmeldeinformationen verwenden, sondern auch das Authentifizierungs-Cookie mit SSL schützen. Überprüfen Sie außerdem, ob die Gültigkeitsdauer der Sitzung beschränkt ist, um der Gefahr von Cookie-Replay-Angriffen entgegenzuwirken, und stellen Sie sicher, dass das Cookie verschlüsselt ist.

    Weitere Informationen zur Formularauthentifizierung finden Sie in Modul 10, "Erstellen sicherer ASP.NET-Seiten und -Steuerelemente" und in Modul 19, "Schützen der ASP.NET-Anwendung und -Webdienste".

Wie wird die Authentifizierung bei der Datenbank durchgeführt?

Wenn eine Verbindung von der Anwendung zur Datenbank hergestellt werden soll, überprüfen Sie den Authentifizierungsmechanismus, welches Konto oder welche Konten verwendet werden sollen und wie die Anwendung in der Datenbank authentifiziert werden soll.

Anhand folgender Fragen können Sie Ihren Ansatz zur Datenbankauthentifizierung überprüfen:

  • Verwenden Sie SQL-Authentifizierung?
    Im Idealfall wird eine Windows-Authentifizierung für die Verbindung zum SQL-Server verwendet, da dies ein sichererer Ansatz ist. Wenn Sie SQL-Authentifizierung verwenden, untersuchen Sie, wie Anmeldeinformationen über das Netzwerk und bei Datenbankverbindungen in Zeichenketten geschützt werden.

    Wenn die Netzwerkinfrastruktur keine IPSec-verschlüsselten Kanäle bietet, muss ein Serverzertifikat für die Datenbank installiert sein, um eine automatische Verschlüsselung von SQL-Anmeldeinformationen zu ermöglichen. Betrachten Sie auch, wie Zeichenketten für Datenbankverbindungen geschützt werden, da diese Zeichenketten SQL-Benutzernamen und -Kennwörter enthalten.

  • Verwenden Sie das Prozesskonto?
    Wenn Sie das Prozesskonto der Anwendung verwenden und mit der Windows-Authentifizierung eine Verbindung zum SQL-Server herstellen, sollte der Entwurf von einem Konto mit geringsten Berechtigungen ausgehen. Zu diesem Zweck wird das lokale ASPNET-Konto bereitgestellt, obwohl Sie bei lokalen Konten ein dupliziertes Konto auf dem Datenbankserver erstellen müssen.

    Wenn Sie ein Domänenkonto verwenden möchten, stellen Sie sicher, dass es sich um ein Konto mit geringsten Berechtigungen handelt. Stellen Sie außerdem sicher, dass alle dazwischen eingerichteten Firewalls Windows-Authentifizierung unterstützen, indem Sie die entsprechenden Ports öffnen.

  • Verwenden Sie Dienstkonten?
    Wenn bei Ihrem Entwurf mehrere Identitäten erforderlich sind, um eine feinstufigere Autorisierung für die Datenbank zu erreichen, untersuchen Sie, wie die Konteninformationen gespeichert werden, und wie die Dienstidentität eingesetzt werden soll. Im Idealfall werden Sie mit Data Protection API (DPAPI) verschlüsselt und in einem geschützten Registrierungsschlüssel aufbewahrt.

    Stellen Sie auch fest, welcher Prozess zum Erstellen des Sicherheitskontexts mit Identitätswechsel über das Dienstkonto verwendet wird. Das sollte nicht vom ASP.NET-Anwendungsprozess unter Microsoft Windows 2000 erledigt werden, da Sie dann gezwungen wären, die Berechtigungen des Prozesskontos zu erhöhen und diesem die Berechtigung "Einsetzen als Teil des Betriebssystems" zu geben. Das sollten Sie vermeiden, da sich das Risiko hierdurch beträchtlich erhöht.

  • Werden Sie die Identität eines anonymen Internetbenutzers zu verwenden?
    Für Anwendungen, die eine Formular- oder Passport-Authentifizierung verwenden, können Sie separate anonyme Benutzerkonten für jede Anwendung konfigurieren. Daraufhin können Sie den Identitätswechsel aktivieren und anschließend die anonyme Identität für den Zugriff auf die Datenbank verwenden. Bei diesem Ansatz werden separate Autorisierung und Identitätsverfolgung bei verschiedenen Anwendungen auf demselben Webserver berücksichtigt.

  • Verwenden Sie die ursprüngliche Benutzeridentität?
    Wenn der Entwurf einen Identitätswechsel des ursprünglichen Benutzers verlangt, müssen Sie erwägen, ob der Ansatz ausreichende Skalierbarkeit bietet, da eine Poolbildung für Verbindungen nicht effektiv ist. Ein anderer Ansatz besteht darin, die Identität des ursprünglichen Benutzers auf Anwendungsebene durch vertrauenswürdige Abfrageparameter zu übertragen.

  • Wie speichern Sie Zeichenfolgen für Datenbankverbindungen?
    Wenn die Zeichenfolgen einer Datenbankverbindung fest codiert oder im Klartext in Konfigurationsdateien oder im COM+-Katalog gespeichert sind, sind sie gefährdet. Stattdessen sollten Sie diese verschlüsseln und den Zugriff auf die verschlüsselten Daten einschränken.

    Weitere Informationen zu verschiedenen Optionen bei der Verbindung zu SQL Server und zum sicheren Speichern der Zeichenfolgen für die Datenbankverbindung finden Sie in Modul 14, "Erstellen eines sicheren Datenzugriffs".

Erzwingen Sie starke Kontenverwaltungsverfahren?

Die Verwendung starker Kennwörter, beschränkter Anmeldeversuche und anderer bewährter Kontenverwaltungsrichtlinien können von der Windows-Sicherheitsrichtlinie erzwungen werden, wenn die Anwendung die Windows-Authentifizierung nutzt. Andernfalls muss dies auf Anwendungsebene geschehen. Prüfen Sie folgende Gesichtspunkte der Kontenverwaltung Ihrer Anwendung:

  • Erzwingt die Anwendung starke Kennwörter?
    Verwenden sie auf Ihren ASP.NET-Webseiten beispielsweise reguläre Ausdrücke zum Überprüfen der Kennwortkomplexitätsregeln?

  • Ist die Anzahl der fehlgeschlagenen Anmeldeversuche begrenzt?
    Dadurch können Sie der Gefahr von Wörterbuchangriffen entgegnen.

  • Werden bei fehlgeschlagenen Versuchen zu viele Informationen preisgegeben?
    Stellen Sie sicher, dass keine Meldungen wie "Falsches Kennwort" angezeigt werden, da Benutzer mit unlauteren Absichten so erfahren, dass der Benutzername richtig ist. Sie können dann ihre Anstrengungen auf das Herausfinden des Kennworts konzentrieren.

  • Wird ein periodischer Wechsel der Kennwörter erzwungen?
    Dies wird empfohlen, da andernfalls eine hohe Wahrscheinlichkeit besteht, dass Benutzer ihre Kennwörter nicht ändern und dadurch stärker gefährdet sind.

  • Können Konten bei Kompromittierungen schnell deaktiviert werden?
    Können Sie ein kompromittiertes Konto auf einfache Weise deaktivieren, um den Angreifer an der weiteren Nutzung dieses Kontos zu hindern?

  • Werden Anmeldeversuche von der Anwendung aufgezeichnet?
    Das Aufzeichnen fehlgeschlagener Anmeldeversuche ist eine effektive Methode zur Entdeckung eines Angreifers, der versucht, sich Zugang zu verschaffen.

 

Autorisierung

Untersuchen Sie, wie Benutzer von Ihrer Anwendung autorisiert werden. Überprüfen Sie auch, wie die Anwendung in der Datenbank autorisiert wird und wie der Zugriff auf Ressourcen auf Systemebene gesteuert wird. Sicherheitslücken bei der Autorisierung können zur Offenlegung von Informationen, Verfälschung von Daten und Erweiterung von Berechtigungen führen. Eine Tiefenverteidigungsstrategie ist das wichtigste Sicherheitsprinzip, das Sie für die Autorisierung der Anwendung einsetzen können. In Tabelle 5.3 werden die häufigsten Sicherheitslücken bei der Autorisierung genannt.

Tabelle 5.3. Häufige Sicherheitslücken bei der Autorisierung

Sicherheitslücken

Auswirkungen

Vertrauen auf einen einzelnen Gatekeeper

Wenn der Gatekeeper umgangen wird oder nicht korrekt konfiguriert ist, erhält ein Benutzer nicht autorisierten Zugriff.

Fehlende Sperrung von Systemressourcen für Anwendungsidentitäten

Ein Angreifer kann die Anwendung dazu bringen, auf zugriffsbeschränkte Systemressourcen zuzugreifen.

Fehlende Einschränkung des Datenbankzugriffs auf angegebene gespeicherte Prozeduren

Ein Angreifer kann eine SQL-Injektion zum Abrufen, Manipulieren oder Zerstören von Daten erstellen.

Ungeeignete Trennung von Berechtigungen

Es gibt keine Instanz, die für eine Benutzerautorisierung verantwortlich wäre oder die Möglichkeit dazu hätte.

Überprüfen Sie anhand der folgenden Fragen die Autorisierungsstrategie Ihres Anwendungsentwurfs:

  • Wie werden Endbenutzer autorisiert?

  • Wie wird die Anwendung in der Datenbank autorisiert?

  • Wie wird der Zugriff auf Systemressourcen beschränkt?

Wie werden Endbenutzer autorisiert?

Beim Entwurf sollten Sie die Autorisierung unter zwei Gesichtpunkten betrachten. Ziehen Sie zunächst die Endbenutzer-Autorisierung in Betracht. Welche Benutzer können auf welche Ressourcen zugreifen und welche Vorgänge ausführen? Wie hindern Sie böswillige Benutzer daran, die Anwendung für den Zugriff auf Systemressourcen zu nutzen? Überprüfen Sie anhand der folgenden Fragen die Autorisierungsstrategie Ihrer Anwendung:

  • Setzen Sie eine Tiefenverteidigungsstrategie ein?
    Stellen Sie sicher, dass der Entwurf sich bei der Umsetzung der Zugriffskontrolle nicht auf einen einzelnen Gatekeeper verlässt. Bedenken Sie die Auswirkungen, wenn dieser Gatekeeper ausfällt oder er bei einem Angriff umgangen wird.

  • Welche Gatekeeper werden verwendet?
    Zu den Optionen gehören IIS-Webberechtigungen, NTFS-Berechtigungen, ASP.NET-Dateiautorisierung (die nur zusammen mit der Windows-Authentifizierung gültig ist), URL-Autorisierung und Prinzipalberechtigungsanforderungen. Wenn bestimmte Arten nicht verwendet werden, sollten Ihnen die Gründe dafür bekannt sein.

  • Verwenden Sie einen rollenbasierten Ansatz?
    Wenn ja, wie werden die Rollenlisten verwaltet und wie sicher sind die hierfür erforderlichen Administrationsschnittstellen?

  • Bieten die Rollen eine angemessene Rechtetrennung?
    Verfügt der Entwurf über den richtigen Grad von Feinstufigkeit, so dass die unterschiedlichen Benutzerrollen zugeordneten Rechte ausreichend getrennt sind? Vermeiden Sie Situationen, in denen Rollen erweiterte Rechte erhalten, nur um den Anforderungen bestimmter Benutzer gerecht zu werden. In diesem Fall sollten besser neue Rollen hinzugefügt werden.

Wie wird die Anwendung in der Datenbank autorisiert?

Die Konten, die die Anwendung für Verbindungen zur Datenbank nutzt, sollten über eingeschränkte Fähigkeiten verfügen, die für die Anwendungsanforderungen ausreichen, jedoch nicht darüber hinausgehen.

  • Greift die Anwendung über gespeicherte Prozeduren auf die Datenbank zu?
    Dies wird empfohlen, da bei Anmeldung der Anwendung nur Berechtigungen für den Zugriff auf die angegebenen gespeicherten Prozeduren erteilt werden können. Bei der Anmeldung kann die Ausführung direkter Vorgänge wie Erstellen, Lesen, Aktualisieren und Löschen in der Datenbank verhindert werden.

    Das erhöht die Sicherheit und wirkt sich auch auf die Leistung und zukünftige Wartungsfähigkeit positiv aus. Weitere Informationen zu Ansätzen für die Datenbankautorisierung finden Sie in Modul 14, "Erstellen eines sicheren Datenzugriffs".

Wie wird der Zugriff auf Systemressourcen beschränkt?

Ziehen Sie beim Entwerfen der Anwendung die Einschränkungen in Betracht, die für den Zugriff auf Systemressourcen eingerichtet werden. Für die Anwendung sollten nur die unbedingt erforderlichen Ressourcen zugänglich sein. Diese Risikominderungsstrategie beschränkt den Schaden bei Kompromittierung einer Anwendung. Folgende Probleme müssen Sie berücksichtigen:

  • Verwendet Ihr Entwurf Codezugriffssicherheit?
    Codezugriffssicherheit bietet ein Modell der Ressourcenbeschränkung, welches verhindertr, dass Code (und Webanwendungen) auf bestimmte Arten von Systemressourcen zugreifen kann. Wenn Sie Codezugriffssicherheit verwenden, beeinflusst dies unvermeidlich den Entwurf. Legen Sie fest, ob Codezugriffssicherheit in Ihren Entwurf integriert werden soll oder nicht. Gestalten Sie den Entwurf dann entsprechend, indem Sie privilegierten Code isolieren, kontrolliert ausführen und den Ressourcenzugriffscode in eigenen separaten Assemblys platzieren.

  • Welche Identitäten werden von Ihrer Anwendung verwendet?
    Im Entwurf sollten alle Identitäten erkannt werden, die von der Anwendung verwendet werden, einschließlich der Prozessidentität und aller Wechselidentitäten, anonymer Internetbenutzerkonten und Dienstidentitäten. Der Entwurf sollte auch anzeigen, auf welche Ressourcen diese Identitäten Zugriff benötigen.

    Bei der Bereitstellung können die entsprechenden Zugriffsteuerungslisten für Ressourcen auf Systemebene konfiguriert werden, um sicherzustellen, dass die Identitäten der Anwendung nur Zugriff auf die Ressourcen haben, die sie benötigen.

    Weitere Informationen zum Entwerfen mit Codezugriffssicherheit finden Sie in Modul 9 "Verwenden der Codezugriffssicherheit mit ASP.NET".

 

Konfigurationsverwaltung

Wenn die Anwendung über eine Administrationsschnittstelle verfügt, über die sie konfiguriert werden kann, untersuchen Sie, wie die Administrationsschnittstellen geschützt sind. Untersuchen Sie auch, wie wichtige Konfigurationsdaten geschützt sind. In Tabelle 5.4 werden die häufigsten Sicherheitslücken bei der Konfigurationsverwaltung genannt.

Tabelle 5.4 Häufige Sicherheitslücken bei der Konfigurationsverwaltung

Sicherheitslücken

Auswirkungen

Unsichere Administrations-
schnittstellen

Nicht autorisierte Benutzer können die Anwendung neu konfigurieren und
auf vertrauliche Daten zugreifen.

Unsichere Konfigurationsspeicher

Nicht autorisierte Benutzer können auf Konfigurationsspeicher
zugreifen und geheime Daten wie Kontonamen, Kennwörter
und Datenbank-Verbindungsdaten einsehen.

Klartext-Konfigurationsdaten

Jeder, der sich beim Server anmeldet, kann wichtige
Konfigurationsdaten einsehen.

Zu viele Administratoren

Hierdurch wird es schwierig, Administratoren zu überwachen und zu überprüfen.

Prozess- und Dienstkonten
mit zu vielen Rechten

Dies kann Angriffe mit Berechtigungserweiterungen ermöglichen.

Überprüfen Sie anhand der folgenden Fragen den Ansatz Ihres Anwendungsentwurfs für die Konfigurationsverwaltung:

  • Wird Remoteverwaltung unterstützt?

  • Werden sichere Konfigurationsspeicher unterstützt?

  • Werden Administratorrechte getrennt?

Wird Remoteverwaltung unterstützt?

Wenn im Entwurf die Remoteverwaltung vorgesehen ist, müssen Sie die Administrationsschnittstellen und Konfigurationsspeicher schützen, da diese Vorgänge besonders empfindlich sind und über die Administrationschnittstelle auf die Daten zugegriffen werden kann. Überprüfen Sie folgende Aspekte Ihres Entwurf für die Remoteverwaltung:

  • Verwenden Sie eine starke Authentifizierung?
    Alle Benutzer der Administrationsschnittstelle sollten sich authentifizieren müssen. Verwenden Sie eine starke Authentifizierung wie Windows- oder Clientzertifikat-Authentifizierung.

  • Wird der Netzwerkverkehr verschlüsselt?
    Verwenden Sie verschlüsselte Kommunikationskanäle, wie sie durch IPSec oder in virtuellen privaten Netzwerken (VPN) verfügbar sind. Unterstützen Sie keine Remoteverwaltung über unsichere Kanäle. Mit IPSec können Sie die Identität und die Anzahl der Clientcomputer beschränken, die für die Verwaltung des Servers verwendet werden.

Werden sichere Konfigurationsspeicher unterstützt?

Identifizieren Sie die Konfigurationsspeicher Ihrer Anwendung und untersuchen Sie Ihren Ansatz zum Beschränken des Zugriffs auf die Speicher und zum Schützen der Daten in diesen Speichern.

  • Befindet sich der Konfigurationsspeicher im Webspeicher?
    Konfigurationsdaten, die sich in Dateien im Webspeicher befinden, werden als weniger sicher betrachtet als Daten, die außerhalb des Webspeichers gespeichert sind. Fehler bei der Hostkonfiguration oder nicht entdeckte Fehler können es einem Angreifer ermöglichen, Konfigurationsdateien über HTTP abzurufen und herunterzuladen.

  • Sind die Daten im Konfigurationsspeicher sicher?
    Stellen Sie sicher, dass wichtige Elemente der Konfigurationsdaten wie Zeichenfolgen für Datenbankverbindungen, Verschlüsselungsschlüssel und Dienstkonteninformationen im Speicher verschlüsselt werden.

  • Wie wird der Zugriff auf den Konfigurationsspeicher beschränkt?
    Überprüfen Sie, dass die erforderliche Autorisierung für die Administrationsschnittstelle durchgeführt wird, um sicherzustellen, dass nur authentifizierte Administratoren auf die Daten zugreifen und sie ändern können.

Werden Administratorrechte getrennt?

Wenn Ihre Administrationsschnittstellen verschiedene Funktionen unterstützen - beispielsweise Inhaltsaktualisierungen, Dienstkonten-Neukonfiguration und Datenbank-Verbindungsdaten - überprüfen Sie, ob die Administrationsschnittstellen eine rollenbasierte Autorisierung unterstützen, damit zwischen Entwicklern, Operatoren und Systemadministratoren unterschieden werden kann. Eine Person, die statische Websiteinhalte aktualisiert, sollte nicht unbedingt die Höhe des Kreditlimits eines Kunden ändern oder eine Zeichenkette für die Datenbankverbindung neu konfigurieren können.

 

Vertrauliche Daten

Untersuchen Sie, wie vertrauliche Daten im Speicher, im Arbeitsspeicher und bei der Übertragung im Netzwerk von der Anwendung behandelt werden. In Tabelle 5.5 werden die häufigsten Sicherheitslücken beim Umgang mit vertraulichen Daten genannt.

Tabelle 5.5 Häufige Sicherheitslücken beim Umgang mit vertraulichen Daten

Sicherheitslücken

Auswirkungen

Unnötiges Speichern geheimer Daten

Hierdurch entsteht ein sehr hohes Sicherheitsrisiko, das vermieden werden kann, wenn die geheimen Daten gar nicht erst gespeichert werden.

Speichern von geheimen Daten in Code

Wenn der Code sich auf dem Server befindet, kann ein Angreifer ihn möglicherweise herunterladen. Geheime Daten sind in binären Assemblys sichtbar.

Speichern von geheimen Daten in Klartext

Jeder, der sich beim Server anmeldet, kann auch auf die geheimen Daten zugreifen.

Weitergabe vertraulicher Daten in Klartext über Netzwerke

Personen können das Netzwerk abhören, um Daten zu enthüllen und sie zu manipulieren.

Überprüfen Sie anhand der folgenden Fragen die Behandlung vertraulicher Daten in Ihrer Anwendung:

  • Werden geheime Daten gespeichert?

  • Wie werden wichtige Daten gespeichert?

  • Werden wichtige Daten über das Netzwerk weitergegeben?

  • Werden wichtige Daten protokolliert?

Werden geheime Daten gespeichert?

Zu geheimen Daten gehören Konfigurationsdaten der Anwendung wie Kontokennwörter und Verschlüsselungsschlüssel. Geben Sie nach Möglichkeit alternative Entwurfsansätze an, bei denen Gründe zum Speichern geheimer Daten wegfallen. Wenn Sie mit geheimen Informationen umgehen, überlassen Sie deren Behandlung vorzugsweise der Plattform, so dass Ihre Anwendung von dieser Last befreit ist. Wenn Sie geheime Daten speichern, überprüfen Sie folgende Punkte:

  • Lässt sich das Speichern der geheimen Daten vermeiden?
    Wenn Sie eine andere Implementierungstechnik verwenden, könnte das Speichern der geheimen Daten überflüssig werden. Sie müssen beispielsweise nur überprüfen, ob ein Benutzer das Kennwort kennt, die Kennwörter selbst jedoch nicht speichern. Speichern Sie stattdessen unidirektionale Kennwort-Hashwerte.

    Mit der Windows-Authentifizierung können sie außerdem das Speichern von Verbindungszeichenfolgen mit integrierten Anmeldeinformationen vermeiden.

  • Wie werden geheime Daten gespeichert?
    Wenn Sie eine Verschlüsselung verwenden, wie werden die Verschlüsselungsschlüssel geschützt? Erwägen Sie die Verwendung der von der Plattform bereitgestellten DPAPI-Verschlüsselung, die die Schlüsselverwaltung für Sie übernimmt.

  • Wo werden geheime Daten gespeichert?
    Untersuchen Sie, wie in Ihrer Anwendung verschlüsselte Daten gespeichert werden. Um die maximale Sicherheit zu erreichen, sollte der Zugriff auf die verschlüsselten Daten mit Windows-ACLs beschränkt werden. Vergewissern Sie sich, dass von der Anwendung keine geheimen Daten in Klartext oder in Quellcode gespeichert werden.

    Wenn Sie die Local Security Authority (LSA) verwenden, muss der Code für das Abrufen der geheimen Daten mit Administratorrechten ausgeführt werden. Dadurch erhöht sich das Risiko. Ein alternativer Ansatz, bei dem keine erweiterten Berechtigungen erforderlich sind, ist die Verwendung von DPAPI.

  • Wie werden geheime Daten verarbeitet?
    Untersuchen Sie, wie auf die geheimen Daten zugegriffen wird und wie lange sie in Klartext im Arbeitsspeicher behalten werden. Geheime Daten sollten generell auf Nachfrage abgerufen, nur für den kleinstmöglichen Zeitraum verwendet und anschließend entfernt werden.

  • Werden geheime Daten in Cookies gespeichert?
    Wenn ja, stellen Sie sicher, dass das Cookie verschlüsselt ist und nicht auf dem Clientcomputer beibehalten wird.

Wie werden wichtige Daten gespeichert?

Wenn Sie wichtige Anwendungsdaten wie benutzerspezifische Kreditkarteninformationen speichern, untersuchen Sie, wie die Daten geschützt werden.

  • Welchen Verschlüsselungsalgorithmus verwenden Sie? Sie sollten die Daten mit einem sicheren Verschlüsselungsalgorithmus mit großer Schlüssellänge wie Triple DES verschlüsseln.

  • Wie werden die Verschlüsselungsschlüssel geschützt? Die Daten sind nur so sicher wie der Schlüssel, daher sollten Sie den Schlüssel sorgfältig sichern. Im Idealfall verschlüsseln Sie den Schlüssel mit DPAPI und sichern ihn an einem zugangsbeschränkten Ort, beispielsweise einem Registrierungsschlüssel.

Werden vertrauliche Daten über das Netzwerk weitergegeben?

Wenn wichtige Daten im Netzwerk weitergegeben werden, stellen Sie sicher, dass die Daten entweder von der Anwendung verschlüsselt werden oder dass die Daten ausschließlich über verschlüsselte Verbindungen weitergeleitet werden.

Werden wichtige Daten protokolliert?

Untersuchen Sie, ob wichtige Daten wie Kennwörter für Benutzerkonten von der Anwendung (oder vom Host) in Klartext-Protokolldateien gespeichert werden. Dies sollten Sie generell vermeiden. Stellen Sie sicher, dass keine wichtigen Daten in Abfrage-Zeichenketten weitergegeben werden, da diese protokolliert werden und darüber hinaus in der Browser-Adressleiste des Clients deutlich zu sehen sind.

 

Sitzungsverwaltung

Da Webanwendungen auf dem statusfreien HTTP-Protokoll basieren, erfolgt die Sitzungsverwaltung auf Anwendungsebene. Untersuchen Sie den in Ihrer Anwendung verwendeten Ansatz für die Sitzungsverwaltung, da dieser sich direkt auf die gesamte Sicherheit der Anwendung auswirkt. In Tabelle 5.6 werden die häufigsten Sicherheitslücken bei der Sitzungsverwaltung genannt.

Tabelle 5.6 Häufige Sicherheitslücken bei der Sitzungsverwaltung

Sicherheitslücken

Auswirkungen

Weitergabe von Sitzungs-IDs über nicht verschlüsselte Kanäle

Angreifer können Sitzungs-IDs abfangen, um eine Identität vorzutäuschen.

Verlängerte Sitzungsdauer

Hierdurch wächst das Risiko von Sitzungsübernahmen und Replay-Angriffen.

Unsichere Sitzungsstatus-Speicher

Angreifer können auf die privaten Sitzungsdaten eines Benutzers zugreifen.

Sitzungs-IDs in Abfragezeichenfolgen

Sitzungs-IDs können auf dem Client einfach geändert werden, um Identitäten vorzutäuschen und als anderer Benutzer auf die Anwendung zuzugreifen.

Überprüfen Sie anhand der folgenden Fragen die Behandlung vertraulicher Daten in Ihrer Anwendung:

  • Wie werden Sitzungs-IDs ausgetauscht?

  • Wird die Sitzungsdauer beschränkt?

  • Wie wird der Sitzungsstatusspeicher geschützt?

Wie werden Sitzungs-IDs ausgetauscht?

Untersuchen Sie die von der Anwendung zur Verwaltung der Benutzersitzungen verwendete Sitzungs-ID und wie die Sitzungs-IDs ausgetauscht werden. Folgende Probleme müssen berücksichtigt werden:

  • Werden die Sitzungs-IDs über nicht verschlüsselte Kanäle weitergegeben?
    Wenn Sie den Sitzungsstatus mit Sitzungs-IDs verfolgen - beispielsweise mit in Cookies enthaltenen Token - untersuchen Sie, ob die ID oder das Cookie nur über einen verschlüsselten Kanal wie SSL weitergegeben wird.

  • Werden Sitzungscookies verschlüsselt?
    Wenn Sie eine Formularauthentifizierung verwenden, stellen Sie sicher, dass die Authentifizierungscookies von der Anwendung über das Attribut protection="All" des Elements <forms> verschlüsselt werden. Dieses Verfahren wird zusätzlich zu SSL empfohlen, um das Risiko eines XSS-Angriffs zu verringern, bei dem das Authentifizierungscookie eines Benutzers entwendet wird.

  • Werden Sitzungs-IDs in Abfragezeichenfolgen weitergegeben?
    Stellen Sie sicher, dass keine Sitzungs-IDs in Abfragezeichenfolgen weitergegeben werden. Diese Zeichenfolgen können auf dem Client einfach geändert werden, so dass ein Benutzer als ein anderer Benutzer auf die Anwendung und die privaten Daten anderer Benutzer zugreifen und potenziell Berechtigungen erweitern kann.

Wird die Sitzungsdauer beschränkt?

Untersuchen Sie, wie lange eine Sitzungs-ID von Ihrer Anwendung als gültig betrachtet wird. Diese Zeit sollte in der Anwendung begrenzt sein, um die Gefahr von Sitzungsübernahmen und Replay-Angriffen zu verringern.

Wie wird der Sitzungsstatusspeicher geschützt?

Untersuchen Sie, wie der Sitzungsstatus in der Anwendung gespeichert wird. Der Sitzungsstatus kann im Webanwendungsprozess, dem ASP.NET-Sitzungsstatusdienst oder einem SQL Server-Statusspeicher gespeichert werden. Wenn Sie einen Remotestatusspeicher verwenden, stellen Sie sicher, dass die Verbindung vom Webserver zum Remotespeicher mit IPSec oder SSL verschlüsselt ist, um die Daten im Netzwerk zu schützen.

Weitere Informationen zum Schützen des ASP.NET-Sitzungsstatus finden Sie unter "Sitzungsstatus" in Modul 19, "Schützen der ASP.NET-Anwendung und -Webdienste".

 

Kryptografie

Wenn Sie in Ihrer Anwendung Kryptografie für die Sicherheit verwenden, untersuchen Sie, wofür und in welcher Weise sie eingesetzt wird. In Tabelle 5.7 werden die häufigsten Sicherheitslücken bei der Kryptografie genannt.

Tabelle 5.7 Häufige Sicherheitslücken bei der Kryptografie

Sicherheitslücken

Auswirkungen

Verwenden benutzerdefinierter Kryptografie

Diese ist fast immer unsicherer als die bewährte Plattform-Kryptografie.

Verwenden eines falschen Algorithmus oder eines zu kurzen Schlüssels

Neuere Algorithmen und längere Schlüssel erhöhen die Sicherheit.

Keine Sicherung der Verschlüsselungsschlüsssel

Verschlüsselte Daten sind nur so sicher wie der dazu gehörende Schlüssel.

Verwenden desselben Schlüssels über einen längeren Zeitraum

Ein gleich bleibender Schlüssel kann mit der Zeit leichter entdeckt werden.

Überprüfen Sie anhand der folgenden Fragen die Behandlung wichtiger Daten in Ihrer Anwendung:

  • Warum verwenden Sie bestimmte Algorithmen?

  • Wie werden die Verschlüsselungsschlüssel geschützt?

Warum verwenden Sie bestimmte Algorithmen?

Kryptografie bietet nur wirklich Sicherheit, wenn sie richtig angewendet und die richtigen Algorithmen für die richtigen Aufgaben verwendet werden. Die Stärke des Algorithmus spielt ebenfalls eine wichtige Rolle. Überprüfen Sie anhand der folgenden Fragen Ihre Verwendung kryptografischer Algorithmen:

  • Entwickeln Sie eine eigene Kryptografie?
    Unterlassen Sie das. Kryptografische Algorithmen und Routinen sind äußerst schwierig zu entwickeln und richtig einzusetzen. Benutzerdefinierte Implementierungen resultieren oftmals in schwachem Schutz. Sie sind fast immer unsicherer als die bewährten Dienste, die von der Plattform bereitgestellt werden.

  • Verwenden Sie den richtigen Algorithmus mit passender Schlüssellänge?
    Untersuchen Sie, welche Algorithmen Ihre Anwendung zu welchem Zweck verwendet. Längere Schlüssel führen zu höherer Sicherheit, schränken aber die Leistung ein. Eine stärkere Verschlüsselung ist bei für längere Zeit gespeicherten Daten am wichtigsten.

Weitere Informationen zum Wählen der angemessenen Algorithmen und Schlüsselgrößen finden Sie im Abschnitt "Kryptografie" in Modul 4, "Entwurfsrichtlinien für sichere Webanwendungen".

Wie werden die Verschlüsselungsschlüssel geschützt?

Verschlüsselte Daten sind nur so sicher wie der dazu gehörende Schlüssel. Zum Entschlüsseln verschlüsselter Daten muss der Angreifer den Schlüssel und den verschlüsselten Text abrufen können. Untersuchen Sie daher Ihren Entwurf, und stellen Sie sicher, dass die Schlüssel und die verschlüsselten Daten geschützt sind. Richten Sie sich bei der Überprüfung nach folgenden Fragen:

  • Wie werden die Verschlüsselungsschlüssel geschützt?
    Wenn Sie DPAPI verwenden, wird der Schlüssel von der Plattform verwaltet. Andernfalls muss die Schlüsselverwaltung von der Anwendung festgelegt werden. Untersuchen Sie, wie die Schlüssel von der Anwendung geschützt werden. Eine gute Methode besteht darin, DPAPI zum Verschlüsseln der für andere Arten von Verschlüsselung benötigten Schlüssel zu verwenden. Speichern Sie dann den verschlüsselten Schlüssel an einem sicheren Ort, beispielsweise indem Sie ihn in der Registrierung unter einen mit zugriffsbeschränkter ACL konfigurierten Schlüssel platzieren.

  • Wie oft werden die Schlüssel wiederverwendet?
    Verwenden Sie Schlüssel nicht zu oft. Je länger derselbe Schlüssel verwendet wird, desto größer ist die Wahrscheinlichkeit, dass er gefunden wird. Ist in Ihrem Entwurf berücksichtigt, wie und wie oft Schlüssel wiederverwendet werden und wie sie auf den Servern verteilt und installiert werden?

 

Parametermanipulation

Untersuchen Sie, wie in Ihrer Anwendung Parameter verwendet werden. Zu diesen Parametern, die zwischen Client und Server übertragen werden, gehören Formularfelder, Abfragezeichenfolgen, Cookies, HTTP-Header und Anzeigestatus. Bei der Weitergabe wichtiger Daten wie Sitzungs-IDs und der Verwendung von Parametern wie Abfragezeichenfolgen, können Prüfungen auf dem Server mit einfacher Parametermanipulation von einem Client aus leicht umgangen werden. In Tabelle 5.8 werden die häufigsten Sicherheitslücken bei der Parametermanipulation genannt.

Tabelle 5.8 Häufige Sicherheitslücken bei der Parametermanipulation

Sicherheitslücken

Auswirkungen

Keine Überprüfung sämtlicher Eingabeparameter

Ihre Anwendung ist anfällig für Dienstverweigerungsangriffe und Code-Injektion, einschließlich SQL-Injektion und XSS.

Wichtige Daten in nicht verschlüsselten Cookies

Cookiedaten können auf dem Client geändert oder bei der Übertragung im Netzwerk abgefangen und geändert werden.

Wichtige Daten in Abfragezeichenfolgen und Formularfeldern

Diese können einfach auf dem Client geändert werden.

Vertrauen in HTTP-Headerinformationen

Diese können einfach auf dem Client geändert werden.

Ungeschützter Anzeigestatus

Dieser kann einfach auf dem Client geändert werden.

Stellen Sie anhand der folgenden Fragen sicher, dass der Entwurf keinen Parametermanipulationen ausgesetzt ist:

  • Werden alle Eingabeparameter überprüft?

  • Werden wichtige Daten in Parametern weitergegeben?

  • Verwenden Sie HTTP-Headerdaten zu Sicherheitszwecken?

Werden alle Eingabeparameter überprüft?

Überprüfen Sie, ob alle Eingabeparameter, einschließlich der normalen und ausgeblendeten Formularfelder, Abfragezeichenfolgen und Cookies, von der Anwendung überprüft werden.

Werden wichtige Daten in Parametern weitergegeben?

Wenn von der Anwendung wichtige Daten in Parametern wie Abfragezeichenfolgen oder Formularfeldern weitergegeben werden, untersuchen Sie, warum dieser Ansatz gegenüber dem viel sichereren Konzept der Weitergabe einer Sitzungs-ID (zum Beispiel in einem verschlüsselten Cookie) bevorzugt wird. Verwenden Sie diese Informationen, um die Sitzung dem Status eines Benutzers zuzuordnen, der im Statusspeicher auf dem Server aufbewahrt wird. Ziehen Sie bei der Überprüfung folgende Punkte in Betracht:

  • Werden Cookies verschlüsselt, die wichtige Daten enthalten?
    Wenn von der Anwendung ein Cookie mit wichtigen Daten, zum Beispiel ein Benutzername oder eine Rollenliste verwendet wird, sollte dieser verschlüsselt werden.

  • Werden wichtige Daten in Abfragezeichenfolgen oder Formularfeldern weitergegeben?
    Dies wird nicht empfohlen, da die Manipulation von Daten in Abfragezeichenfolgen oder Formularfeldern nicht auf einfache Weise verhindert werden kann. Stattdessen sollten Sie verschlüsselte Sitzungs-IDs verwenden und wichtige Daten im Sitzungsstatusspeicher auf dem Server speichern.

  • Ist der Anzeigestatus geschützt?
    Wenn für Webseiten oder Steuerelemente der Anzeigestatus verwendet wird, um den Status über mehrere HTTP-Anforderungen hinweg beizubehalten, überprüfen Sie, dass der Anzeigestatus verschlüsselt und mit Nachrichtenauthentifizierungscode auf Integrität geprüft wurde. Sie können dies auf Computerebene oder seitenweise konfigurieren.

Verwenden Sie HTTP-Headerdaten zu Sicherheitszwecken?

Stellen Sie sicher, dass bei der Webanwendung keine Sicherheitsentscheidungen auf Basis der Informationen in HTTP-Headern getroffen werden, da ein Header leicht von Angreifern manipuliert werden kann. Verlassen Sie sich bei der Überprüfung, ob die Anfrage von einer Seite stammt, die von Ihrer Webanwendung erzeugt wurde, nicht auf den Wert des HTTP-Felds "Referer" - so entstehen Sicherheitslücken. Dieses Vorgehen ist prinzipiell unsicher, da das Feld "HTTP-Referer" auf dem Client einfach geändert werden kann.

 

Ausnahmeverwaltung

Untersuchen Sie, wie Ihre Anwendung Fehler behandelt. Sie sollten stets eine strukturierte Ausnahmebehandlung verwenden. Überprüfen Sie außerdem, ob von der Anwendung bei einer Ausnahme zu viele Informationen ausgegeben werden. In Tabelle 5.9 werden die beiden am häufigsten auftretenden Sicherheitslücken bei der Ausnahmeverwaltung genannt.

Tabelle 5.9 Häufige Sicherheitslücken bei der Ausnahmeverwaltung

Sicherheitslücken

Auswirkungen

Keine strukturierte Ausnahmebehandlung

Ihre Anwendung ist anfälliger für Dienstverweigerungsangriffe und Logikfehler. Dies kann die Sicherheit beeinträchtigen.

Es sind zu viele Informationen auf dem Client zugänglich

Ein Angreifer kann diese Informationen für die Planung und Abstimmung von Folgeangriffen verwenden.

Stellen Sie anhand der folgenden Fragen sicher, dass der Entwurf keine Sicherheitslücken bei der Ausnahmeverwaltung aufweist:

  • Verwenden Sie eine strukturierte Ausnahmebehandlung?

  • Geben Sie zu viele Informationen an den Client weiter?

Verwenden Sie eine strukturierte Ausnahmebehandlung?

Untersuchen Sie, wie die strukturierte Ausnahmebehandlung von der Anwendung verwendet wird. Im Entwurf sollte festgelegt sein, dass die strukturierte Ausnahmebehandlung für die gesamte Anwendung konsistent verwendet wird. So erhalten Sie eine robustere Anwendung, bei der gleichzeitig weniger inkonsistente Zustände auftreten, die Sicherheitslücken sichtbar machen.

Geben Sie zu viele Informationen an den Client weiter?

Stellen Sie sicher, dass ein böswilliger Benutzer die übermäßig genauen Informationen in einer Fehlermeldung nicht ausnutzen kann. Überprüfen Sie die folgenden Punkte:

  • Werden Ausnahmen auf dem Server erfasst, behandelt und protokolliert?
    Stellen Sie sicher, dass interne Ausnahmebedingungen nicht außerhalb der Anwendung abrufbar sind. Ausnahmen sollten auf dem Server erfasst und protokolliert, und allgemeine Fehlermeldungen an den Client ausgegeben werden.

  • Verwenden Sie ein zentrales Ausnahmeverwaltungssystem?
    Die beste Möglichkeit der konsistenten Behandlung und Protokollierung von Ausnahmen in der ganzen Anwendung ist ein formalisiertes Ausnahmeverwaltungssystem. Darüber hinaus können Sie dieses System in die Überwachungssysteme einbinden, die zur Überwachung von Zustand und Leistung verwendet werden.

  • Haben Sie einen Satz von benutzerdefinierten Fehlermeldungen erstellt?
    Ihr Entwurf sollte benutzerdefinierte Fehlermeldungen enthalten, die von der Anwendung angezeigt werden, wenn schwerere Fehler auftreten. Stellen Sie sicher, dass diese Fehlermeldungen keine wichtigen Daten enthalten, die von einem böswilligen Benutzer ausgenutzt werden könnten.

    Weitere Informationen zum Entwerfen und Implementieren eines Frameworks für die Ausnahmeverwaltung von .NET-Anwendungen finden Sie im MSDN-Artikel "Exception Management Architecture Guide" unter: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnntmag00/html/secure.asp.

 

Überwachen und Protokollieren

Untersuchen Sie, wie das Überwachen und Protokollieren in der Anwendung verwendet werden. Zusätzlich zum Vermeiden von Ablehnungen hilft eine regelmäßige Analyse der Protokolldateien beim Erkennen von Eindringversuchen. In Tabelle 5.10 werden die häufigsten Sicherheitslücken beim Überwachen und Protokollieren genannt.

Tabelle 5.10 Häufige Sicherheitslücken beim Überwachen und Protokollieren

Sicherheitslücken

Auswirkungen

Fehlgeschlagene Anmeldungen werden nicht überwacht

Einbruchsversuche bleiben unentdeckt.

Überwachungsdateien sind nicht geschützt

Angreifer können ihre Spuren verwischen.

Keine übergreifende Überwachung auf verschiedenen Anwendungsschichten

Die Gefahr einer Ablehnung steigt.

Überprüfen Sie anhand der folgenden Fragen den Ansatz Ihrer Anwendung beim Überwachen und Protokollieren:

  • Haben Sie die wichtigsten zu überwachenden Aktivitäten festgelegt?

  • Haben Sie darüber nachgedacht, wie der Datenfluss für die Identität des Benutzers erfolgen soll?

  • Haben Sie sichere Protokolldatei-Verwaltungsrichtlinien in Betracht gezogen?

Haben Sie die wichtigsten zu überwachenden Aktivitäten festgelegt?

In Ihrem Entwurf sollte angegeben sein, welche Aktivitäten überwacht werden sollen. Folgende Probleme müssen berücksichtigt werden:

  • Werden fehlgeschlagene Anmeldeversuche überwacht?
    Auf diese Weise können Sie versuchte Einbrüche und Kennwortentschlüsselungen entdecken.

  • Werden andere wichtige Vorgänge überwacht?
    Überprüfen Sie, ob andere wichtige Ereignisse überwacht werden, einschließlich des Abrufens von Daten, Netzwerkübertragungen und administrativer Funktionen (zum Beispiel das Aktivieren und Deaktivieren der Protokollierung).

Haben Sie darüber nachgedacht, wie der Datenfluss für die Identität des Benutzers erfolgen soll?

Im Entwurf sollte sichergestellt sein, dass Aktivitäten über mehrere Anwendungsschichten hinweg überwacht werden. Dazu muss die Identität des ursprünglichen Benutzers auf jeder Schicht verfügbar sein.

  • Überwachen Sie verschiedene Anwendungsschichten?
    Untersuchen Sie, ob die Aktivitäten auf jeder Schicht ordnungsgemäß überwacht werden.

  • Wie werden mehrere Protokolle synchronisiert?
    Protokolldateien können für Rechtsverfahren erforderlich sein, um Straftaten nachweisen oder um Ablehnungsfälle regeln zu können. Im Allgemeinen wird die Überwachung als am zuverlässigsten bewertet, wenn die Sicherheitsüberwachungen zum Zeitpunkt des Ressourcenzugriffs und von denselben Routinen erzeugt werden, die für den Zugriff auf die Ressourcen verwendet werden. Stellen Sie sicher, dass in der Anwendung eine Protokolldatei-Synchronisierung erfolgt und Anfrage-IDs in irgendeiner Form protokolliert werden, um sicherzustellen, dass mehrere Protokolldateieinträge verglichen und auf eine einzelne Anforderung zurückgeführt werden können.

  • Wie wird die Identität des ursprünglichen Benutzers weitergeleitet?
    Wenn Sie die Identität des ursprünglichen Benutzers nicht auf Betriebssystemebene weiterleiten, da dieser Ansatz nur eine beschränkte Skalierbarkeit bietet, legen Sie fest, wie die Identität des ursprünglichen Benutzers in der Anwendung weitergeleitet wird. Dies ist für die Überwachung auf mehreren Schichten (und potenziell auch für die Autorisierung) erforderlich.

    Sind außerdem mehrere Benutzer einer einzelnen Anwendungsrolle zugeordnet, sollten Sie überprüfen, ob die Identität des ursprünglichen Benutzers protokolliert wird.

Haben Sie sichere Protokolldatei-Verwaltungsrichtlinien in Betracht gezogen?

Überprüfen Sie, ob Ihre Anwendung berücksichtigt, wie Protokolldateien gesichert, archiviert und analysiert werden. Protokolldateien sollten regelmäßig archiviert werden, um sicherzustellen, dass sie nicht zu groß und ältere Versionen nicht überschrieben werden. Außerdem sollten sie regelmäßig auf potenzielle Eindringversuche überprüft werden. Vergewissern Sie sich auch, dass alle für die Sicherung verwendeten Konten über geringste Berechtigungen verfügen, und alle zusätzlichen Kommunikationskanäle, die nur zu Sicherungszwecken verwendet werden, geschützt sind.

 

Zusammenfassung

Wenn Sie vorab etwas Zeit und Mühe für die Analyse und Überprüfung Ihrer Anwendungsarchitektur und des Entwurfs aufwenden, können Sie die gesamte Sicherheit verbessern, indem Sie im Entwurf begründete Sicherheitslücken eliminieren. Es ist viel einfacher und billiger, die Sicherheitslücken in der Entwurfphase zu beseitigen als später im Entwicklungszyklus, da dann technische Nacharbeiten in größerem Umfang erforderlich werden können.

Wenn Sie Ihren Entwurf in Bezug auf die Zielumgebung und die dadurch vorgegebenen Sicherheitsrichtlinien betrachten, tragen Sie zur reibungslosen und sicheren Anwendungsentwicklung bei.

Auch wenn die Anwendung bereits erstellt wurde, stellt die Prüfung von Architektur und Entwurf einen wichtigen Teil der Bestandsaufnahme dar, der Ihnen beim Beseitigen von Sicherheitslücken hilft und zu besseren zukünftigen Entwürfen führt.

 

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Quellen.