goSecurity BLOG

Eine API (Application Programming Interface) wird dann entwickelt, wenn die Funktion der jeweiligen Applikation verbessert, erweitert oder mit einem anderen Service kombiniert werden muss. Ich gehe hier bewusst nur auf die Sicherheitsaspekte ein – wie genau eine API funktioniert, ist bereits in anderen Artikeln im Internet eingängig erklärt. [1] Ein möglicher Anwendungsfall könnte sein, dass ein Onlineshop mit den Systemen der Post für die Paketauslieferung verbunden wird, so dass dem Kunden nach der Bestellung die Paketnummer mitgeteilt werden kann (für das Tracking seiner Lieferung). Hier würde eine API die Kommunikation zwischen den beiden Systemen sicherstellen und die benötigten Daten austauschen.

Leider kommt es immer wieder vor, dass die Sicherheit in den Software-Projekten vernachlässigt wird. Gerade in grösseren Projekten oder bei hoher Systemkomplexität ist die Gefahr besonders gross, und es entstehen unbeabsichtigt sogenannte Rogue, Shadow und Zombie APIs. Wofür stehen diese Begriffe? Im nächsten Abschnitt gehe ich ganz kurz darauf ein.

Schädliche APIs

Rogue API: Eine Rogue API ist eine nicht offiziell autorisierte oder genehmigte API. Die Verwendung einer “unseriösen” API könnte es Personen ermöglichen, ohne Erlaubnis Kundendaten z.B. aus einem CRM-System abzurufen, oder sie könnten die Sicherheitskontrollen einer Website umgehen. Rogue APIs entstehen meist ungewollt und durch mangelndes Wissen des Entwicklers, z.B. durch die Implementierung von Third Party APIs in seinen Projekten. Gerade bei Third Party APIs besteht die grosse Gefahr darin, dass der Code nicht mehr gepflegt wird und dadurch Schwachstellen beinhaltet, ohne dass der Entwickler sich dessen bewusst ist. Mal ganz abgesehen davon, dass die Quelle womöglich nicht seriös ist und dazu die API noch ungenügend dokumentiert ist, was sich fatal auf den Einsatz auswirken kann. Hacker kennen aber womöglich den Code ganz genau, und können sich über eine solche Rogue API problemlos Zugriffe auf Systeme verschaffen.

Shadow API: Bei einer Shadow API handelt es sich um eine API, die nicht von der Organisation, welche sie verwendet, verwaltet oder gesichert wird. Häufig werden Shadow APIs von Entwicklern und anderen Benutzern innerhalb einer Organisation während des Entwicklungsprozesses eingeführt (z.B. für Testzwecke), aber vor dem Release der Applikation dann vergessen zu entfernen. Eine Shadow API kann sich schnell zu einer gefährlichen Schwachstelle entwickeln, aus denselben Gründen, die ich zuvor bei der Rogue API erwähnt habe.

Zombie API: Es gibt viele verschiedene Arten von Zombie APIs, aber sie haben alle eines gemeinsam: sie werden vom ursprünglichen Anbieter nicht mehr gepflegt und unterstützt. Diese APIs werden oft instabil, der Code ist veraltet und deshalb werden diese APIs zu einem Problem im Alltagsbetrieb. Auch hier besteht die Gefahr, dass Daten unbemerkt manipuliert oder sogar wegkopiert werden, denn aufgrund des eingestellten Supports des Anbieters werden auch Schwachstellen in der API nicht mehr behoben.

API-Security ist Chefsache

Da die oben genannten APIs sehr gefährlich werden können, muss API-Security Chefsache sein! Und wenn wir von einem Chef reden, ist hier klar, wer gemeint ist: der CISO. Entschuldige, lieber CISO, ein Task mehr auf Deiner ToDo-Liste, und nur Du kannst die Welt noch retten! Aber keine Angst, Du kannst “die 3 Säulen der API-Security“ zum Einsatz bringen! Die 3 Säulen der API-Sicherheit setzen sich aus folgenden Themen zusammen:

• Führung

• Testen

• Überwachung

Und wie das im Alltag funktioniert, darauf gehen wir nun etwas näher ein.

Führung

Eine sichere API-Entwicklung sollte hier im Fokus eines jeden Software-Projektes stehen und darf nicht stiefmütterlich behandelt werden. Die Entwickler müssen im Bereich API-Security sensibilisiert und entsprechend geschult werden. Planen sie genügend Zeit in den Projekten ein, um die APIs sauber und vollständig zu dokumentieren. Hierfür gibt es verschiedene Tools wie “Swagger” [2], die einem viel Arbeit abnehmen.

