ALAKEEL

WAF für Pentester

Eine WAF (Web Application Firewall) ist für dich als Pentester im Prinzip ein Filter vor der Web-App, der HTTP(S)-Traffic analysiert und Angriffe wie SQLi, XSS, LFI, RCE etc. blocken oder zumindest erschweren soll.
Ich erklär dir das so, dass du am Ende weißt:

  • Was eine WAF genau macht
  • Wie sie arbeitet (Signaturen, Anomalien, Positivlisten)
  • Wie du sie im Pentest erkennst, umgehst, austrickst
  • Welche typischen Schwächen sie hat

1. Was ist eine WAF überhaupt?

Ein WAF (Web Application Firewall) ist eine Sicherheitskomponente, die HTTP/HTTPS-Traffic zwischen Client (Browser/API-Client) und Webanwendung überwacht, filtert und ggf. blockiert. Sie:

  • Liest und analysiert HTTP(S)-Requests und -Responses
  • Entscheidet anhand von Regeln/Heuristiken, ob etwas:
    • durchgelassen,
    • geblockt,
    • umgeschrieben (normalisiert),
    • geloggt/markiert werden soll
  • Ziel: Angriffe auf Anwendungsebene (OWASP Top 10 & Co.) minimieren

Typische Angriffe, die eine WAF erkennen/blocken soll:

  • SQL Injection
  • XSS
  • Command Injection / RCE
  • Directory Traversal / LFI / RFI
  • Broken Authentication (z. B. brutale Login-Versuche)
  • Path Manipulation
  • bekannte Exploit-Payloads (z. B. /etc/passwd, UNION SELECT, <script> etc.)

Wichtig:
Eine WAF schützt nicht den Server-Port allgemein (das macht eher eine klassische Firewall), sondern konzentriert sich auf HTTP/HTTPS und Applikationslogik-Ebene.

2. Typische Einsatzarten & Architekturen

2.1 Reverse Proxy WAF

  • Klassisch: WAF steht vor dem Webserver.
  • Client -> WAF -> Webserver.
  • WAF terminates TLS (SSL-Offloading) oft, sieht den Klartext-Traffic.
  • Kann Header/Body inspizieren, Regeln anwenden, Antworten modifizieren.

Für Pentester:
Du sprichst eigentlich nur noch mit der WAF – der echte Webserver sieht nur, was sie durchlässt.

2.2 Integrierte WAF (z. B. Module im Webserver oder im Load Balancer)

  • WAF als Modul in:
    • Nginx, Apache, IIS,
    • Load Balancer (F5, Citrix, AWS ALB/WAF, Cloudflare, etc.)
  • Technisch ähnlich, aber du merkst nicht immer, wo sie sitzt.

2.3 Cloud / CDN-basierte WAF

  • Anbieter wie Cloudflare, Akamai, AWS WAF, Azure WAF, usw.
  • Traffic läuft über CDN/WAF-Anbieter, der dann ins Backend routet.
  • Vorteile: DDoS-Schutz, Bot-Schutz, Geo-Fencing, Rate-Limits, etc.

Pentest-Relevanz:
Du testest oft primär die WAF-Regeln des Providers plus ggf. zusätzliche kundenspezifische Regeln.

3. Wie „denkt“ eine WAF? (Detection-Modelle)

WAFs arbeiten meist mit einer Kombination aus mehreren Mechanismen:

3.1 Signatur-basiert (Pattern Matching)

  • Vergleich mit bekannten Angriffsmustern (ähnlich wie Virenscanner).
  • Beispiele:
    • Request enthält UNION SELECT, sleep(, <script>, ../etc/passwd, <?php etc.
    • oder typische Tools-Payloads (sqlmap, wpscan, Nikto usw.).

Vorteil:

  • Einfach, effizient, gut gegen bekannte Angriffe / Standard-Exploits.

Nachteil:

  • Einfach zu umgehen durch:
    • Obfuskation (URL-Encoding, Doppelkodierung, Leerzeichen-Varianten, Kommentar-Einschübe),
    • andere Syntax, andere Groß-/Kleinschreibung,
    • exotische DB-Dialekte, polyglotte Payloads.

Pentest-Fokus: Signature Evasion.

3.2 Anomalie-basiert (Heuristiken, Score-basiert)

  • Jeder Request wird „gewertet“:
    • bestimmte Merkmale (z. B. viele Sonderzeichen, ungewöhnliche Parameter, sehr lange Input-Felder) geben Punkte.
  • Ab einem Schwellwert → Block / Captcha / Challenge.

Beispiele:

  • „Parameter enthält zu viele Sonderzeichen“ → +10
  • „Enthält SQL-Schlüsselwörter“ → +20
  • „Parameterlänge > 1000“ → +5
  • Score ≥ 30 → WAF blockiert.

Vorteil:

  • Erkennt auch Variationen/Unbekanntes bis zu einem gewissen Grad.

Nachteil:

  • False Positives (legitime Requests, die ungewöhnlich aussehen).
  • Kann durch „Verdünnen“ umgangen werden (Payload auf mehrere Requests verteilen, lieber 10 kleinere Angriffe als 1 großen).

3.3 Positivlisten-Modell (whitelisting)

  • „Positives Security Model“:
    Was nicht ausdrücklich erlaubt ist, wird blockiert.
  • Beispiel:
    • Feld age darf nur Ziffern 0–9 umfassen.
    • Feld username nur [a-zA-Z0-9_-].
    • Nur bestimmte Pfade/Parameter-Kombinationen erlaubt.

Vorteil:

  • Sehr sicher, wenn gut gepflegt.
  • Selbst neue Exploit-Techniken haben es schwer.

Nachteil:

  • Hoher Pflegeaufwand → selten richtig konsequent umgesetzt.
  • Änderungen in der App müssen in der WAF nachgezogen werden.

Pentest-Winkel:
Wenn du so eine WAF hast, sind klassische Payloads schwerer, aber du kannst:

  • nach Lücken in den Positivlisten suchen (Felder ohne Regeln),
  • alternative Eingabekanäle nutzen (Header, JSON, Uploads, etc.),
  • Fehlkonfigurationen ausnutzen (z. B. bestimmte Pfade/Namen nicht abgedeckt).

3.4 Kontext- und Protokollvalidierung

  • Überprüfung, ob Requests dem erwarteten HTTP-Protokoll entsprechen:
    • Korrekte Methoden,
    • Korrekte Content-Types,
    • Korrekte Parameterformate.
  • Kann anormalen Traffic erkennen (z. B. binäre Exploit-Daten, Trailing-Junk, etc.).

4. Typische Schutzfunktionen einer WAF

4.1 OWASP Top 10-Abdeckung

Die meisten WAFs werben mit Schutz gegen:

  • SQLi – durch Erkennung von SQL-Patterns oder ungewöhnlichen Zeichenketten.
  • XSS – <script>, onerror=, Event-Handler, javascript: usw.
  • Command Injection – ;, &&, ||, |, $( ), backticks etc.
  • LFI/RFI/Path Traversal – ../, %2e%2e%2f, %252f etc.
  • Insecure Deserialization – bedingt, z. B. Erkennung bekannter Gadget-Ketten oder Serien von Base64-kodierten Objekten.
  • Authentifizierungs- und Bruteforce-Schutz – Rate-Limits, Captchas, IP-Sperren.

4.2 Rate Limiting & Bot-Schutz

  • Limitierung von Requests pro IP / pro Session / pro Pfad.
  • Captcha-/JS-Challenges bei Verdacht auf Bot.
  • Bad-User-Agents blocken.

4.3 Virtuelle Patches

  • Wenn eine neue Schwachstelle in einer Applikation oder einem Framework entdeckt wird (z. B. CVE für eine bestimmte URI), kannst du über eine WAF „schnell“ Regeln einspielen, bevor Code gefixt ist.

Für Pentester wichtig:
Es kann sein, dass du eine Schwachstelle nur hinter der WAF findest – die App selbst ist verwundbar, aber die WAF blockiert die Payload. Das ist trotzdem relevant (WAF ist keine „echte“ Behebung). Eine WAF blockt oft Payload-Strings, nicht die eigentliche Logik-Schwachstelle. Eine IDOR/Access-Control-Lücke wird häufig nicht geblockt, weil sie „legitimer Traffic“ ist.

5. WAF aus Pentester-Sicht: Erkennen, Analysieren, Umgehen

5.1 Woran erkennst du eine WAF?

  • Fehlermeldungen/Blockseiten:
    • Standard-Seiten („Access Denied“, „Request Blocked“, „ModSecurity“, „Cloudflare“, „Akamai“, „WAF ID XYZ“).
  • Ungewöhnliche HTTP-Statuscodes:
    • 403, 406, 501, 502 bei bestimmten Payloads.
  • Verhalten bei schrittweise aggressiveren Payloads:
    • Normaler Request geht durch,
    • sobald du UNION SELECT oder <script> sendest → Block.
  • Header / Response-Patterns:
    • Zusätzliche Response-Header, z. B. WAF-spezifische IDs.
  • DNS/Whois-Hinweise bei Cloud-WAF/CDN.

5.2 Typische WAF-Beschränkungen

  • Inspektion nur in bestimmten Teilen:
    • URL und Query-String, aber JSON-Body wird nicht korrekt geparst.
    • Nur application/x-www-form-urlencoded, aber nicht multipart/form-data.
  • Begrenzte Verarbeitungslänge:
    • Nur die ersten X KB eines Bodys werden analysiert.
  • Protokoll-/Content-Blindspots:
    • WebSockets, spezielle APIs, Datei-Uploads.

Pentest-Idee:
Angriffe in Bereiche verschieben, die die WAF nicht (vollständig) analysiert.

Praktisch für Pentester: WAF erkennen (WAF-Fingerprinting)

1) Symptome im Response
  • Statuscodes: 403/406/429 bei Payloads, die „harmlos“ wirken
  • Headers: server, via, x-... (nicht immer zuverlässig)
  • Blockpage-HTML: „Access denied“, „Request blocked“, Ray IDs etc.
  • Cookies: WAF setzt Tracking/Challenge Cookies
2) Verhalten
  • Ein Payload triggert Block, ein leicht veränderter nicht → typischer WAF
  • Viele Requests in kurzer Zeit → 429 oder Challenge
  • Burp Scanner/Active Scan triggert sofort
3) Tools (vorsichtig einsetzen)
  • wafw00f kann helfen, aber: False Positives/Negatives sind normal.
  • Manchmal besser: manuelles Testen mit 2–3 bekannten Triggern.

Mini-Checkliste zum Erkennen

  • Sende ?q=<script>alert(1)</script> → Block?
  • Sende ?id=1' OR '1'='1 → Block?
  • Sende ../etc/passwd → Block?
    Wenn diese Muster sofort blocken, ist sehr wahrscheinlich eine WAF aktiv.

6. WAF-Umgehung (Evasion)

Wichtig:
Im Pentest-Kontext geht es darum, Schwachstellen trotz WAF aufzuspüren, nicht darum, „sinnlos Krawall“ zu machen. Du dokumentierst meist:

  • Welche Payloads geblockt wurden,
  • welche Umgehungen funktionieren,
  • welche Schwachstellen unter der WAF noch da sind.

6.1 Payload-Obfuskation

Ziel: Die WAF-Regeln triggern nicht, aber die App interpretiert die Payload trotzdem wie beabsichtigt.

