Start Empfohlen Wie technische Schulden die API-Sicherheit beeinträchtigen

Wie technische Schulden die API-Sicherheit beeinträchtigen [Q&A]

5
0


api

APIs ermöglichen den einfachen Austausch von Informationen zwischen Apps, Microservices und Containern. Sie sind zu einem wesentlichen Bestandteil der Funktionsweise unserer digitalen Infrastruktur geworden.

Aber die Allgegenwart von APIs bedeutet, dass Entwickler unter dem Druck stehen, sie schnell zu produzieren, und das kann zu „technischen Schulden“ führen, weil Abstriche gemacht werden. Wir haben mit Tom Hudson, dem technischen Leiter der Sicherheitsforschung bei App Vulnerability Scanner, gesprochen Erkennen um mehr darüber zu erfahren, warum APIs auf diese Weise angreifbar sind und wie sie gesichert werden können.

BN: Warum stehen bei Sicherheitsexperten technische Schulden im Vordergrund? Wie wirken sich technische Schulden auf die API-Sicherheit aus?

TH: Technische Schulden treten überall dort auf, wo eine Ecke gekürzt wurde, um Zeit zu sparen, um die Funktionalität aus dem Weg zu räumen. Manchmal bedeutet dieser Eckenschnitt, keine Tests zu schreiben, nur den „glücklichen Weg“ zu berücksichtigen oder alte, ungenutzte Funktionen nicht zu entfernen. Wenn Entwickler nur die beabsichtigten Eingaben und die grundlegendsten ungültigen Eingaben berücksichtigen, können Sicherheitslücken entstehen. Nicht entfernte alte/unbenutzte Funktionen werden in der Regel nicht gewartet oder getestet. Wenn neue Schwachstellen entdeckt und neue Techniken entwickelt werden, kann sich dieser alte Code als angreifbar erweisen. Per Definition werden APIs von anderen Systemen konsumiert, und die Tendenz, Dinge für diese Systeme nicht kaputt zu machen, ist weit verbreitet, was bedeutet, dass alter Code manchmal länger bleibt als sonst, was möglicherweise zu Sicherheitsproblemen führt.

BN: Wie nutzen Angreifer verlassenen Code aus früheren Versionen einer API aus, um an Informationen/Assets zu gelangen? Welche Arten von Angriffen sind am häufigsten, sobald sie Zugang erhalten?

TH: Neben regulären Schwachstellen wie SQL Injection, SSRF usw. kann eine frühere Version einer API oft andere Geschäftsregeln haben, die regeln, was als Eingaben verwendet werden kann und was nicht. Geschäftsanforderungen ändern sich häufig zwischen API-Versionen (und sind manchmal der Grund für eine neue API-Version), was manchmal zu einer freizügigeren Filterung in älteren Versionen führt. Beispielsweise kann eine frühere Version der API die Verwendung eines größeren Zeichensatzes in einigen vom Benutzer bereitgestellten Daten ermöglichen; ein Entwickler kann später basierend auf den Regeln in einer neueren Version der API eine falsche Annahme darüber treffen, welche Zeichen in den Daten erscheinen können, was möglicherweise dazu führt, dass diese Daten auf unsichere Weise behandelt werden.

APIs werden zunehmend auch von anderen APIs verwendet. Eine öffentlich zugängliche API kann interne APIs aufrufen, um die zum Bilden einer Antwort erforderlichen Daten abzurufen. Vom Benutzer bereitgestellte Daten können in den Pfaden für diese internen API-Anforderungen verwendet werden, und ohne ordnungsgemäße Bereinigung dieser Daten können Pfaddurchläufe dazu führen, dass private Daten durchsickern. Zum Beispiel kann eine öffentliche API eine Benutzer-ID als Eingabe akzeptieren, wie ‚1234‘ und diese als Teil der Anfrage an eine interne API verwenden, zB internalapi.example.net/users/1234. Ein Angreifer könnte ‚1234/../2345‘ als Benutzer-ID übergeben. Es ist möglich, dass ein Teil des Codes diese Eingabe als Ganzzahl parst, was zu ‚1234‘ führt und bestätigt, dass sie gültig ist, während der ursprüngliche Wert weiterhin als Teil des Pfads verwendet wird. Das Endergebnis kann ein Aufruf von internalapi.example.net/users/1234/../2345 sein, der wiederum internalapi.example.net/users/2345 wird – fälschlicherweise werden Daten für Benutzer 2345 dem Angreifer, Benutzer 1234, preisgegeben Diese Art von Angriff kann leicht verwendet werden, um Daten für alle Kunden zu extrahieren. Neben der Bereinigung von Eingaben und der ausschließlichen Verwendung der bereinigten Versionen dieser Eingaben wäre es vorzuziehen, dass die interne API den Ursprungskontext der Anfrage erfordert (dh welcher Benutzer den öffentlichen API-Aufruf getätigt hat, damit sie auch den Zugriff ausführen kann). Kontrollen).