Und wenn wir gerade beim Thema Dokumentation sind: lassen Sie die Dokumentation nicht durch einen Entwickler schreiben. Entwickler sind keine gute Wahl, wenn es um die Dokumentation der APIs geht. Nicht, dass sie das nicht können, im Gegenteil. Doch hier kommt ein anderer Aspekt zum Tragen, und zwar muss für die Dokumentation eine andere “Flughöhe” anvisiert werden – Entwickler stecken meist viel zu tief in der Thematik des Programmierens. Zudem hat der Entwickler meist wenig bis gar keine Zeit, nebst dem Coding noch zu dokumentieren, denn schliesslich wartet bereits das nächste Arbeitspaket im Backlog. Meine Empfehlung: prüfen Sie, ob sich womöglich Ihr Test-Engineer besser dafür eignet, die Dokumentation zu schreiben. Denn durch das Testing hat er ein sehr gutes technisches Verständnis, ist aber trotzdem nicht zu tief in die Umsetzung involviert.

Wie bei allen Werten einer Unternehmung, empfiehlt es sich auch bei den APIs ein Inventar zu erstellen und zu pflegen. Das verhindert zudem, dass Zeit und Ressourcen in die Entwicklung von neuen APIs investiert werden, die denselben Zweck erfüllen wie die bestehenden (aber womöglich vergessenen) APIs. Auch hier helfen ihnen Tools, den Überblick zu behalten.

Der Aufwand für die Implementierung und Aufrechterhaltung von Sicherheitsstandards sollte nicht unterschätzt werden. Einfacher ist es, wenn das Thema Sicherheit von Anfang an in das Projekt eingeplant wird und in Ihrer agilen Methodik in jedem Schritt integriert und überprüft wird. Eine nachträgliche Implementierung führt meist zu Mehrkosten, Fehlern und Verzögerungen im Projekt. Wird das Thema Sicherheit und die Implementierung als normales Arbeitspaket im Projekt behandelt, ist es planbar und wesentlich kostengünstiger als die nachträgliche Implementierung in eine bereits implementierte Lösung und ggf. der Umbau der Architektur.

Zur Führung gehört auch, dass gezielte Massnahmen ergriffen werden, um das Entstehen der oben erwähnten Typen von schädlichen APIs zu vermeiden:

• Verwenden Sie eine Netzwerksicherheitslösung, die API-Bedrohungen erkennt und blockiert.

• Gewähren Sie den Zugriff auf sensible Daten nur denjenigen, die ihn wirklich benötigen

• Etablieren Sie eine ständige Überwachung der API-Aktivitäten auf verdächtige oder nicht autorisierte Aktivitäten

• Blockieren Sie unverzüglich verdächtige IP-Adressen

• Sorgen Sie für eine Gewährleistung der Sicherheit aller Daten durch die Nutzung vertrauenswürdiger Drittanbieterdienste

• Entwickeln und setzen Sie eine API-Entwicklungs-Richtlinie durch

• Nutzen Sie eine “Definition-of-Done” Check-Liste und setzen z.B. folgende Punkte auf die Liste: “laufende Code Reviews, Architektur-Reviews oder Security Checks“

• Stellen Sie eine regelmässige API-Inventarisierung und -Auditierung sicher

• Implementieren Sie API-Gateways

• Führen Sie eine geeignete Versionierung- und Lebenszyklus-Strategie für Ihre APIs ein

Testen

„Inputvalidation & sanitization“ sind bei der Softwareentwicklung an der Tagesordnung. Manche Frameworks haben bereits diese Funktionen mit an Bord, wodurch man sich viel Zeit mit der Implementierung spart. Doch die Sache hat einen Haken: oft erfolgt die Validierung der Eingabedaten nur auf der UI-Ebene (im Front-End), aber nicht im Back-End, wo die API ebenfalls ansprechbar ist. Hier werden oft alle relevanten Daten in der Anfrage mitgegeben. Der API Endpoint arbeitet stateless und speichert keine Daten zwischen den einzelnen Anfragen. Somit werden alle Daten, die für eine Authentifizierung notwendig sind, immer mit übergeben.

Beim “Test-Driven-Development” handelt es sich um eine Entwicklungsstrategie, die darauf abzielt, das Testen in den Vordergrund zu stellen, bevor der eigentliche Code entsteht. Ziel ist es, die Qualität der Software deutlich zu erhöhen und den späteren Wartungsaufwand zu reduzieren, indem die Entwickler Softwaretests vor den zu testenden Komponenten erstellen.

Proaktives “vulnerability testing” (also die proaktive Suche nach Schwachstellen im Code) lautet hier das richtige Stichwort. Hier sollten vor jedem Release Testfälle konstruiert werden, in der die API vollständig auf ihre Funktion geprüft wird. Die fehlerhaft formatierten Anfragen sollten positive Tests für die korrekte Verarbeitung und negative Tests für die korrekte Ablehnung der Anfragen erhalten. Ebenso ist es wichtig in den Testszenarien nicht nur das UI zu testen, wie beispielsweise mit Postman [3], auch das Back-End zu überprüfen. Neben den Negativ-Tests, bei welchen eine Korrekte Ablehnung oder Fehlermeldung erwartet wird, sollten auch Break-Tests etabliert werden, in denen der Tester wie ein Hacker vorgeht. Hacker sind aus Sicht der Applikation auch nur Anwender, die eine API aber auf eine andere Weise aufrufen und versuchen diese auszutricksen, um Daten zurückzuerhalten, auf die sie eigentlich keinen Zugriff haben sollten.

