Firewalls für Webanwendungen
Abwehr von Angriffen auf Anwendungsebene
Paketfilter versagen jämmerlich, wenn sie mit Angriffen auf Webanwendungen wie Parameter Manipulation, Cross Site Scripting oder SQL Injection konfrontiert werden. Web Application Firewalls können den notwendigen Schutz bieten.
In den vergangenen acht Jahren hat zwar ein stiller, aber um so revolutionärer Fokuswechsel in
den Köpfen der IT-Spezialisten stattgefunden. Dieser Wechsel hat die
Informations-Sicherheitsindustrie und die Hacking-Community gleichermaßen verändert und neu
geprägt. Während die Unternehmen zunächst vollauf damit beschäftigt waren, Herr über Technik und
Prozesse zu werden, um ihre Netze und Betriebssysteme zu sichern, etablierte sich das World Wide
Web als benutzerfreundlicher Zugang zu Kunden und Informationen. Die direkte Folge: Firewalls,
Intrusion-Detection- und -Prevention-Systeme und Härtungsmaßnahmen für Betriebssysteme als
Sicherungsinstrumente reichen nicht mehr. Die Webanwendungen bekamen in einer Zeit, in der sie
extrem schnell verbreitet wurden, bezüglich der Sicherheit nur wenig Aufmerksamkeit geschenkt.
Daran hat sich bis heute wenig geändert. Meist wird als Schutzmechanismus ein mehrstufiges
Paketfilterdesign verwendet, das es erlaubt, die verschiedenen Komponenten einer Webanwendung wie
Frontend-Webserver, Applikationsserver, Backendserver in unterschiedlichen Zonen zu platzieren.
Die in den Zonen eingesetzten Komponenten oder Systeme werden "sicher" konfiguriert und das
Betriebsystem gehärtet. Gelingt es einem Angreifer durch Ausnutzen einer Sicherheitslücke das
System zu kont-rollieren, werden weitere Schäden verhindert, weil zwischen den Zonen nur die Ports
freigeschaltet sind, die für die Anwendung wirklich notwendig sind (Bild 1). Der Nachteil: Die
mehrstufigen Paketfilter sind gegen Angriffe auf Webanwendungsebene völlig machtlos, da sie nicht
unterscheiden können, ob etwa Eingabefelder oder Formulare aus Sicht der Anwendung legal oder
illegal sind.
Bei herkömmlichen Client-/Server-Anwendungen wird auf dem PC des Anwenders eine Client-Software
installiert, die im binären Format vorliegt. Anders stellt sich die Situation bei Webanwendungen
dar, bei denen der Quelltext lesbar auf den Client-PC übertragen wird und somit von jedem
eingesehen und natürlich auch verändert werden kann.
Folglich kann es sehr einfach sein, in der nächsten Anfrage an den Server einen veränderten
Quelltext, eine veränderte URL (Adressleiste des Browsers) oder auch einen Angriffsversuch in einem
Eingabefeld zu senden, der schließlich auf dem Zielserver abgearbeitet wird. Schmuggelt zum
Beispiel ein Hacker einen SQL-Befehl über ein Eingabefeld via Datenautobahn zum Anwendungsserver,
wird dieser Befehl über die erlaubte Verbindung durch den Paketfilter an die Datenbank
weitergegeben. Für den Paketfilter nämlich ist die Welt völlig in Ordnung. Für das Unternehmen gilt
dies danach nicht mehr, denn die Anfrage enthielt möglicherweise eine gefährliche Attacke.
Die Situation heute
Zeitgemäße Webanwendungen bestehen zumeist aus mehreren Ebenen, die separat angreifbar sind. Oft
findet man eine Drei-Ebenen-Architektur, bestehend aus Präsentations-, Logik- und Datenebene. Die
Präsentationsebene nimmt Eingaben auf und bereitet die Ergebnisse für die Darstellung auf. Die
Logikebene übernimmt die Eingaben der Präsentationsebene, bearbeitet sie (möglicherweise mit der
Unterstützung der Datenebene) und gibt das Resultat zurück an die Präsentationsebene. Die
Datenebene stellt zum Beispiel Informationsspeicher zur Verfügung, der von der Logikebene entweder
aktualisisert oder abgefragt werden kann (Bild 2).
Grundsätzlich hat jeder die Möglichkeit, Programme auf dem Webserver mit selbst spezifizierten
Eingaben zu starten. Das Problem: Auch das Einspielen von Patches oder das Härten des Webservers
bringt hier keine Besserung.
Anhand des folgenden Beispiels einer Anfrage für ein PHP-Skript lässt sich dies verdeutlichen.
Die URL lautet:
Die Datei "artikel.php" wird auf dem Remote-Server ausgeführt inklusive der Parameter, die sich
rechts neben dem Fragezeichen befinden. Wenn man sich nun "artikel.php" als ausführbare Datei unter
Win-dows vorstellt (artikel.exe) würde das vorige Beispiel etwa so aussehen:
C:\artikel.exe /id:22 /format: html
Die Lösung: Am naheliegendsten wäre es, diese Angriffe durch eine sichere Programmierung der
Webanwendung zu verhindern. Dazu müsste bei obigem Beispiel der Entwickler das Objekt
(artikel.php), die Parameternamen (id, format) und den Wert des Parameters (22, html), der über
einen HTTP-Request an die Webanwendung geschickt wird, überprüfen. In der Praxis aber finden meist
nur rudimentäre Überprüfungen statt.
Komplett ignoriert werden vielfach Elemente wie Cookies, HTTP-Header, Ses- sion-Informationen in
der URL, versteckte Felder im Quelltext (Hidden Fields) und so weiter. Da das HTTP-Protokoll
keinerlei Statusinformationen eines Anwenders enthält, kann der Angreifer je nach Anwendung zum
Beispiel durch das Ändern des Cookies (Cookie Poisoning, Cookie Stea-ling) oder der
Sessioninformation in der URL auf die bestehende Session eines anderen Anwenders und somit auf
dessen Daten ohne Username und Passwort zugreifen. Auch das Ändern der Werte von Hidden Fields im
Quelltext ist problemlos möglich. Einfacher machen es so genannte "Interception Proxies" die auf
dem PC des Angreifers laufen und die Manipulation der genannten Werte stark vereinfachen.
Bei der sicheren Anwendungsentwicklung muss der Programmierer also davon ausgehen, dass der
Angreifer jegliche Werte manipuliert haben könnte. Zusätzlich müssen Eingabefelder auf
Sonderzeichen und Scripts überprüft werden, da diese – wenn sie an den Backendserver übertragen
werden – zum Beispiel besondere Funktionen auslösen oder über ein externes Programm einen
Shell-Zugang ermöglichen können. So kann beispielsweise die Verwendung eines einfachen
Anführungszeichens (?) in Verbindung mit SQL-Befehlen in einem Eingabefeld eine unerwünschte Aktion
in der Backend-Datenbank auslösen. Ein weiteres Szenario ist ein Angriff, bei dem kriminelle
Eingaben in kodierter Form vorliegen. Wendet der Angreifer Cross-Site-Scripting an, werden die
Sonderzeichen sogar erst später bei der Ausgabe durch den Browser eines ahnungslosen Anwenders
interpretiert und auf dessen PC ausgeführt. Eine Längenüberprüfung sollte zum Schutz vor Buffer
Overflow durchgeführt werden.
Fazit: Der Programmierer sollte zum einen überprüfen, ob der Angreifer Werte, die von der
Webanwendung vorgegeben werden, manipuliert hat, und zum anderen, ob Eingabefelder illegale Inhalte
wie SQL Injec-tion, Cross Site Scripting, Command Injection oder Buffer Overflow enthalten.
Sicher programmieren
Unternehmen sollten sich nicht darauf verlassen, dass ihre eigenen oder externe Entwickler
sicher programmieren. Die Realität nämlich zeigt, dass viele Programmierer sich darauf beschränken,
die oben genannte Punkte nur ansatzweise zu berücksichtigen. Viele Webanforderungen erfüllen die
notwendigen Anforderungen an die Sicherheit deshalb bei weitem nicht. Dies liegt zum einem daran,
dass kein sehr umfassendes Wissen im Bereich Angriffstechniken auf Anwendungsebene vorhanden ist,
und zum anderen daran, dass sicheres Programmieren komplex, aufwändig und folglich teuer ist.
Gleichzeitig muss die Anwendung weiterhin funktionieren. Daher sollte man individuell
entscheiden, welche Zeichen bei der Eingabe erforderlich sind und welche man von vornherein
verbieten kann. Es hat beispielsweise keinen Sinn, wenn ein Anwender "O?Grady" als Username eingibt
und der Request mit Verdacht auf SQL Injec- tion aufgrund des Hochkommas geblockt wird (Bild 3).
Jedes Feld muss deshalb individuell behandelt werden.
Bei gekauften Standard-Webanwendungen "von der Stange" oder beim Outsourcing der Programmierung
von Webanwendungen haben Unternehmen nur geringen oder keinen Einfluss auf die Art und Sorgfalt der
Programmierung. Daher führen einige Anwender so genannte Audits durch, mit denen sie versuchen, die
gefährdeten Stellen der Webanwendungen herauszufinden und – wenn möglich – auch zu beseitigen.
Eine Alternative zu dieser Methode ist der Einsatz einer Web Application Firewall (WAF). Diese
Systeme werden vor der Webanwendung ins Netzwerk integriert und gehen weit über das hinaus, was
klassische Firewall-Hersteller derzeit leisten können. Eine WAF sollte mehrere Webanwendungen
unterstützen und übernimmt somit eine zentrale Rolle in der IT-Landschaft eines Unternehmens. Der
Unterschied zu den klassischen Technologien besteht darin, dass die WAF die zu schützenden
Webanwendungen mit ihren einzelnen Seiten, Eingabefeldern, Parameterwerten und Cookies
interpretieren kann.
Die WAF ist also in der Lage, in den aufgerufenen URLs das Objekt und die Parameter im GET- oder
POST-Request sowie die übertragenen Cookies zu kontrollieren und bösartige Requests zu blockieren.
Als weitere Basisfunktionalität muss sie gewährleisten, dass nur solche URLs aufgerufen werden
dürfen, die auch zur Anwendung gehören. Das System blockiert also den Zugriff auf alle anderen
Ressourcen, die sich unterhalb des Zielverzeichnisses auf dem Webserver befinden, wie etwa
Logdateien, Skripte und Administrationsanwendungen.
Zusätzlich sollte der Response kontrolliert und bei Bedarf geblockt werden, denn
Fehlerbeschreibungen im Response können wichtige Informationen für den Angreifer enthalten. Der
Server-Header, der bei der Standardkonfiguration des Webservers den eingesetzten Servertyp enthält
(zum Beispiel Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev) wird
von den meisten WAFs im Response überschrieben, um für den Angreifer diese einfache Art der
Informationsgewinnung zu verhindern.
Negativ oder Positiv
Grundsätzlich gibt es zwei Ansätze für Sicherheitslösungen: Die negative und die positive
Sicherheitslogik. Bei der negativen Logik wird lediglich definiert, was verboten ist – alles andere
ist erlaubt, wie etwa bei einem Virenscanner.
WAFs werden mit einer vordefinierten Blacklist ausgeliefert, die Muster für gängige
Angriffsarten enthält. Somit bieten sie bereits einen Schutz gegen viele bekannte Angriffe, die auf
diesen Mustern basieren, und es besteht nicht zwingend die Notwendigkeit alle Parameter kennen und
konfigurieren zu müssen. Außerordentlich wichtig ist die Funktion, einzelne Eingabefelder von
dieser Überprüfung auszunehmen, um False Positives zu verhindern. In gewissen Webanwendungen
nämlich, wie zum Beispiel in einem technischen Diskussionsforum, kann es unter Umständen erwünscht
sein, die Möglichkeit einer Eingabe von HTML-Codes oder Scripts zu gestatten.
Bei der positiven, auch als Whitelist bekannten Sicherheitslogik, wird definiert, was erlaubt
ist – alles andere ist untersagt. Dies bedeutet zwar einen größeren Konfigurationsaufwand für den
Administrator, aber auch einen wesentlich konsequenteren Schutz, der auch Day-Zero-Angriffen Paroli
bietet. WAFs sollten eine Kombination beider Möglichkeiten unterstützen. Einen echten Trumpf spielt
die WAF dann aus, wenn sie die Webanwendung entsprechend interpretieren kann, also die positive
Logik überwiegt. Grundlage dabei ist die Erstellung eines Regelwerks, das auch "Policy" genannt
wird. Dabei gibt es zwei Ansätze: Den dynamischen und den statischen. Beim dynamischen Ansatz
definiert der Administrator die gültigen Einstiegsseiten und die WAF zur Laufzeit. Bei jeder vom
Anwender angeforderten Seite werden die im HTML-Code enthaltenen Links inklusive der in der URI
enthaltenen Werte einer dynamischen Policy hinzufügt. Leider kann bei komplexeren Anwendungen, die
client-seitig Javascript einsetzen, diese Möglichkeit häufig nicht sinnvoll genutzt werden.
Javascript nämlich erlaubt, dass die aufzurufende URL mit den zu übergebenden Parametern auf dem
Client erzeugt wird. Dies hat zur Folge, dass der Administrator die betreffenden URLs als
Ausnahmeregel definieren muss – es handelt sich dabei um eins von mehreren Beispielen, bei dem der
Einsatz von Javascript auf dem Client bei der dynamischen Variante prob-lematisch ist. Daher wird
in der Praxis häufig die statische Variante verwendet.
Beim statischen Ansatz erstellt der Administrator eine Policy im Vorfeld des WAF-Einsatzes.
Dieser Vorgang kann manuell geschehen oder mithilfe von Tools automatisiert werden. So kann man die
WAF transparent in den Datenstrom schalten und den Verkehr aufzeichnen lassen. Aus diesen Daten
kann der Administrator dann durch Angabe von vertrauenswürdigen IP-Adressen oder -Bereichen und
eines Zeitraums alle erlaubten Zugriffe in die Policy übernehmen lassen.
Ein weiteres Tool ist der Crawler. Er sollte, ausgehend von der spezifizierten Startseite, alle
Links automatisch verfolgen und somit in kurzer Zeit eine Liste aller URLs inklusive der
Eingabefelder und der statischen Werte für Checkboxen, Radio Buttons und Auswahllisten für
Parameter erstellen und daraus eine Policy entwickeln können.
Die Möglichkeit, Javascript vom Crawler analysieren zu lassen, ist eine wichtige Funktion.
Zusätzlich sollte auch die Möglichkeit bestehen, den Navigationspfad, über den eine bestimmte Seite
aufgerufen werden soll, festlegen zu können. Definiert man zum Beispiel, dass eine Seite "z.html"
erst erreichbar sein soll, wenn der Anwender vorher die Seite "x.html" und danach "y.html"
angefordert hat, würde die WAF einen Request, der direkt auf "z.html" gerichtet ist, blockieren.
Man spricht hier von "Flows", die jeweils mit einem Source- und Destina-tion-Object definiert
werden. Wenige Hersteller bieten zum Feintuning noch einen eigenen Browser an, der ebenfalls bei
der Erstellung der Policy behilflich sein kann. Da die Policy nicht während der Laufzeit dynamisch
generiert werden muss, ist der statische Ansatz wesentlich performanter.
Die Überprüfung, ob ein statischer Wert im HTTP-Request durch den Angreifer verändert wurde oder
nicht, stellt für die meisten WAFs kein Problem dar. Allerdings muss die WAF auch beim Einsatz des
statischen Ansatzes gegen das Ändern von dynamischen Werten, die auf dem Server generiert werden,
schützen können. Dieser dynamische Wert, der während der Laufzeit von der Anwendung generiert wird,
kann zum Beispiel in der URL oder auch in versteckten Feldern (hidden fields) vorkommen. Der
Angreifer könnte diesen Wert einfach ändern und im nächsten HTTP-Request an die Webanwendung
schicken. Eine mögliche Folge wäre dann zum Beispiel, dass sich eine Ware dann zu einem günstigeren
Preis im Warenkorb befände (Bild 4).
Andere Anwendungen verwenden die Ses- sion-ID, die als dynamischer Wert auf dem Server generiert
wird, als eindeutige Identifizierung des Anwenders. Gelingt es dem Angreifer bei einer solchen
Anwendung an die Session-ID eines anderen Anwenders zu kommen, könnte er damit auf dessen
Anwendungssession und somit auf dessen Daten ohne Username und Passwort zugreifen. Um die
IT-Landschaft zu schützen, kann man die WAF so steuern, dass sie zum Beispiel gezielt diesen
dynamischen Wert vom Response extrahiert.
Eine weitere wichtige Aufgabe einer WAF ist die Überprüfung der Cookies. Die WAF muss
verhindern, dass durch den Anwender modifizierte Cookies (Cookie Poisoning) an die Webanwendungen
gelangen. Würde dies dem Angreifer gelingen, könnte er versuchen wie im obigen Beispiel mit der
Session-ID auf die Anwendungs-Session eines anderen Benutzers zuzugreifen. Eine Prüfungsvariante in
der WAF ist es, die Namen und Inhalte aller Anwendungs-Cookies in einem zusätzlichen
Session-Cookie, das nur im Speicher des Clients vorgehalten wird, verschlüsselt und signiert
abzulegen. Werden die Cookies vom Browser zur Anwendung übermittelt – wie es bei jedem HTTP-Request
der Fall ist – erkennt die WAF mittels dieses zusätzlichen Session-Cookies, ob der Angreifer ein
oder mehrere Cookies verändert hat. Einige Anwendungen ändern leider auch client-seitig den Inhalt
von einzelnen Anwendungs-Cookies. Daher ist es wichtig, dass diese Anwendungs-Cookies von der
Überprüfung ausgenommen werden können. Eine andere Variante ist, das die WAF alle
Anwendungs-Cookies verschlüsselt. Dabei gilt, wie vorher beschrieben, das einzelne
Anwendungs-Cookies von der Verschlüsselung ausgenommen werden können. Wenn nämlich die Anwendung
den Inhalt einzelner Anwendungs-Cookies auf dem Client ändert, müssen diese im Klartext
vorliegen.
Die meisten WAFs arbeiten als Reverse Proxy. Sie nehmen stellvertretend für den Webserver oder
den Loadbalancer den HTTP-Request vom Client entgegen, analysieren ihn auf Basis der Policy und
bauen eine neue HTTP-Verbindung mit ihrer eigenen IP-Adresse zum Webserver oder Loadbalancer auf
(Bild 5). Daher ist es für das Logging der Absender-IP-Adressen im Webserver erforderlich, dass die
WAF die ursprüngliche IP-Adresse des Clients zum Beispiel im X-Forwarded-For-Header (XFF)
weiterleiten kann. SSL-Terminierung und hardwarebeschleunigte Ver- und Entschlüsselung inklusive
Key-Handshake sollten heutzutage bei keiner WAF mehr fehlen, da nur unverschlüsselte Daten
analysiert werden können. Ein passiver Monitormodus, bei dem ein bösartiger Request nicht
blockiert, sondern nur als Eintrag in den Reports erscheint, ist nicht nur bei der Inbetriebnahme,
sondern auch für hochsensible Anwendungen interessant. Dadurch besteht zumindest die Möglichkeit,
ohne die Anwendung zu unterbrechen, Aufschluss über alle Angriffe auf die Webanwendung und den
Webserver zu erhalten.
Die ersten kommerziellen WAF-Produkte kamen 2000 auf den Markt. Die Akzeptanz steigt zunehmend,
sodass sich auch diese Technologie weiter verbreiten wird. Einige Analysten sind sich sicher, dass
die Märkte "Web-enabled Application Delivery" und "Web Application Firewall" zusammenwachsen, da
die jeweils zugrunde liegende Technologie und die Positionierung im Netz sehr ähnlich ist. Die
Vorteile der Vereinigung in ein Produkt sind etwa höhere Performance, geringere Kosten und
reduzierter Managementaufwand.
Lesen Sie mehr zum Thema
