Im Gegensatz zu den meisten Schwachstellen in den OWASP-API-Top-Ten geht es bei der unsachgemäßen Verwaltung von Assets nicht speziell um Kodierungsfehler. Stattdessen handelt es sich bei dieser Schwachstelle eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs auch dann noch verwendet werden, wenn sie längst durch neuere, sicherere Versionen hätten ersetzt werden müssen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt werden, bevor sie vollständig gegen Bedrohungen abgesichert sind.

Diese Schwachstelle ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell in Betrieb genommen werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und nie außer Betrieb genommen werden. Wenn die älteren APIs mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.

Möchten Sie eine gamifizierte Herausforderung zu diesem Sicherheitsproblem ausprobieren? Betreten Sie unsere Arena: [Hier starten]

Wie wirken sich unsachgemäße Mängel in der Vermögensverwaltung auf APIs aus?

Der Makel des falschen Asset-Managements ist ein Produkt der modernen Zeit. Organisationen, die sich mit der Geschwindigkeit des Geschäfts bewegen, können manchmal hunderte oder tausende von Services und Microservices pro Tag aufsetzen. Dies geschieht oft schnell und ohne die Erstellung einer begleitenden Dokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie kritisch sie sind. Dies kann schnell zu einem API-Wildwuchs führen, der mit der Zeit nicht mehr zu bändigen ist, vor allem, wenn es keine pauschalen Richtlinien gibt, die festlegen, wie lange APIs existieren dürfen.

In dieser Umgebung ist es sehr gut möglich, dass einige APIs verloren gehen, in Vergessenheit geraten oder nie außer Betrieb genommen werden.

Auch Benutzer mit der Berechtigung, neue Dienste außerhalb des normalen Prozesses zu erstellen, sind manchmal schuld. Zum Beispiel könnte eine Marketinggruppe einen Dienst erstellen, um ein bevorstehendes Ereignis wie eine Produkteinführung zu unterstützen, und ihn dann nie wieder zurücknehmen, nachdem das Ereignis abgeschlossen ist. Jemand, der sich diesen Dienst und die zugehörigen APIs später ansieht, hat vielleicht keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich vielleicht nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie kritisch sie sind oder was sie tun.

Die Schwachstelle wird gefährlich, weil sich die Sicherheit von APIs in Frameworks mit der Zeit verbessert. Ein Forscher könnte eine Schwachstelle entdecken, oder es könnte zusätzliche Sicherheit hinzugefügt werden, um eine zunehmend beliebte Art von Angriffen zu stoppen. Ältere APIs können für diese Angriffe anfällig bleiben, wenn sie nicht aktualisiert werden, sodass Hacker oft nach ihnen suchen oder automatisierte Tools verwenden, um sie aufzuspüren.

In einem realen Beispiel, das von OWASP zur Verfügung gestellt wurde, aktualisierte ein Unternehmen seine APIs, die zum Durchsuchen von Benutzerdatenbanken verwendet werden, um eine kritische Schwachstelle zu beheben. Die alten APIs wurden jedoch versehentlich beibehalten.

Ein Angreifer bemerkte, dass der Speicherort der neuen API in etwa (api.criticalservice.com/v2) lautete. Durch Ersetzen der URL mit (api.criticalservice.com/v1) konnten sie stattdessen die alte API mit der bekannten Schwachstelle verwenden. Dadurch wurden letztlich die persönlichen Daten von über 100 Millionen Benutzern offengelegt.

Beseitigung von Fehlern in der Vermögensverwaltung

Die einzige Möglichkeit, den Fehler der unsachgemäßen Verwaltung von Assets in Ihrer Umgebung zu beseitigen, besteht darin, ein genaues Inventar aller APIs, ihrer Verwendung und Versionen zu führen. Dies sollte mit einer Inventarisierung der vorhandenen APIs beginnen und sich auf Faktoren konzentrieren, wie z. B. in welcher Umgebung sie eingesetzt werden sollen, wie Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben soll und natürlich ihre Version.

Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem die Dokumentation automatisch zu allen neuen APIs oder Diensten hinzugefügt wird, die erstellt werden. Dies sollte alle Aspekte der API umfassen, einschließlich der Ratenbegrenzung, der Behandlung von Anfragen und Antworten, der gemeinsamen Nutzung von Ressourcen, der Endpunkte, mit denen eine Verbindung hergestellt werden kann, sowie aller relevanten Richtlinien, die für eine spätere Prüfung erforderlich sind. Sie sollten auch vermeiden, jemals nicht produktive APIs oder solche aus der Entwicklungsumgebung in der Produktion zu verwenden. Ziehen Sie auch in Erwägung, eine zeitliche Begrenzung für APIs einzuführen, bei der ihre weitere Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.

Wann immer neue Versionen aktiver APIs verfügbar werden, führen Sie ein Risiko assessment durch, um festzustellen, ob Sie ein Upgrade durchführen sollten und wie dieser Prozess ablaufen sollte, um eine Unterbrechung der Produktionsumgebung zu vermeiden. Sobald Sie auf die neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.

Wenn Sie all das tun, können Sie verhindern, dass die unsachgemäße Verwaltung von Assets Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk Schaden zufügt. Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.

‍