Beispiele (allgemein):

  • Encoding/Obfuscation: URL-encoding, double-encoding, Unicode Homoglyphs
    • %27 statt '
    • doppelte Encodings: %2527 → vom Server einmal decodiert → %27 → '
  • Groß-/Kleinschreibung / Leerzeichen / Kommentare:
    • UNION SELECT → UnIoN/**/SeLeCT → WAF erkennt Pattern evtl. nicht.
    • OR 1=1 → oR/**/1=1.
    • Kommentare /**/
  • Alternative Syntax:
    • SQL: Nutzung von Funktionen statt UNION SELECT, z. B. OR 1=1, AND 1=0, Subselects etc.
    • XSS: statt <script>alert(1)</script> → <img src=x onerror=alert(1)>, svg/onload, math-Elemente usw.
  • Polyglotte Payloads:
    • Payloads, die in mehreren Kontexten gültig sind (z. B. HTML+JS+JSON).

6.2 Parameter Pollution & Verteilung

  • HTTP Parameter Pollution:
    • Mehrere Parameter gleichen Namens: id=1&id=UNION SELECT.
    • WAF bewertet beide, aber App nimmt nur den letzten/ersten.
  • Verteilung der Payload auf mehrere Parameter/Requests:
    • App setzt Parameter zusammen, WAF prüft jeden einzeln.

6.3 Wechsel von Methoden / Content Types

  • Wenn POST mit application/x-www-form-urlencoded stark überwacht ist:
    • Versuch mit JSON: application/json.
    • Versuch mit multipart/form-data.
  • Manche WAFs haben schwache JSON-Payload-Parsing:
    • {"name":"test' OR '1'='1"} wird evtl. anders bewertet.
  • GET ↔ POST ↔ PUT (je nach App)

6.4 Nutzung von weniger überwachten Bereichen

  • HTTP-Header:
    • X-Original-URL, X-Forwarded-For, etc.
  • PATH-Infos, Query-Parameter, Cookies.
  • Datei-Uploads:
    • Exploit im File-Inhalt, der später serverseitig verarbeitet wird.

6.5 Rate und Timing

  • Langsame, verteilte Angriffe:
    • statt 100 SQLi-Versuche pro Minute → 1 alle paar Minuten.
  • WAF konfigurierte Thresholds nicht triggern.

7. WAF im Pentest-Report: Was ist wichtig?

  1. WAF erkannt?
    • Vendor/Typ, soweit bekannt (z. B. Cloudflare, ModSecurity, F5 ASM, etc.)
  2. Welche Angriffe wurden offensichtlich geblockt?
    • z. B. Standard-SQLi-Payloads.
  3. Welche Schwachstellen sind trotzdem ausnutzbar?
    • Das ist entscheidend: Eine WAF ist kein Fix.

Du unterscheidest:

  • Technische Schwachstelle in der Anwendung (z. B. SQLi vorhanden).
  • WAF blockiert bestimmte Payloads, aber nicht alle:
    • Du kannst trotzdem injizieren (Evasion).
    • Oder du kannst Schwachstelle theoretisch ausnutzen, wenn WAF deaktiviert würde.

Im Report solltest du klarstellen:

„Die WAF reduziert das Ausnutzungsrisiko, aber die zugrundeliegende Schwachstelle ist weiterhin vorhanden und sollte im Code behoben werden.“

8. Typische WAF-bezogene Findings

8.1 „Security by WAF only“

  • Anwendung hat z. B. SQL Injection, aber WAF blockiert einige Testpayloads.
  • Kunde denkt: „Wir sind sicher, wir haben ja WAF.“
  • Dein Finding:

„Wir konnten nachweisen, dass die Anwendung ohne WAF-Konfiguration SQL-Injection verwundbar ist. Die WAF reduziert das Risiko, kann aber durch Payload-Variationen potentiell umgangen werden. Code-Fix dringend empfohlen.“

8.2 Fehlkonfigurierte WAF-Regeln

  • WAF-Regel zu strikt → legitime Requests werden blockiert (False Positives).
  • Oder zu locker → gefährliche Requests kommen durch.

Pentest-Aspekt:

  • Zeig Beispiele:
    • legitimer Parameter mit bestimmten Sonderzeichen → 403.
    • unsichere Payload durch speziellen Pfad → kein Block.

8.3 Unvollständige Abdeckung

  • Nur bestimmte Pfade/Hosts sind hinter WAF.
  • Admin-Backend oder interne API laufen ohne WAF.

Finding:

„Während die Hauptanwendung über eine WAF geschützt wird, sind administrative Endpunkte / APIs unter admin.example.com nicht durch diese Filterung geschützt. Hier besteht ein höheres Risiko, dass Angriffe unbemerkt bleiben.“

9. Limitierungen von WAFs – wichtig für dein Mindset

Eine WAF kann:

  • viele triviale, automatisierte Angriffe abfangen,
  • Exploit-Versuche verlangsamen/detekten,
  • als temporärer „Virtueller Patch“ dienen.

Eine WAF kann nicht:

  • schlechte Business-Logik reparieren,
  • fehlerhafte Authentifizierungs- und Authorisierungs-Konzepte ersetzen,
  • Applikationsfehler und Design-Flaws heilen.

Beispiele:

  • IDOR / Broken Access Control:
    • /user/1234 vs. /user/1235 → WAF kann schwer beurteilen, ob das „angreifbar“ ist.
  • Logikfehler (Shop-Rabatt, Workflow-Bugs):
    • WAF sieht nur HTTP-Requests, nicht den „Sinn“ dahinter.
  • CSRF (oft nur mit Token-Logik behebbar).

-> Als Pentester: WAF ist ein Hindernis, aber nicht das „Endboss“-Level der Sicherheit.

10. Praktische Checkliste für dich als Pentester

Wenn du auf eine WAF stößt, geh ungefähr so vor:

  1. Erkennen
    • Reaktionen auf offensichtliche Payloads testen.
    • Typische Blockseiten & Header identifizieren.
  2. Mapping
    • Welche Pfade/Hosts sind durch WAF geschützt?
    • Gibt es direkte Backend-Pfade ohne WAF?
    • Welche HTTP-Methoden/Codierungen sind erlaubt?
  3. Baseline testen
    • Mit harmlosen, aber „komischen“ Requests experimentieren.
    • Ggf. Rate-Limits und Thresholds abschätzen.
  4. Evasion-Techniken ausprobieren
    • Encoding-Varianten, andere Methoden, JSON/multipart, Parameter-Splitting.
    • Payloads fragmentieren, alternative Syntax nutzen.
  5. Applikationsschwachstellen trotz WAF identifizieren
    • Prüfe Business-Logik, Auth/Access-Control, CSRF, etc.
    • Wenn technische Schwachstellen (SQLi/XSS) trotz WAF belegt werden können → auflisten.
  6. Reporting
    • WAF-Einsatz erwähnen, aber klar sagen:
      • Ist sie korrekt konfiguriert?
      • Welche Angriffe blockt sie?
      • Wo hat sie Lücken?
      • Warum WAF kein Ersatz für Fix im Code ist.

11. WAF vs. andere Controls

  • WAF: schützt HTTP-Requests zur App (L7)
  • Network Firewall: Ports/Protokolle (L3/L4)
  • API Gateway: Routing/Auth/Rate limit für APIs, kann WAF-Funktionen haben
  • RASP: läuft in der App-Runtime und erkennt Angriffe „von innen“
  • IDS/IPS: Netzwerk-basiert, nicht app-spezifisch (IPS kann blocken)
  • CDN/Bot Protection: DDoS/Edge-Schutz, oft kombiniert mit WAF

In

, , , , , , , , , , ,