M 4.361 Sichere Konfiguration von Webanwendungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Eine Webanwendung stellt den Benutzern Informationen und Funktionen zur Verfügung, die mit Hilfe eines Browsers genutzt werden können. Ähnliche Funktionen bieten Web-Services, jedoch wird in diesem Fall die Ausgabe der Ergebnisse nicht für einen Browser aufbereitet. Die Daten werden vom Web-Service in strukturierter Form zum anfragenden System zurückgeliefert. Webanwendungen sind daher zur direkten Kommunikation mit einem Benutzer ausgelegt, während Web-Services zur Kommunikation zwischen Computersystemen bzw. den darauf betriebenen Programmen verwendet werden.

Filterung von Anfragen und Ausgaben

Alle an die Webanwendung herangetragenen Daten, unabhängig von Kodierung oder Form der Übermittlung, müssen als potenziell gefährlich behandelt und entsprechend gefiltert werden. Daher sollte ein generischer, sehr restriktiver Eingabe-Filter implementiert werden. Alle Daten, die an die Geschäftslogiken übermittelt werden, sollten zuvor durch den Eingabe-Filter bearbeitet werden. Die Geschäftslogik ist eine zentrale Komponente einer Webanwendung, die die geschäftsbezogenen Eingaben entgegennimmt, verarbeitet und ausgibt. Bei der Übertragung von Parametern ist die POST-Methode der GET-Methode vorzuziehen.

Ist es für einzelne Funktionen notwendig, den generischen Eingabe-Filter weniger restriktiv zu gestalten, muss dies explizit beim Zugriff auf die Daten definiert und dokumentiert werden. Zusätzlich ist es möglich, kontextsensitive Filter in der Geschäftslogik oder in den Hintergrundsystemen zu implementieren. Auf diese Weise können auf die Funktionen der Geschäftslogik beziehungsweise der Hintergrundsysteme angepasste Filterungen durchgeführt werden.

Um Clients vor etwaigen Angriffen zu schützen, müssen auch die Ausgaben einer Webanwendung gefiltert werden. Beispielsweise können Clients so gegen Cross-Site-Scripting-Angriffe geschützt werden.

Filtermethoden

Für die Filterung stehen verschiedene Methoden mit unterschiedlichen Vor- und Nachteilen zur Verfügung:

Beim Blacklisting wird anhand bestimmter, nicht erlaubter Zeichen beziehungsweise Zeichenketten gefiltert. Der Nachteil dieser Variante ist jedoch, dass nur gegen bekannte Muster gefiltert wird. Zudem schützt diese Art der Filterung nicht vor allen Permutationen von Angriffsmustern und kann somit umgangen werden. Beispielsweise können Zeichen in unterschiedlichen Kodierungsformen dargestellt werden. Werden nicht alle davon gefiltert, besteht die Möglichkeit, dass der Filtermechanismus umgangen werden kann.

Diese Probleme werden beim Whitelisting vermieden, da nur explizit erlaubte Zeichen beziehungsweise Zeichenketten den Filter passieren können. Allerdings müssen bei dieser Variante die Filterregeln an Veränderungen in der Anwendung angepasst werden, da ansonsten auch erlaubte Zeichen(-ketten) abgewiesen werden.

Eine weitere Möglichkeit der Filterung ist das sogenannte "Maskieren". Dabei werden Syntax-spezifische Zeichen durch Voranstellen eines Steuerzeichens besonders als solche gekennzeichnet. Sehr effektiv ist es, vor allem beim Schutz vor Cross-Site-Scripting-Angriffen, wenn Syntax-spezifische Zeichen in Zeichenketten umgewandelt werden, die nicht fehlinterpretiert werden können. Beispielsweise können ausgewählte Zeichen HTML-codiert werden, z. B. kann das Zeichen '>' vor dessen Ausgabe im HTML -Code durch ">" ersetzt werden, ohne dass sich dies negativ auf die Ausgabe im Browser auswirkt. Script-Code kann jedoch nicht mehr ausgeführt werden, wenn alle notwendigen Zeichen HTML-kodiert werden.

Die angeführten Filterungsvarianten können jedoch auch kombiniert werden, um deren Vorteile zu vereinen.

Authentisierung und Benutzermanagement

Es gibt mehrere gängige Authentisierungsverfahren, die den Zugriff auf Webangebote steuern können. Die mit Abstand weiteste Verbreitung hat dabei das Ein-Faktor-Verfahren mit Benutzername und Passwort. Dieses ist für den normalen Schutzbedarf ausreichend, sofern nur über verschlüsselte bzw. vertrauenswürdige Kanäle kommuniziert wird. Authentisierungsverfahren, die mehr Sicherheit bieten, sind Challenge-Response-Verfahren, Einmalpasswörter und zertifikatsbasierte Verfahren.

Wird der Zugriff auf ein Webangebot ausschließlich mittels Benutzername und Passwort geschützt, ist das Passwort das einzig geheime Element. Der Benutzername kann in der Regel nicht als geheim angesehen werden. Dies ist problematisch, da Angreifer so mit diesem Wissen Brute-Force-Angriffe durchführen können. Dabei werden alle möglichen Passwörter zu einem bekannten Benutzernamen automatisiert durchprobiert. Hat der Benutzer ein einfaches Passwort gewählt, das beispielsweise in einem Wörterbuch gefunden werden kann, besteht eine hohe Wahrscheinlichkeit, dass der Angriff Erfolg hat. Um einen solchen Angriff zu erschweren, müssen die Mindestanforderungen an Passwörter in einer Sicherheitsrichtlinie festgelegt werden. Zusätzlich kann eine Teergrube implementiert werden. Diese beiden Maßnahmen werden in den folgenden Abschnitten beschrieben.

Passwortrichtlinie

Im Rahmen einer Passwortrichtlinie sollten Mindestanforderungen an Passwörter definiert werden. Dabei sollten die Kriterien der Maßnahme M 2.11 Regelung des Passwortgebrauchs berücksichtigt werden.

Im Rahmen der Passwortrichtlinie sollte auch definiert werden, ob und welche Passwort-Verwaltungswerkzeuge verwendet werden dürfen. Die Vorgaben der Passwortrichtlinie sollten, soweit möglich, technisch erzwungen werden.

Teergrube

Eine sogenannte "Teergrube" bezeichnet ein System, das einen Angriff verlangsamt, bei dem alle möglichen Passwörter für ein Benutzerkonto durchprobiert werden, ohne das Benutzerkonto längerfristig zu sperren. Um Brute-Force-Angriffe zu unterbinden, kann ein Benutzerkonto nach einer definierten Anzahl an misslungenen Anmeldeversuchen gesperrt werden. Dies bietet allerdings die Möglichkeit eines Denial-of-Service-Angriffs, da ein Angreifer beliebige Benutzerkonten auf diese Weise sperren kann. Mit Hilfe von Teergruben kann dies verhindert werden, wenn ein Benutzerkonto nach Überschreiten der maximalen Anzahl an misslungenen Anmeldeversuchen nicht vollständig, sondern nur für ein begrenztes Zeitintervall gesperrt wird. Je nach Variante können diese Zeitintervalle immer länger werden. Wichtig ist jedoch, dass für die Intervalle sinnvolle Zeitspannen verwendet wird, um die Gefahr von Denial-of-Service-Angriffen zu vermeiden.

Zusätzlich sollten bei der Implementierung von Teergruben Maßnahmen berücksichtigt werden, die gegen verschiedene Verschleierungstaktiken wirken. Versucht beispielsweise ein Angreifer zu einem Passwort einen Benutzer zu finden, ist ein temporäres Sperren des Zugangs auf Basis des Benutzernamens nicht ausreichend. Es sollte daher z. B. überlegt werden, auch die anfragende IP-Adresse beim Verdacht auf einen Angriff temporär zu sperren.

Da ein Angreifer diese Maßnahme mit Hilfe von unterschiedlichen Proxy-Servern ebenfalls umgehen könnte, sollten bei einer signifikant höheren Anzahl an Anmeldeversuchen eine Anmeldeverzögerung bei allen Benutzerkonten aktiviert werden.

