Rezept für eine Katastrophe: API-First mit Security-Last-Strategien

Es besteht eine wachsende Nachfrage nach APIs. Ob sie nun dazu beitragen, die digitale Wirtschaft durch die Aktivierung mobiler Apps voranzutreiben oder die interne Produktivität durch Automatisierungs- und Orchestrierungsinitiativen zu steigern – APIs sind allgegenwärtig.

Viele Organisationen haben den digitalen Schlachtruf „API first!“ übernommen. Konkret heißt das: Eine Mehrheit (60 %) der Teilnehmer am „State of API Integration 2018“ von Cloud Elements stellt jedem Entwickler eine API zur Verfügung. Es zahlt sich aus. Unglaubliche 85 % der Unternehmen erwirtschaften zumindest einen gewissen Umsatz durch APIs und API-bezogene Implementierungen. Der Großteil (59 %) erwirtschaftet zwischen 11 und 50 % des Umsatzes ihres Unternehmens. Mehr als ein Zehntel (11 %) erzielt über die Hälfte seines Umsatzes allein durch APIs. ( Der steigende Wert der APIs von MuleSoft )

Ich möchte Sie jedoch daran erinnern, dass sie ihre APIs JEDEM Entwickler zugänglich machen. Nicht irgendein Entwickler mit guten Absichten, sondern jeder Entwickler.

Die offene Natur der heutigen API-Wirtschaft ist einer der Gründe dafür, dass eine API-First-Strategie leider allzu oft von einer Security-Last-Strategie begleitet wird.

Eine wahre Fülle von API-bezogenen Sicherheitsvorfällen, an denen namhafte Organisationen beteiligt sind, lässt sich relativ einfach finden. Ob von Forbes erwähnt oder von unseren eigenen F5 Labs aufgedeckt: Diese Organisationen waren von API-bezogenen Sicherheitsverletzungen betroffen, die mit gut verstandenen Sicherheitspraktiken und -tools hätten verhindert werden können.

Unser eigener Ray Pompon – Principal Threat Research Evangelist für F5 Labs – stellte in seiner Forschung zur API-Sicherheit fest:

„…Sie können Muster erkennen, die mit denselben klassischen Problemen der Anwendungssicherheit zusammenhängen, die wir schon immer hatten: Angreifer verschaffen sich Zugriff durch Brute-Force-Angriffe oder gestohlene Anmeldeinformationen. Darüber hinaus nutzten Angreifer nach der Authentifizierung gegenüber der API die zu weit gefassten zugewiesenen Berechtigungen aus.“

Von < https://www.f5.com/labs/articles/threat-intelligence/reviewing-recent-api-security-incidents >

Dieselben, klassischen Probleme. Denn letztendlich werden APIs meistens als über HTTP transportierte URIs implementiert, die eine Nutzlast von JSON- oder XML-Daten transportieren. Das ist nicht viel anders als eine über HTTP transportierte URI, die eine Nutzlast aus per POST übermittelten Formulardaten transportiert.

Und vergessen wir nicht, dass eine API nur eine Schnittstelle zum Code ist. Code, der basierend auf den WhiteHat Application Security Statistics durchschnittlich 39 Schwachstellen pro 100.000 Codezeilen (LOC) aufweist. Moment, das gilt für eine herkömmliche App. Wie wäre es mit 180 pro 100.000 LOC, wenn Sie die Schnittstelle (API) mithilfe einer Microservices-Architektur implementieren würden? So oder so, das sind eine Menge Schwachstellen.

Eine API birgt dieselben Schwachstellen wie ihr Gegenstück, die Web-App. Und das bedeutet, dass sie in Bezug auf die Sicherheit die gleiche Aufmerksamkeit erfordert wie eine Webanwendung.

Und doch wird der API-Sicherheit nicht der gleiche Stellenwert beigemessen wie der Sicherheit von Web-Anwendungen – zumindest nicht auf der Grundlage existentieller Beweise, die die mangelhafte Vorgehensweise bei den durchgeführten Sicherheitstests entlarven. Eine informelle Umfrage von SmartBear ergab, dass heute nur 12 % der Befragten „umfassende“ API-Sicherheitstests durchgeführt haben. Fast doppelt so viele – 23 % um genau zu sein – haben überhaupt KEINE API-SICHERHEITSTESTS durchgeführt. Dies steht im Einklang mit einer formaleren Untersuchung von SmartBear , die ergab, dass 80 % der Befragten ihre APIs testen.

Damit sind immer noch 20 % übrig, die dies nicht tun.

API-First ist eine großartige Möglichkeit, sich an der digitalen Wirtschaft zu beteiligen und sowohl Unternehmen als auch Betriebe in schlanke, leistungsfähige digitale Maschinen zu verwandeln. Aber wenn man die Sicherheit an die letzte Stelle setzt, kann daraus schnell ein verbitterter Hashtag auf Twitter* werden. Und das will niemand.

Wenn Sie sich also für die API entscheiden – und das sollten Sie –, dann muss Sicherheit für Sie oberste Priorität haben. Akzeptieren Sie für Ihre APIs keine Strategie, bei der die Sicherheit an letzter Stelle steht.

Einige einfache Schritte erleichtern Ihnen den Einstieg:

1. Wenn es existiert, testen Sie es.
2. Wenn Benutzereingaben vorhanden sind, vertrauen Sie diesen nicht.
3. Wenn eine Benutzeranmeldung vorhanden ist, schützen Sie diese vor Brute-Force- und Credential-Stuffing-Angriffen.
4. Denken Sie daran, dass Sie die Systeme und Dienste, auf denen Ihre API basiert, warten und patchen müssen. Ihre Schwachstelle ist die Schwachstelle Ihrer API.

Passen Sie da draußen auf sich auf.