Das Testen sollte nicht (was vielleicht naheliegend wäre) durch die Entwickler selbst erfolgen, sondern durch eigene Test-Engineers oder sogar durch externe Spezialisten. Eine Kombination von allen ist sicherlich am sinnvollsten. Auf diese Weise wird auch sichergestellt, dass die Vorstellungen aller Beteiligten in Bezug auf die Funktionalität eines bestimmten Endpunkts identisch sind. Entwickler sollten jedoch ein Verständnis dafür haben, wie eine API umgangen werden kann. Die OWASP Top 10 API Security Risks [4] sind hier sehr hilfreich. Dennoch ist der Entwickler meist durch die Implementierung etwas betriebsblind geworden und testet weniger genau als jemand, der die API nicht von Grund auf kennt.

 Empfehlenswerte Testverfahren:

An dieser Stelle will gesagt sein, dass ein API-Gateway oder eine Web Application Firewall (WAF) keinen 100% Schutz bietet! Denn wie zuvor erwähnt, verhält sich ein Hacker hier wie ein Anwender. Die Anfragen werden bewusst manuell erzeugt und nicht automatisiert, um möglichst nicht aufzufallen. Anders sieht es aus mit KI-basierten Systemen – diese erkennen Anomalien und reagieren darauf. Letztlich bieten aber auch diese keinen vollständigen Schutz, sondern stellen nur eine weitere Schutzmassnahme dar. Die Überwachung ist im Idealfall eine Kombination aus den erwähnten Schutzmassnahmen, damit ein möglichst breites Feld an möglichen Angriffen abgedeckt werden kann. Zusätzlich sollten Run-Time Analyse- und Erkennungs-Systeme etabliert werden, zeitnah auf Incidents reagieren zu können.

Fazit

Werfen wir nochmals einen Blick auf Best-Practice-Ansätze zu diesem Thema:

• Informieren Sie sich über alle Sicherheitsrisiken:

  • Indem sie sich über die neuesten Hacking-Trends auf dem Laufenden halten, können Entwickler ihre APIs entsprechend so designen, dass sie den neuesten Angriffen standhalten.

• Authentifizierung und Autorisierung:

  • Kontrollieren Sie sorgfältig den Zugriff auf Ihre API-Ressourcen. Identifizieren Sie dabei alle zugehörigen Geräte und Benutzer sorgfältig. Bei einer clientseitigen Anwendung, verwenden Sie ein Token, damit der Dienst beim API-Aufruf den Client validieren kann.

  • Nutzen Sie Standard-Web-Tokens zur Authentifizierung des API-Verkehrs und zur Festlegung von Zugriffskontrollregeln.

  • Ausserdem können Sie mithilfe von Berechtigungstypen festlegen, welche Benutzer, Gruppen und Rollen Zugriff auf bestimmte API-Ressourcen benötigen.

• Verschlüsseln Sie Ihre Daten:

  • Alle Daten müssen angemessen verschlüsselt werden, damit nur befugte Benutzer die Daten ändern und entschlüsseln können.

• Validieren Sie die Daten:

  • Verlassen Sie sich nicht darauf, dass die Daten korrekt in ihrem System ankommen. Validieren und führen Sie eine Datenbereinigung durch, bevor Sie die Daten zur weiteren Verarbeitung weiterreichen.

• Identifizieren Sie API-Schwachstellen:

  • Für die Sicherheit Ihrer APIs ist die Durchführung einer Risikobewertung essenziell. Führen Sie deswegen regelmässig Tests durch, um die Sicherheit der APIs überprüfen.

• Begrenzen Sie die Weitergabe vertraulicher Informationen:

  • Beschränken Sie den gesamten Datensatz eines API-Aufrufes auf das Notwendigste an Informationen. Natürlich ist es einfacher in einem Aufruf gleich alle Daten mitzugeben, anstatt mehrere dedizierte Endpoints zu entwickeln. Aber dadurch steigt die Gefahr, dass unnötige oder gar sensible Informationen weitergegeben werden.

• Verwenden Sie API-Gateways:

  • Mithilfe eines API-Gateway lässt sich der Datenverkehr, und wie eine API genutzt wird validieren, analysieren und kontrollieren.

  • Seien Sie sich bewusst, dass eine API-Gateway kein 100% Schutz bietet und nur eine von mehreren Schutzmassnahmen sein kann.

Quellen:

[1]: https://www.talend.com/de/resources/was-ist-eine-api/

[2]: https://swagger.io/

[3]: https://www.testautomatisierung.org/lexikon/postman-api/#:~:text=Postman%20ist%20eines%20der%20beliebtesten,REST%20APIs%20auf%20HTTP%2DBasis.

[4]: https://owasp.org/API-Security/editions/2023/en/0x11-t10/

[5]: https://jmeter.apache.org/