
Coder Conquer Security OWASP Top 10 API-Serie — Unsachgemäße Vermögensverwaltung
Im Gegensatz zu den meisten Sicherheitslücken in den Top Ten der OWASP-API geht es bei unsachgemäßem Asset-Management nicht speziell um Codierungsfehler. Stattdessen handelt es sich bei dieser Sicherheitslücke eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange bestehen bleiben, nachdem sie durch neuere, sicherere Versionen hätten ersetzt werden sollen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt sind, bevor sie vollständig gegen Bedrohungen geschützt sind.
Diese Sicherheitsanfälligkeit ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell bereitgestellt werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und niemals außer Betrieb genommen werden. Wenn die älteren APIs weiterhin mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.
Willst du eine spielerische Herausforderung zu diesem Sicherheitsproblem ausprobieren? Treten Sie ein in unsere Arena: [Fangen Sie hier an]
Wie wirken sich unsachgemäße Fehler in der Vermögensverwaltung auf APIs aus?
Der Fehler in der unsachgemäßen Vermögensverwaltung ist ein Produkt der Neuzeit. Unternehmen, die mit der Geschwindigkeit ihrer Geschäftstätigkeit Schritt halten, können manchmal täglich Hunderte oder Tausende von Diensten und Microservices anbieten. Dies geschieht häufig schnell und ohne die Erstellung einer Begleitdokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie wichtig sie sind. Dies kann schnell zu einer Vielzahl von APIs führen, die im Laufe der Zeit unzähmbar werden könnten, insbesondere wenn es keine pauschalen Richtlinien gibt, die definieren, wie lange APIs existieren können.
In dieser Umgebung ist es sehr wahrscheinlich, dass einige APIs verloren gehen, vergessen oder nie außer Betrieb genommen werden.
Manchmal sind auch Benutzer schuld, die die Erlaubnis haben, neue Dienste außerhalb des normalen Prozesses zu erstellen. Zum Beispiel könnte eine Marketinggruppe einen Service zur Unterstützung einer bevorstehenden Veranstaltung wie einer Produkteinführung erstellen und ihn dann nach Abschluss der Veranstaltung nie wieder abschalten. Jemand, der sich diesen Service und die zugehörigen APIs später ansieht, hat möglicherweise keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich möglicherweise nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie wichtig sie sind oder was sie tun.
Die Sicherheitsanfälligkeit wird gefährlich, da sich die Sicherheit von APIs in Frameworks im Laufe der Zeit verbessert. Ein Forscher könnte eine Sicherheitslücke entdecken, oder es könnten zusätzliche Sicherheitsmaßnahmen hinzugefügt werden, um eine immer beliebter werdende Art von Angriff abzuwehren. Ältere APIs können für diese Angriffe anfällig bleiben, sofern sie nicht aktualisiert werden. Daher suchen Hacker häufig nach ihnen oder verwenden automatisierte Tools, um sie ausfindig zu machen.
In einem realen Beispiel von OWASP hat ein Unternehmen seine APIs aktualisiert, mit denen Benutzerdatenbanken durchsucht werden, um einen kritischen Fehler zu beheben. Aber sie haben versehentlich die alten APIs an Ort und Stelle belassen.
Ein Angreifer bemerkte, dass der Speicherort der neuen API etwa so lautete (api.criticalservice.com/v2). Indem sie die URL durch (api.criticalservice.com/v1) ersetzten, konnten sie stattdessen die alte API mit der bekannten Sicherheitslücke verwenden. Dadurch wurden letztendlich die persönlichen Daten von über 100 Millionen Benutzern preisgegeben.
Beseitigung unsachgemäßer Mängel in der Vermögensverwaltung
Die einzige Möglichkeit, den Fehler in der Verwaltung unsachgemäßer Ressourcen in Ihrer Umgebung zu beseitigen, besteht darin, ein enges Inventar aller APIs, ihrer Verwendungen und Versionen zu führen. Dies sollte mit einer Bestandsaufnahme der vorhandenen APIs beginnen und sich auf Faktoren wie die Umgebung konzentrieren, in der sie bereitgestellt werden sollten, z. B. in der Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben sollte und natürlich auf ihre Version.
Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem 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 Art und Weise, wie Anfragen und Antworten verarbeitet werden, der gemeinsamen Nutzung von Ressourcen, den Endpunkten, zu denen sie eine Verbindung herstellen kann, aller relevanten Richtlinien, die gelten, sowie alles andere, was für eine spätere Überprüfung erforderlich ist. Sie sollten auch vermeiden, jemals APIs außerhalb der Produktionsumgebung oder APIs aus der Entwicklungsumgebung in der Produktion zu verwenden. Erwägen Sie auch, APIs zeitlich zu begrenzen, wenn ihre fortgesetzte Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.
Wenn neue Versionen aktiver APIs verfügbar werden, führen Sie eine Risikobewertung 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 zu den neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.
Wenn Sie all dies tun, können Sie verhindern, dass die Sicherheitslücke bei der unsachgemäßen Vermögensverwaltung Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk schadet. Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.


