Neuer Cloudflare-Bericht zu API-Sicherheit und -Verwaltung 2024

Ihnen ist Cloudflare vielleicht als das Unternehmen ein Begriff, das die Grundlage für fast 20 % des Internets liefert. Doch die Bereitstellung und der Schutz von Websites und statischen Inhalten macht nur einen Bruchteil unserer Aktivitäten aus. Tatsächlich geht weit mehr als die Hälfte des dynamischen Datenverkehrs in unserem Netzwerk nicht auf Webseiten, sondern auf Programmierschnittstellen (Application Programming Interface – API) zurück, dem Rückgrat von Technologie. Dieser Blogbeitrag soll zugleich eine Einführung und eine Ergänzung zum Bericht zu API-Sicherheit 2024 bieten. Wir werden ausführlich darauf eingehen, wie wir unsere Kunden schützen und was dies für die Zukunft der API-Sicherheit bedeutet. Anders als andere Branchenberichte zu diesem Thema stützt sich unser Report nicht auf Nutzerumfragen, sondern auf Daten zu echtem Traffic.

Wenn wir unseren diesjährigen Bericht auf eine Feststellung reduzieren müssten, dann wäre es diese: Viele Firmen haben keine klares Bild von ihrem API-Bestand – selbst wenn sie glauben, API-Traffic korrekt identifizieren zu können. Cloudflare hilft Unternehmen mit zwei Ansätzen, alle ihre öffentlich zugänglichen API zu ermitteln. Zunächst konfigurieren die Kunden unser API-Erkennungstool so, dass es in dem Datenverkehr, der bekanntermaßen auf API zurückgeht, nach identifizierenden Merkmalen sucht. Anschließend verwenden wir ein Machine Learning-Modell, um nicht nur diese bereits als API-Aufrufe identifizierten, sondern alle HTTP-Anfragen zu durchsuchen und so den bislang möglicherweise noch nicht erfassten API-Traffic zutage zu fördern. Der Unterschied zwischen den beiden Ansätzen ist frappierend: Mit der auf maschinellem Lernen basierenden Methode wurden 30,7 % mehr API-Endpunkte aufgespürt als laut Eigenangabe der Kunden existieren. Das deutet darauf hin, dass es sich bei fast einem Drittel der API um „Schatten-API“ handelt, die möglicherweise nicht ordnungsgemäß erfasst und geschützt werden.

Im Folgenden finden Sie Highlights aus unserem ersten Bericht zu API-Sicherheit und einige Extras. Die vollständige Fassung des Reports enthält aktuelle Statistiken zu den Bedrohungen, die von uns registriert und neutralisiert werden, sowie unsere Prognosen für 2024. Wir sagen voraus, dass eine Vernachlässigung des Themas API-Sicherheit in Unternehmen zu erhöhter Komplexität und Kontrollverlust führen wird. Außerdem rechnen wir mit einer Zunahme der API-bezogenen Risiken aufgrund der größeren Verfügbarkeit generativer KI. Darüber hinaus steht für 2024 einem Anstieg der Angriffe auf API-Geschäftslogik zu erwarten. Und schließlich wird es aufgrund dieser verschiedenen Gefahren nötig sein, zur Gewährleistung der API-Sicherheit die Kontrollmechanismen zu verschärfen.

Verborgene Angriffsflächen

Worin besteht der Unterschied zwischen Webseiten und API? API sind eine schnelle und einfache Möglichkeit für Anwendungen, Daten im Hintergrund abzurufen oder andere Applikationen mit der Ausführung von Aufgaben zu beauftragen. Zum Beispiel kann jeder eine Wetter-App programmieren, ohne Meteorologe zu sein: Ein Entwickler erstellt einfach eine Seite oder Mobilgeräte-Anwendung und bezieht die Vorhersage für den Standort des jeweiligen Nutzers von einer externen Wetter-API. Den meisten Endnutzern ist dabei nicht bewusst, dass die Daten von der Wetter-API und nicht vom Eigentümer der App bereitgestellt wurden.

API bilden das Rückgrat des Internets, sind aber auch sehr anfällig für Missbrauch. So machten Schwachstellen bei der API-Authentifizierung und -Autorisierung der Firma Optus es möglich, dass ein Krimineller 10 Millionen erbeutete Nutzerdatensätze zum Verkauf anbieten konnte. Behörden haben bereits vor genau solchen API-bezogenen Angriffen gewarnt. Entwickler in Unternehmen erstellen oft API, die mit dem Internet verbunden sind und von ihren eigenen Anwendungen genutzt werden, um effizienter zu arbeiten. Doch es ist Aufgabe der IT-Sicherheit, diese neuen öffentlich zugänglichen Schnittstellen zu schützen. Wenn nicht eindeutig geregelt ist, wie API dokumentiert werden und wie man die IT-Sicherheitstsabteilung über ihre Existenz informiert, entstehen sogenannte „Schatten-API“. Diese sind zwar in der Produktivumgebung im Einsatz, allerdings ohne Wissen des Unternehmens. Das kann sich zu einem Sicherheitsproblem entwickeln.

Um dem zu begegnen, haben wir für unsere Kunden die API Discovery bzw. API-Erkennung entwickelt. Bei Einführung unserer neuesten Version haben wir darauf hingewiesen, dass nur wenige Unternehmen über eine genaue Aufstellung ihrer API verfügen. Um eine solche zu erstellen, sind Sicherheitsteams manchmal gezwungen, die Existenz von API per E-Mail zu erfragen. Das Bild, das sich dadurch zusammensetzt, ist aber schon mit dem nächsten Release einer Anwendung wieder veraltet. Deshalb ist es besser, API-Änderungen anhand der Anpassungen des zugrundeliegenden Programmcodes zu verfolgen, um mit neuen Versionen Schritt zu halten. Das hat jedoch den Nachteil, dass nur aktiv gewarteter Programmcode inventarisiert wird. Für ältere Applikationen werden möglicherweise keine neuen Versionen veröffentlicht, obwohl sie weiterhin in der Produktivumgebung zum Einsatz kommen.

Der Cloudflare-Ansatz für die API-Verwaltung beinhaltet das Anlegen einer umfassenden, genauen Aufstellung aller API vor. Dafür wird eine Kombination aus Machine Learning, API-Erkennung und Prüfung des Netzwerkverk-Traffics genutzt. Dies ist ein wesentlicher Bestandteil unseres API Gateway-Produkts, mit dem Kunden ihre Internet-Endpunkte verwalten und den API-Status überwachen können. Außerdem erlaubt der Dienst es ihnen, API-Traffic anhand von Sitzungsmerkmalen (in der Regel ein Header oder Cookie) zu identifizieren und sich so einen besseren Überblick verschaffen.

Wie bereits erwähnt, zeigt unsere Analyse, dass selbst sachkundige Kunden oft erhebliche Teile ihres API-Datenverkehrs nicht auf dem Radar haben. Ein Vergleich der sitzungsbasierten API-Erkennung (bei der API-Sitzungen zur Eingrenzung des Datenverkehrs genutzt werden) mit unserer auf maschinellem Lernen beruhenden API Discovery (im Rahmen derer der gesamter eingehende Traffic analysiert wird) ergibt, dass letztere im Durchschnitt 30,7 % mehr Endpunkte aufdeckt. Ohne eine umfassende Analyse des Datenverkehrs bleibt also unter Umständen fast ein Drittel Ihres API-Bestands im Verborgenen.

Auch wenn Sie kein Cloudflare-Kunde sind, können Sie mit einer umfassenden Aufstellung ihrer API beginnen. API werden in der Regel in einem standardisierten Format namens OpenAPI katalogisiert und viele Entwicklungstools können Schema-Dateien im OpenAPI-Format erstellen. Wenn Sie über eine Datei mit diesem Format verfügen, können Sie selbst mit der Erfassung Ihrer API anfangen, indem Sie diese Schemata sammeln. Das folgende Beispiel zeigt, wie Endpunkte aus einer Schema-Datei abgefragt können. Dies setzt das Vorhandensein einer Datei im Format OpenAPI v3 mit dem Namen „my_schema.json“ voraus:

import json
import csv
from io import StringIO

# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
    schema = json.load(file)

# Prepare CSV output
output = StringIO()
writer = csv.writer(output)

# Write CSV header
writer.writerow(["Server", "Path", "Method"])

# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
    url = server['url']
    for path, methods in schema['paths'].items():
        for method in methods.keys():
            writer.writerow([url, path, method])

# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)

Wenn Sie nicht schon zu Beginn des Entwicklungsprozesses Ihrer Anwendung OpenAPI-Schemata erstellt und die Zahl Ihrer API erfasst haben, fehlen Ihnen wahrscheinlich einige Endpunkte im API-Bestand der Produktivanwendung.

Genaue Durchsatzbegrenzungen minimieren das Angriffspotenzial

Wenn es darum geht, Missbrauch zu unterbinden, denken die meisten Fachleute zuerst an Durchsatzbegrenzung. Die Implementierung von Grenzwerten für Ihre API ist ein wertvolles Instrument, um Missbrauch einzudämmen und eine versehentliche Überlastung des Ursprungsservers zu verhindern. Aber woher wissen Sie, ob Sie den richtigen Ansatz zur Durchsatzbegrenzung gewählt haben? Die Ansätze können variieren, aber im Allgemeinen hängen sie vom gewählten Fehlercode und der Grundlage für den Grenzwert selbst ab.

Für einige API konfigurieren Fachleute Durchsatzbegrenzungsfehler so, dass als Antwort HTTP 403 („Forbidden“) oder HTTP 429 („Too Many Requests“) ausgegeben wird. Die Verwendung von HTTP 403 klingt so lange harmlos, bis Sie feststellen, dass auch andere Sicherheitstools eine 403-Antwort ausgeben. Wenn Sie angegriffen werden, lässt sich daher unter Umständen nur schwer herausfinden, welche Tools für welche Fehler/Blockierungen verantwortlich sind.

Benutzen Sie dagegen HTTP 429 für Ihre Durchsatzbegrenzung, wissen Angreifer sofort, dass sie einer Durchsatzbegrenzung unterzogen werden. Dann können sie dafür sorgen, dass sie knapp unterhalb der Grenze bleiben und dadurch nicht bemerkt werden. Das kann durchaus in Ordnung sein, wenn Sie Anfragen nur begrenzen, damit Ihr Backend funktionsfähig bleibt. Allerdings kann es Angreifern in die Hände spielen. Darüber hinaus können Angreifer ihre Aktivitäten auf weitere API-Clients ausweiten, um de facto mit ihren Anfragen das durch die Durchsatzbegrenzung gesetzte Limit zu umgehen.

Beide Ansätze haben ihre Vor- und Nachteile. Wir haben aber festgestellt, dass die mit Abstand meisten API (fast 52 %) auf alle 4xx- und 5xx-Fehlermeldungen mit HTTP 429 reagieren.

Und wie sieht es aus, wenn man nicht nur den Antwortcode, sondern die Logik der Durchsatzbegrenzungsregel selbst betrachtet? Die Implementierung von Anfragelimits auf Basis von IP-Adressen kann verlockend erscheinen. Doch wir empfehlen, das Limit auf eine Sitzungs-ID zu stützen und nur dann auf die IP-Adresse (oder IP + JA3-Fingerprint) zurückzugreifen, wenn keine Sitzungs-ID verfügbar sind. Wenn sich die Durchsatzbegrenzung nicht nach IP, sondern nach Nutzersitzungen richtet, können Sie Ihre echten Nutzer zuverlässig identifizieren und Fehlalarme aufgrund von gemeinsam genutztem IP-Adressraum minimieren. Mit der erweiterten Durchsatzbegrenzung von Cloudflare und dem Schutz vor volumetrischem Missbrauch von API Gateway lassen sich diese Obergrenzen leicht durchzusetzen, indem an jedem API-Endpunkt ein Profil des Sitzungsdatenverkehrs erstellt wird und die Durchsatzbegrenzung für jeden Endpunkt individuell mit einem Klick festgelegt werden kann.

Zur Ermittlung der richtigen Werte für Ihre Durchsatzbegrenzungen berechnet Cloudflare API Gateway Sitzungsanforderungsstatistiken für Sie. Um Ihnen einen Grenzwert vorschlagen zu können, schauen wir uns die Verteilung der Anfragen pro Sitzung für alle Sitzungen Ihrer API an, die durch die vom Kunden konfigurierte API-Sitzungskennung identifiziert werden. Anschließend berechnen wir statistische p-Werte – die die Anfrageraten für verschiedene Datenverkehrskohorten beschreiben – für p50, p90 und p99 innerhalb dieser Verteilung und verwenden die Varianz der Verteilung, um einen empfohlenen Grenzwert für jeden einzelnen Endpunkt in Ihrem API-Bestand zu ermitteln. Die Empfehlung stimmt möglicherweise nicht mit den p-Werten überein, was ein wichtiger Unterschied und ein Grund ist, nicht ausschließlich p-Werte zu verwenden. API Gateway übermittelt nicht nur die Empfehlung, sondern informiert die Nutzer auch darüber, für wie zuverlässig wir diese halten. Im Allgemeinen gilt: Je mehr API-Sitzungen wir erfassen können, desto zuverlässiger ist die Empfehlung.

Das Aktivieren einer Durchsatzbegrenzung ist so einfach wie das Klicken auf den Link „Regel erstellen“. API Gateway leitet Ihre Sitzungskennung automatisch an die Seite für die Erstellung erweiterter Durchsatzbegrenzungsregeln weiter. So wird sichergestellt, dass Ihre Regeln hochpräzise sind, um Angriffe abzuwehren und Fehlalarme im Vergleich zu herkömmlichen, allzu weit gefassten Grenzen auf ein Mindestmaß zu begrenzen.

Angriffe auf Webanwendungen können auch API treffen

API sind nicht immun gegen normale Angriffe nach Art der OWASP Top 10 wie SQL-Injection. Der Text von API-Anfragen kann auch als Datenbankeingabe verwendet werden, genau wie eine Formulareingabe oder ein URL-Argument auf einer Webseite. Sie sollten unbedingt sicherstellen, dass eine Web Application Firewall (WAF) auch Ihren API-Datenverkehr schützt, um diese Arten von Attacken abzufangen.

Eine Untersuchung der Managed Rules für die Cloudflare-WAF hat ergeben, dass Injection-Angriffe der zweithäufigste Bedrohungsvektor bei API waren. An erster Stelle standen HTTP-Anomalien. Beispiele für HTTP-Anomalien sind fehlerhafte Methodennamen, Null-Byte-Zeichen in Headern, nicht standardisierte Ports oder eine Inhaltslänge von Null bei einer POST-Anfrage. Hier sind die Statistiken zu den anderen von uns verzeichneten größten Bedrohungen für API:

Nicht in der Tabelle enthalten ist die Kategorie „fehlerhafte Authentifizierung und Autorisierung“. Eine fehlerhafte Authentifizierung und Autorisierung tritt auf, wenn eine API nicht überprüft, ob eine Einheit, die Informationen von einer API anfordert, tatsächlich die Berechtigung hat, diese Daten anzufordern. Gelegentlich versuchen Angreifer auch, Anmeldedaten zu fälschen und weniger eingeschränkte Berechtigungen in ihre vorhandenen (gültigen) Anmeldedaten einzufügen, deren Berechtigungen stärker eingeschränkt sind. OWASP kategorisiert diese Angriffe auf verschiedene Weise, aber die Hauptkategorien sind Broken Object Level Authorization (BOLA)- und Broken Function Level Authorization (BFLA)-Angriffe.

Die Hauptursache für einen erfolgreichen BOLA-/BFLA-Angriff liegt darin, dass eine Ursprungs-API nicht die korrekte Eigentümerschaft von Datenbankdatensätzen mit der Identität abgleicht, die diese Datensätze anfordert. Die Verfolgung dieser spezifischen Angriffe kann schwierig sein, da die Berechtigungsstruktur unter Umständen einfach nicht vorhanden, unzureichend oder nicht ordnungsgemäß implementiert ist. Erkennen Sie hier das Henne-Ei-Problem? Diese Angriffe wären leicht zu stoppen, wenn wir die richtige Berechtigungsstruktur kennen würden. Doch wenn wir oder unsere Kunden die richtige Berechtigungsstruktur kennen oder ihre Durchsetzung garantieren könnten, wären die Angriffe von vornherein erfolglos. Wir planen für die Zukunft die Einführung neuer API Gateway-Funktionen, bei denen wir unser Wissen über die Standards des API-Traffic einfließen lassen werden, um automatisch Sicherheitsrichtlinien vorzuschlagen, die BOLA-/BFLA-Angriffe aufzeigen und stoppen.

Im Folgenden zeigen wir Ihnen vier Möglichkeiten auf, wie Sie selbst dann etwaige Authentifizierungslücken bei Ihren API schließen können, wenn Sie nicht über eine stark ausdifferenzierte Autorisierungsrichtlinie verfügen:

1. Erstens: Erzwingen Sie die Authentifizierung bei jeder öffentlich zugänglichen API, es sei denn, es gibt eine vom Unternehmen genehmigte Ausnahme. Setzen Sie auf Technologien wie mTLS und JSON Web Tokens.
2. Begrenzen Sie die Geschwindigkeit von API-Aufrufen an Ihre Server, um potenzielle Angreifer zu bremsen.
3. Blockieren Sie abnormale Mengen an sensiblen Daten.
4. Verhindern Sie, dass Angreifer legitime Sequenzen von API-Anfragen auslassen.

Der menschliche Faktor beim API-Traffic

Wenn Sie schon in der Zeit, als es noch keine Smartphones gab und man weniger häufig online unterwegs war, mit Technologie beschäftigt haben, ist der Gedanke verlockend, dass API nur für die Kommunikation von Maschine zu Maschine verwendet werden – z. B. für eine Stapelverarbeitung über Nacht. Doch weit gefehlt. Wie schon erwähnt, setzen viele Web- und Mobilgeräte-Anwendungen API ein, die alles von der Authentifizierung über Transaktionen bis hin zur Bereitstellung von Mediendateien ermöglichen. Parallel zur Verbreitung dieser Anwendungen steigt auch das Volumen des API-Traffics.

Das lässt sich anhand der API-Datenverkehrsmuster veranschaulichen, die während Feiertagen zu beobachten sind, wenn man sich mit Freunden und Familienmitgliedern trifft und mehr Zeit mit persönlichen Kontakten und weniger Zeit im Internet verbringt. In dem folgenden Diagramm zum weltweiten API-Datenverkehr haben wir die wichtigsten Feiertage sowie Tage, an denen besondere Verkaufsaktionen stattfinden, eingetragen. Zu beachten ist, dass der Datenverkehr um den Black Friday und den Cyber Monday herum einen Spitzenwert bei etwa +10 % erreicht, weil dann online eingekauft wird. An den Weihnachts- und Neujahrsfeiertagen kommt es dann aber wieder zu einem Rückgang.

Dieses Muster ähnelt stark dem, das bei normalem HTTP-Traffic zu beobachten ist. Daran wird deutlich, dass bei API inzwischen nicht mehr ausschließlich automatisierte Prozesse eine Rolle spielen, sondern eine enge Verknüpfung mit menschlichen Verhaltensweisen und gesellschaftlichen Trends besteht.

Empfehlungen

Ein Patentrezept für eine ganzheitliche API-Sicherheit gibt es nicht. Cloudflare empfiehlt vier Strategien zur Verbesserung der API-Sicherheit:

1. Führen Sie Entwicklung, Sichtbarmachung, Performance und Sicherheit von API-Anwendungen auf einer gemeinsamen Steuerungsebene zusammen, wo auch eine aktuelle Aufstellung über alle vorhandenen API geführt werden kann.
2. Verwenden Sie Sicherheitstools, die maschinelles Lernen nutzen, um personelle Ressourcen freizusetzen und Kosten zu senken.
3. Führen Sie ein positives Sicherheitsmodell für Ihre API ein (unten werden das positive und negative Sicherheitsmodell erklärt).
4. Messen und verbessern Sie mit der Zeit den API-Reifegrad Ihres Unternehmens (unten wird der Begriff des API-Reifegrads erklärt).

Was versteht man unter einem „positiven“ oder „negativen“ Sicherheitsmodell? Bei einem negativen Modell suchen Sicherheitstools nach bekannten Anzeichen für Angriffe und ergreifen Maßnahmen, um diese zu stoppen. Bei einem positiven Modell suchen die Sicherheitstools nach bekanntermaßen gutartigen Anfragen und lassen nur diese zu, während alle anderen blockiert werden. API sind oft so aufgebaut, dass positive Sicherheitsmodelle sinnvoll sind, wenn man das höchstmögliche Sicherheitsniveau gewährleisten möchte. Sie können auch Sicherheitsmodelle kombinieren, also z. B. eine WAF im Sinne eines negativen Modells und eine API-Schema-Validierung im Sinne eines positiven Modells einsetzen.

Hier ist eine schnelle Methode, um den API-Sicherheitsreifegrad Ihres Unternehmens im Zeitverlauf zu messen: Die Neueinsteiger unter den Unternehmen beginnen damit, ihre API zu erfassen – gleichgültig, wie unvollständig eine solche Aufstellung zunächst sein mag. Weiter fortgeschrittene (reifere) Unternehmen streben eine genaue Bestandsaufnahme ihrer API und automatischen Aktualisierungen an. Die Unternehmen mit dem höchsten Reifegrad in diesem Bereich setzen aktiv Sicherheitsprüfungen in einem positiven Sicherheitsmodell für ihre API durch, indem sie das API-Schema und eine gültige Authentifizierung erzwingen und das Verhalten auf Anzeichen von Missbrauch hin überprüfen.

Prognosen

Abschließend unsere vier wichtigsten Vorhersagen für 2024 und darüber hinaus:

Zunehmender Kontrollverlust und wachsende Komplexität: Bei einer Umfrage unter Fachleuten im Bereich API-Sicherheit und -Verwaltung haben 73 % der Befragten angegeben, dass die Sicherheitsanforderungen ihre Produktivität und Innovationsfähigkeit beeinträchtigen. In Verbindung mit zunehmend ausufernden Anwendungen und ungenauen Bestandsaufnahmen werden sowohl API-Risiken als auch die Komplexität steigen.

Mehr API-Risiken durch größere Verfügbarkeit von KI: Die Verbreitung generativer KI birgt potenzielle Risiken, etwa die Anfälligkeit der API von KI-Modellen für Angriffe. Ein Problem können aber auch Entwickler sein, die fehlerhaften, von einer KI verfassten Programmcode einführen. Forrester prognostiziert, dass man 2024 ohne angemessene Schutzmaßnahmen „unsicheren, von KI generierten Programmcode öffentlich für mindestens drei Datenlecks verantwortlich machen wird – entweder aufgrund von Sicherheitsmängeln im generierten Code selbst oder aufgrund von Schwachstellen in von KI vorgeschlagenen Abhängigkeiten“.

Zunahme von auf Geschäftslogik basierenden Betrugsangriffen: Professionelle Betrüger agieren wie ein Unternehmen und bei ihnen fallen auch die entsprechenden Kosten an. Wir gehen davon aus, dass Angreifer noch mehr als in den vergangenen Jahren Betrugs-Bots effizient gegen API einsetzen werden.

Wachsende Kontrolle: Die erste Version von PCI DSS, die sich direkt mit API-Sicherheit befasst, gilt ab März 2024. Erkundigen Sie sich bei Ihrer Audit-Abteilung nach den spezifischen Anforderungen Ihrer Branche, um vorbereitet zu sein, wenn die neuen Regeln in Kraft treten.

Sollten Sie an der vollständigen Fassung interessiert sein, können Sie den Bericht zu API-Sicherheit 2024 hier herunterladen. Dieser enthält alle Einzelheiten zu unseren Empfehlungen.

Unsere API-Sicherheitslösung Cloudflare API Gateway steht allen Firmenkunden zur Verfügung. Wenn Sie API Gateway noch nicht abonniert haben, klicken Sie hier, um sich Ihre ersten API-Discovery-Ergebnisse anzeigen zu lassen und eine Testversion im Cloudflare-Dashboard zu starten. Wenn Sie wissen möchten, wie Sie API Gateway zur Absicherung Ihres Datenverkehrs nutzen können, klicken Sie hier, um sich unsere Entwicklerdokumentation anzusehen. Hier finden Sie eine Anleitung für die ersten Schritte.