Gemäss dem im Mai 2013 publizierten «Website Security Statistics Report» von Whitehat Security hatten 86 Prozent der getesteten Webanwendungen mindestens eine ernsthafte Schwachstelle. Mit ernsthafter Schwachstelle ist gemeint, dass es einem Angreifer mit verhältnismässig wenig Aufwand möglich ist, die Kontrolle über die Website teilweise oder ganz zu erlangen, Benutzer-Accounts zu kompromittieren oder vertrauliche Daten zu entwenden. Sprich: Das Potential für finanzielle Verluste, negative Publizität und damit Imageverlust ist gross. Fast erstaunlicher ist jedoch, dass das Beheben der gemeldeten Schwachstellen im Durchschnitt 193 Tage dauerte. Ein Grund dafür dürfte die Tatsache sein, dass sich viele solcher Schwachstellen mit traditionellen Firewalls und Intrusion-Prevention-Systemen nicht beheben lassen.
(Quelle: www.firewalls.com/blog/what_is_waf/)
WAF vs. sichere Anwendungen
Es gibt grundsätzlich zwei Möglichkeiten, Webanwendungen und damit in Verbindung stehende Daten und Prozesse besser abzusichern. Der erste Weg ist, jede Anwendung unter den erforderlichen Anwendungsbedingungen und Sicherheitsaspekten nach vorgegebenen Richtlinien fehlerfrei zu programmieren. Dieses Vorhaben scheitert aber in der Regel bereits im Ansatz, denn die nachträgliche Integration von Sicherheitsfunktionen in eine bestehende Anwendung ist in den meisten Fällen nicht nur schwierig, sondern vor allen Dingen kostspielig. Ein Beispiel: Ein Programm, das bisher seine Ein- und Ausgaben nicht über zentrale Schnittstellen abgewickelt hat, soll so erweitert werden, dass es die Überprüfung von Daten zulässt. Dann reicht es nicht aus, nur die neuen Funktionen hinzuzufügen. Die Entwickler (wenn sie denn überhaupt noch zur Verfügung stehen) müssen das Programm zunächst genau analysieren und dann tief in seine Grundstrukturen eingreifen. Das ist nicht nur mühsam, sondern birgt zusätzlich auch die Gefahr von neuen Fehlern.
Bei neu zu entwickelnden Webanwendungen stellt sich die Situation nicht viel besser dar. Es gibt keine Software, die jemals auf Anhieb fehlerfrei oder ohne Schwachstellen in den Produktivbetrieb gegangen wäre. Vielfach werden die Mängel erst dann festgestellt. Zu diesem Zeitpunkt ist die Fehlerbeseitigung wieder zeitaufwendig und teuer. Zudem kann die Anwendung in diesem Zeitraum nicht deaktiviert werden, wenn sie als Umsatzträger oder Teil eines wichtigen Geschäftsprozesses agiert. Trotzdem besitzt die Notwendigkeit einer möglichst guten Programmierung, die Effektivität, Funktionalität und Sicherheit sinnvoll vereint, weiterhin oberste Priorität. Je sicherer eine Webanwendung geschrieben ist, desto geringer fallen die Nachbesserungsarbeiten aus und desto weniger komplex gestalten sich die zu ergreifenden zusätzlichen Sicherungsmassnahmen.
Der zweite Ansatz ist der Einsatz einer Web Application Firewall (WAF). Gemäss Untersuchungen von NT Objectives und Whitehat Security lassen sich zwischen 60 und 80 Prozent der identifizierten Schwachstellen in Webanwendungen bereits durch eine WAF ohne spezielle Konfiguration (also im Blacklist-Modus) beseitigen. Zudem lassen sich neu entdeckte Sicherheitslücken mit einer WAF in vielen Fällen wesentlich schneller und günstiger beheben als eine Änderung an der eigentlichen Anwendung. Sichere Programmierung und WAFs ergänzen sich: Analog zum Flugverkehr ist es wichtig, dass das Flugzeug, also die Applikation selbst, gut gewartet und sicher ist. Aber selbst das perfekte Flugzeug ersetzt niemals die
Sicherheitsschleuse am Flughafen, also die Web Application Firewall, die als erste Sicherheitsschicht schon einmal die Risiken eines Angriffs auf das Verkehrsmittel beziehungsweise die Applikation erheblich minimiert.
Funktionsweise einer WAF
Eine WAF soll also Webanwendungen wie Portale, Onlineshops, Intranets oder Cloud Services vor Angriffen über das Internet beziehungsweise das Hypertext Transfer Protocol (HTTP/HTTPS) schützen. Doch wie funktioniert das? Die WAF untersucht dazu alle eingehenden Anfragen und die Antworten des Webservers. Damit stellt sie einen Spezialfall von Application Level Firewalls (ALF) oder Application Level Gateways (ALG) dar.
Obwohl sich in letzter Zeit die Anbieter von traditionellen Netzwerk-Firewalls mit Begriffen wie «Next Generation Firewall» oder «Application Aware Firewall» geradezu überbieten, gibt es aber nach wie vor Unterschiede zwischen einer WAF und einer klassischen Firewall. Im speziellen sind WAF in der Lage , die Kommunikation auf Anwendungsebene Verhaltens-basiert zu analysieren und entsprechend einzugreifen, das heisst unerlaubte Transkationen zu unterbinden. Dabei unterscheiden sie sich auch von klassischen Intrusion-Detection- und Intrusion-Prevention-Systemen (IDS und IPS), die Signatur- und nicht Verhaltens-basiert arbeiten.
Eine WAF kann in verschiedenen Modi operieren: einem negativen (Blacklist), einem positiven (Whitelist) oder einer Kombination daraus. Die Blacklist unterbindet bekannte Attacken wie zum Beispiel Cross Site Scripting oder SQL Injection. Die Whitelist hingegen lässt ausschliesslich zu, was in der zu schützenden Applikation zugelassen ist. Eine effektive Whitelist zu erstellen, ist entsprechend schwierig und aufwendig, setzt vertiefte Applikationskenntnisse voraus und ist kurzlebig. Je nach Hersteller stehen hier Hilfsmittel wie ein Lernmodus zur Verfügung, in welchem die WAF das Verhalten der Applikation über eine gewisse Zeit beobachtet und daraus die richtige Konfiguration vorschlägt. Änderungen an den zu schützenden Webanwendungen sind mit einer WAF normalerweise nicht erforderlich.
Ein einfaches Beispiel der Funktion einer WAF ist die Überprüfung der Parameter eines Formulars: Sind zwei Parameter für ein untersuchtes Formular definiert, kann die WAF alle Requests blockieren, die drei oder mehr Parameter enthalten. Ebenso kann die Länge und der Inhalt der Parameter geprüft werden. Allein durch die Spezifikation allgemeiner Regeln über die Parameter- Beschaffenheit, zum Beispiel der maximalen Länge und des erlaubten Wertebereichs, können viele Angriffe verhindert oder für den Angreifer erschwert werden.
Die WAF wird üblicherweise als Reverse Proxy eingesetzt. Sowohl der Client wie auch der Webserver kommunizieren ausschliesslich mit der WAF. Eine direkte Verbindung zwischen Client und Server wird unterbunden.
Wichtige Evaluationskriterien
Eine WAF kann grundsätzlich in drei verschiedenen Ausprägungen vorkommen: als Modul einer integrierten Gesamtlösung, also zum Beispiel als Teil einer Load-Balancing-Lösung, als Netzwerk-basierte oder als Host-basierte Standalone-Lösung. Je nach Anwendungsbereich ist die eine oder andere Variante zu bevorzugen.
Der Markt für Web Application Firewalls ist noch immer sehr fragmentiert und unübersichtlich (in der untenstehenden Tabelle finden Sie die wichtigsten Hersteller). Es gibt keine allgemeingültige Definition von Funktionalitäten. Zudem legt jeder Hersteller den Fokus auf unterschiedliche Elemente. Das macht insbesondere die Evaluation einer geeigneten Lösung anspruchsvoll und zentral.
Das Open Web Application Security Project (OWASP), eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im Internet zu verbessern, schlägt folgende Evaluationskriterien für WAF vor:
- Möglichst wenig «false positives», das heisst keine Unterbindung von autorisierten, gültigen Anfragen
- Wieviel kann «out of the box», das heisst ohne aufwendige Konfiguration, bereits erreicht werden?
- Wie mächtig ist und wie einfach funktioniert der «Lernmodus»?
- Arten von erkannten Schwachstellen
- Möglichkeit, Benutzer innerhalb einer Session zu behalten
- Fähigkeit, spezifische Probleme mittels Konfiguration zu lösen. Darunter fallen unter anderem «emergency patches» für zu schützende Anwendungen.
- Art der WAF: Software vs. Hardware (OWASP bevorzugt Hardware)
Versteckte Kosten
Um ein konstant hohes Sicherheitsniveau zu gewährleisten, sind nach der richtigen Evaluation sowohl die Erstinstallation wie auch die konstante Pflege der WAF entscheidend. Hier kommt der Faktor Kosten ins Spiel. Was einem viele Hersteller nämlich verschweigen, ist der doch beträchtliche Aufwand für diese beiden Aufgaben. Je nach Komplexität und Funktionsumfang der Anwendung benötigt man schnell mehrere Tage (oder Wochen) für die Inbetriebnahme. Zudem fallen bei allen Änderungen der zu schützenden Applikationen entsprechend wieder Kosten für die Anpassung der WAF an. Insofern ist es zentral, dass eine entsprechende Risiko-Analyse der IT-Umgebung gemacht wird und basierend darauf Investitionsentscheide gefällt werden.
Integration in traditionelle Firewalls
2013 nutzten bereits etwas mehr als die Hälfte aller grösseren Organisationen eine WAF. Es ist davon auszugehen, dass dieser Anteil in den nächsten Jahren mit zunehmender Wichtigkeit von Webanwendungen für Geschäftsprozesse und damit auch für den finanziellen Erfolg von Unternehmen stetig steigen wird. Es ist ebenfalls zu erwarten, dass mittelfristig die Funktionalität von WAFs zunehmend in traditionelle Firewalls integriert wird. Bei all dem darf aber nicht vergessen werden, dass die WAF nur ein Tool ist und keine Kompensation für schlechten Code oder fehlendes Patching von Sicherheitslücken.
Martin Altorfer ist COO des Managed Service Provider Cyberlink. Marc Chauvin ist Head of Engineering bei Cyberlink.
Erweiterte Funktionen einer WAF
Eine WAF kann erweiterte Sicherheitsmechanismen zur Verfügung stellen. Bekannte Beispiele sind die Verschlüsselung von URLs, die Verschlüsselung oder das «Verstecken» von Cookies sowie ein Client-Fingerprinting, um eine «Man in the Middle»-Attacke zu erkennen. Bei letzterem wird versucht, innerhalb einer gültigen Session, welche meist durch ein Cookie identifiziert wird, Änderungen am Client festzustellen (Browser, TCP/IP-Verbindungseigenschaften, usw). Nachfolgend einige weitere, interessante Funktionen einer WAF:
SSL Offloading: Bei Anwendungen die SSL (HTTPS) verwenden, wird die Ver-/Entschlüsselung auf der WAF vorgenommen. Zwischen WAF und Webserver kann in der Regel auf Verschlüsselung verzichtet werden. Dies entlastet den Webserver.
Authentication/Authorization: Die WAF wird vielfach so angewendet, dass ein Benutzer sich zuerst authentifizieren muss. Dabei werden X.509-Zertifikate, Anbindungen an die Active Directory oder Radius-Server verwendet. Der erste Zugriff auf eine Webapplikation wird erst dann gestattet, wenn der Benutzer bereits authentifiziert und autorisiert wurde. In solchen Umgebungen bietet die WAF eine echte Single-Sign-On-Lösung für alle Webapplikationen, die von der WAF geschützt werden.
Load Balancing: Manche Hersteller bieten die Möglichkeit an, nicht nur einen, sondern gleich mehrere Webserver als Backend einzurichten. Die Last wird auf diese verteilt, mit oder ohne «Session Stickiness». Zudem werden die Backend-
Server auf ihre Verfügbarkeit geprüft und bei hoher Last oder Ausfall aus dem Pool entfernt.
Content Rewriting: Kaum eine Webapplikation lässt sich ohne Content Rewriting hinter einer WAF betreiben. Dabei ersetzt die WAF Teile der Antworten des Servers, die für den Client bestimmt sind. Typischerweise müssen URLs, Headers und Body umschrieben werden. Bei Standard-Applikationen (z.B. Outlook Web Access) stehen je nach Hersteller Vorlagen zur Verfügung. Eine grosse Herausforderung beim Rewriting sind die URLs, die mittels Java Script auf dem Client zusammengebaut werden und somit von der WAF nicht oder nur schwer erkannt werden können.
