- Es gibt nicht viele Leute, die sich gegen den Einsatz von WAFs aussprechen, deshalb wurde dieser Artikel geschrieben. Die meisten Suchergebnisse zu WAFs stammen von WAF-Anbietern
- WAFs wurden in den frühen Tagen des Internets entwickelt. Sie fangen jede HTTP-Anfrage ab und werten Hunderte reguläre Ausdrücke aus, um Anfragen zu blockieren, die SQL, Shellcode usw. ähneln
- In den Anfängen der Cybersicherheit schienen WAFs eine gute Idee zu sein, heute ist das nicht mehr der Fall
- Wegen Leistungsproblemen, leichter Umgehbarkeit, des Risikos als Angriffsvektor und hoher False-Positive-Raten gibt es heute bessere Sicherheitstechnologien
Die Leistung von WAFs ist miserabel
- WAFs führen für jede Anfrage Hunderte reguläre Ausdrücke aus, was zu Leistungseinbußen führt
- Beim Einsatz von WAFs ist erheblich zusätzlicher RAM erforderlich, die durchschnittliche Upload-Zeit, die Verarbeitungsgeschwindigkeit von Anfragen und die CPU-Auslastung steigen, und es kommt auch zu fehlerhaften Blockierungen
WAFs lassen sich leicht umgehen
- Im ständigen Wettlauf zwischen WAFs und Angreifern haben die Angreifer die Oberhand
- Mit komplexer Syntax und Encoding-Techniken lassen sich WAF-Regeln umgehen
- Zum Beispiel lässt sich der Log4shell-Angriff nicht durch einfache String-Prüfungen blockieren, und Angreifer können verschiedene Umgehungstechniken einsetzen (Log4J Lookup)
- Außerdem wird ein WAF nutzlos, wenn die Angriffszeichenkette mit etwa 8 KB überflüssiger, aber harmloser Zeichen aufgefüllt wird, da der WAF dann nicht weiter in den RAM puffern kann und abschneidet
WAFs sind ein Angriffsvektor
- 2019 kam es bei Capital One durch eine Fehlkonfiguration des WAFs zu einem Vorfall, bei dem 100 Millionen Kreditanträge offengelegt wurden
- Berichten zufolge täuschte der Angreifer den WAF, um Anfragen an den EC2-Metadatenservice zu senden, und erhielt so Anmeldedaten, mit denen sensible Dateien aus S3 gelesen werden konnten
- Das heißt, Fehlkonfigurationen von WAFs können Sicherheitsvorfälle verursachen
- Die meisten WAFs sind komplex und oft als Closed Source entwickelt, was die Angriffsfläche vergrößert
- Da es sich um teure „Enterprise“-Produkte handelt, packen Unternehmen sie mit unnötigen Funktionen voll, damit sie gegenüber Konkurrenzprodukten auffallen
- Grundlegende Sicherheitsprinzipien für Sicherheitsprodukte werden oft ignoriert
Hohe False-Positive-Rate bei WAFs
- In den vergangenen 20 Jahren wurden Open-Source-Regelsätze für WAFs erheblich erweitert, um moderne Angriffstypen zu erkennen. Proprietäre WAFs dürften dasselbe tun
- Das bedeutet, dass immer mehr Zeichenfolgen existieren, die beim Betrieb eines WAFs zur Blockierung einer Anfrage führen können
- Jedes Mal, wenn neue Regeln hinzukommen, steigt durch die Erweiterung der WAF-Regeln auch die False-Positive-Rate
- „WAFs der nächsten Generation“ behaupten, dieses Problem zu lösen, indem sie mehrere Anfragen prüfen oder IP-Reputationssysteme verwenden
- Das mag die False-Positive-Rate verbessern, kann das Problem von Fehlalarmen aber nicht vollständig lösen
- Durch Fehlalarme haben Nutzer und Support-Teams möglicherweise kein klares Verfahren zur Problemlösung
Alternativen zu WAFs
- Isolation: Techniken, die sicherstellen, dass die Kompromittierung eines Teils des Systems keine Auswirkungen auf andere Teile hat
- Browser erreichen dies, indem sie sämtlichen Code in speziellen Sandbox-Prozessen ausführen, die keinen beliebigen Zugriff auf Cookies, gespeicherte Passwörter oder andere Tabs haben
- Microservices wurden mit Blick auf Isolation entworfen, aber dasselbe lässt sich auch als Monolith mit verschiedenen Bibliotheken und Sprachen umsetzen
- Immutability: Eliminierung ganzer Angriffskategorien durch schreibgeschützte Dateisysteme, Paketmanager, die einen Neustart erfordern, und Backups, die nur erweitert werden können
- Statische Analyse: Einsatz von prepared statements zur Verhinderung von SQL-Injection sowie Codeprüfung durch statische Analyse in CI-Pipelines
- Capability-based Security: Nicht jeder API-Endpunkt muss unbegrenzten Zugriff auf Datenbank und Dateisystem haben; stattdessen werden nur die jeweils benötigten Berechtigungen vergeben
5 Kommentare
:+1:
Mit der Kombination aus nginx + naxsi trifft wohl nichts von dem Obigen zu.
Das WAF-Regelwerk muss so gehandhabt werden, dass die Service-Entwickler es pflegen.
Sicherheitsexperten nehmen ohne Verständnis für den Service allgemeine Einstellungen vor, was zu einer hohen False-Positive-Rate führt, und indem auf Anfrage die Regelsets einzeln gelöscht werden, geht die eigentliche Funktion des WAF verloren.
Ich stimme den Punkten zu Bypässen und False Positives teilweise zu, aber insgesamt wirkt es stark so, als würden unsichere Informationen aufgelistet, als wären sie Fakten. Wenn ich Zeit habe, sollte ich mir wohl auch den Originaltext ansehen. Gerade das CapitalOne-Beispiel als Problem des WAF einzuordnen, zeigt meines Erachtens, dass der Autor des Originaltexts nur ein sehr begrenztes Verständnis von WAFs hat. Ein WAF ist keine Lösung, die Schwachstellen grundlegend mitigiert. Schwachstellen, die im Code entstehen, sollten richtigerweise auch im Code behoben werden. In der Realität ist das jedoch oft nicht möglich, weshalb man irgendetwas Geeignetes braucht, das verdächtige oder bösartige Inputs vorgelagert prüft. Wenn man so etwas gut betreibt, kann es wirklich ein sehr gutes Werkzeug sein; wenn man es nicht gut betreibt, wird es zu einem Messer, an dem man sich selbst verletzt. Diese Doppelseitigkeit von Werkzeugen gibt es immer, aber dieses Thema scheint die schlechten Seiten zu stark zu betonen.
In den Hacker-News-Kommentaren gibt es dazu verschiedene Meinungen und Gegenargumente. Sieh sie dir ebenfalls an
https://news.ycombinator.com/item?id=38255004