WAF vs. WAAP vs. API Security

15.04.2025

Danny Merkel, Senior Cyber Security Architect, Consulteer InCyber

Entstehung der Web Application Firewall

Mit der Verbreitung des Internets und dem damit einhergehenden immer grösser werdenden Angebot an Web Applikationen in den 1990er Jahren haben auch die Möglichkeiten zugenommen, diese Web Anwendungen und vor allem ihre Benutzer auszunutzen oder zu manipulieren. Immer mehr Menschen hatten Zugriff zum Internet und die ursprüngliche, idealistische Vision, dass das Internet ein Ort des Guten sei, wurde zunehmend unrealistisch. Betreiber von Websites mussten sich und ihre Benutzer schützen und so kamen Ende des Jahrtausends die ersten Web Application Firewalls (WAF) auf.

Web Apps durch WAFs zu schützen wurde ein Muss auch durch das Aufkommen immer neuer Sicherheitslücken wie z. B. durch die Veröffentlichung der SQL-Injection Sicherheitslücke durch Jeff Forristal, der eine SQL-Injection in einem Windows NT Server mit Microsoft SQL Server Datenbank nachweisen konnte.

Die ersten WAF-Produkte fokussierten sich darauf, spezifische Sicherheitsbedrohungen wie eben solche SQL-Injection oder Cross-Site-Scripting-Angriffe (XSS) zu bekämpfen. Über die Zeit nahm die Anzahl der Angriffsvektoren zu und mittels der Open Worldwide Application Security Project (OWASP) Top 10 - einer Zusammenstellung der zehn kritischsten Sicherheitsrisiken rund um Webanwendungen - wurde durch ein Ranking die Awareness in der IT Branche gestärkt.

Mit der Veröffentlichung von ModSecurity im Jahr 2002, einer Open-Source und plattformübergreifende WAF, und der Entwicklung des OWASP ModSecurity Core Rule Set gewann das Thema auch in der Open-Source Welt an Bedeutung. Das OWASP Core Ruleset ist heute noch wichtiger Bestandteil einiger Open-Source und kommerzieller WAF/ WAAP Anbieter. Der letzte kommerzielle Besitzer von ModSecurity war Trustwave, der das Projekt und damit die Entwicklung und den Support zum 1. Juli 2024 vollständig an die Open Source Community, in die Hände der OWASP, übergeben hat.

ModSecurity setzt auf ein "Negative Security Model". Hierbei werden Traffic Patterns definiert, die blockiert werden. Dies steht im Gegensatz zum “Positive Security Model” welches explizit nur definierte Muster zulässt.

Entstehung von APIs

APIs (Application Programming Interface) gibt es etwa seit den 1960er Jahren, als Mainframe Systeme Schnittstellen zum Datenaustausch benötigten.

Erst in den 1970er und 1980er Jahren entstand das Bedürfnis, Softwarebibliotheken nicht nur auf dem eigenen Rechner, sondern auch auf entfernten Rechnern aufrufen zu können. Dies förderte die Entwicklung der heute üblichen “Web” APIs, die auf Standards wie gRPC, SOAP, REST, GraphQL etc. basieren. Ihre Bedeutung hat in den letzten Jahren deutlich zugenommen, da mehr und mehr APIs im Internet exponiert werden.

Spätestens seit der Umsetzung von Mircroservice Architekturen und der damit einhergehenden Aufteilung von Applikationen in ihre Kernfunktionen, die unabhängig betrieben werden können, nimmt die Anzahl von APIs stetig zu.

AI - das P fehlt

Es wird viel über KI - auf Englisch “Artificial Intelligence (AI)” - jedoch wenig über die Anzahl API Endpunkte und die damit verbundenen potentiellen Angriffsvektoren gesprochen. Unser Partner Wallarm hat in seinem jährlichen API ThreatStats Report herausgefunden, dass 2024 im Vergleich zu 2023 die Zahl der AI CVEs auf 439 zugenommen hat, eine Zunahme um 1025%. Von diesen beziehen sich 98,9% API related.

Von WAF zu WAAP

Eine Web Application Firewall ist nach wie vor ein Schlüsselfaktor für den Schutz von Webanwendungen vor diversen Sicherheitslücken und Zero-Day-Attacken.

Leider sind es oft nicht intrinsische Anreize, welche ein Unternehmen dazu treiben, eine WAF einzusetzen. Denn der Betrieb einer WAF bedeutet zusätzliche Ressourcen und Know-how, welche bereitgestellt werden müssen. Meistens sind es externe Treiber, welche den Einsatz einer WAF fordern. Zum Beispiel verlangen IT-Versicherungen häufig, dass Unternehmen eine WAF einsetzen, damit die Wahrscheinlichkeit des Eintritts eines Schadenfalls deutlich reduziert wird. Ebenfalls sind in diversen Branchen regulatorische Anforderungen ein Treiber für den Einsatz einer WAF.

Wie oben erwähnt, hat sich die Anwendungslandschaft mit der Zunahme von Microservices und AI stark verändert und wir sehen einen grossen Anstieg von APIs und neuen Protokollen wie gRPC und GraphQL. Ausserdem werden verstärkt Angriffe wie so genannte Distributed Denial of Service (DDoS) Attacken auf Webanwendungen und APIs durchgeführt, um deren Verfügbarkeit einzuschränken. Zur Durchführung dieser Angriffe werden insbesondere Bot Netzwerke genutzt.

Eine Weiterentwicklung der WAF ist deren Nachfolgelösung WAAP. Der Begriff WAAP steht für Web Application and API Protection und ist eine relativ junge und fortschrittliche Sicherheitstechnologie zum Schutz von Webanwendungen und APIs. Mit deren Entwicklung wurden Möglichkeiten zum Schutz vor DDoS Attacken, beispielsweise durch Rate-Limiting und Bot-Management, sowie der Schutz von APIs verstärkt in den Mittelpunkt gestellt.

Bei unserer Partnerauswahl für den Managed Security Service im Bereich WAAP waren diese zusätzlichen API-Schutzfunktionen wichtige Bewertungskriterien. Oft mussten wir jedoch feststellen, dass nur weil WAAP auf einem Produkt draufsteht, noch lange nicht WAAP drin ist. Einige Hersteller scheinen zunächst nur dem Marketingtrend gefolgt zu sein, um mit dem neuen Schlagwort WAAP erfolgreich gefunden zu werden - sozusagen alter Wein in neuen Schläuchen.

Machen Sie sich am besten selbst ein Bild und nutzen Sie das Open Source Test Tool “GoTestWAF“ oder fragen Sie explizit bei Ihrem Anbieter nach: Wofür steht API Protection? Gerne übernehmen wir dies auch für Sie und geben Ihnen kostenlos unsere Einschätzung mittels des API Attack Surface Management (AASM).

Next Level: API Security vs API Protection

Wir rekapitulieren noch einmal die Begriffe:

Eine Web Application Firewall, bzw. eine WAF, schützt klassische Web Anwendungen. Bietet jedoch APIs nur unzureichenden Schutz.
Eine WAAP, also Web Application and API Protection, ist die Weiterentwicklung der WAF - wenigstens in der Theorie. Hier ist jedoch Vorsicht geboten, ob das Produkt hält, was der Name verspricht. Der Teil der API Protection stellt den Schutz von APIs sicher.

Doch kenne ich als Unternehmen meine APIs? Und was tue ich für meine API Sicherheit? Häufig sind Entwickler extrem schnell im Veröffentlichen von neuen APIs oder von neuen Endpunkten bestehender APIs. Und noch öfter werden bestehende Endpunkte nicht mehr benötigt, aber es wird vergessen, diese zu deaktivieren.

Hier kommt der Begriff “API Security” ins Spiel: API Security erweitert API Protection um die Handlungsfelder Identify, Respond and Detect.

API Identify bietet Transparenz für Ihr gesamtes API-Portfolio und ermöglicht:

Verständnis über Ihre API-Angriffsoberfläche zu gewinnen und das damit verbundene Risiko zunächst sichtbar zu machen und anschliessend zu reduzieren.
Identifikation und Beheben riskanter APIs basierend auf der Analyse des Echtzeit-Datenverkehrs und OpenAPI-Spezifikationen.
Identifizieren von sensiblen Informationen im Datenverkehr und API-Endpunkten.

Zum Thema Respond gehören:

Möglichkeit zur Nachvollziehbarkeit und Analyse eines Angriffs und Incidents
Virtual Patching
Automatisches Alerting

API Detect:

Vulnerability Scanning
Open API Testing
Testing mittels Integration einer Scanning Lösung in CI/CD Pipelines

Fazit

Die Angriffsvektoren nehmen weiter zu und Unternehmen sollten überprüfen, welchen Schutz ihre WAAF-/WAAP-Produkte bieten. Darüber hinaus sollte jedes Unternehmen verstehen, welche Anwendungen und APIs es exponiert und ob und wie diese geschützt sind.

Wo stehen Sie mit Ihrem Unternehmen? Möchten Sie wissen wie Ihr Unternehmen geschützt ist und welche Service und APIs Sie anbieten?

Kontaktieren Sie uns für eine kostenlose Evaluation.