Web Application Security
Ungeschützte Web-APIs sind ein willkommenes Einfallstor für Angreifer
Die vergessenen Gefilde der Cybersicherheit
„Was heute ein Beinaheunfall ist, kann morgen ein Unfall sein.“ Anfang dieses Jahres bekamen man einen Eindruck davon, wie wahr dieses Sprichwort ist, dieses Mal in Bezug auf die Kundendaten eines globalen Einzelhändlers. Ein „trivialer“ Path-Traversal-Angriff auf eine der APIs des Unternehmens führte zu einem potenziellen Datenleck, wovon fast 100 Millionen Kundendaten betroffen waren. Glücklicherweise wurde die Schwachstelle im Rahmen eines Bug-Bounty-Programms entdeckt und verantwortungsbewusst offengelegt und gepatcht, wie Palo Alto Networks berichtet.
Diese jüngste potenzielle Sicherheitslücke im Zusammenhang mit dem Schutz von Web-APIs ist eine von vielen, die Unternehmen in den letzten Jahren erlebt haben und die sich sehr negativ auf die Privatsphäre von Millionen von Menschen und das öffentliche Vertrauen in Großunternehmen ausgewirkt haben.
Zu den anderen Vorfällen seit 2018 gehören die API-Verletzung eines Entwicklers, die die Konten von 50 Millionen Social-Media-Nutzern offenlegte; eine gehackte API für eine Versand-Website, wobei die Daten von 60 Millionen Nutzerkonten offengelegt wurden; der Missbrauch von API-Diensten, der die IDs und Telefonnummern von bis zu 309 Millionen Social-Media-Nutzern offenlegte; und eine API-Verletzung für eine Finanzdienstleistungs-App, die das massenhafte Scraping von 200 Millionen Transaktionen ermöglichte.
Bei der Bewertung der Sicherheitslage einer Webanwendung gilt es, sich vor Augen zu halten, was das schwächste Glied in der Schutzkette sein könnte. Anstatt sich frontal mit den Sicherheitsmaßnahmen des „Haupttors“ auseinanderzusetzen, suchen Angreifer nach potenziellen unbeaufsichtigten Lücken, durch die sie hindurch gelangen können. APIs sind aus Sicht eines Angreifers die perfekten Kandidaten.
Warum APIs als Ziel?
Anhand der Entwicklung der Architektur von Webanwendungen in den letzten Jahren wird der Trend ziemlich offensichtlich. Webanwendungen bewegen sich weg von monolithischen Designs und verlagern sich auf eine Microservices-basierte Architektur, die aufgrund ihrer inhärenten Vorteile – CI/CD-unabhängige Pipeline, automatische Skalierung und hohe Portabilität – meist mit Cloud-nativen Technologien implementiert wird.
APIs, kurz für Application Programming Interfaces, sind der „Klebstoff“ solcher Microservices und ermöglichen die Kommunikation zwischen verschiedenen Backend- und Frontend-Diensten der Anwendung. Palo Alto Networks fragt: Warum also sind sie bei Angreifern so beliebt? Klassische Maßnahmen zur Anwendungssicherheit scheinen mit der Absicherung von APIs zu kämpfen zu haben.
APIs sind von Natur aus für die Maschine-zu-Maschine-Kommunikation gedacht. Daher kann die Anwendung clientbasierter Ratenbeschränkungen eine Herausforderung darstellen oder oft nicht anwendbar sein.
Die Mensch/Bot-Herausforderungen
Challenges, die Automatisierungs-Tools erkennen und blockieren sollen, sind beim Schutz eines API-Endpunkts aufgrund des Content-Typs der Antwort (in der Regel JSON oder XML), der keine Injektion und Darstellung von Javascript-Challenges oder CAPTCHA-Injektion zulässt, fast unmöglich zu implementieren. In anderen Fällen werden APIs von vornherein für den programmatischen Zugriff verwendet, so dass es keinen Sinn macht, Maßnahmen zur Bot-Erkennung zu implementieren.
Sicherheitsbewusstsein
Da Microservices lose gekoppelt sind, ist es oft der Fall, dass mehrere Teams sie unabhängig voneinander entwickeln und dabei jeweils unterschiedliche sichere Codierungsstandards anwenden. Das Endergebnis für mittlere bis große Unternehmen sind Hunderte von exponierten APIs intern und am Perimeter, bei denen das Sicherheitsteam Schwierigkeiten hat, sie zu identifizieren, Änderungen an ihnen zu verfolgen oder angemessene Schutzmaßnahmen anzuwenden.
Hybrideinsatz
Nicht alle Microservices werden in der gleichen Umgebung bereitgestellt. Einige werden vor Ort bereitgestellt, einige in öffentlichen Clouds, einige in privaten Clouds, die von Dritten gehostet werden. Und im Laufe ihres Lebenszyklus werden sie zwischen verschiedenen Umgebungen hin- und hergeschoben, einige intern, andere extern (z. B. Test, QA, Labor, Corp., Produktion usw.). Dies stellt ein Problem für Sicherheitsmaßnahmen dar, die am Perimeter eingesetzt werden, da es keine Sicht auf interne Umgebungen oder die Kommunikation zwischen Diensten innerhalb des Perimeters gibt (d. h. „Ost-West“-Verkehr).
In der Praxis machen alle oben genannten Überlegungen APIs zu einem bequemen Ziel für alle Arten von beliebten Angriffen, wie z. B. Missbrauch von Anmeldeinformationen, Web Scraping, Befehlsinjektionen, SSRF (Server-side Request Forgery), lokale Dateieinschlüsse und mehr. Tatsächlich ist der Schutz von Web-APIs zu einem solchen Bedürfnis in der Welt der Anwendungssicherheit geworden, dass die OWASP-Stiftung 2019 ein eigenes Projekt initiierte, das die Top-10-API-Sicherheitsrisiken verfolgt: „Von Natur aus legen APIs Anwendungslogik und sensible Daten wie personenbezogene Daten (PII) offen und sind daher zunehmend ein Ziel für Angreifer geworden. Ohne sichere APIs wäre eine schnelle Innovation unmöglich.“
API-Sicherheit richtig umgesetzt
Klar ist mittlerweile, dass API-Sicherheit Aufmerksamkeit und entsprechende Schutzmaßnahmen erfordert. Palo Alto Networks nennt einige wichtige Überlegungen bei der Auswahl einer API-Schutzlösung:
Die OpenAPI-Spezifikation (formell bekannt als Swagger) ermöglicht Standarddefinitionen von API-Fähigkeiten. Eine Lösung zum Schutz von Web-APIs sollte in der Lage sein, die Kommunikation mit APIs auf der Grundlage solcher Spezifikationsdateien zu erzwingen, wobei die zulässigen Methoden für jeden Endpunkt, die Eingabeparameter und das Werteformat berücksichtigt werden müssen. All dies kann anhand der Spezifikationen explizit definiert werden und sollte als Definitionen mit einem einzigen Klick in die Firewall importiert werden können. Die Konzentration aller Schutzbemühungen auf den Perimeter würde nur eine Teillösung darstellen. Schutzmaßnahmen sollten so nah an der Anwendung wie möglich eingesetzt werden. Die Sicherheitslösung sollte sowohl eingehende Konversationen (Nord-Süd-Verkehr) als auch die interne Kommunikation von anderen Microservices (Ost-West-Verkehr) einsehen können.
Runtime-Schutz
Eine erstklassige Application-Firewall, die den eingehenden Datenverkehr zur Anwendung überprüft, reicht nicht aus. Jede Firewall, so gut sie auch sein mag, ist anfällig für falsch-negative Ergebnisse, entweder durch eine ausgeklügelte Umgehungstechnik oder eine fiese Zero-Day-Schwachstelle. Um solche Risiken zu minimieren, sollte eine ganzheitliche Lösung auch das Verhalten der Webanwendung während der Laufzeit als zusätzliche Schutzschicht überwachen. Eine solche Lösung sollte das normale Anwendungsverhalten erlernen und bei unerwartetem ausgehendem Datenverkehr von der Anwendung (ins Internet oder zu anderen Servern innerhalb des Perimeters), unerwartet gestarteten Prozessen, erhöhter CPU-Auslastung oder anderen verdächtigen Aktivitäten Alarm schlagen.
Skalierbarkeit
Wenn der eingehende Datenverkehr zum geschützten Endpunkt zunimmt, sollte auch die gewählte Lösung skalieren, um Serviceausfälle oder unerwünschte Engpässe zu vermeiden. Idealerweise sollte sie in der Lage sein, automatisch zu skalieren, um so die Risiken einer langfristigen Kapazitätsplanung und die unnötigen Kosten für den Kauf von Überkapazitäten zu vermeiden, um zukünftiges Wachstum zu ermöglichen.
Erkennung ungeschützter APIs
Unternehmen können keine Assets schützen, von denen sie nichts wissen. Die Lösung der Wahl sollte in der Lage sein, ihre Bereitstellungen kontinuierlich zu scannen und vor ungeschützten Webanwendungen zu warnen.
Da sich die Welt der Webanwendungsentwicklung hin zur Verwendung von APIs als Teil einer Cloud-nativen Microservices-Architektur verschiebt, sollten sich die Sicherheitslösungen entsprechend weiterentwickeln. Die meisten der heutigen Microservices werden als orchestrierte containerisierte Anwendungen ausgeführt, die auf hybride Weise bereitgestellt werden – einige vor Ort und einige in öffentlichen Clouds gehostet. Um dieser Herausforderung gerecht zu werden, hat Palo Alto Networks in den letzten Monaten am Modul Web Application and API Security (WAAS) gearbeitet, um eine ganzheitliche Lösung für den Schutz von Webanwendungen zu entwickeln.
