SCW 아이콘
영웅 배경, 구분선 없음
블로그

Coder Conquer Security OWASP Top 10 API-Serie — Unsachgemäße Vermögensverwaltung

마티아스 마두, Ph.
게시일 : 2020년 12월 22일
마지막 업데이트: 2026년 3월 9일

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.

더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 소프트웨어 개발 주기 전반에 걸쳐 코드를 보호하고 사이버 보안을 최우선으로 하는 문화를 조성하도록 귀사를 Secure Code Warrior . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.

데모 예약하기
공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 12월 22일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

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.

리소스 보기
리소스 보기

아래 양식을 작성하여 보고서를 다운로드하십시오.

귀하의 허락을 받아 당사 제품 및 안전한 코딩과 관련된 주제에 대한 정보를 보내드리고자 합니다. 당사는 귀하의 개인정보를 항상 세심하게 처리하며, 마케팅 목적으로 타사에 판매하지 않습니다.

제출
scw 성공 아이콘
scw 오류 아이콘
양식을 제출하려면 '분석' 쿠키를 활성화해 주십시오. 완료 후에는 언제든지 다시 비활성화할 수 있습니다.

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.

웨비나 시청하기
시작하세요
더 알아보세요

아래 링크를 클릭하여 이 자료의 PDF를 다운로드하십시오.

Secure Code Warrior 소프트웨어 개발 주기 전반에 걸쳐 코드를 보호하고 사이버 보안을 최우선으로 하는 문화를 조성하도록 귀사를 Secure Code Warrior . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.

보고서 보기데모 예약하기
리소스 보기
공유하기:
링크드인 브랜드사회적x 로고
더 알고 싶으신가요?

공유하기:
링크드인 브랜드사회적x 로고
저자
마티아스 마두, Ph.
게시일: 2020년 12월 22일

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.

마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.

공유하기:
링크드인 브랜드사회적x 로고

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.

목차

PDF 다운로드
리소스 보기
더 알고 싶으신가요?

마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.

더 알아보세요

Secure Code Warrior 소프트웨어 개발 주기 전반에 걸쳐 코드를 보호하고 사이버 보안을 최우선으로 하는 문화를 조성하도록 귀사를 Secure Code Warrior . 앱 보안 관리자, 개발자, 최고정보보안책임자(CISO) 또는 보안 관련 업무를 담당하는 분이라면 누구든, 저희는 귀사가 안전하지 않은 코드로 인한 위험을 줄일 수 있도록 돕습니다.

데모 예약하기다운로드
공유하기:
링크드인 브랜드사회적x 로고
자원 허브

시작을 위한 자료

더 많은 글
자원 허브

시작을 위한 자료

더 많은 글