Coders Conquer Security OWASP Top 10 API Series - Unsachgemäße Verwaltung von Assets
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.
Bei dieser Schwachstelle handelt es sich eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange nach ihrer Ablösung durch neuere, sicherere Versionen weiter verwendet werden können.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
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.
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Die Leistungsfähigkeit von OpenText Fortify + Secure Code Warrior
OpenText Fortify und Secure Code Warrior bündeln ihre Kräfte, um Unternehmen dabei zu helfen, Risiken zu reduzieren, Entwickler zu Sicherheits-Champions zu machen und Kundenvertrauen aufzubauen. Lesen Sie hier mehr darüber.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Die Secure-by-Design-Bewegung ist die Zukunft der sicheren Softwareentwicklung. Erfahren Sie mehr über die wichtigsten Elemente, die Unternehmen berücksichtigen müssen, wenn sie über eine Secure-by-Design-Initiative nachdenken.
Ressourcen für den Einstieg
10 wichtige Vorhersagen: Secure Code Warrior über den Einfluss von KI und Secure-by-Design im Jahr 2025
Unternehmen stehen vor schwierigen Entscheidungen über den Einsatz von KI, um die langfristige Produktivität, Nachhaltigkeit und den Sicherheits-ROI zu unterstützen. In den letzten Jahren ist uns klar geworden, dass KI die Rolle des Entwicklers niemals vollständig ersetzen wird. Von KI + Entwicklerpartnerschaften bis hin zum zunehmenden Druck (und der Verwirrung) rund um die Secure-by-Design-Erwartungen - lassen Sie uns einen genaueren Blick darauf werfen, was wir im nächsten Jahr erwarten können.
OWASP Top 10 für LLM-Bewerbungen: Was ist neu, was hat sich geändert, und wie bleibt man sicher?
Bleiben Sie bei der Absicherung von LLM-Anwendungen mit den neuesten OWASP Top 10 Updates immer einen Schritt voraus. Entdecken Sie, was neu ist, was sich geändert hat und wie Secure Code Warrior Sie mit aktuellen Lernressourcen ausstattet, um Risiken in der generativen KI zu minimieren.
Trust Score zeigt den Wert von Secure-by-Design-Upskilling-Initiativen
Unsere Forschung hat gezeigt, dass Schulungen für sicheren Code funktionieren. Trust Score verwendet einen Algorithmus, der auf mehr als 20 Millionen Lerndaten aus der Arbeit von mehr als 250.000 Lernenden in über 600 Organisationen basiert, und zeigt, wie effektiv die Initiative ist, um Schwachstellen zu beseitigen und wie man sie noch effektiver gestalten kann.
Reaktive versus präventive Sicherheit: Prävention ist das bessere Heilmittel
Der Gedanke, Legacy-Code und -Systeme zur gleichen Zeit wie neuere Anwendungen mit präventiver Sicherheit auszustatten, kann entmutigend erscheinen, aber ein Secure-by-Design-Ansatz, der durch die Weiterbildung von Entwicklern durchgesetzt wird, kann die besten Sicherheitsverfahren auf diese Systeme anwenden. Dies ist für viele Unternehmen die beste Chance, ihre Sicherheitslage zu verbessern.