Die WAF ist tot

– Es lebe WAAP + Web-Anwendungen und APIs sind seit Jahren ein attraktives Ziel von Cyberkriminellen, entsprechend sind sie auch für die IT-Sicherheit eine kontinuierliche Herausforderung. Wie kann man die darin enthaltenen Sicherheitslücken eliminieren oder zumindest dafür sorgen, dass sie nicht ausgenutzt werden? Analog zu WAFs gibt es dafür spezialisierte API-Sicherheitslösungen. Immer häufiger werden auch kombinierte Lösungen zum Schutz von Webanwendungen und APIs eingesetzt. So wurde das Akronym WAAP zum Leben erweckt, das für Web Application and API Protection steht.

Dieser Artikel besteht aus zwei Teilen: Dieser erste Teil zeigt auf, wie moderne Sicherheitslösungen diesen Bedrohungen begegnen: Mit vielfältigen Schutzmechanismen und künstlicher Intelligenz. Im zweiten Teil geht es darum, wie sich eine identitätsbasierte Zero-Trust-Architektur umsetzen lässt, um insbesondere Cloud-native Anwendungen vor unbefugten Zugriffen zu schützen.

Die eigentliche Schwachstelle ist der Mensch

Etwa die Hälfte aller Webanwendungen und APIs sind heutzutage verwundbar (Quelle). Die Fehlerursache liegt fast immer beim Menschen, sei es in der Programmierung oder bei der Konfiguration. Hacks und Leaks sind daher leider an der Tagesordnung und können zu irreparablen Imageschäden und grossen finanziellen Ausfällen führen.

Verbesserungen von Entwicklung bis Betrieb

Um die Sicherheit von Webanwendungen zu erhöhen, muss an allen Stellen des Software- Lebenszyklus angesetzt werden, von der Entwicklung bis zum Betrieb. Es leuchtet ein: Je früher eine Schwachstelle gefunden wird, desto schneller und günstiger ist die Korrektur. Die Ausbildung und Sensibilisierung von Software-Entwicklern und -Architekten gehen das Problem an der Wurzel an, auch wenn dies keine hundertprozentige Sicherheit bringen wird.

Zusätzlich sind regelmässige Penetration-Tests durch Sicherheitsexperten notwendig, doch sie sind aufwändig und immer nur eine Momentaufnahme. Um die Fehlerquote zu reduzieren, braucht der Mensch deshalb noch weitere technische Unterstützung. Dazu gehören automatisierte Testwerkzeuge, die gefährliche Stellen im Code oder bekannte Sicherheitslücken in OpenSource-Bibliotheken aufdecken. Auch diese Tools können allerdings nicht verhindern, dass eine Schwachstelle erst dann entdeckt wird, wenn die Anwendung bereits live ist.

Deswegen braucht es nochmals eine Massnahme: Exponierte und sensitive Daten müssen zusätzlich auch im Betrieb geschützt werden. Dies hat die Kreditkarten-Industrie schon sehr früh erkannt und in ihrem Branchen-Sicherheitsstandard (PCI-DSS 4.0) den Schutz durch eine Web Application Firewall (WAF) explizit vorgeschrieben. Eine solche WAF wird zwischen dem Benutzer und der laufenden Webanwendung platziert und schützt letztere auch vor Angriffen und Missbrauch, wenn alle anderen Massnahmen versagt haben.

Von WAF zu WAAP

Neben Webanwendungen erfreuen sich APIs einer immer grösseren Beliebtheit. Das liegt auch daran, dass moderne Webanwendungen und viele mobile Apps ihre Daten per APIs beziehen. APIs bringen aber neue und spezifische Probleme mit sich. Die OWASP hat deshalb 2019 eine eigene Top 10 Liste für API Security Risks herausgegeben. Analog zu WAFs gibt es dafür spezialisierte API-Sicherheitslösungen. Immer häufiger werden auch kombinierte Lösungen zum Schutz von Webanwendungen und APIs eingesetzt. So wurde das Akronym WAAP zum Leben erweckt, das für Web Application and API Protection steht. Zum Umfang einer WAAP-Lösung gehören folgende Funktionsbereiche: Web Application Firewall, API Security, Denial-of-Service-Schutz und Bot-Abwehr. Neben den gutartigen Suchmaschinen gibt es nämlich immer mehr unerwünschte Bots, die unbefugt Informationen sammeln oder auch ferngesteuert durch Cyberkriminelle automatisierte Angriffe durchführen.Funktionsbereiche der Web Application und API Protection (WAAP)

Virtuelle Pflaster als schnelle Überbrückung

WAAP macht also allen unerwünschten Besuchern das Leben schwer, egal ob Hobby-Hacker oder professioneller Cyberkrimineller. Für die normalen, befugten Benutzer hingegen ist eine WAAP-Lösung nicht sichtbar. Die Schutzmassnahmen können im Idealfall sogar unbekannte Angriffe abwehren. Ein wichtiger Zusatz-Nutzen von WAAP ist das «Virtual Patching»: Was passiert, wenn eine heikle Schwachstelle einer Anwendung im laufenden Betrieb bekannt wird? Im Durchschnitt dauert es nämlich über 250 Tage (Quelle), bis eine kritische Schwachstelle behoben ist! Bis die Korrektur verfügbar ist, können WAAP-Betreiber einen virtuellen Patch erstellen, der das Ausnutzen der Schwachstelle sofort verhindert. Selbst wenn ein Anwendungs-Patch zeitnah verfügbar ist, kann mit einem virtuellen Patch das verwundbare Zeitfenster nochmals verkürzt und das Update ohne Zeitdruck getestet und ausgerollt werden.

Wie funktioniert eigentlich WAAP?

Anwendungs-Firewalls arbeiten auf Schicht 7 des OSI-Modells und können zahlreiche Bedrohungen wie Injections, Cross-Site Scripting (XSS) und andere Angriffe abfangen. Der Schutz gilt also der Server-Anwendung und deren Daten, nicht dem darauf zugreifenden Browser oder Gerät. Aus technischer Perspektive handelt es sich meist um einen Reverse Proxy, der die allenfalls verschlüsselte (HTTPS-) Verbindung aufbricht, den Datenfluss in beide Richtungen kontrolliert und bei Bedarf verändert. Alternativ werden die Schutzfunktionen in die Anwendung eingebettet, diese Variante wird Runtime Application Self Protection (RASP) genannt und ist weniger verbreitet, weil die Integration in die Anwendung deutlich aufwändiger ist.

Um die unterschiedlichen Angriffsarten zu unterbinden, werden eine Vielzahl von Schutzmechanismen angewendet:

Negative Sicherheitsfilter: Mittels Block-Listen werden verdächtige Muster und bekannte Angriffsarten wie Cross-Site-Scripting oder Injection-Angriffe erkannt und blockiert.
Positive Sicherheitsfilter: Die beste Sicherheit erreicht man, wenn man genau weiss, was die Anwendung erwartet. Diese Filterregeln blockieren entsprechend alles, was nicht explizit erlaubt ist. Eine solche White-List kann durch einen Lernmodus entstehen. Bei APIs kann man dafür eine schon vorhandene Schnittstellen-Spezifikation verwenden.
Authentifizierung und Zugriffskontrolle: Die Angriffsfläche lässt sich deutlich reduzieren, wenn nur berechtigte Nutzer bis zur Anwendung gelangen. In Zusammenarbeit mit einem Identity Provider wird jeder Benutzer vorgängig authentifiziert. Damit kann ein Angreifer ohne einen gültigen Zugang gar nicht erst nach Schwachstellen suchen.
Rate Limiting & Quotas: Durch die Begrenzung des Durchsatzes können Brute Force Attacken oder Content Scraping erschwert werden. Im Idealfall sind diese Limiten abhängig von der Identität des Aufrufs; insbesondere beim Aufruf von APIs.
Anomalie-Erkennung: Mittels künstlicher Intelligenz lassen sich auffällige Abweichungen vom «normalen» Anwenderverhalten erkennen. Falls der Verdacht besteht, dass ein unerwünschter Bot am Werk ist, kann ein erneuter Login oder das Lösen eines Captcha gefordert werden.
Threat Intelligence: Einige Benutzer sind möglicherweise allein aufgrund von Standort oder IP-Adresse weniger vertrauenswürdig. So kann man alle abweisen, die aus dem Darknet kommen oder ihre Herkunft absichtlich verschleiern.
Cookie-Schutz: Cookies werden oft verwendet, um Benutzer-Sessions auf einer Webanwendung zu verfolgen. WAAP-Lösungen können das Verändern von Cookies und damit auch Session Hijacking verhindern.
Session-Schutz: Ein verstecktes Token verhindert Cross-Site-Request-Forgery-Angriffe, bei denen das eingeloggte Opfer unerwünschte Aktionen auslöst, ohne sich dessen bewusst zu sein.

OWASP Top 10

Das Open Web Application Security Project (OWASP) publiziert regelmässig eine Top-10-Liste der häufigsten Schwachstellen in Webanwendungen; auch für APIs gibt es eine entsprechende Rangliste. Diese Listen eignen sich gut für die Sensibilisierung und Aufklärung.

Teil 2: Zero Trust mit verteilter Zugriffskontrolle

Die Verlagerung in die Cloud und die zunehmende Bewegunsfreiheit der Mitarbeiter führt zu neuen Angriffsflächen. Wie lässt sich in diesem Umfeld eine identitätsbasierte Zero-Trust-Architektur umsetzen? Wie können insbesondere Cloud-native Anwendungen vor unbefugtem Zugriff geschützt werden?

Unsere Antworten darauf finden Sie im Teil 2: Verteilte WAAP mit Microgateways.