BN: Wie können Entwickler die „Code-Hygiene“ verbessern, um diese verschiedenen Versionen zu berücksichtigen und sicherzustellen, dass keine Lücken entstehen?

TH: Statische Analyse- und Code-Linting-Tools können bei richtiger Konfiguration sehr hilfreich sein, aber es kann auch effektiv sein, Zeit für die Bewältigung technischer Schulden zu haben – vorausgesetzt, sie wird nicht routinemäßig durch die Entwicklung „dringender“ neuer Funktionen in Anspruch genommen.

Aus organisatorischer Sicht ist es entscheidend, das Sicherheitsbewusstsein der Entwickler zu schärfen und ihnen die neuesten Informationen zu Schwachstellen in einem verdaulichen Format bereitzustellen, das ihnen das Handeln erleichtert. Sicherheitsteams müssen Entwickler und Ingenieure proaktiv anleiten, um fundierte Entscheidungen zu treffen – und nicht nur ihren Code auf Fehler überwachen. Es geht um Zusammenarbeit. Sicherheit ist nicht die Aufgabe einer einzelnen Person, jeder sollte sich in der Lage fühlen, Web-Sicherheit in seinen verschiedenen Rollen und Aufgaben zu besitzen.

BN: Wie können Unternehmen die Höhe ihrer technischen Schulden für ihre Vermögenswerte einschätzen?

TH: Ein guter Asset-Monitoring-Service kann Ihnen helfen, Dinge zu erkennen, von denen Sie nicht wussten, dass Sie sie haben. Gerade wenn Unternehmen größer werden und eine größere Anzahl autonomer Teams haben, wird es immer wahrscheinlicher, dass Schattensysteme auftauchen (dh Systeme, die Ihre zentrale IT- oder Sicherheitsfunktion nicht kennt). Ein Asset-Monitoring-System kann dieselben Techniken verwenden, die auch von Angreifern verwendet werden, um unbekannte Angriffsflächen, nicht gewartete Systeme und baumelnde DNS-Einträge zu entdecken.

BN: Wie sollten Unternehmen vorgehen, wenn sie Opfer eines API-Sicherheitsangriffs werden, der auf technische Schulden zurückzuführen ist? Ist es zu diesem Zeitpunkt zu spät für eine Behebung oder können Unternehmen die Lücke noch schließen?

TH: Es ist nie zu spät, aber eine große Anhäufung technischer Schulden kann dazu führen, dass es sich ein bisschen so anfühlt, als würde man versuchen, das Durcheinander von Drähten zu entwirren, die man für alle Fälle in dieser Schublade versteckt. Manchmal ist es einfacher, alles herauszuziehen und ordentlich wieder zu verstauen, als zu versuchen, es zu entwirren. Die Ursachenanalyse ist wichtig, um herauszufinden, wie Sie vorgehen sollten. Wenn festgestellt wird, dass die Hauptursache der Schwachstelle eine bekannte technische Schuld war, sollte der primäre Ansatz darin bestehen, sicherzustellen, dass Zeit für die Behebung der technischen Schulden bereitgestellt wird, möglicherweise indem sichergestellt wird, dass in jedem Sprint mindestens ein Element der technischen Schulden enthalten ist ( oder was auch immer das Äquivalent für die von Ihnen verwendete Entwicklungsmethodik ist). Wenn die Ursache eine unbekannte technische Schuld war, müssen Sie erwägen, Zeit für die Ermittlung und Verfolgung von technischen Schulden einzuplanen, z. B. mithilfe von Jira-Tickets oder Ähnlichem. Unabhängig von der Ursache ist die Zustimmung der Führung unerlässlich, um zu zeigen, dass technische Schulden echte Probleme verursachen können und angegangen werden müssen.

BN: Wie können Entwickler- und Sicherheitsteams zusammenarbeiten, um sicherzustellen, dass alle Facetten von Entwicklungen sicher sind, auch wenn sie nicht mehr aktiv genutzt werden?

TH: Am besten achtet man darauf, dass nicht mehr genutzte Anlagen nach Möglichkeit außer Betrieb genommen werden. Manchmal bedeutet dies, dass das Sicherheitsteam den Zustand der Dinge überwacht und die Entwicklungsteams auffordert, die Dinge außer Betrieb zu nehmen. Die andere Sache, die sehr nützlich ist, ist, immer unter der Annahme zu arbeiten, dass Sie verletzt werden, und entsprechend zu planen. Dies wird oft als „tiefe Verteidigung“ bezeichnet, um sicherzustellen, dass sensible Daten verschlüsselt werden, interne APIs eine ordnungsgemäße Authentifizierung und Zugriffskontrolle erzwingen usw.

Bildnachweis: Panchenko Vladimir/Shutterstock



Vorheriger ArtikelMINISFORUM EliteMini HX90 ist ein winziger Windows 11-fähiger PC mit einem AMD Ryzen 9 5900HX
Nächster ArtikelTCL 20-Serie erschwinglicher Android-Smartphones endlich in den USA erhältlich

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein