OWASP Top 10 API-Sicherheitsrisiken: Die Ausgabe 2023 ist endlich da
Die heutigen Programmierschnittstellen (APIs) ermöglichen eine flexible und schnelle Integration zwischen praktisch jeder Software, jedem Gerät und jeder Datenquelle. APIs bieten eine breite Palette an Funktionen und bilden die Grundlage für Innovation und digitale Transformation.
APIs haben sich praktisch zum Standard bei Aufbau und Verbindung moderner Anwendungen entwickelt, insbesondere angesichts des zunehmenden Umstiegs auf Microservices-Architekturen. APIs müssen in jedem Fall richtig abgesichert sein, da sie als digitaler Klebstoff zur Verbindung unterschiedlicher Systeme dienen.
Jeder dieser API-Aufrufe kann potenzielle Sicherheitslücken öffnen und Risiken für den Datenschutz bergen, die von mangelhafter Datenvalidierung sowie Konfigurations- und Implementierungsfehlern bis hin zu einer nicht vorhandenen Integration zwischen Sicherheitskomponenten reichen. Dies muss beim Beheben der Schwachstellen beachtet werden, die in den Top 10 API-Sicherheitsrisiken des Open Web Application Security Project (OWASP) definiert sind.
Am 5. Juni 2023 wurde von OWASP das erste große Update zur ursprünglichen Liste von 2019 veröffentlicht. Sehen wir uns die Änderungen an und betrachten wir, welche Schlüsselfaktoren die heutigen API-Schwachstellen beeinflussen, damit Sie bei der Absicherung Ihrer APIs besser informiert sind.
OWASP Top 10 API-Sicherheitsrisiken
OWASP ist eine Nichtregierungsorganisation, die Dokumentation zur Sensibilisierung des Sicherheitsbewusstseins erstellt. Grundlage dafür sind Community-Feedback und Experteneinschätzungen, darunter auch Beiträge von Akamai. In diesen Dokumenten werden die häufigsten Schwachstellen beschrieben, die heutzutage in Unternehmen auftreten. Sie dienen als eine ausgezeichnete Ressource für alle, die mit APIs arbeiten – von Entwicklern bis hin zu CISOs.
OWASP veröffentlicht ein separates Dokument mit dem Titel Top 10 API-Sicherheitsrisiken zusätzlich zu den anderen Top-10-Listen, um so hervorzuheben, dass API-Sicherheitslösungen einen einzigartigen Ansatz erfordern. Im OWASP-Projekt zur API-Sicherheit „liegt der Fokus auf Strategien und Lösungen, um die besonderen Schwachstellen und Sicherheitsrisiken von … APIs zu verstehen und abzumildern.“
Die Unterschiede
Schauen wir uns einmal die Unterschiede zwischen den Ausgaben von 2019 und 2023 an (Abbildung 1).
Abb. 1: Die Veränderungen bei den OWASP Top 10 API-Sicherheitsrisiken
Laut der Versionshinweise für 2023:
Die Ausgabe der „OWASP Top 10 API-Sicherheitsrisiken“ von 2023 ist ein zukunftsweisendes Dokument zur Sensibilisierung für eine sich schnell verändernde Branche. Sie ersetzt keines der anderen Top-10-Dokumente. Themen in dieser Ausgabe:
- Wir haben die übermäßige Offenlegung von Daten und Massenzuweisung kombiniert und uns dabei auf die gemeinsame Ursache konzentriert: Fehler bei der Autorisierungsvalidierung auf Objekteigenschaftsebene.
- Wir haben den Schwerpunkt stärker auf den Verbrauch von Ressourcen gelegt und uns sehr auf das Tempo konzentriert, mit dem sie erschöpft werden.
- Wir haben eine neue Kategorie "Unbeschränkter Zugriff auf sensible Geschäftsabläufe" geschaffen, um neue Bedrohungen anzusprechen, einschließlich der meisten Bedrohungen, die mithilfe von Ratenbeschränkung gemindert werden können.
- Wir haben die Kategorie "Unsichere Nutzung von APIs" hinzugefügt, um ein Phänomen aufzuzeigen, das wir mittlerweile beobachten: Angreifer suchen nach den integrierten Diensten eines Ziels, um diese anzugreifen, anstatt die APIs ihres Ziels direkt zu treffen. Dies ist der richtige Zeitpunkt, um ein Bewusstsein für dieses zunehmende Risiko zu schaffen.
Was ist neu, was wurde hinzugefügt und was wurde entfernt
NEU | API3:2023 | Fehlerhafte Autorisierung auf Objekteigenschaftsebene
OWASP kombinierte die früheren Kategorien „Übermäßige Offenlegung von Daten“ und „Massenzuweisung“ in der neuen Kategorie „Fehlerhafte Autorisierung auf Objekteigenschaftsebene (BOPLA)“, deren Schwerpunkt auf der gemeinsamen Ursache liegt: Fehler bei der Autorisierungsvalidierung auf Objekteigenschaftsebene.
Der Unterschied zwischen BOLA (Fehlerhafte Autorisierung auf Objektebene) und BOPLA besteht darin, dass sich BOLA auf ein ganzes Objekt bezieht und BOPLA auf eine Eigenschaft innerhalb eines Objekts (Abbildung 2).
Abb. 2: BOPLA bezieht sich auf eine Eigenschaft innerhalb eines Objekts
Sowohl OWASP als auch Akamai sehen nach wie vor große Risiken auf Objektebene. Deshalb bleibt BOLA das oberste und kritischste API-Sicherheitsrisiko.
Wenn man jedoch eine Ebene tiefer geht und die Objekteigenschaftsebene betrachtet, besteht ein zusätzliches Risiko, dass Informationen übermäßig geteilt oder bestimmte Eigenschaften geändert oder gelöscht werden, obwohl das nicht der Fall sein sollte.
Wenn Sie vor BOLA geschützt sind, bedeutet dies nicht, dass Sie auch vor BOPLA geschützt sind. Die Kombination von Massenzuweisung und übermäßiger Offenlegung von Daten in einer einzigen Kategorie unterstreicht die Aufmerksamkeit, die API-Entwickler den Eigenschaften einzelner Objekte widmen sollten.
Diese Unterscheidung ist wichtig für diejenigen, die vor der Wahl eines API-Sicherheitsprodukt stehen, da sie sicherstellen müssen, dass das Produkt beide Arten von Angriffen abdeckt.
HINZUGEFÜGT | API6:2023 | Serverseitig manipulierte Anforderungen
OWASP stufte das Injection-Sicherheitsrisiko herunter, entfernte es somit aus den Top 10 und machte damit Platz für Serverseitig manipulierte Anforderungen (SSRF) auf der Liste.
SSRF ist eine Angriffsart, die eine Schwachstelle in einer Webanwendung oder API ausnutzt, durch die ein Angreifer nicht-autorisierte Anfragen vom Server an andere interne oder externe Systeme zu stellen.
Im Folgenden sind einige mögliche Gründe aufgeführt, weshalb OWASP sich für diese Änderung entschieden hat:
- APIs sind anfälliger für SSRF-Angriffe, da sie auf modernen Technologien wie Kubernetes und Docker basieren, die auf HTTPS-API-basierten Kommunikationsprotokollen beruhen.
- Mit Technologien wie Webhooks, SSO-Integrationen und dem Abrufen/Umleiten von URL-Dateien über API-Endpunkte besteht für Angreifer die Möglichkeit, SSRF zu nutzen.
Tiefere Einblicke
Um mehr über SSRF-Angriffe zu erfahren, lesen Sie den Artikel von Mike Elissen Ihre APIs ermöglichen SSRF-Angriffe (serverseitig manipulierte Anforderungen).
ENTFERNT | API8:2019 | Injection
Die Streichung von Injection-Angriffen aus der Liste war ein drastischer und umstrittener Schritt innerhalb der API-Sicherheits-Community; allerdings hat die Bedrohung durch Injection-Angriffe auf API-Endpunkte abgenommen.
Injection ist nun im Wesentlichen ein Teil von API8:2023 | Fehlerhafte Sicherheitskonfiguration. Eine ordnungsgemäße Sicherheitskonfiguration sollte Schutzmechanismen für Webanwendungen und APIs umfassen, die standardmäßig Injections scannen und verhindern sollten.
GraphQL ist als API-Technologie auf dem Vormarsch. Im Kern handelt es sich dabei um eine abfragende Sprache, die wieder für einen Anstieg von Injection-Angriffen sorgen könnte. API-Entwickler, die mit GraphQL arbeiten, sollten daher weiterhin wachsam bleiben.
NEU | API4:2023 | Uneingeschränkte Ressourcennutzung
Die ursprüngliche Liste konzentrierte sich insbesondere darauf, auf das Risiko des Ressourcenverbrauchs aufmerksam zu machen, der dazu führt, dass API-Endpunkte überlastet werden (und möglicherweise nicht mehr verfügbar sind), wodurch das Nutzererlebnis beeinträchtigt wird.
API-Endpunkte müssen heutzutage verfügbar sein – aber Verfügbarkeit allein reicht nicht aus. Die Implementierung von API-Gateway-, Lastausgleichs- und Ratenbegrenzungskontrollen ist ein Schritt in die richtige Richtung.
In den letzten Jahren haben wir einen enormen Wandel in der „Ökonomie der API-Nutzung“ erlebt. Diese aktualisierte Kategorie zielt darauf ab, das Bewusstsein für diesen Aspekt zu schärfen, der durch API-Integrationen von Drittanbietern weiter zunehmen wird.
NEU | API6:2023 | Unbeschränkter Zugriff auf sensible Geschäftsabläufe
Eine weitere neue Ergänzung ist API6:2023 Unbeschränkter Zugriff auf sensible Geschäftsabläufe. Diese Kategorie hat endlich kodifiziert, was die Sicherheit so besonders macht: mehr wie ein Angreifer zu denken und zu sehen, wo potenzielle Vorteile möglich sind.
Die Technologie (die API) ist nur eine Möglichkeit, die Geschäftslogik auszuführen und Möglichkeiten zur Umgehung oder Änderung dieser Geschäftslogik durch die Technologie sind unerwünscht und könnten zu Komplikationen führen.
OWASP hat konkrete Beispiele dafür genannt, wie diese Komplikationen verhindert werden können. Dieses Sicherheitsrisiko ist jedoch sehr spezifisch für die Geschäftslogik, die durch Ihre API-Endpunkte unterstützt wird.
API-Entwickler: Beispiel
Vor kurzem führte Mike Elissen ein Gespräch mit API-Entwicklern bei einem Streaming-Service. Um ein neues Publikum anzulocken, bot dieser Streaming-Service eine kostenlose 30-tägige Testversion für neue Nutzer an, die ihre Kreditkarteninformationen angaben.
Die Geschäftslogik berücksichtigte jedoch nur eindeutige E-Mail-Adressen für Neuanmeldungen. Jede neue E-Mail-Adresse konnte problemlos auf eine neue Testversion zugreifen, auch wenn dieselben Kreditkarteninformationen dafür verwendet wurden. Dadurch konnten Nutzer jeden Monat einen neuen Account erstellen und den Service auf unbestimmte Zeit kostenlos nutzen.
NEU | API10:2023 | Unsichere Nutzung von APIs
Die Drittanbieter- API-Nutzung wächst rasend schnell. APIs müssen häufig in verschiedene interne und externe Dienste (Drittanbieter) integriert werden und mit ihnen kommunizieren sowie Daten senden und empfangen.
Auch in diesen Fällen ist es wichtig, die „grundlegenden“ Sicherheitsregeln zu befolgen, da es für Sicherheitsprodukte schwierig sein kann, in diesem Bereich Schwachstellen zu erkennen und proaktiv zu schützen.
Das OWASP-Dokument enthält eine Reihe von allgemeinen, aber auch API-spezifischen Vorschlägen, z. B.:
- Achten Sie auf die Nachverfolgung von Umleitungen. Integrieren Sie diese Überwachung in die Geschäftslogik und fügen Sie Sicherheitslösungen hinzu, die den Traffic kontinuierlich überwachen und überprüfen.
- Vertrauen Sie nicht einfach auf APIs von Drittanbietern, selbst wenn diese einen guten Ruf haben. Bauen Sie Schutzmechanismen und Begrenzungsfunktionen in Ihre Anwendung und API-Endpunkte ein.
Akamai kann Sie bei der API-Sicherheit unterstützen
Unternehmen und ihre Sicherheitsanbieter müssen eng zusammenarbeiten und Menschen, Prozesse und Technologien zusammenbringen, um effektiven Schutz vor den in den OWASP Top 10beschriebenen API-Sicherheitsrisiken zu gewährleisten.
Akamai bietet branchenführende Sicherheitslösungen, erfahrene Experten und die Akamai Connected Cloud, die jeden Tag Einblicke aus Millionen von Angriffen auf Webanwendungen, Milliarden von Bot-Anfragen und Billionen von API-Anfragen bereitstellt. Die Sicherheitslösungen für Webanwendungen und APIs von Akamai schützen Ihr Unternehmen vor den fortschrittlichsten Formen von Webanwendungs-, DDoS- (Distributed Denial of Service) und API-basierten Angriffen.
Akamai + Neosec
Die neue OWASP-Version fällt mit unserer kürzlichen Übernahme von Neoseczusammen. Die API-Sicherheitslösung von Neosec ergänzt das marktführende Anwendungs- und API-Sicherheitsportfolio von Akamai, indem sie die Sichtbarkeit von Akamai in der schnell wachsenden Landschaft der API-Bedrohungen deutlich erhöht.
Die Kombination soll es Kunden erleichtern, ihre APIs abzusichern, indem sie sie dabei unterstützt, alle ihre APIs zu erkennen, ihr Risiko zu bewerten und auf Schwachstellen und Angriffe zu reagieren.
Weitere Informationen
Erfahren Sie mehr über API-Sicherheitslösungen von Akamai und unsere Übernahme von Neosec.
Herzlichen Glückwunsch und vielen Dank, OWASP!
Die Schaffung eines Sicherheitsbewusstseins erfordert großen Aufwand aus der Community. Deshalb schätzen wir OWASP für die Leitung dieses Projekts. Ein besonderer Dank gilt Erez Yallon, Inon Shkedy und Paulo Silva für ihre großartige Arbeit an der Ausgabe 2023.
Wir möchten uns auch bei allen Beteiligten bedanken, insbesondere bei Maxim Zavodchik und Mike Elissen von Akamai für die Teilnahme an diesem Projekt und ihre Wissensvermittlung zur API-Sicherheit an die größere Entwickler-Community.
Zusätzliche Informationen zu APIs
Akamai verfolgt die Nutzung von APIs und den API-Traffic im Rahmen seiner SOTI-Berichte (State of the Internet). Lesen Sie ältere SOTI-Berichte für weitere Informationen. Neue SOTI-Berichte werden quartalsweise veröffentlicht.
Zusätzliche Ressourcen
Videoreihe: Grundlagen der API-Sicherheit
Blogbeitrag: Was die vorgeschlagenen neuen Änderungen bei OWASP Top 10 API-Sicherheitsrisiken für Sie bedeuten