"Passwort vergessen"-Funktion

Da es immer wieder erforderlich ist, Passwörter zurückzusetzen, sollte auch eine entsprechende Funktion passend zum Schutzbedarf ausgewählt und sicher implementiert werden (siehe M 2.402 Zurücksetzen von Passwörtern).

Session-Management

Bei der Implementierung von Session-Management können Session-Frameworks verwendet werden, die eine sichere Handhabung der Sitzungsdaten gewährleisten. Session- ID s dürfen nicht als GET-Parameter übergeben werden, sondern nur als Cookie im Header. Cookies sollen nur als http-only-Cookies verwendet werden. Auf diese Weise wird verhindert, dass Session-IDs in Protokollierungsdateien von Webservern erscheinen beziehungsweise lokal im Cache der besuchten Web-Seiten des Clients vorhanden bleiben. Zudem sollte der Austausch von Session-Daten nur über sichere Kanäle erfolgen.

Jede Form von Session-Management kann jedoch durch Cross-Site-Scripting-Schwachstellen kompromittiert werden. Es sollte daher sehr großer Wert darauf gelegt werden, dass derartige Schwachstellen nicht vorhanden sind.

Session-IDs müssen mit Hilfe kryptographischer Zufallszahlengeneratoren zufällig erzeugt werden. Nach der erfolgreichen Authentisierung muss eine neue Session-ID vergeben werden. Um Session Riding zu verhindern, können zusätzlich Authentisierungsmerkmale (z.B. Chipkarten, TANs) bei sicherheitskritischen Anfragen wie z. B. wenn eine Transaktion angestoßen oder ein Benutzerkonto gelöscht wird, verwendet werden. Als Session Riding werden Angriffe bezeichnet, bei denen (ungewollt) Anweisungen in der Session eines Opfers ausgeführt werden. Beispielsweise können in URLs Anweisungen übertragen werden, die in einer aktiven Session des Benutzer das Passwort ändern oder andere Anweisungen ausgeführen.

Sicherheitskritische Eigenschaften eines autorisierten Benutzers, wie z. B. Berechtigungen, dürfen nur serverseitig gespeichert werden. Cookies, die auf dem Client abgelegt werden, sind dafür nicht geeignet und dürfen ausschließlich für die Ablage der Session-ID verwendet werden. Die Session-IDs dürfen nur serverseitig den Berechtigungen zugeordnet werden. Session-Daten sind zudem in geeigneter Weise zu schützen (beispielsweise durch Ablage in ein geschütztes Temporär-Verzeichnis oder durch Verschlüsselung).

Session Time-outs können helfen, Brute-Force-Angriffe zu erschweren. Dabei wird nach einer gewissen Zeit, in der ein Benutzer keine Aktionen mehr an der Webanwendung durchgeführt hat, die Session beendet und der Benutzer abgemeldet. Einem Angreifer steht dadurch nur ein begrenzter Zeitraum zur Verfügung, in dem er alle möglichen Session-IDs durchprobieren und dadurch eine Sitzung übernehmen kann. Um die Session-IDs zu schützen, stehen mehrere Möglichkeiten zur Verfügung, die auch parallel verwendet werden können:

Darüber hinaus muss jedoch auch das manuelle Abmelden von einer Session möglich sein, wobei die Session-Daten gelöscht werden müssen und die Session von diesem Zeitpunkt an als ungültig betrachtet wird.

