Warum API-Sicherheit jeden etwas angeht

Aug 20, 2023

Der Planet ist voll von APIs, den Mechanismen, mit denen Computer Informationen austauschen, den Bausteinen aller Software. Unternehmen erstellen ihre eigenen APIs für den internen Gebrauch oder um Kunden die Interaktion mit ihren Systemen zu ermöglichen. Sie nutzen APIs, um mit Partnern in Extranets und über Clouds hinweg zu kommunizieren. Sie nutzen APIs von Drittanbietern, um auf vorgefertigte Funktionen zuzugreifen – beispielsweise um Google Maps anzuzeigen oder Postleitzahlen-Suchtabellen in Formularen zu verwenden.

Die Anzahl der APIs wächst exponentiell mit der Verbreitung mobiler, Web- und Cloud-Anwendungen. Einige Branchenstatistiken:

Es überrascht nicht, dass APIs auch ein bedeutender und schnell wachsender Angriffsvektor sind. Laut Gartner: „Das explosionsartige Wachstum von APIs erweitert die Angriffsfläche von Unternehmen und bietet böswilligen Akteuren neue Möglichkeiten für Sicherheitsverletzungen und Datenexfiltration.“

Je nach Standpunkt ist es entweder sehr überraschend oder sehr wenig überraschend, dass etwa 50 % der verwendeten APIs nicht verwaltet werden.

Überraschend, weil sie ein offensichtliches und wachsendes Risiko darstellen. Dies ist nicht überraschend, da die explosionsartige Zunahme der API-Nutzung durch ein mangelndes Risikobewusstsein verstärkt wird – und weil APIs schwer zu verwalten sind. Entwickler veröffentlichen häufig neue APIs oder neue Versionen, ohne sich die Mühe zu machen, ihre Vorgänger zu löschen. Der Cyberspace ist mit Zombie-APIs übersät, die Back-End-Systeme und Daten offenlegen, aber nicht überwacht werden und keinen Geschäftswert bieten.

Eine ständig wachsende und schlecht überwachte Angriffsfläche: Hier wird der Traum eines jeden Hackers wahr.

Die Warnung von Gartner verdeutlicht eines der offensichtlichen Risiken der API-Sicherheit: APIs sind Kreuzungspunkte für eine Menge sensiblen Datenverkehrs. In Banking- oder E-Commerce-Apps können dies beispielsweise Kontodaten oder Kreditkartennummern von Kunden sein. Aber APIs legen nicht nur die Daten eines Unternehmens (und seiner Kunden) offen, sondern auch die Geschäftslogik hinter den Diensten. Schwachstellen in der Geschäftslogik bieten Hackern neue Möglichkeiten, Angriffe zu starten, die wahrscheinlich unentdeckt bleiben, bevor es zu ernsthaften Verlusten kommt.

Beispielsweise haben wir für eine Bank gearbeitet, die eine Routine zum Aufrunden sehr kleiner Beträge bei Devisentransaktionen einsetzte. Der Algorithmus war für typische Geschäfte bedeutungslos, da er eine Differenz von einem Bruchteil eines Cents bedeutete. Das System beschränkte jedoch die Anzahl der Transaktionen, die ein einzelner Kunde an einem Tag durchführen konnte, nicht. Durch die Umgehung von Front-End-Kontrollen und den direkten Angriff auf die Geschäftslogik war es möglich, eine große Anzahl kleiner Transaktionen durchzuführen, die einem Angreifer ermöglicht wurden die Rundungsfunktion zu nutzen, um Geld auf unser eigenes Konto zu drucken. Ähnliche Ergebnisse haben wir bei Kunden in der Kryptoindustrie erzielt, wo der Missbrauch der API-Geschäftslogik es uns auch ermöglichte, Kryptowährungen zu stehlen.

Natürlich verfügte die Bank über Kontrollen, die sie irgendwann auf das Problem aufmerksam gemacht hätten, räumte jedoch ein, dass es zu anomalen Geschäften im Wert von mehreren Millionen Dollar hätte kommen können, bevor Warnsignale gehisst wurden. Dieses Beispiel veranschaulicht einige wichtige Prinzipien der API-Sicherheit. Die nützlichsten APIs sind öffentlich. Sie sollen verwendet werden. Sie können sie nicht verstecken oder den Zugriff auf sie zu erschweren, ohne sie an ihrer Arbeit zu hindern.

Techniken wie Penetrationstests können hilfreich sein, aber auch Penetrationstests sind nur punktuelle Übungen und die Tester bewerten nur den bereitgestellten Umfang. Unternehmen mit API-Blindspots wissen nicht, wie sie die APIs eingrenzen sollen, und die meisten Penetrationstester werden entweder nicht gebeten, die Geschäftslogik zu testen, oder es mangelt ihnen an API-spezifischen Fähigkeiten, um zu beurteilen, was ein kompetenter API-Angreifer mit ihrem Zugriff anstellen könnte .