Bei dieser Sicherheitslücke handelt es sich eher um ein menschliches Problem oder ein Managementproblem, das es älteren APIs ermöglicht, lange nachdem sie durch neuere, sicherere Versionen ersetzt werden sollten, bestehen zu bleiben.
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.


Im Gegensatz zu den meisten Sicherheitslücken in den Top Ten der OWASP-API geht es bei unsachgemäßem Asset-Management nicht speziell um Codierungsfehler. Stattdessen handelt es sich bei dieser Sicherheitslücke eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange bestehen bleiben, nachdem sie durch neuere, sicherere Versionen hätten ersetzt werden sollen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt sind, bevor sie vollständig gegen Bedrohungen geschützt sind.
Diese Sicherheitsanfälligkeit ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell bereitgestellt werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und niemals außer Betrieb genommen werden. Wenn die älteren APIs weiterhin mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.
Willst du eine spielerische Herausforderung zu diesem Sicherheitsproblem ausprobieren? Treten Sie ein in unsere Arena: [Fangen Sie hier an]
Wie wirken sich unsachgemäße Fehler in der Vermögensverwaltung auf APIs aus?
Der Fehler in der unsachgemäßen Vermögensverwaltung ist ein Produkt der Neuzeit. Unternehmen, die mit der Geschwindigkeit ihrer Geschäftstätigkeit Schritt halten, können manchmal täglich Hunderte oder Tausende von Diensten und Microservices anbieten. Dies geschieht häufig schnell und ohne die Erstellung einer Begleitdokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie wichtig sie sind. Dies kann schnell zu einer Vielzahl von APIs führen, die im Laufe der Zeit unzähmbar werden könnten, insbesondere wenn es keine pauschalen Richtlinien gibt, die definieren, wie lange APIs existieren können.
In dieser Umgebung ist es sehr wahrscheinlich, dass einige APIs verloren gehen, vergessen oder nie außer Betrieb genommen werden.
Manchmal sind auch Benutzer schuld, die die Erlaubnis haben, neue Dienste außerhalb des normalen Prozesses zu erstellen. Zum Beispiel könnte eine Marketinggruppe einen Service zur Unterstützung einer bevorstehenden Veranstaltung wie einer Produkteinführung erstellen und ihn dann nach Abschluss der Veranstaltung nie wieder abschalten. Jemand, der sich diesen Service und die zugehörigen APIs später ansieht, hat möglicherweise keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich möglicherweise nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie wichtig sie sind oder was sie tun.
Die Sicherheitsanfälligkeit wird gefährlich, da sich die Sicherheit von APIs in Frameworks im Laufe der Zeit verbessert. Ein Forscher könnte eine Sicherheitslücke entdecken, oder es könnten zusätzliche Sicherheitsmaßnahmen hinzugefügt werden, um eine immer beliebter werdende Art von Angriff abzuwehren. Ältere APIs können für diese Angriffe anfällig bleiben, sofern sie nicht aktualisiert werden. Daher suchen Hacker häufig nach ihnen oder verwenden automatisierte Tools, um sie ausfindig zu machen.
In einem realen Beispiel von OWASP hat ein Unternehmen seine APIs aktualisiert, mit denen Benutzerdatenbanken durchsucht werden, um einen kritischen Fehler zu beheben. Aber sie haben versehentlich die alten APIs an Ort und Stelle belassen.
Ein Angreifer bemerkte, dass der Speicherort der neuen API etwa so lautete (api.criticalservice.com/v2). Indem sie die URL durch (api.criticalservice.com/v1) ersetzten, konnten sie stattdessen die alte API mit der bekannten Sicherheitslücke verwenden. Dadurch wurden letztendlich die persönlichen Daten von über 100 Millionen Benutzern preisgegeben.
Beseitigung unsachgemäßer Mängel in der Vermögensverwaltung
Die einzige Möglichkeit, den Fehler in der Verwaltung unsachgemäßer Ressourcen in Ihrer Umgebung zu beseitigen, besteht darin, ein enges Inventar aller APIs, ihrer Verwendungen und Versionen zu führen. Dies sollte mit einer Bestandsaufnahme der vorhandenen APIs beginnen und sich auf Faktoren wie die Umgebung konzentrieren, in der sie bereitgestellt werden sollten, z. B. in der Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben sollte und natürlich auf ihre Version.
Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem 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 Art und Weise, wie Anfragen und Antworten verarbeitet werden, der gemeinsamen Nutzung von Ressourcen, den Endpunkten, zu denen sie eine Verbindung herstellen kann, aller relevanten Richtlinien, die gelten, sowie alles andere, was für eine spätere Überprüfung erforderlich ist. Sie sollten auch vermeiden, jemals APIs außerhalb der Produktionsumgebung oder APIs aus der Entwicklungsumgebung in der Produktion zu verwenden. Erwägen Sie auch, APIs zeitlich zu begrenzen, wenn ihre fortgesetzte Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.
Wenn neue Versionen aktiver APIs verfügbar werden, führen Sie eine Risikobewertung 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 zu den neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.
Wenn Sie all dies tun, können Sie verhindern, dass die Sicherheitslücke bei der unsachgemäßen Vermögensverwaltung Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk schadet. Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Im Gegensatz zu den meisten Sicherheitslücken in den Top Ten der OWASP-API geht es bei unsachgemäßem Asset-Management nicht speziell um Codierungsfehler. Stattdessen handelt es sich bei dieser Sicherheitslücke eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange bestehen bleiben, nachdem sie durch neuere, sicherere Versionen hätten ersetzt werden sollen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt sind, bevor sie vollständig gegen Bedrohungen geschützt sind.
Diese Sicherheitsanfälligkeit ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell bereitgestellt werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und niemals außer Betrieb genommen werden. Wenn die älteren APIs weiterhin mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.
Willst du eine spielerische Herausforderung zu diesem Sicherheitsproblem ausprobieren? Treten Sie ein in unsere Arena: [Fangen Sie hier an]
Wie wirken sich unsachgemäße Fehler in der Vermögensverwaltung auf APIs aus?
Der Fehler in der unsachgemäßen Vermögensverwaltung ist ein Produkt der Neuzeit. Unternehmen, die mit der Geschwindigkeit ihrer Geschäftstätigkeit Schritt halten, können manchmal täglich Hunderte oder Tausende von Diensten und Microservices anbieten. Dies geschieht häufig schnell und ohne die Erstellung einer Begleitdokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie wichtig sie sind. Dies kann schnell zu einer Vielzahl von APIs führen, die im Laufe der Zeit unzähmbar werden könnten, insbesondere wenn es keine pauschalen Richtlinien gibt, die definieren, wie lange APIs existieren können.
In dieser Umgebung ist es sehr wahrscheinlich, dass einige APIs verloren gehen, vergessen oder nie außer Betrieb genommen werden.
Manchmal sind auch Benutzer schuld, die die Erlaubnis haben, neue Dienste außerhalb des normalen Prozesses zu erstellen. Zum Beispiel könnte eine Marketinggruppe einen Service zur Unterstützung einer bevorstehenden Veranstaltung wie einer Produkteinführung erstellen und ihn dann nach Abschluss der Veranstaltung nie wieder abschalten. Jemand, der sich diesen Service und die zugehörigen APIs später ansieht, hat möglicherweise keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich möglicherweise nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie wichtig sie sind oder was sie tun.
Die Sicherheitsanfälligkeit wird gefährlich, da sich die Sicherheit von APIs in Frameworks im Laufe der Zeit verbessert. Ein Forscher könnte eine Sicherheitslücke entdecken, oder es könnten zusätzliche Sicherheitsmaßnahmen hinzugefügt werden, um eine immer beliebter werdende Art von Angriff abzuwehren. Ältere APIs können für diese Angriffe anfällig bleiben, sofern sie nicht aktualisiert werden. Daher suchen Hacker häufig nach ihnen oder verwenden automatisierte Tools, um sie ausfindig zu machen.
In einem realen Beispiel von OWASP hat ein Unternehmen seine APIs aktualisiert, mit denen Benutzerdatenbanken durchsucht werden, um einen kritischen Fehler zu beheben. Aber sie haben versehentlich die alten APIs an Ort und Stelle belassen.
Ein Angreifer bemerkte, dass der Speicherort der neuen API etwa so lautete (api.criticalservice.com/v2). Indem sie die URL durch (api.criticalservice.com/v1) ersetzten, konnten sie stattdessen die alte API mit der bekannten Sicherheitslücke verwenden. Dadurch wurden letztendlich die persönlichen Daten von über 100 Millionen Benutzern preisgegeben.
Beseitigung unsachgemäßer Mängel in der Vermögensverwaltung
Die einzige Möglichkeit, den Fehler in der Verwaltung unsachgemäßer Ressourcen in Ihrer Umgebung zu beseitigen, besteht darin, ein enges Inventar aller APIs, ihrer Verwendungen und Versionen zu führen. Dies sollte mit einer Bestandsaufnahme der vorhandenen APIs beginnen und sich auf Faktoren wie die Umgebung konzentrieren, in der sie bereitgestellt werden sollten, z. B. in der Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben sollte und natürlich auf ihre Version.
Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem 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 Art und Weise, wie Anfragen und Antworten verarbeitet werden, der gemeinsamen Nutzung von Ressourcen, den Endpunkten, zu denen sie eine Verbindung herstellen kann, aller relevanten Richtlinien, die gelten, sowie alles andere, was für eine spätere Überprüfung erforderlich ist. Sie sollten auch vermeiden, jemals APIs außerhalb der Produktionsumgebung oder APIs aus der Entwicklungsumgebung in der Produktion zu verwenden. Erwägen Sie auch, APIs zeitlich zu begrenzen, wenn ihre fortgesetzte Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.
Wenn neue Versionen aktiver APIs verfügbar werden, führen Sie eine Risikobewertung 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 zu den neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.
Wenn Sie all dies tun, können Sie verhindern, dass die Sicherheitslücke bei der unsachgemäßen Vermögensverwaltung Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk schadet. Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstrationMatias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.
Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.
Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.
Im Gegensatz zu den meisten Sicherheitslücken in den Top Ten der OWASP-API geht es bei unsachgemäßem Asset-Management nicht speziell um Codierungsfehler. Stattdessen handelt es sich bei dieser Sicherheitslücke eher um ein menschliches oder verwaltungstechnisches Problem, das dazu führt, dass ältere APIs noch lange bestehen bleiben, nachdem sie durch neuere, sicherere Versionen hätten ersetzt werden sollen. Sie kann auch auftreten, wenn APIs, die sich noch in der Entwicklung befinden, der Produktionsumgebung ausgesetzt sind, bevor sie vollständig gegen Bedrohungen geschützt sind.
Diese Sicherheitsanfälligkeit ist aufgrund des Aufkommens von Microservices und Cloud Computing besonders schwierig zu handhaben. In dieser Umgebung können neue Dienste schnell bereitgestellt werden, um einen vorübergehenden Bedarf zu decken, und dann vergessen und niemals außer Betrieb genommen werden. Wenn die älteren APIs weiterhin mit der Produktionsumgebung verbunden bleiben, kann dies das gesamte Netzwerk gefährden.
Willst du eine spielerische Herausforderung zu diesem Sicherheitsproblem ausprobieren? Treten Sie ein in unsere Arena: [Fangen Sie hier an]
Wie wirken sich unsachgemäße Fehler in der Vermögensverwaltung auf APIs aus?
Der Fehler in der unsachgemäßen Vermögensverwaltung ist ein Produkt der Neuzeit. Unternehmen, die mit der Geschwindigkeit ihrer Geschäftstätigkeit Schritt halten, können manchmal täglich Hunderte oder Tausende von Diensten und Microservices anbieten. Dies geschieht häufig schnell und ohne die Erstellung einer Begleitdokumentation oder einer Erklärung, wofür die zugehörigen APIs verwendet werden, wie lange sie benötigt werden oder wie wichtig sie sind. Dies kann schnell zu einer Vielzahl von APIs führen, die im Laufe der Zeit unzähmbar werden könnten, insbesondere wenn es keine pauschalen Richtlinien gibt, die definieren, wie lange APIs existieren können.
In dieser Umgebung ist es sehr wahrscheinlich, dass einige APIs verloren gehen, vergessen oder nie außer Betrieb genommen werden.
Manchmal sind auch Benutzer schuld, die die Erlaubnis haben, neue Dienste außerhalb des normalen Prozesses zu erstellen. Zum Beispiel könnte eine Marketinggruppe einen Service zur Unterstützung einer bevorstehenden Veranstaltung wie einer Produkteinführung erstellen und ihn dann nach Abschluss der Veranstaltung nie wieder abschalten. Jemand, der sich diesen Service und die zugehörigen APIs später ansieht, hat möglicherweise keine Ahnung, warum sie existieren, und wenn es keine Dokumentation gibt, könnte es ein Rätsel bleiben. Sie fühlen sich möglicherweise nicht wohl dabei, diese APIs aus der Produktionsumgebung zu entfernen oder sie sogar auf neuere Versionen zu aktualisieren, weil sie keine Ahnung haben, wie wichtig sie sind oder was sie tun.
Die Sicherheitsanfälligkeit wird gefährlich, da sich die Sicherheit von APIs in Frameworks im Laufe der Zeit verbessert. Ein Forscher könnte eine Sicherheitslücke entdecken, oder es könnten zusätzliche Sicherheitsmaßnahmen hinzugefügt werden, um eine immer beliebter werdende Art von Angriff abzuwehren. Ältere APIs können für diese Angriffe anfällig bleiben, sofern sie nicht aktualisiert werden. Daher suchen Hacker häufig nach ihnen oder verwenden automatisierte Tools, um sie ausfindig zu machen.
In einem realen Beispiel von OWASP hat ein Unternehmen seine APIs aktualisiert, mit denen Benutzerdatenbanken durchsucht werden, um einen kritischen Fehler zu beheben. Aber sie haben versehentlich die alten APIs an Ort und Stelle belassen.
Ein Angreifer bemerkte, dass der Speicherort der neuen API etwa so lautete (api.criticalservice.com/v2). Indem sie die URL durch (api.criticalservice.com/v1) ersetzten, konnten sie stattdessen die alte API mit der bekannten Sicherheitslücke verwenden. Dadurch wurden letztendlich die persönlichen Daten von über 100 Millionen Benutzern preisgegeben.
Beseitigung unsachgemäßer Mängel in der Vermögensverwaltung
Die einzige Möglichkeit, den Fehler in der Verwaltung unsachgemäßer Ressourcen in Ihrer Umgebung zu beseitigen, besteht darin, ein enges Inventar aller APIs, ihrer Verwendungen und Versionen zu führen. Dies sollte mit einer Bestandsaufnahme der vorhandenen APIs beginnen und sich auf Faktoren wie die Umgebung konzentrieren, in der sie bereitgestellt werden sollten, z. B. in der Produktion oder Entwicklung, wer Netzwerkzugriff auf sie haben sollte und natürlich auf ihre Version.
Sobald dies abgeschlossen ist, müssen Sie einen Prozess implementieren, bei dem 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 Art und Weise, wie Anfragen und Antworten verarbeitet werden, der gemeinsamen Nutzung von Ressourcen, den Endpunkten, zu denen sie eine Verbindung herstellen kann, aller relevanten Richtlinien, die gelten, sowie alles andere, was für eine spätere Überprüfung erforderlich ist. Sie sollten auch vermeiden, jemals APIs außerhalb der Produktionsumgebung oder APIs aus der Entwicklungsumgebung in der Produktion zu verwenden. Erwägen Sie auch, APIs zeitlich zu begrenzen, wenn ihre fortgesetzte Verwendung von ihren Eigentümern begründet werden muss, um eine automatische Außerbetriebnahme zu verhindern.
Wenn neue Versionen aktiver APIs verfügbar werden, führen Sie eine Risikobewertung 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 zu den neuen APIs migriert haben, entfernen Sie die alten vollständig aus der Umgebung.
Wenn Sie all dies tun, können Sie verhindern, dass die Sicherheitslücke bei der unsachgemäßen Vermögensverwaltung Ihrem Unternehmen, Ihren Benutzern oder Ihrem Netzwerk schadet. Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.
Table des matières
Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.




%20(1).avif)
.avif)
