Cybersicherheit

Wie testete Cloudflare eine WAF mit fortschrittlichen KI-Modellen?

Cloudflare verwendete ein adaptives Testsystem auf Grundlage von KI-Modellen, um die Formate von Angriffsanfragen anhand der WAF-Antworten zu verändern, und protokollierte 1.107 Versuche über sechs Angriffskategorien hinweg. Die menschliche Überprüfung führte zu 49 untersuchungswürdigen Ergebnissen und trug zur Verbesserung der SSRF-Erkennung innerhalb des Managed Ruleset bei.

2026-09-29
4 Min. Lesezeit
79 Aufrufe
certi.news Editorial Team
Wie testete Cloudflare eine WAF mit fortschrittlichen KI-Modellen?

Cloudflare testete ihre Web Application Firewall (WAF) mit fortschrittlichen KI-Modellen, die Angriffsanfragen nach jedem Versuch anpassen konnten, anstatt sich auf eine feste Testsammlung zu beschränken. Das Unternehmen führte den Versuch in einer kundenspezifischen Staging-Umgebung mit vorheriger Genehmigung durch und protokollierte 1.107 Versuche in 45 Szenarien.

Die Grundidee besteht darin, einen Teil des Verhaltens eines Angreifers zu simulieren, der verschiedene Kodierungen ausprobieren, die Payload an andere Stellen innerhalb einer HTTP-Anfrage verschieben oder die Darstellungsweise des Ziels ändern kann und anschließend die Antwort nutzt, um den nächsten Versuch auszuwählen. Das Modell erhielt weder den Anwendungscode noch interne WAF-Regeln oder Regelnummern, sondern arbeitete ausschließlich mit dem Anfragekontext und bestimmten HTTP-Antwortdaten.

Wie funktionierte der adaptive Test?

Jedes Szenario begann mit einer Anfrage, von der bekannt war, dass die WAF sie blockiert, woraufhin das Modell eine neue Änderung vorschlug. Nach dem Senden der Anfrage überprüfte ein anderes Modell oder ein Überprüfungsaufruf des Modells die Antwort, bevor das System den nächsten Schritt innerhalb einer maximalen Versuchszahl festlegte. Der Code führte die Anfragen aus und protokollierte die Belege. Außerdem überprüfte er vor jedem Versuch den Domainnamen anhand einer Zulassungsliste, deaktivierte Weiterleitungen und hinderte das System daran, Schutzregeln zu ändern oder bereitzustellen.

44 der Szenarien umfassten sechs Kategorien: Cross-Site-Scripting (XSS), SQL-Injection, Command Injection, Server-Side Request Forgery (SSRF), Path Traversal oder Local File Inclusion (LFI) sowie Log4j-Angriffe. Das 45. Szenario behandelte Log Injection separat.

Von 1.107 Versuchen zu 49 untersuchungswürdigen Ergebnissen

Die WAF zeigte insgesamt eine starke Leistung mit nahezu vollständiger Abdeckung der Kategorien XSS, LFI, SQLi und Log4j. Nach der menschlichen Überprüfung blieben 49 untersuchungswürdige Ergebnisse übrig, von denen 48 den Kategorien Command Injection und SSRF angehörten. Insgesamt wurden 558 Anfragen blockiert, während andere Versuche ausgeschlossen wurden, weil sie ungültig, harmlos oder doppelt waren oder das Ziel nicht erreichten.

Cloudflare betrachtete eine nicht blockierte Anfrage nicht als bestätigte Schwachstelle. Sie musste gültig sein und das Ziel erreichen, eindeutig schädlich bleiben, der WAF zugerechnet werden können und von den Ingenieuren sicher reproduzierbar sein. Diese Unterscheidung ist wichtig, weil die Umgehung einer WAF allein keinen erfolgreichen Angriff auf die Anwendung oder den Zugriff auf sensible Daten beweist.

Beispiel für eine Lücke bei der SSRF-Erkennung

In einem der Szenarien änderte das System die Schreibweise der Adresse des Cloud-Metadatendienstes, verwendete verschiedene numerische Darstellungen und platzierte die Adresse in mehreren Teilen der Anfrage. Die meisten Versuche wurden blockiert, doch einer der Versuche, der eine Darstellung mit einem abschließenden Punkt verwendete, führte zu einer Weiterleitung statt zu einer Blockierung durch die WAF. Cloudflare betrachtete dies als ein untersuchungswürdiges Signal, nicht als Beleg für den Zugriff auf Zugangsdaten oder einen erfolgreichen Angriff.

Was änderte sich in der Praxis?

Cloudflare überprüfte die Ergebnisse, um festzustellen, ob eine neue Regel, eine verbesserte Normalisierung von Anfragen oder ein Eingreifen einer anderen Sicherheitsebene erforderlich war. Die Ergebnisse führten zu drei Änderungen am Managed Ruleset: der Hinzufügung der Erkennungen SSRF - Obfuscated Host und SSRF - Restricted Protocol in der Version vom 21. Juli sowie einer Verbesserung der Erkennung SSRF - Cloud. Die Erkennung des verschleierten Hosts ging direkt aus Anfragen hervor, die ungewöhnliche numerische Formate für interne Adressen verwendeten.

Der Versuch zeigt, dass KI hier ein Werkzeug zur Erweiterung des Testumfangs und kein Ersatz für ingenieurtechnisches Urteilsvermögen ist. Zwei Modelle derselben Familie erzeugten unterschiedliche Varianten, doch die grundlegenden Probleme traten bei beiden auf. Auch eine Erhöhung der Versuchsanzahl innerhalb eines einzelnen Szenarios garantierte keine zusätzlichen Ergebnisse; einige Sequenzen begannen, Ideen zu wiederholen, während mehr Ausgangspunkte, Angriffskategorien und Eingabepositionen eine breitere Abdeckung ermöglichten.

Die Grenzen der WAF bleiben bestehen: Eine Payload, die die Firewall umgeht, ist nur dann erfolgreich, wenn die Anwendung selbst ausnutzbar ist. Daher bleiben die Aktualisierung der Software und die Behebung von Schwachstellen unerlässlich. Cloudflare empfiehlt außerdem, die Regeln zunächst im Protokollierungsmodus zu aktivieren, übereinstimmende Anfragen und Sicherheitsereignisse zu überprüfen und erst danach zur Blockierung überzugehen, nachdem sichergestellt wurde, dass der legitime Datenverkehr nicht beeinträchtigt wird. Das Unternehmen plant später, einen White-Box-Test vorzustellen, bei dem das Modell sowohl die Schwachstellen der Anwendung als auch die WAF-Regeln kennt.

Nachrichtenquelle
Cloudflare Blog
Originalquelle öffnen ↗
c
Autor

certi.news Editorial Team

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen