API-Schwachstellen 3 API-Sicherheitsrisiken, die jeder Entwickler kennen muss

Anbieter zum Thema

Imperva Ltd.

netfiles GmbH

Cloudgermany.de GmbH

STACKIT GmbH & Co. KG

Immer mehr Unternehmen setzen auf Cloud-Computing und es zeichnet sich ab, dass sich dieser Trend in naher Zukunft noch weiter verstärkt. Damit einhergehend müssen in Unternehmen jedoch auch erweiterte Sicherheitsvorkehrungen getroffen werden, da diese Entwicklung auch für Kriminelle neue Einfallstore bietet – zum Beispiel bei APIs.

APIs spielen in der nativen Cloud-Architektur jetzt und in Zukunft eine große Rolle. Doch bereits im vergangenen Jahr ist die Zahl der API-Schwachstellen in Unternehmen merklich gestiegen. In diesem Zusammenhang wird prognostiziert, dass sich das Volumen von Cyber-Attacken auf APIs bis 2024 bereits verdoppeln wird. Umso wichtiger ist es, dass sich Unternehmen dieser steigenden Gefahr bewusst sind und bereits jetzt mögliche Schwachstellen ausmerzen. In vielen Fällen liegt die Verantwortung für die Sicherheit der unternehmerischen Entwicklungs- und Produktionsumgebungen jedoch nicht allein beim Cybersecurity-Team, sondern auch bei den Entwicklern selbst. Daher müssen auch diese für mögliche API-Schwachstellen sensibilisiert werden.

Insbesondere die folgenden drei API-Einfallstore für Cyberkriminelle sollte man dabei im Blick haben:

1. Schatten-APIs

Im Durchschnitt gibt es in Unternehmen bis zu 620 verschiedene APIs. Die Untersuchungen der Aite Group zeigten jedoch, dass viele Unternehmen die genaue Anzahl gar nicht kennen – denn in schnelllebigen DevOps-Umgebungen kann die Erstellung von unbekannten APIs, sogenannten Schatten-APIs, leicht passieren.

Wenn APIs ohne Sicherheitsüberprüfung oder Kontrollen veröffentlicht werden, bleiben sie für das Sicherheitsteam und das API-Gateway meist unsichtbar. Auch solche, die außerhalb eines definierten Prozesses veröffentlicht wurden oder deren Struktur bei der Aktualisierung einer Anwendung verändert wurde, können zu Schatten-APIs werden. Möglicherweise ist sich der Entwickler auch nicht vollständig über den Veröffentlichungsprozess im Klaren und geht davon aus, dass er eine API eigenständig veröffentlichen kann. Dazu kommt: Sollte ein Entwickler das BFF-Muster (Backends for Frontends) in seinem Anwendungsdesign nutzen, kann dies dazu führen, dass Backend-Dienste – auf die normalerweise nur intern zugegriffen werden dürfte – dem direkten Zugriff von externen Client-API-Aufrufen ausgesetzt sind.

Das Problem bei Schatten-APIs ist, dass sie Zugriff auf dieselben sensiblen Informationen haben wie veröffentlichte, gesicherte APIs, aber niemand weiß, wo sie existieren oder mit was sie verbunden sind. Dies kann unter anderem zu Verstößen gegen die Compliance führen – und ermöglicht es im schlimmsten Fall Angreifern, auf die sensiblen Daten des Unternehmens und denen der Kunden zuzugreifen.

2. Automatisierte Bot-Angriffe

Automatisierter Bot-Verkehr ist ein weit verbreitetes Problem, das sich auf jedes Unternehmen auswirkt, das eine Website, eine mobile App oder eine öffentlich zugängliche API hat. Webanwendungen sind ein lohnendes Ziel für Botnets, da sie einen direkten Weg zu sensiblen Daten darstellen, die abgegriffen und im Dark Web weitergegeben oder verkauft werden können.

Diese Art von Angriffen ist schwieriger zu stoppen, da die Bots menschliches Verhalten imitieren und sich so der Erkennung entziehen können. Im Gegensatz zu anderen Arten von Angriffen arbeiten Botnets rund um die Uhr und sind absichtlich so konzipiert, dass sie sich wiederholende Aufgaben ausführen, die von Menschen nur schwer zu bewältigen sind. Werden APIs auf diese Weise attackiert, kann dies zum Verlust personenbezogener Daten, zu Datenlecks und mehr führen. Dennoch versäumen es viele Unternehmen, die Sicherheit ihrer APIs richtig zu verwalten und verlassen sich stattdessen ausschließlich auf einfache Authentifizierungs-Tokens oder IP-Ratenbegrenzungen. Im Gegensatz zur Identifikation menschlicher Benutzer durch eine Mehrfaktor-Authentifizierung sind diese API-Tokens jedoch oft nur eine Einfaktor-Authentifizierung, die einen Aufruf verifiziert. Für einen Entwickler, der also über keine richtige Cybersecurity-Ausbildung verfügt, ist es schwierig, diese Bedrohung zu stoppen.

3. Veraltete APIs (auch „Zombie-APIs“)

Die Ausmusterung von APIs ist Teil des natürlichen API-Lebenszyklus. Wenn eine API jedoch nicht ordnungsgemäß deaktiviert wurde, wird sie zu einer schlafenden Brutstätte für cyberkriminelle Aktivitäten – in der Regel außerhalb des Blickfelds von Entwicklern und der Cybersecurity-Verantwortlichen.

Diese nicht überwachten APIs sind mit einem unverschlossenen Fenster vergleichbar: Cyber-Kriminelle können sich durch sie „hineinschleichen“ und so auf Daten zugreifen oder ausgeklügelte Angriffe starten – ohne, dass der Entwickler oder das Sicherheitsteam davon etwas mitbekommt. Das Problem: Veraltete APIs werden oft übersehen oder nicht beachtet und sind auch nicht mehr Teil der regelmäßigen Software-Updates. So können diese „Zombie-APIs“ für die Übernahme von Konten, betrügerische Transaktionen oder Datenextraktionen ausgenutzt werden.

Komplexität der Angriffe wird weiter steigen

Obwohl die meisten Unternehmen heute eine API-Gateway-Lösung verwenden, ist diese Technologie kein Allheilmittel für die wachsenden API-Sicherheitsrisiken. Gateways eignen sich zwar hervorragend für die Bereitstellung und das Zugriffsmanagement, sind aber nicht ausgereift genug, um komplexe Angriffe abzuwehren. Darüber hinaus werden Ansätze wie gRPC, MQTT und GraphQL immer beliebter, da die Unternehmen nach immer vielfältigeren technischen Modellen verlangen. Dies öffnet das Unternehmen jedoch für ausgefeiltere Angriffe auf APIs. Die Einführung von Governance-Standards und fortschrittlichen Sicherheitstools ist daher unerlässlich, wenn API-Protokolle mit noch flexibleren Strukturen als RESTful APIs genutzt werden.

Fazit

Unternehmen müssen nach Security-Tools suchen, die nicht nur Runtime-Protection bieten, sondern sich auch nahtlos in den Anwendungsentwicklungsprozess einfügen. Entwickler und Cybersecurity-Beauftragte sollten daher zunächst eine klare Bewertung der größten API-Risiken vornehmen. Das beginnt mit der automatischen Erkennung und der regelmäßigen Aktualisierung eines API-Katalogs. Da die Angriffe immer komplexer werden, sollte die Lösung auch eine Bot-Erkennung beinhalten, die einen guten von einem schlechten Bot sowie allgemein einen Bot von einem echten menschlichen Benutzer unterscheiden kann. Um schließlich auch das Problem der veralteten APIs angehen zu können, muss eine Lösung auch den Lebenszyklus der API-Tokens sowie die verschiedenen Versionen der APIs überwachen. Mit diesem Ansatz können Entwickler die größten API-Sicherheitsrisiken adäquat angehen, ohne dabei ihre Innovationsagenda verlangsamen zu müssen.

Über den Autor: Kai Zobel ist Area Vice President EMEA Central bei Imperva.

(ID:48046502)