Wenn Sie die OWASP API Security Top-10 verfolgt haben, haben Sie sicherlich bemerkt, dass sich die Version 2023 erheblich verändert hat. Zugegeben, einige Änderungen sind eher semantische Umstellungen, aber der neue Eintrag auf Platz 10 ist alles andere als oberflächlich. Er trägt den Titel „Unsichere Nutzung von APIs“. Es ist verständlich, wenn das nicht sofort bei Ihnen Alarm auslöst. Dennoch handelt es sich um eine wachsende Bedrohung, die sich von den anderen Bedrohungen unterscheidet. Aber ich habe eine einfache Lösung für Sie. Lassen Sie mich das erklären.
Verstehen der unsicheren API-Nutzung
Was ist unsichere API-Nutzung? Unternehmen nutzen zunehmend Softwaresysteme als Dienstleistung in der Cloud. APIs sind definitiv eine sehr bequeme Möglichkeit, diese Cloud-Systeme miteinander und mit verbleibenden On-Premises-Systemen zu verbinden. Es ist kaum Montage erforderlich. Herrlich. Aber sind Sie sich ausreichend bewusst, dass es eine tatsächliche Bedrohung gibt, wenn Sie API-Antworten blind verarbeiten? Eine Bedrohung, die der unsicheren Bereitstellung von APIs ähnlich ist?
Warum ist es eine wachsende Bedrohung? Als Konsument von Cloud-Diensten erwarten Sie, dass diese Systeme zuverlässig sind. Ein professionelles Unternehmen verwaltet sie und hat wahrscheinlich mehr Fachwissen in der sicheren Verwaltung ihrer Systeme als Sie in einem On-Premises-Szenario hätten. Richtig? Nun, meistens ja. Sie gehen davon aus, dass Ihre Anbieter niemals Opfer einer Insider-Bedrohung, eines böswilligen Eindringens oder einfach eines fehlerhaften Updates werden können. Und Sie gehen davon aus, dass niemand dazwischen Ihre Nachrichten durcheinander bringt. Doch Lieferkettenangriffe sind real.
Die Bedeutung von Vertrauen und Verifizierung
Die Rolle der Zero Trust Security
Es gibt einen Grund, warum Zero Trust Security so wichtig geworden ist. Sind Sie wirklich sicher, dass Sie mit Ihrem Anbieter verbunden sind? Sind Sie wirklich sicher, dass es keinen Man-in-the-Middle gibt? Sie wären sicherlich nicht der Erste, der in eine häufige Falle tappt. Und selbst wenn Sie ein VPN oder eine gegenseitig authentifizierte TLS-Verbindung eingerichtet haben, könnten Sie dennoch böswillig zu einem Dritten umgeleitet werden, wenn Sie nicht vorsichtig sind.
Potenzielle Risiken bei der API-Nutzung
Ihr Anbieter könnte Opfer eines Insider-Angriffs oder sogar eines Lieferketten-Angriffs werden, was die Antworten auf Ihre API-Aufrufe durcheinander bringt. Das ist eine bekannte Methode, um falsche Weiterleitungen, Malware, explodierende Zip-Dateien oder zufälliges Kauderwelsch zu injizieren, das Ihr Client-System zum Absturz bringen soll. Leider passiert das wirklich, sonst wäre es nicht in die OWASP Top-10 aufgenommen worden.
Unsichere Nutzung von APIs ist im Wesentlichen ein Mangel an Antwortvalidierung. Zum Glück gibt es eine einfache Strategie, um dem entgegenzuwirken.
Wie man sich vor unsicherer API-Nutzung schützt
Als Konsument einer API besitzen Sie nicht die Open API-Spezifikation. Diese wird Ihnen vom API-Besitzer zur Verfügung gestellt. Darüber hinaus wird auch der Lebenszyklus von dem Besitzer verwaltet. Ein verantwortungsbewusster API-Besitzer sollte eine detaillierte Spezifikation seiner API bereitstellen, die darauf ausgelegt ist, Missbrauch zu verhindern. Schließlich fungiert eine Open API-Spezifikation als Vertrag zwischen dem API-Anbieter und dem API-Client. Ein schlechter Vertrag ist ein Nährboden für Missverständnisse und Konflikte. Daher ist eine Investition in einen klaren, gut geschriebenen Vertrag eine Investition in eine gesunde Beziehung zu Ihren Kunden.
Denken Sie daran, die Open API-Spezifikation formalisiert die Semantik des Vertrags und ermöglicht die automatische Durchsetzung. Es geht darum, Ihren Vertrag so detailliert auszuarbeiten, dass jede API-Aufruf sinnvoll gegen ihn validiert werden kann. Ich nenne es ‚API-Härtung‚. Es nimmt die Brüchigkeit aus den Integrationen.
Leider bietet nicht jeder API-Besitzer aus welchem Grund auch immer einen gut definierten Vertrag. Aber das sollte Sie nicht davon abhalten, die API-Spezifikation, die Sie verwenden, zu härten. Besonders die Definition der Informationen, die Sie in Ihre Systeme fließen lassen, sollte von Interesse sein.
Wie Sie Ihren Schild hochfahren
Verwendung von Tools für API-Sicherheitsaudits
Sie nehmen die API-Spezifikation wie bereitgestellt. Nehmen wir die SCIMv2 API als Beispiel. SCIM, System for Cross-domain Identity Management, ist ein branchenweiter Standard-API für die Benutzerbereitstellung. Es wird beispielsweise weit in Identity Management Systemen, HR-Systemen und CRM-Systemen implementiert.
Ich habe zufällig die SCIM2 yaml-Datei von gravity.io genommen und in meine VS Code IDE geladen. Mein erster Schritt ist immer das Scannen mit dem 42Crunch Audit Scanner. Es stellt sich heraus, dass die API-Spezifikation behauptet, eine swagger: ‚2.0‘-Datei zu sein, aber nicht dem Standard entspricht. Das ist schlecht, aber leider nicht ungewöhnlich. In diesem Fall ist der oauth2-Grant-Typ ‚client-credentials‘ ein Problem. Wenn man ihn in ‚password‘ ändert, erfüllt er zumindest den Audit Scanner. Aber für interne Zwecke könnten Sie in Betracht ziehen, das Sicherheitsschema stattdessen in APIkey zu ändern.
Zusätzlich gab es einen Tippfehler in einem Schlüsselwort zu korrigieren: Schlampig! Und dies blockierte zufällig meinen Scanner daran, seine Magie zu entfalten.
Nach diesen Korrekturen zeigte unser vertrauenswürdiger 42Crunch Audit Scanner schnell viel Raum für Verbesserungen auf. Eine magerer Audit-Score von 10/100. Zeit, an die Arbeit zu gehen!
Beispiel: Verbesserung der SCIMv2 API-Spezifikationen
Wie Sie wahrscheinlich wissen, hat die Open API-Spezifikation JSON Schema übernommen, um die Nachrichteninhalte zu definieren – sowohl ausgehende Anfragen als auch eingehende Antworten. Offensichtlich werden wir uns auf die eingehenden Antworten konzentrieren. Tatsächlich gibt es zwei verschiedene Arten von JSON-Objekten zu berücksichtigen: gültige Antworten und Fehlermeldungen. Nehmen wir GET /Groups als Beispiel.
Es stellt sich heraus, dass die gelieferte Definition viel mehr zulässt, als Sie sich wünschen würden. Es gibt jedoch wertvolle Informationen, die in den Kommentaren innerhalb der Swagger-Datei versteckt sind. Wenn Sie in die eigentliche API-Spezifikation eintauchen und sich die Objektbeschreibungen ansehen, finden Sie nützliche Hinweise wie „description: REQUIRED“ oder „description: Non-negative integer“. Das Traurige ist, dass solche informativen Kommentare keine formale Spezifikation haben, sodass Sie sie nicht automatisch durchsetzen können. Glücklicherweise hat JSON Schema jedoch die Semantik, um unseren Bedürfnissen gerecht zu werden. Es ist eigentlich ganz einfach. Durch das Hinzufügen eines „minimum: 1“ zur Spezifikation wird die Ganzzahl per Definition nicht negativ. Ebenso wird das Hinzufügen des Schlüsselworts „required“ zum Objekttyp Ihnen ermöglichen, eine Antwort besser automatisch zu validieren. So wie das:
Group: {
type: object
required: [schemas, totalResults, Resources],
properties: …Es gibt weitere einfache Schema-Verbesserungen zu berücksichtigen, z.B. das Hinzufügen eines RegEx-Musters für Strings, einer Formatspezifikation für eine gültige URI, die einen Namespace der SCIM-Schemata spezifiziert,
schemas :
type: string,
format: uri,
maxLength: 1024
}oder eines Enumerationsarrays gültiger Werte,
enum: [book, movie, video, blog, podcast, webinar],oder alles, was zu Ihrem Abwehrschild beiträgt.
Wenn Sie mit der Spezifikation der Daten, die Sie akzeptieren möchten, zufrieden sind, gibt es noch eine Sache zu beachten. Und das ist der Durchsetzungsteil. Indem Sie eine 42Crunch WebAPI Firewall zwischen Ihrem Client und dem entfernten Dienst platzieren, mit Ihrer verbesserten Spezifikation der API, können Sie sicher sein, dass keine Daten, die gegen Ihre API-Definition verstoßen, durchgelassen werden. Darüber hinaus nimmt es Ihre API-Spezifikation als Positivliste, was bedeutet, dass nur vordefinierte Elemente die Firewall passieren dürfen. Selbst ohne die Richtlinie „unevaluatedProperties: false“ werden nicht definierte Eigenschaften – obwohl technisch im Standard erlaubt – blockiert.
Ebenso wird Ihre API-Firewall jede Antwort einfach verwerfen, solange in Ihrem API-Vertrag keine http:301 (Moved Permanently) oder http:308 (Permanent Redirect) Antwort deklariert ist. Sollte eine solche Weiterleitung jemals auftreten, wird eine potenziell bösartige Weiterleitung effektiv neutralisiert. Sie sind verantwortlich für die Antworten, die Sie akzeptieren möchten, und mit der 42Crunch API-Firewall haben Sie die Kontrolle zurück. Keine unsichere Nutzung von APIs unter Ihrer Aufsicht. Darum geht es beim defensiven API-Verbrauch.
Gibt es einen Nachteil?
Ich kann Sie fast einwenden hören.
„Aber, aber, jedes Mal, wenn mein Anbieter eine Änderung an seinem JSON-Schema vornimmt, müsste ich meine API-Spezifikation aktualisieren, und meine Clients müssten auf die neue Version migrieren. Wäre das nicht unnötig umständlich?“
Nun, ich bin fest davon überzeugt, dass es tatsächlich eine gute Sache ist, Ihre API-Spezifikation zu aktualisieren, wenn Sie deren Implementierung oder Vertrag geändert haben. Es gibt den Verbrauchern die Möglichkeit, die Auswirkungen der Änderung zu analysieren und die neue Version erst dann zu übernehmen, wenn sie bereit dafür sind. Sie wollen Ihre Clients doch niemals brechen, oder?
In diesem speziellen Fall betreiben Sie jedoch den Client. Trotzdem kontrollieren Sie Ihre eigene API-Spezifikation. Tatsächlich habe ich Ihnen ein Werkzeug gegeben, um zu verhindern, dass Sie schwer beschädigt werden. Wer weiß, wie sich Ihr Client mit nicht definierten Antworten verhält? Sie können einfach nicht für alles testen, was passieren könnte. Erinnern Sie sich an Hyrum’s Law? Auf der sicheren Seite zu bleiben, anstatt blind Änderungen zu akzeptieren, wird Ihnen helfen, nachts besser zu schlafen.
Natürlich sollten Sie im Falle einer Notfalländerung einen Prozess haben, um Ihre API-Firewall schnell zu aktualisieren. Vielleicht sogar vorübergehend Ihre Firewall in den Hörmodus versetzen, sobald Sie sicher sind, dass die Änderung gültig ist. Sie könnten auch eine Warnung auslösen, sobald eine API-Antwort von der Firewall abgelehnt wird. Schließlich handelt es sich um ein Sicherheitsereignis, das Sie verfolgen möchten. Aber das ist ein kleiner Preis, den Sie zahlen müssen, um eine unsichere Nutzung von APIs zu vermeiden.
Wenn Sie mehr über 42Crunch erfahren möchten und was es tun kann, um Ihre APIs zu schützen, sind Sie hier genau richtig. Wir teilen gerne unsere Erfahrungen. Warum kontaktieren Sie uns nicht sofort?
