Die Sicherheitslücken bei Webanwendungen
Wie fragmentierte Sicherheit zu Kompromissen führt
Die Geschichte von Unternehmen A und B
Dies ist die Geschichte von Unternehmen A und Unternehmen B, deren auf den ersten Blick unterschiedliche Webanwendungs- und API-Sicherheitsansätze eine gemeinsame unauffällige, aber entscheidende Schwachstelle aufweisen. Diese führte bei beiden Firmen zu Datenschutzverstößen (und allen damit verbundenen negativen Folgen).
Unternehmen A verfügt über den stärksten denkbaren API-Schutz. Es blockiert alle Schemaverstöße, begrenzt die Anfragemenge auf ein vernünftiges Maß und verwendet die neuesten Bedrohungsdaten, um bekanntermaßen bösartige IP-Adressen zu sperren. Die passwortbasierte API-Authentifizierung des Unternehmens könnte noch sicherer sein, wenn sie durch mutual TLS ersetzt würde, doch es gab noch nie einen Sicherheitsvorfall.
Allerdings stammen die API-Sicherheitslösung, der Bedrohungsdaten-Feed und die WAF jeweils von unterschiedlichen Anbietern. Und aufgrund anbieterseitiger Updates sind die für die API-Sicherheit relevanten Bedrohungsdaten nicht mehr mit der WAF kompatibel, die die Kontoanmeldeseite schützt. Deshalb kann ein Angreifer einen neuen SQL-Injection-Exploit auf dieser Seite verwenden und den Benutzernamen und das Passwort eines legitimen Nutzers erlangen. Der Angreifer sendet dann authentifizierte, schemavalidierte Anfragen an die API des Unternehmens und erlangt so zahlreiche vertrauliche Daten.
Was Unternehmen B angeht, so ist dessen Webanwendung vollständig gegen DDoS-Angriffe geschützt. Unternehmen B stellt außerdem eine API für zahlende Nutzer zur Verfügung, die sich eine Möglichkeit zur Integration in die Anwendung von Unternehmen B wünschen.
In diesem Fall erwirbt der Angreifer den API-Schlüssel eines legitimen zahlenden Nutzers im Dark Web. Damit startet er einen langsamen und unauffälligen DDoS-Angriff auf den API-Server von Unternehmen B. Er aktiviert einen Bot, der in unregelmäßigen Abständen Anfragen sendet. Jeder API-Aufruf, den der Bot sendet, wird vom API-Server als legitim angesehen, da er mit einem akzeptablen API-Schlüssel verknüpft ist. Leider hat das Backend-Team von Unternehmen B vergessen, dem eigenen API-Server den genutzten DDoS-Abwehrdienst als Proxy vorzuschalten, auch wenn alle anderen Server der Firma geschützt sind.
Da immer mehr Anfragen auflaufen, ist der API-Server zunehmend überfordert. Irgendwann ist er überhaupt nicht mehr in der Lage, die Anfragen der anderen Nutzer von Unternehmen B noch zu bearbeiten. Viele von ihnen kündigen aus Verärgerung ihre kostenpflichtigen Konten.
Welches Problem haben Unternehmen A und B gemeinsam?
Eine Kombination aus verschiedenen Lösungen führte zu Versäumnissen und Sicherheitslücken
In diesen Beispielen nutzen beide Unternehmen für die Webanwendungs- und API-Sicherheit Lösungen diverser Anbieter. Diese sind nicht miteinander integriert und zu allem Übel auch anfällig für manuelle Fehler.
Um zu verstehen, warum das ein Problem ist, sollten Sie sich die üblichen Elemente eines Sicherheitskonzepts für Webanwendungen und APIs vor Augen führen:
WAF: Blockiert Angriffe auf Webanwendungen und andere Internetpräsenzen
Bot-Management: Überprüft oder blockiert mutmaßlich bösartige Bots
DDoS-Abwehr: Sorgt dafür, dass Internetpräsenzen bei (volumetrischen ebenso wie schwachen und langsamen) DDoS-Angriffen jeglicher Art über das Web erreichbar bleiben
API-Schutz: Umfasst Durchsatzbegrenzung, Schema-Validierung, Authentifizierung usw. für APIs
Bei Unternehmen A und B sind all diese Schutzmaßnahmen im Einsatz. Weil ihre Sicherheitslösungen für Webanwendungen aber fragmentiert sind (auch wenn sie zu den besten ihres Bereichs gehören), weisen sie Schwachstellen auf, die von Angreifern ausgenutzt werden können.
Bei Unternehmen A mussten sowohl die WAF als auch der API-Schutz, die nicht miteinander integriert, sondern lediglich nebeneinander geschaltet sind, Angriffe jeweils allein abwehren. Angriffe, die von einer Lösung gestoppt werden konnten, waren in der Lage, die anderen zu überwinden. Die DDoS-Abwehr von Unternehmen B hat die API-Infrastruktur nicht geschützt, das Bot-Managementsystem hat keine von Bots stammenden API-Aufrufe erkannt und die Authentifizierung war sowohl schwach als auch leicht angreifbar.
Das sind nur ein paar Beispiele für potenzielle Sicherheitslücken. Andere häufige Lücken in der Sicherheit von Webanwendungen sind:
Begrenzte Bedrohungsdaten: Bedrohungsdaten, die nicht auf dem neuesten Stand sind, nicht an der richtigen Stelle eingehen oder nicht in einem kompatiblen Format vorliegen. Das war bei Unternehmen A zu beobachten.
Zu viele Bedrohungsdaten aus zu vielen Quellen: Dies führt zu Fehlalarmen, Redundanz und anderen Ineffizienzen.
Bot-Fehlalarme: Das kann Nutzer frustrieren, den Dienst verlangsamen und zu einer laxen Durchsetzung der Regeln führen.
Abstumpfung gegenüber Warnmeldungen:: Ein durchschnittliches Unternehmen verwendet 45 Cybersicherheits-Tools von verschiedenen Anbietern, und jedes von ihnen generiert Warnmeldungen. Zu viele unterschiedliche Produkte können dazu führen, dass Mitarbeitende Bedrohungen ignorieren, um ihre Arbeit erledigen zu können.
Unzureichende Authentifizierung: Sowohl Unternehmen A als auch Unternehmen B waren in irgendeiner Form anfällig für den Diebstahl von Zugangsdaten.
Nicht skalierbare Bedrohungsabwehr: Sicherheits-Hardware sorgt für Traffic-Nadelöhre und ist bei großen Angriffen oder bei einer Vielzahl unterschiedlicher Attacken überfordert.
Mit zunehmender Komplexität und Raffinesse von Cyberangriffen werden solche Sicherheitslücken immer riskanter. Laut McKinsey finden sich heute unter den Angreifern „hochentwickelte Organisationen, die integrierte Tools und Funktionen mit künstlicher Intelligenz und maschinellem Lernen kombinieren“. Moderne Angreifer sind oft schneller und bei der Optimierung ihrer Taktik häufig agiler als ihre Ziele.
Das zusätzliche Risiko von APIs
APIs werden für die Infrastruktur von Webanwendungen moderner Unternehmen immer wichtiger. Heute sind 58 % des gesamten von Cloudflare verarbeiteten dynamischen Datenverkehrs API-basiert, und dieser Anteil ist weiter im Steigen begriffen. Tatsächlich beschreiben sich inzwischen viele Unternehmen als „API first“. Darüber hinaus ist der Anteil des von Cloudflare als bösartig eingestuften und deshalb blockierten Datenverkehrs bei APIs größer als bei Web-Traffic. Das zeigt, dass APIs fest im Fadenkreuz der Angreifer stehen.
Weil APIs oft tief in Webanwendungen eingebettet sind, muss ihre Sicherheit an erster Stelle stehen. Doch wohlmeinende interne Teams stellen APIs häufig schnell bereit – nicht selten ohne Rücksprache mit der IT-Sicherheitsabteilung. Deshalb sind viele Sicherheitsverstöße bei Webanwendungen auf schwachen API-Schutz zurückzuführen.
So war beispielsweise die US-amerikanische Post (US Postal Service – USPS) von einer API-Sicherheitslücke betroffen: Man stellte fest, dass bei einer API, die die Paketverfolgung in Echtzeit unterstützt, eine grundlegende Autorisierung fehlte. Angemeldete Nutzer konnten deshalb Kontoinformationen für jeden anderen Nutzer abfragen, indem sie Platzhalter-Suchparameter verwendeten, die alle Einträge des Datensatzes offenlegten. Dadurch waren die Daten von 60 Mio. Inhabern von USPS-Konten gefährdet.
Eine konsolidierte Lösung
Was wäre, wenn Unternehmen A und B statt eines Flickwerks aus verschiedenen Sicherheitsprodukten alle ihre Sicherheitsservices für Webanwendungen und APIs in einer konsolidierten Plattform gebündelt hätten und diese verschiedenen Dienste alle untereinander integriert wären? Was, wenn zudem Daten über den Zustand der Unternehmensinfrastruktur an einem einzigen Ort angezeigt würden, sodass Angriffe und die Sicherheitslage schnell bewertet werden könnten?
Unternehmen A hätte sicherstellen können, dass alle Elemente seines Sicherheitskonzepts für Webanwendungen und APIs über die neuesten Bedrohungsdaten verfügen und den Angriff stoppen können, noch bevor er überhaupt begonnen hätte – weil alles über eine einzige Plattform abrufbar gewesen wäre. Unternehmen B wiederum hätte seinen DDoS-Schutz leichter auf alle seine Server ausweiten können.
Die Nutzung einer einzigen, übergeordneten Plattform würde eine einfachere und lückenlosere Verwaltung ermöglichen.
Ein solcher konsolidierter Ansatz zur Absicherung von Webanwendungen erfordert eine in hohem Maß skalierbare Infrastruktur, die in der Lage ist, alle Arten von Datenverkehr über einen Proxy an sein Ziel zu leiten. In vergangenen Jahrzehnten haben sich Unternehmen Hardware zugelegt, wenn sie sich gegen neue Angriffe verteidigen oder skalieren mussten. Doch ein cloudbasierter Dienst lässt sich leichter skalieren und sollte in der Lage sein, als Proxy für jede Art von Infrastruktur zu dienen. Und obwohl eine konsolidierte Plattform kein Patentrezept ist, hätte sie den Unternehmen in den hypothetischen Beispielen sicherlich geholfen.
Mehr als eine Gedankenspielerei: Die wachsende Bedeutung von WAAP
Dabei handelt es sich nicht um reine Gedankenspielerei. Gartner definiert diese konsolidierten Dienste als „Web Application and API Protection“ (Webanwendungs- und API-Schutz) bzw. WAAP. Im Jahr 2022 hat die Firma vorhergesagt, dass „bis 2024 70 % der Unternehmen, die Multi-Cloud-Strategien für Webanwendungen in Betriebsumgebungen implementieren, Cloud-Services für WAAP-Plattformen den Vorzug gegenüber WAAP-Appliances und IaaS-nativem WAAP geben werden“.
WAAP ist nicht nur ein weiteres Akronym: Die Konsolidierung von WAF, Bot-Management, DDoS-Schutz, API-Sicherheit und anderen Diensten ist für moderne Unternehmen zunehmend von maßgeblicher Bedeutung. Aufgrund der Internationalität des Internets sind Webanwendungen und APIs ständig Angriffen unterschiedlichster Größe und Komplexität ausgesetzt, die von vielen verschiedene Standorten ausgehen. Es überrascht deshalb nicht, dass 2022 laut IBM 83 % der befragten Unternehmen von Datenlecks betroffen waren. Die dadurch entstandenen Kosten beziffern sich weltweit durchschnittlich auf 4,35 Mio. US-Dollar und in den Vereinigten Staaten im Schnitt auf 9,44 Mio. US-Dollar.
Eine weitere Überlegung: heterogene Infrastrukturen
Würden Unternehmen A und B ihre Anwendungen und APIs heute von Grund auf neu entwickeln, könnten sie sie vollständig in der Cloud hosten, zur leichteren Bereitstellung vielleicht sogar bei einem einzigen Hosting-Anbieter. In der Praxis nutzen die meisten Firmen jedoch eine hybride Infrastruktur mit älteren lokalen Datenbankservern, cloudbasierten APIs von Drittanbietern und in mehreren Clouds gehosteten Anwendungsdiensten. Dies bietet viele Vorteile, bringt aber unter dem Sicherheitsaspekt auch eigene Herausforderungen mit sich.
So kann es beispielsweise sein, dass die native Sicherheit im Angebot eines bestimmten Cloud-Providers nicht die gesamte Infrastruktur eines Unternehmens abdeckt. Zunächst einmal kann es sich schon als schwierig erweisen, die gesamte Infrastruktur zu erfassen und abzubilden, um sie dann zu schützen. Last but not least sind die Sicherheitsprodukte des Anbieters möglicherweise nicht mit anderen technischen Lösungen des betreffenden Unternehmens kompatibel.
WAAP muss deshalb nicht nur wichtige Funktionen der Webanwendungssicherheit zusammenführen, sondern auch infrastrukturneutral sein, d. h. die Lösung muss jeder Art von Infrastruktur oder Cloud-Bereitstellungsmodell vorgeschaltet werden können.
Konsolidierte und infrastrukturneutrale Websicherheit
Cloudflare ist cloudnativ und infrastrukturneutral, bietet seit mehr als einem Jahrzehnt Webapplikationssicherheit und stellt all diese Funktionen in Gestalt einer konsolidierten Plattform über ein einziges Dashboard bereit. Ein weiterer Vorteil ist, dass wir einen großen Prozentsatz des Internet-Traffics zu Gesicht bekommen, über 57 Mio. HTTP-Anfragen pro Sekunde bearbeiten und im Durchschnitt 209 Mrd. Cyberbedrohungen am Tag blockieren. Das erlaubt uns einen einzigartigen Überblick über Zero Day-Bedrohungen und neue Angriffe.
Dieser Beitrag ist Teil einer Serie zu den neuesten Trends und Themen, die für Entscheidungsträger aus der Tech-Branche heute von Bedeutung sind.
Vertiefung des Themas:
2022 wurde Cloudflare von Gartner als ein Marktführer („Leader“) im Gartner® Magic Quadrant™ für Web Application and API Protection (WAAP) eingestuft.
Wichtigste Eckpunkte
Folgende Informationen werden in diesem Artikel vermittelt:
Wie durch eine Vielzahl von Sicherheitslösungen Schwachstellen entstehen können
Beispiele für solche Sicherheitslücken
Weshalb Gartner die Konsolidierung mit einer infrastrukturneutralen Sicherheitsplattform für Webanwendungen empfiehlt