Sicherheit von Webanwendungen

Die Sicherheit von Webanwendungen ist ein unabdingbarer Aspekt der Entwicklung von Webanwendungen. Mit Hilfe des Ebenenmodells erfolgt eine Aufteilung der einzelnen Teilsegmente an die jeweiligen Verantwortlichen.https://www.owasp.org/index.php/Category:OWASP_Guide_Project Ebenenmodell

Ein Ebenenmodell dient dazu, die Zuständigkeiten für die einzelnen Teilaufgaben bei der Sicherheitskonzeption und Realisierung von Webanwendungen zu ordnen. Ausgangspunkt ist eine Unterteilung in fünf Ebenen: Der Semantik, Logik, Implementierung, Technik, des Systems sowie der Ebene „Netzwerk und Host“.

Angriffsmethoden Es gibt unzählige Möglichkeiten, Schwachstellen in einer Webanwendung zu finden und diese auszunutzen. Im Folgenden findet sich eine Beschreibung allgemein bekannter und oft benutzter Angriffsmöglichkeiten im Zusammenhang mit Webanwendungen.

SQL-Injection

Bei einer SQL-Injection sendet der Angreifer Verbindungsanfragen an den Webserver, wobei die Anfrage-Parameter mit SQL-Steuerzeichen versehen sind. Fängt die Webanwendung diese Steuerzeichen nicht ab, sondern sendet sie als Teil einer SQL-Abfrage an die Datenbank, kann der Angreifer für ihn auf herkömmlichem Weg nicht zugängliche Daten entweder auslesen oder verändern.

Cross-Site-Scripting

Hinter der Bezeichnung Cross-Site-Scripting (XSS) verbergen sich zwei (manchmal wird noch ein dritter Typ unterschieden) grundsätzlich verschiedene Angriffe. Beim clientseitigen XSS schleust der Angreifer HTML-Steuerzeichen und Code einer clientseitigen Skriptsprache, wie z. B. JavaScript, in eine Webseite ein, die in dem Webbrowser des Opfers ausgeführt wird. Dieser Angriff nutzt dabei Sicherheitslücken bei der lokalen Ausführung der Skripte aus oder leitet eine Cross-Site-Request-Forgery ein. Unter serverseitigem XSS versteht man das Einschleusen von manipulierten Informationen in eine auf dem Webserver ausgeführte Scriptsprache, so dass diese beispielsweise bei einem dynamisch generierten include() eine vom Programmierer nicht vorgesehene Datei (ggf. sogar von einem anderen Server) ausführt.

Session Hijacking

Da HTTP ein verbindungsloses Protokoll ist, muss die Webanwendung selbst die Identifikation eines Benutzers feststellen. Dies geschieht anhand einer Session-ID, die als Basic/Digest Authentication, Cookie, URL-Rewriting oder HTTP-Form-Parameter (GET oder POST) jedem Request mitgegeben wird. Beim Session Hijacking versucht der Angreifer Kenntnis von der Session-ID des Benutzers zu erlangen, um dann die Identität des Opfers vorzutäuschen und mit dessen Rechten auf die Webanwendung zuzugreifen.

Cross-Site-Request-Forgery

Cross-Site-Request-Forgery setzen eine bestehende Session zwischen dem Benutzer und der Webanwendung voraus. Dabei versucht der Angreifer über verschiedene Techniken (ggf. XSS) den Benutzer oder über ein clientseitiges Script auch direkt den Browser zum Aufruf einer manipulierten URL zu bewegen. Anders als beim Session-Hijacking erlangt der Angreifer selbst aber keine Kenntnis von der Session-ID, da der Angriff ausschließlich im Browser des Benutzers stattfindet.

Directory Traversal

Bei einem Directory-Traversal-Angriff nutzt der Angreifer die fehlende Prüfung der Webanwendung auf manipulierte Pfadangaben aus. Erwartet die Webanwendung beispielsweise einen Parameter wie item=datei1.html, kann dieser ggf. mit item=../../../Config.sys missbraucht werden.

E-Mail-Injection

Bei einer E-Mail-Injection fügt der Angreifer in ein Kontaktformular manipulierte Daten ein, so dass anstelle der Nachricht an den vom Betreiber der Webanwendung beabsichtigten Empfänger nun beliebige E-Mails an beliebige Empfänger gesendet werden. Diese Möglichkeit wird meist für den Versand von Spam missbraucht.

Man-in-the-Middle-Angriff

Bei einem Man-in-the-Middle-Angriff (MitM) zielt der Angreifer darauf ab, dass der Benutzer anstatt mit dem Webserver vielmehr direkt mit dem Rechner des Angreifers eine Verbindung aufbaut, ohne dies zu bemerken. Der „In-the-middle“-Rechner startet bei jeder Anfrage des Benutzers seinerseits eine Anfrage an den echten Webserver und gibt dessen Antwort an den Benutzer weiter. Der Nutzwert besteht für den Angreifer darin, Anfragen an oder Rückgaben der Webanwendung beliebig manipulieren zu können. Gegen diese Art von Angriff bietet nur die Verschlüsselung der Datenübertragung, beispielsweise mittels SSL, Schutz. Dieser Schutz wird aber unwirksam, wenn sich der Angreifer ein SSL-Zertifikat der betroffenen Webseite verschaffen kann, zu dem ein Root-Zertifikat im Browser des Opfers installiert ist.

Man-in-the-Browser

Man-in-the-Browser ist eine Sonderform des Man-in-the-middle-Angriffs, bei der die Darstellung von Webseiten direkt im Browser verändert wird. Das Programm kann eigenständig Transaktionen durchführen, die vom Nutzer im Normalfall nicht bemerkt werden, da der Nutzer sich auf den echten Seiten der Anbieter bewegt, korrekt angemeldet ist und die unerwünschten Transaktionen für den Nutzer wie normale Vorgänge angezeigt werden.

Denial of Service

Bei einem Denial-of-Service-Angriff (DoS-Angriff) versucht der Angreifer, den Server durch eine Vielzahl von Verbindungsanfragen lahmzulegen. Wird der Angriff gleichzeitig von mehreren (ggf. mehrere tausend) Computern gleichzeitig durchgeführt, spricht man auch von einem Distributed-Denial-of-Service-Angriff (DDoS). Ein DoS ist nicht auf Webanwendungen beschränkt, sondern kann sich gegen jede Art von Server richten.

Mustererkennung Grundlegendes Problem jeder Maßnahme zur Verhinderung von DoS-Angriffen ist die Unterscheidung eines solchen Angriffs von legitimen Zugriffen sowie die gezielte Blockierung des Angreifers, ohne legitime Benutzer in Mitleidenschaft zu ziehen. Ein automatisierter DoS-Angriff kann wirksam dadurch verhindert werden, dass der Benutzer nach Erreichen einer festgelegten Toleranzschwelle von erlaubten Wiederholungen aufgefordert wird, eine Eingabe zu tätigen, die ein Programm nicht liefern kann. Wird die Eingabe korrekt gegeben, kann davon ausgegangen werden, dass kein automatisierter Angriff stattfindet. Folgende Verfahren kommen in Frage: Captcha (Beim Einsatz von Captchas und der Auswahl einer Captcha-Bibliothek ist zu beachten, dass die Sicherheit dieses Verfahrens mit der maschinellen Nichtlösbarkeit der Aufgabe steht und fällt. Fortschritte in der Mustererkennung oder die Entdeckung von Algorithmen können diese Art von Schutz mit einem Schlag wertlos machen.) Rätselfrage (Dem Benutzer wird eine Frage gestellt, die eine Maschine nicht interpretieren und damit nicht beantworten kann.)

Phishing / Identitätsdiebstahl

Beim Phishing handelt es sich nicht um eine Sicherheitslücke einer Webanwendung, es gehört vielmehr in den Bereich des Social Hacking. Hierbei fordert der Angreifer seine potentiellen Opfer meist massenweise per E-Mail auf, Zugangsdaten, wie z. B. PIN und TAN zum Online Banking, auf einer Webseite einzugeben. Diese sieht in der Regel äußerlich so aus wie die des Betreibers der Webanwendung, unterliegt aber der Kontrolle des Angreifers. Nimmt das Opfer diese Fälschung nicht wahr und gibt seine Zugangsdaten preis, kann der Angreifer diese zu seinen Gunsten verwenden. Identitätsprinzip

Das Identitätsprinzip ist eine Art, Webanwendungen und Websites so zu gestalten und darzustellen, dass Benutzer bei einem Phishing-Angriff die gefälschte Seite wahrnehmen und sensible Daten nicht angeben. Dazu muss aus dem Umgang mit der Website, aber auch aus der gesamten Kommunikation mit dem Internetauftritt erkennbar sein, dass der Internetdiensteanbieter bestimmte Muster durchgängig einhält.

Generelle schützende Maßnahmen Data Validation Die Validierung vor allem von Eingangsdaten („input“), aber auch Ausgabedaten („output“) ist der wichtigste Bestandteil einer sicheren Webanwendung. Der Datenfluss ist nicht nur vom Benutzer zur Anwendung und umgekehrt, sondern auch zu den verschiedenen Subsystemen und von dort aus in die Ausgabe zu untersuchen. Im Idealfall werden alle Input- bzw. Output-Daten von einem zentralen „Data-Validation-Modul“ (d. h. einem Programmteil zur Prüfung der Zulässigkeit von Daten) geprüft. In PHP lässt sich so etwas mit Funktionen lösen. Neben den offensichtlichen Eingabedaten in Formular-Variablen (engl. „form variable“ wegen „form“ = Formular) gibt es eine Reihe weiterer Quellen. Alternativ lässt sich Filterung einsetzen. Dies ist immer dann angebracht, wenn keine Nebenwirkungen zu befürchten sind oder wenn die Art der Datenverwendung gefährliche Zeichen oder Zeichenketten aufgrund ihrer Natur erlauben muss. Beispiel: Ein Forum, in dem über JavaScript diskutiert wird, kann nicht die Eingabe von <script> verbieten, muss dieses aber als HTML-Tag validieren. Bei der Filterung ist mit großer Umsicht vorzugehen, denn man läuft permanent Gefahr, eine Variante zu übersehen.

Whitelisting statt Blacklisting Sofern der Input klar definierbar ist, ist es meist sinnvoller, nur bestimmte Eingaben zuzulassen, als bestimmte andere Angaben nicht zuzulassen. Beim Blacklisting werden die Muster definiert, die aus der Eingabe herausgefiltert werden, alles andere wird durchgelassen. Beim Whitelisting ist es umgekehrt: Werte, die nicht ausdrücklich erlaubt sind, sind verboten. Blacklisting ist dann problematisch, wenn als „nicht kritisch“ erkannte Zeichen im Verlaufe der weiteren Verarbeitung zu einem ungewollten Systemverhalten oder auch Fehlern führen. Werden allerdings problematische Muster vergessen oder nicht erkannt oder kommen neue problematische Muster hinzu, so werden sie beim Whitelist-Ansatz hingegen automatisch blockiert. Beim Blacklist-Ansatz werden sie solange durchgelassen, bis die Regeln angepasst werden. Blacklist- oder Whitelist-Verfahren können nicht nur mit festen Schlüsselwörtern benutzt werden. Auch ein Einsatz mit regulären Ausdrücken kann sinnvoll sein.

Behandlung von manipulierten Eingaben Bei der Behandlung von ungültigen Eingaben sollte zwischen nachfolgenden zwei Fällen unterschieden werden: Fehleingaben des Benutzers und bewusste Manipulation. Im ersten Fall ist in benutzerfreundlicher Weise zu reagieren – unter Wahrung des Minimalitätsprinzips. Der Benutzer ist auf den Fehler hinzuweisen. Im zweiten Fall sollte die Reaktion in geeigneter Weise den Manipulationsversuch abwehren. Dann ist zu entscheiden, ob eine Filterung erfolgt oder ob die Weiterverarbeitung abgelehnt wird. Eine erfolgreiche Filterung könnte eine Weiterverarbeitung implizieren. Ein sicheres Kriterium für den Abbruch der Verarbeitung mit einer Fehlermeldung ist immer dann gegeben, wenn die Eingabedaten mit bestimmungsgemäßer Browserbedienung nicht eintreten können, wie z. B.: zusätzliche oder fehlende Formular-Variablen Das Session-Cookie enthält Zeichen, die von der Anwendung nicht vergeben werden, oder es entspricht nicht dem definierten Format. In HIDDEN-, SELECT- oder CHECKBOX-Variablen transportierte Werte wurden verändert oder entsprechen nicht dem Muster, welches die Anwendung gesetzt hat. Die Quelle der Variablen (z. B. GET, POST, Cookie) stimmt nicht mit der Vorgabe der Anwendung überein.

Zu den möglichen Reaktionen auf derartige Fehler können je nach Situation zählen: Die weitere Verarbeitung ist zu stoppen. Es ist zu erwägen, statt einer Fehlermeldung eine Reaktion in dieser Weise vorzunehmen: Dem Benutzer – dem in diesem Fall ein Angriff unterstellt wird – wird der korrekte Umgang mit der Eingabe vorgetäuscht, um seinen Angriffsversuch zu unterlaufen und weiteres Suchen nach Schwachstellen zu erschweren. So würde die Antwort auf das manipulierte Absenden eines Kontaktformulars beispielsweise genauso wie im korrekten Fall lauten: Vielen Dank für Ihre Anfrage, die wir umgehend bearbeiten werden. Es ist zur Hauptseite oder der (neutralen) Seite, die auch bei Zugriffen auf nicht vorhandene Seiten angezeigt wird, zurückzukehren.