Je nach Schutzbedarf der Webanwendung kann neben der flüchtigen Authentisierung (bei jedem Zugriff ist erneute Anmeldung erforderlich) auch persistente Authentisierung (Wiedererkennung des Benutzers über dessen Session-ID und damit automatische Anmeldung) eingesetzt werden. Bei persistenter Authentisierung besteht allerdings die Gefahr von Session Riding Angriffen. Schutz gegen Session Riding kann durch einen zusätzlichen Parameter realisiert werden, der zur Laufzeit in jede Antwort des Servers eingeschlossen wird. Dieser Parameter muss für jede Antwort neu mit Hilfe eines Zufallszahlen-Generators erstellt und in alle sicherheitskritischen Links und Formulare eingebettet werden. Ruft der legitime Benutzer einen dieser Links auf bzw. sendet ein Formular an den Server, prüft dieser die Gültigkeit des eingebetteten Parameters. Da nur der Browser eines legitimen Benutzers diesen flüchtigen Parameter kennen kann, wird sichergestellt, dass der Aufruf nicht von einem anderen Client oder durch Klick auf einen externen Link ausgelöst wurde. Man-in-the-Middle-Angriffe, bei denen zusätzlichen Parameter ausgelesen werden können, müssen durch eine gesicherte Übertragung (z. B. mittels HTTPS ) verhindert werden. Es ist jedoch anzumerken, dass die Schutzmaßnahme des zusätzlichen Parameters durch Cross-Site-Scripting-Angriffe ausgehebelt werden kann.

Sicherer Umgang mit Webanwendungen

Um die Sicherheit des Webangebotes nicht zu gefährden, sollte festgelegt werden, ob und wie neue Webanwendungen eingebunden beziehungsweise erzeugt und angenommen werden können. Hierfür muss festgelegt werden, wer für die Pflege des Webangebots zuständig ist (siehe M 2.272 Einrichtung eines Internet-Redaktionsteams). Generell sollten Webanwendungen erst veröffentlicht werden, wenn sie getestet und freigegeben wurden. Durch Fehler in diesem Bereich kann sehr schnell das IT-System vollständig kompromittiert werden, da ein Angreifer die Möglichkeit bekommen kann, beliebige Kommandos mit den Rechten des Webserver-Dienstes auszuführen.

Einbinden von Dateien

Dateien, die von einer Webanwendung eingebunden und ausgeführt werden können, dürfen nicht von Benutzern manipulierbar sein. Darüber hinaus müssen auch die Pfade von eingebunden Dateien vor Manipulation geschützt werden. Werden Dateien über ein Netz eingebunden ("remote include"), muss eine Whitelist sicherstellen, dass diese nur von vertrauenswürdigen Servern kommen können. Andernfalls kann ein Angreifer möglicherweise beliebigen Code in das Webangebot einschleusen. Wird kein Whitelisting unterstützt, dann sollte diese "remote include"-Funktion auf dem Server deaktiviert werden.

Datei-Upload und -Erzeugung

Oft können die Benutzer, die das Webangebot nutzen dürfen, Dateien direkt auf den Webserver kopieren. Beispiele hierfür sind Bilder, die anderen Benutzern zur Verfügung gestellt werden sollen. Damit die Benutzer ohne zusätzliche Applikationen und Server-Dienste, z. B. FTP , die Dateien auf den Webserver kopieren können, wird oft eine "Upload"-Funktion bereitgestellt. Dateien, die von beliebigen Benutzern, auf den Webserver kopiert werden können, müssen folgende Regeln genügen:

Dateien, die nötig sind, um das Webangebot bereitzustellen und Programmcode enthalten, müssen bei Aufruf der entsprechenden URL vom Webserver-Dienst interpretiert bzw. ausgeführt werden. In keinem Fall darf jedoch deren Inhalt (d. h. der Quelltext) an den anfragenden Client zurückgeliefert werden. Dateien, die Programmcode enthalten und vom Webserver-Dienst eventuell nicht als solche erkannt werden, können beispielsweise durch Editoren entstehen (z. B. ".php~" bei Sicherheitskopien). Derartige Sicherungsdateien sind auch oft mit Dateiendungen versehen (z. B. .bak), die dazu führen, dass diese vor der Ausgabe nicht interpretiert werden. Ruft ein Angreifer solche Dateien auf, so erhält er Zugriff auf den Quellcode des Webangebots. Auch bei Konfigurationsdateien ist darauf zu achten, dass diese keine Endungen (z. B. .inc) aufweisen, die Informationen preisgeben können.

