Awesome WAF 
Alles über Web Application Firewalls (WAFs) aus Sicherheitsperspektive. 🔥
Vorwort: Dies war ursprünglich meine eigene Sammlung zu WAFs. Ich stelle es als Open Source zur Verfügung, in der Hoffnung, dass es für Pentester und Forscher da draußen nützlich sein wird. Wie es so schön heißt: „Die Gemeinschaft lernt voneinander.“
Eine präzise Definition: Eine Firewall ist ein Sicherheitsrichtlinien-Erzwingungspunkt, der zwischen einer Webanwendung und dem Client-Endpunkt positioniert ist. Diese Funktionalität kann in Software oder Hardware implementiert sein, auf einem Appliance-Gerät oder auf einem typischen Server mit einem gängigen Betriebssystem laufen. Es kann ein eigenständiges Gerät oder in andere Netzwerkkomponenten integriert sein. (Quelle: PCI DSS IS 6.6)
Eine Web Application Firewall sitzt zwischen einem Benutzer und einer Webanwendung und hat die Aufgabe, jegliche schädliche Aktivität daran zu hindern, die Webanwendung zu erreichen. Eine WAF filtert entweder den schädlichen Teil der Anfrage heraus oder blockiert sie einfach.
Du kannst gerne beitragen.
Inhaltsverzeichnis:
Einleitung:
Wie WAFs funktionieren:
- Verwendung einer Reihe von Regeln, um normale Anfragen von böswilligen Anfragen zu unterscheiden.
- Manchmal verwenden sie einen Lernmodus, um automatisch Regeln hinzuzufügen, indem sie das Benutzerverhalten lernen.
Betriebsmodi:
- Negatives Modell (Blacklist-basiert) - Ein Blacklisting-Modell verwendet voreingestellte Signaturen, um Anfragen zu blockieren, die eindeutig böswillig sind. Die Signaturen von WAFs, die in einem negativen Modell arbeiten, sind speziell darauf ausgelegt, Angriffe zu verhindern, die bestimmte Schwachstellen von Webanwendungen ausnutzen. Blacklist-basierte Web Application Firewalls sind eine gute Wahl für Webanwendungen, die dem öffentlichen Internet ausgesetzt sind, und sind sehr effektiv gegen große Schwachstellen. Z.B. Regel zum Blockieren aller
<script>*</script>-Eingaben verhindert grundlegende Cross-Site-Scripting-Angriffe.
- Positives Modell (Whitelist-basiert) - Ein Whitelisting-Modell erlaubt nur Webverkehr gemäß speziell konfigurierter Kriterien. Beispielsweise kann es so konfiguriert werden, dass nur HTTP-GET-Anfragen von bestimmten IP-Adressen zugelassen werden. Dieses Modell kann sehr effektiv sein, um potenzielle großflächige Angriffe zu blockieren, wird aber auch viel legitimen Verkehr blockieren. Whitelist-basierte Firewalls sind wahrscheinlich am besten für Webanwendungen in einem internen Netzwerk geeignet, die nur von einer begrenzten Gruppe von Personen, z.B. Mitarbeitern, genutzt werden sollen.
- Gemischtes/Hybridmodell (Inklusives Modell) - Ein hybrides Sicherheitsmodell kombiniert sowohl Whitelisting als auch Blacklisting. Je nach den verschiedenen Konfigurationsdetails können hybride Firewalls die beste Wahl sowohl für Webanwendungen in internen Netzwerken als auch für Webanwendungen im öffentlichen Internet sein. Ein gutes Szenario kann sein, wenn eine Webanwendung dem öffentlichen Internet zugewandt ist (Blacklists verwenden), während das Admin-Panel nur einer Teilmenge von Benutzern zugänglich sein muss (Whitelists verwenden).
Testmethodik:
Wo suchen:
- Achte immer auf gängige Ports, die eine WAF offenlegen, nämlich die Ports
80, 443, 8000, 8080 und 8888. Es ist jedoch wichtig zu beachten, dass eine WAF leicht auf jedem Port bereitgestellt werden kann, der einen HTTP-Dienst ausführt. Es ist gut, zuerst die HTTP-Dienstports zu enumerieren und dann nach WAFs zu suchen.
- Einige WAFs setzen eigene Cookies in Anfragen (z.B. Citrix Netscaler, Yunsuo WAF).
- Einige assoziieren sich mit separaten Headern (z.B. Anquanbao WAF, Amazon AWS WAF).
- Einige ändern oft Header und mischen Zeichen, um Angreifer zu verwirren (z.B. Netscaler, Big-IP).
- Einige geben sich im
Server-Header zu erkennen (z.B. Approach, WTS WAF).
- Einige WAFs zeigen sich im Antwortinhalt (z.B. DotDefender, Armor, Sitelock).
- Andere WAFs antworten mit ungewöhnlichen Antwortcodes bei böswilligen Anfragen (z.B. WebKnight, 360 WAF).
Erkennungstechniken:
Um WAFs zu identifizieren, müssen wir sie (dummy) provozieren.
- Stelle eine normale GET-Anfrage von einem Browser, fange ab und zeichne die Antwort-Header auf (insbesondere Cookies).
- Stelle eine Anfrage von der Kommandozeile (z.B. cURL) und teste den Antwortinhalt und die Header (kein User-Agent enthalten).
- Sende GET-Anfragen an zufällige offene Ports und greife Banner ab, die die Identität der WAF preisgeben könnten.
- Injiziere auf Anmeldeseiten gängige (leicht erkennbare) Payloads wie
" or 1 = 1 --.
- Injiziere auffällige Payloads wie
<script>alert()</script> in Suchleisten, Kontaktformulare und andere Eingabefelder.
- Füge einen Dummy
../../../etc/passwd an einen zufälligen Parameter am Ende der URL an.
- Füge auffällige Schlüsselwörter wie
' OR SLEEP(5) OR ' an das Ende von URLs an jedem beliebigen Parameter an.
- Sende GET-Anfragen mit veralteten Protokollen wie
HTTP/0.9 (HTTP/0.9 unterstützt keine POST-Anfragen).
- Oft variiert die WAF den
Server-Header bei verschiedenen Arten von Interaktionen.
- Drop Action Technique - Sende ein rohes, maßgeschneidertes FIN/RST-Paket an den Server und identifiziere die Antwort.
Tipp: Diese Methode kann leicht mit Werkzeugen wie HPing3 oder Scapy erreicht werden.
- Side Channel Attacks - Untersuche das Timing-Verhalten der Anfrage und des Antwortinhalts.
Tipp: Weitere Details findest du in einem Blogbeitrag hier.
0xinfection/awesome-waf