Die zweite Lektion ist, dass es keinen Sinn macht, sich nur auf einen Teil des API-Lebenszyklus zu konzentrieren. Die Shift-Left-Prinzipien konzentrieren sich zu Recht auf den Einbau von Sicherheit beim Entwurf und bei der Codierung, aber der Produktionslebenszyklus von Code ist genauso wichtig. Dinge ändern sich. Der ursprüngliche Code wurde von einem anderen Entwickler optimiert. Die Dokumentation ist schlecht oder nicht vorhanden. Das Geschäft steht unter Druck. Updates werden möglicherweise nicht gründlich getestet. Und selbst wenn die Entwicklung und das Testen tadellos waren und die Überarbeitungen sorgfältig durchgeführt wurden, kann es sein, dass im ursprünglichen Design etwas übersehen wurde, das Sie erneut verfolgen könnte. Bewegen Sie sich nach links, ja, aber hören Sie auf, nach rechts zu schauen, denn das ist Ihre Gefahr.

Sie beschränken das Testen eines Verkehrsflugzeugs nicht nur auf die Entwurfsphasen des Baus. Sie führen ein Testflugprogramm ohne Passagiere an Bord durch. Wenn es in Betrieb ist, führen Sie fortlaufend automatisierte Prüfungen durch und überwachen kontinuierlich seine kritischen Systeme, solange es in der Luft ist. Wir müssen etwas Ähnliches mit APIs machen. Das Problem ist, wie wir bereits gesehen haben, ihre schiere Anzahl. Nicht alle befördern Passagiere oder wertvolle Fracht. Einige von ihnen gehen banalen Jobs nach – oder sind arbeitslos, wenn sie in den Ruhestand gegangen oder entlassen wurden.

Wie jeder CISO weiß, besteht die größte Herausforderung im Bereich Sicherheit nicht darin, Bedrohungen zu identifizieren, sondern darin, die wirklich wichtigen Bedrohungen zu erkennen und sie in die richtige Reihenfolge zu bringen.

Es ist entscheidend, wie Sie dies tun. Zunächst müssen Sie die Risiken sichtbar machen.

Das ist nicht schwer, wenn Sie wissen, wo Sie suchen müssen, und die Sicherheitsteams bereits hüfthoch in Alarmbereitschaft sind. Das Schwierige daran ist, sie sinnvoll einzuordnen. Hierzu ist eine dreidimensionale Betrachtung erforderlich, die Folgendes berücksichtigt:

Mit anderen Worten: Sie möchten wissen: Kann etwas Schlimmes passieren, wie schlimm wäre es für Ihr Unternehmen, wenn es passieren würde, und wie hoch ist die Wahrscheinlichkeit, dass etwas Schlimmes passiert? Jeder dieser Faktoren muss dann gewichtet und korreliert werden, um eine Risikobewertung zu erhalten. Um eine nicht-technische Analogie zu verwenden: Wenn eines Ihrer Risiken ein „wilder Löwe“ ist, sich der Löwe jedoch in einem Stahlkäfig befindet, könnte die Punktzahl niedrig sein. Wenn es sich bei einem anderen um eine Mäusefamilie handelt, der Kontext jedoch eine Papiertüte ist, könnten Sie zu einem ähnlichen Schluss kommen. Wenn sich Ihr Löwe in einer Papiertüte befindet, verstehen Sie schon, worauf es ankommt. Hierzu sind wesentlich detailliertere Daten erforderlich, als die meisten Tools derzeit bereitstellen. Das Geheimnis besteht darin, die Informationen aus mehreren Linsen zu sammeln. Das bedeutet, dass man sich beispielsweise nicht nur mit der Datenverkehrsanalyse beschäftigt – obwohl diese nützlich ist, wenn eine API in Produktion ist –, sondern auch mit der Analyse des Quellcodes, der den Kontext liefert, und der Größe der Angriffsfläche, die Aufschluss über die Wahrscheinlichkeit gibt.

Dieser hochauflösende 3D-Ansatz ermöglicht es Unternehmen, ihre API-Risiken mit Sicherheit und Genauigkeit zu verwalten, und bietet dringend benötigte Anleitungen dazu, wie sie bereits überlastete Entwickler- und Technikressourcen nutzen können, um sich zuerst auf ihre größten Risiken zu konzentrieren.

Lassen Sie uns mit zwei überraschenden Gedanken schließen. Erstens, wie weit offen APIs für Angriffe von außen sind. Zweitens, wie wenig die Branche offenbar getan hat, um umfassende Lösungen zu entwickeln, die das gesamte Problem vom Quellcode bis zur Außenwelt angehen. Da der API-Verkehr heute 9 von 10 Paketen im Web ausmacht und immer weiter zunimmt, ist dies ein Problem, das wir jetzt alle lösen müssen.