Was immer noch durch WAF geht: Umgehungstechniken und wie man Abhilfe schafft

Der Glaube, dass eine WAF mit einem Sicherheitsperimeter gleichzusetzen ist, gehört zu den teuersten, die ein technisches Team ertragen kann. WAFs arbeiten mit Darstellungen von Anfragen – empfangen Bytes, interpretieren gemäß Regeln und entscheiden, ob das Muster mit einem bekannten Angriff übereinstimmt. Das Problem besteht darin, dass zwischen der WAF-Interpretation und der Anwendungsinterpretation eine Lücke besteht. Angreifer, die sich dieser Lücke bewusst sind, nutzen sie mit Techniken aus, die es seit mehr als einem Jahrzehnt gibt und die weiterhin wirksam sind, weil sie auf Mehrdeutigkeiten in HTTP-Protokollen und nicht auf spezifischen Fehlern im Produkt basieren.

Wie die Doppelkodierung die Nutzlastprüfung umgeht

Die URL-Kodierung ist ein legitimer HTTP-Mechanismus: ' (einfache Anführungszeichen) kann als %27 dargestellt werden. Die meisten WAFs dekodieren diese Kodierung, bevor sie die Regeln anwenden – korrektes Verhalten, da die Anwendung sie auch dekodiert.

Das Problem tritt bei der Doppelkodierung auf. Der String %2527 wird in zwei Schritten dekodiert: zuerst zu %27, dann zu '. Eine WAF, die nur eine Decodierungsrunde durchführt, sieht %27 und betrachtet dies als harmlose Darstellung einfacher Anführungszeichen. Die Anwendung führt bei der Verarbeitung der Anfrage ihre eigene Dekodierung durch und gelangt zu dem ', das der Angreifer einführen wollte. Die Ladung kam unversehrt an.

Zu den Variationen gehören die Codierung von Leerzeichen wie %09 (Tab statt Leerzeichen, äquivalent in vielen SQL-Kontexten) und das Mischen von Groß- und Kleinbuchstaben-Codierungen, die einige Regex-Engines nicht normalisieren.

Cloudflare wendet vor der Ausführung von Regeln eine Anforderungsnormalisierung an – eine Kanonisierung, die mehrere Kodierungsebenen rückgängig macht. Dadurch werden die meisten Doppelkodierungstechniken abgemildert, die Wirksamkeit hängt jedoch von der Vollständigkeit der auf jedes überprüfte Feld angewendeten Normalisierung ab.

Schmuggel von HTTP-Anfragen: Wenn WAF und Ursprung nicht übereinstimmen

HTTP/1.1 ermöglicht zwei Möglichkeiten, die Größe des Hauptteils einer Anfrage anzugeben: Content-Length, das genaue Bytes angibt, und Transfer-Encoding: chunked, das den Hauptteil in Teilen sendet. Wenn zwei Header mit widersprüchlichen Werten vorhanden sind, wird das Verhalten nicht durch das Protokoll definiert, sondern durch die Implementierung jedes Servers.

Eine WAF, die Content-Length priorisiert, und ein Ursprungsserver, der Transfer-Encoding priorisiert, sind sich nicht einig darüber, wo eine Anfrage endet. Ein Angreifer, der diesen Konflikt kontrolliert, sorgt dafür, dass die WAF eine harmlose Anfrage sieht, während der Server zwei sieht: die erste legitim, die zweite mit bösartigem Inhalt, der die Prüfung nie bestanden hat. Der Schmuggel von HTTP-Anfragen hat sich im Laufe der Jahre auf mehrere kommerzielle WAFs ausgewirkt und erforderte jeweils spezifische Korrekturen.

Cloudflare normalisiert Anfragen, bevor es sie an den Ursprung weiterleitet. Damit der Angriff auf einer Cloudflare-Architektur funktioniert, müsste der Ursprungsserver direkte Verbindungen empfangen – was uns zum wichtigsten und am wenigsten angewandten Abwehrmechanismus bringt.

Was Cloudflare wirklich nicht schützen kann