Auch temporäre Dateien können sicherheitskritische Informationen beinhalten und müssen daher vor unberechtigtem Zugriff geschützt werden.

Konfigurationsdateien

Grundsätzlich müssen Konfigurationsdaten außerhalb des Quelltextes in entsprechenden Konfigurationsdateien gespeichert werden. Diese Dateien müssen außerhalb des Wurzelverzeichnisses des Webserver-Dienstes abgelegt werden und dürfen von außen (Internet) nicht zugänglich sein. Konfigurationseinstellungen, die vertrauliche Daten beinhalten, sollten zudem verschlüsselt werden.

System- und Fehlermeldungen

Wenn System- und Fehlermeldungen ausgegeben werden, muss sichergestellt werden, dass keine sicherheitskritischen Informationen an Benutzer weitergegeben werden. Fehlermeldungen an Benutzer dürfen nur Informationen beinhalten, die keine Rückschlüsse auf eingesetzte Frameworks oder Hintergrundsysteme zulassen. Beim Auftreten von unerwarteten Fehlern muss dafür gesorgt werden, dass die Anwendung in einen definierten sicheren Grundzustand übergeht. Dies kann durch eine geeignete Fehlerbehandlung ("Error-Handler") realisiert werden. Darüber hinaus müssen alle betroffenen Sessions beendet werden. Bei Produktivsystemen dürfen keine Debugging-Informationen, also detaillierte Fehlermeldungen für Entwickler, ausgegeben werden.

Einsatz von Kryptographie

Webangebote können durch verschiedene kryptographische Mechanismen geschützt werden. So werden kryptografische Methoden genutzt, um Session-IDs zu generieren, Passwort-Hashes auszurechnen, Client- und Server-Zertifikate auszutauschen und um die übertragenen Informationen zwischen zwei Endpunkten zu verschlüsseln.

Beim Einsatz von Kryptographie ist darauf zu achten, dass nur etablierte Algorithmen eingesetzt werden. Diese müssen dem Stand der Technik entsprechen. Eine besondere Bedeutung bei der Kryptographie kommt den verwendeten Schlüsseln zu. Diese müssen je nach Einsatzgebiet über eine gewisse Mindestlänge verfügen und verschiedenen mathematischen Anforderungen (z. B. Komplexität) genügen. Zudem muss für einen entsprechend sicheren Transport beziehungsweise Austausch von Schlüsseln gesorgt werden. Gleiches gilt auch für deren Speicherung. Bei der Gestaltung einer Webanwendung sollten diese Punkte geregelt und in einem Kryptokonzept zusammengefasst werden (siehe B 1.7 Kryptokonzept).

Aufruf von externen Programmen

Werden externe Programme auf dem Server ausgeführt, sollten hierfür nach Möglichkeit keine externen Benutzereingaben verwendet werden. Sollte dies erforderlich sein, so müssen diese Eingaben sehr restriktiv gefiltert werden, um Command-Injection-Angriffe zu verhindern.

Schnittstellen zu Hintergrundsystemen

Ein direkter Zugriff auf Hintergrundsysteme aus der Geschäftslogik heraus darf vom Design her nicht möglich sein. Stattdessen sollten für Zugriffe vordefinierte Prozeduren und Wrapper-Funktionen verwendet werden. Hintergrundsysteme dürfen Webanwendungen nicht vertrauen und erfordern daher eine eigene Authentisierung. Dies bedeutet, dass sich Benutzer nicht nur an der Webanwendung, sondern auch am Hintergrundsystem authentisieren müssen.

Sichere Anbindung von Hintergrundsystemen an die Webanwendung

Webanwendungen sollten in erster Linie über vertrauenswürdige Kanäle an Hintergrundsysteme angebunden werden. Kommunizieren die beteiligten IT-Systeme über über vertrauenswürdige Kanäle, sollte dennoch nicht auf eine Authentisierung verzichtet werden.

Werden die beteiligten IT-Systeme über unsichere Kanäle angebunden, so sollte ein kryptographischer Tunnel mit entsprechender Verschlüsselung und Authentisierung verwendet werden.

Prüffragen: