Blog

Web Application Firewalls: Was sie können und was nicht

Was ist eine Web Application Firewall (WAF)?

Eine Web Application Firewall (WAF) ist eine Software, die als eine Art Reverse Proxy für Web-Applikationen dient. Sie arbeitet also auf der Anwendungsschicht des OSI-Modells. Dabei werden die Anfragen an den Webserver und auch teilweise Antworten von diesem auf Angriffsmuster untersucht. Erkennt eine WAF einen Angriff, blockiert sie den Aufruf und verhindert damit hoffentlich die Ausnutzung einer Schwachstelle.

mod_security und das OWASP Core Rule Set

Die bekannteste Open Source WAF ist mod_security, welche ursprünglich für den Apache Webserver entwickelt wurde, aber auch für Microsoft IIS und NGINX verwendet werden kann. Die größeren Distributionen haben Pakete zur Verfügung gestellt, für Windows gibt es einen MSI-Installer. Die Projekt-Homepage ist unter https://www.modsecurity.org/ zu finden. Entwickelt wird mod_security von der Firma Trustwave, die auch kommerzielle Regelsätze anbietet.

Eine WAF nützt freilich nichts ohne Regelsätze – die WAF muss ja wissen, wovor sie schützen soll. Aus diesem Grund hat das OWASP-Projekt das Core Rule Set entwickelt, welche eine grundlegende Absicherung gewährleisten soll. Die Regelsätze hierzu findet man unter https://coreruleset.org/. Hier macht es Sinn, die Regelsätze direkt von Github zu holen, damit auch immer die aktuellste Version im Einsatz ist.

Wie sollte eine Web Application Firewall verwendet werden?

Einfach eine Open Source oder kommerzielle WAF davor zu schalten und danach davon auszugehen, dass die eigene Webanwendung sicher ist, ist falsch. Zum einen muss sichergestellt werden, dass keine gültigen Anfragen blockiert werden (False-Positive). Die WAF muss also eine gewisse Zeit im Monitoring-Mode laufen, damit Ausnahmen für alle gültigen Anfragen erstellt werden können, bevor diese blockiert werden.

Zum anderen sind die Basis-Regeln nicht restriktiv genug. Klar: Auch der Hersteller will möglichst viele False-Positives verhindern. Aus diesem Grund ist die WAF immer an die Applikation anzupassen, um auch die Anzahl der False-Negatives, also nicht erkannte Angriffe, zu minimieren.

Ist die initiale Anpassung erfolgt, hat man schon einmal eine gute Basis, um sich vor einer Reihe von Angriffen schützen zu können. Allerdings ist einer der wichtigsten Schritte danach das permanente Monitoring der Blockierungen. Es gibt verschiedene Techniken, um die Regelsätze einer WAF auszutricksen, gerade wenn ein Mensch die Angriffe durchführt. In den seltensten Fällen ist dies jedoch „lautlos“, es werden also auch Anfragen blockiert. Blöd nur, wenn das keiner merkt: irgendwann findet der Angreifer vielleicht doch einen Weg an der WAF vorbei. Durch ein permanentes Monitoring wird das zwar nicht verhindert, allerdings hat man die Chance, professionelle Angreifer rechtzeitig zu erkennen und Gegenmaßnahmen einzuleiten.

Wovor kann eine WAF schützen?

Eine Web Application Firewall arbeitet regelbasiert. Eine Regel könnte folgendermaßen aussehen: Ist in einem Anfrage-Parameter ein <script>-Tag vorhanden, handelt es sich wahrscheinlich um einen XSS-Angriff. Diese Anfrage sollte also blockiert werden. Gleiches gilt für SQL-Injections und andere Angriffe, die ein Muster erkennen lassen (z.B. XXE). Je nachdem wie effektiv die Regeln sind, kann eine Vielzahl dieser Angriffe abgefangen werden. Wichtig ist, dass man das vorher testet: Gerade wenn ein Rich-Text-Editor in die Applikation integriert ist, stehen die Chancen gut, dass die WAF dazwischenfunkt.

Es gibt auch WAF-Systeme, die Brute-Force Angriffe erkennen oder die HTTP-Response Codes auswerten und intervenieren, wenn zu oft ein anderer Code als 200 OK zurückgegeben wird.

Eine WAF spielt seine Stärken also vor allem gegen automatisierte Angriffe aus und kann helfen, wenn für eine Schwachstelle noch kein Patch vom Hersteller bereitgestellt wurde.

Eine WAF als (D)DoS-Schutz?

Zuerst einmal: wir sind keine Experten für die Verteidigung gegen (D)DoS-Angriffe. Da wir aber schon mehrfach darauf angesprochen wurden, hier unsere Gedanken zum Thema WAF und (D)DoS-Schutz. Man kann Denial-of-Service-Angriffe stark vereinfacht in zwei Kategorien einteilen. Die einen versuchen durch Software-Fehler die Rechenleistung massiv in die Höhe zu treiben. In einem gewissen Rahmen können WAFs vor sowas schützen, vor allem wenn diese nicht spezifisch für die Applikation sind, sondern den Webserver betreffen und geeignete Regeln dafür vorhanden sind. Die WAF kann dann die entsprechenden Anfragen blockieren.

Die andere Möglichkeit für einen Denial-of-Service ist über die Bandbreite. Der Angreifer schickt einfach so viele Daten, bis die Leitung dicht ist. Spätestens seitdem das Mirai-Botnetz gezeigt hat, dass auch DDoS-Angriffe im Terabit-Bereich durchführbar sind, sollte klar sein, dass hier eine WAF wenig ausrichten kann. Um solche Angriffe abzuwehren, muss schon viel früher angesetzt werden, beispielsweise indem ein Dienst wie CloudFlare davor geschaltet wird. Auch manche Cloud-Provider bieten DDoS-Schutz-Systeme und auch nur dort hat man einigermaßen die Chance, etwas dagegen auszurichten. Steht die WAF im eigenen Rechenzentrum, nützt auch eine 10G-Leitung nichts.

Wovor kann eine WAF nicht schützen?

Zuallererst muss einem klar sein: eine Web Application Firewall ist nichts weiter als ein Notnagel für eine unsichere Applikation. Ist die Applikation sicher programmiert, ist eine WAF in den meisten Fällen Geld- und Zeitverschwendung.

Hinzu kommt: Es gibt Schwachstellen, die eine WAF einfach nicht erkennen kann. Ein Beispiel ist das Berechtigungsmanagement. Nehmen wir an, ein Benutzer verfügt nur über Leserechte und sendet nun einen schreibenden Aufruf. Eine WAF muss erstmal wissen, von welchem Benutzer der Aufruf kommt und welche Rechte der hat. Dann muss die WAF wissen, ob die aufgerufene Ressource besondere Rechte benötigt. Die WAF müsste also das Berechtigungsmanagement der Applikation nachbilden, um vor solchen Angriffen zu schützen.

Das sind dann übrigens auch nur die Aufrufe auf Funktionsebene. Viel schwieriger wird es auf Datensatzebene. Angenommen ein Benutzer hat Schreibrechte, aber nur auf die Datensätze 1, 2 und 3. Die WAF kann nicht entscheiden, dass der schreibende Aufruf auf Datensatz 4 blockiert werden muss. Das kann nur die Applikation, die hoffentlich entsprechend abgesichert und geprüft ist.

Selbst wenn man einer WAF das komplette Berechtigungsmanagement beibringen kann: Es gibt immer noch mindestens eine Schwachstellenkategorie, die bisher kein automatisiertes System finden konnte: Logikfehler. Vor ein paar Jahren hatte ich einen Pentest auf einen Webshop. Bei diesem war es möglich, den Bezahlvorgang beim Checkout zu überspringen. Die Bezahlung wurde über einen externen Dienstleister abgewickelt, der – je nachdem, ob die Zahlung erfolgreich war oder nicht – auf eine successURL oder errorURL weitergeleitet hat. Hat man nach der Weiterleitung einfach die successURL aufgerufen, wurde die Bestellung als bezahlt markiert, da die Rückgabewerte des Zahlungsdienstleisters nicht ausgewertet wurden. Auch mit künstlicher Intelligenz und Deep Learning sehe ich keinen Weg, wie diese Art von Logikfehlern durch eine WAF verhindert werden können.

Fazit

Eine Web Application Firewall kann vor einer Reihe von Angriffen effektiv schützen und hilft auch mal, wenn ein Hersteller seine Software nicht rechtzeitig patcht. Eine WAF zu installieren und zu hoffen, dass man sicher ist, bringt allerdings nichts. Die WAF muss an die eigene Applikation angepasst werden, damit sie optimal funktionieren kann. Danach muss ein permanentes Monitoring auf Angriffe stattfinden, damit man im Ernstfall reagieren kann.

Außerdem gibt es auch jede Menge Schwachstellen, vor der eine WAF gar nicht oder nur schwer schützen kann. Bevor man also Unmengen Zeit und Geld in die Anschaffung einer WAF investiert, sollten diese Ressourcen lieber in die sichere Entwicklung gesteckt werden. Ich vertrete nämlich die Meinung, dass eine sichere Applikation nur in ganz wenigen Ausnahmefällen eine WAF benötigt.

Menü