Geschäftslogik ist der klarste Fall. Die WAF hat keinen Kontext für ihre Anwendung: Sie weiß nicht, dass eine Übertragung von 50.000 R$ in schneller Folge verdächtig ist, dass auf den Endpunkt /api/export nur mit der Rolle admin zugegriffen werden sollte oder dass discount_percentage keine negativen Werte akzeptieren sollte. IDOR-Angriffe, Manipulation von Preisparametern und Missbrauch von [Authentifizierungsflüssen] erscheinen aus der WAF-Perspektive als gültige Anfragen, weil sie es sind. Dieser Schutz gehört zur Anwendung.

Zero-Days sind der zweite Fall. Wenn ein kritischer CVE veröffentlicht wird, benötigt Cloudflare Zeit, um eine Signatur zu entwickeln. Dieses Intervall kann Stunden oder Tage betragen und während dieses Zeitraums wird die Anwendung auch bei aktiven verwalteten Regelsätzen verfügbar gemacht. WAF-Regeln ersetzen keine Anwendungspatches.

Die einfachste Umgehung: Greifen Sie direkt auf die Quelle zu

Das gesamte Cloudflare WAF-Schutzmodell hängt von einer Bedingung ab: Der Datenverkehr muss den Proxy durchlaufen, um überprüft zu werden. DNS-Einträge im Nur-DNS-Modus – die graue Wolke auf dem Dashboard – passieren den Proxy nicht. Wenn die Subdomain, die die Anwendung bedient, nur DNS ist, existiert die WAF für diesen Datenverkehr einfach nicht.

Die zweite Bedingung ist die Quell-IP. Wenn ein Angreifer die echte IP des Servers herausfindet, kann er sich mit dem richtigen Host-Header direkt mit Port 443 verbinden und den Edge vollständig umgehen. Diese IP wurde möglicherweise über historische DNS, die vor der Migration von SecurityTrails indiziert wurden, Transparenzprotokolle von TLS-Zertifikaten, die direkt an die IP ausgestellt wurden, oder vom Server gesendete E-Mail-Header offengelegt.

Die Abhilfe besteht darin, den Ursprungsserver so zu konfigurieren, dass er nur Verbindungen von den in https://www.cloudflare.com/ips/ veröffentlichten Cloudflare-IP-Bereichen akzeptiert. Eine Sicherheitsgruppe oder Firewallregel, die nur diese Bereiche akzeptiert, verhindert den direkten Kontakt mit der Quelle. Für diejenigen, die offene Ports zum Internet vollständig eliminieren möchten, stellt Cloudflare Tunnel eine ausgehende Verbindung vom Server zum Edge her, ohne dass IP-Adressen offengelegt werden.

Das Bedrohungsmodell, das kommuniziert werden muss

WAF ist gegen eine bestimmte Kategorie von Angreifern wirksam: diejenigen, die automatisierte Scan-Tools verwenden, Nutzlasten nicht anpassen und nach weichen Zielen in großem Maßstab suchen. Gegen Schwachstellenscanner, generische Exploit-Skripte und Bots, die SQL-Injection und XSS für jeden gefundenen Parameter testen, blockiert eine gut konfigurierte WAF die überwiegende Mehrheit der Versuche ohne manuellen Aufwand.

Gegen einen engagierten Angreifer, der die Anwendung untersucht, die Endpunkte zuordnet und die Nutzlasten speziell für diesen Stack anpasst, ist der Schutz anders. Es gibt Umgehungstechniken, einige funktionieren je nach Normalisierungsstatus und der Spezifität der Regeln, und auf den Ursprung kann immer noch direkt zugegriffen werden, wenn die IP durchgesickert ist. WAF verschafft Zeit, reduziert die automatisierte Angriffsfläche und sorgt für mehr Transparenz bei den versuchten Angriffen – es ersetzt jedoch nicht die starke Authentifizierung, die Validierung von Anwendungseingaben, das Patchen von Abhängigkeiten und die granulare Zugriffskontrolle auf Unternehmensebene.