Coders Conquer Security OWASP Top 10 API Series - Exzessive Datenexposition
Die Schwachstelle "Excessive Data Exposure" unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentliche Mechanik hinter der Schwachstelle ist ähnlich wie bei anderen Schwachstellen, aber exzessive Datenexposition ist in diesem Fall so definiert, dass gesetzlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen umfassen, die oft als PII bezeichnet werden. Oder es kann sich um Informationen der Kreditkartenindustrie (PCI) handeln. Schließlich kann eine übermäßige Datenexposition alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der General Data Protection Regulation (GDPR) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA.
Wie Sie sich vorstellen können, gibt dies Anlass zu großer Sorge, und es ist zwingend erforderlich, dass versierte Entwickler lernen, wie sie diese Fehler, wo immer möglich, ausmerzen können. Wenn Sie bereits bereit sind, es mit einem Datenexpositionsdrachen aufzunehmen, gehen Sie zu unserer gamifizierten Herausforderung:
Wie war Ihr Ergebnis? Lesen Sie weiter und erfahren Sie mehr:
Was sind einige Beispiele für übermäßige Datenbelastung?
Einer der Hauptgründe für die übermäßige Datenexposition ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften für den Endbenutzer offengelegt werden.
Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie dem Benutzer Informationen anzeigen. Für die meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer, z. B. als Teil einer Sitzungs-ID, kann zu großen Problemen führen, sowohl aus Sicherheits- als auch aus rechtlicher Sicht.
Als Beispiel dafür, wie leicht sensible Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IOT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und gesicherte Bereiche, während andere Kameras, die Menschen sehen, auf Wachpersonal oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollen.
Um dem Wächter Zugriff auf autorisierte Kameras zu geben, können Entwickler einen API-Aufruf wie den folgenden verwenden.
/api/sites/111/kameras
Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:
{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}
Oberflächlich betrachtet, scheint dies gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, für die er eine Berechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Anlage enthalten würde. Jeder, der das Netzwerk ausspäht und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, wäre in der Lage, die Standorte und die Nomenklatur jeder Kamera im Netzwerk zu ermitteln. Sie könnten dann ohne Einschränkung auf diese Daten zugreifen.
Eliminieren übermäßiger Datenbelastung
Der größte Schlüssel zur Vermeidung einer übermäßigen Datenexposition ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Generische APIs zu erstellen und es dem Client zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.
Neben dem Verständnis der relevanten Datenschutzbestimmungen ist es auch wichtig, den Prozess zu stoppen, alles mit generischen APIs an einen Benutzer zu senden. Zum Beispiel muss Code wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und ausschließlich diese Informationen senden.
Um sicherzustellen, dass keine geschützten Daten versehentlich weitergegeben werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die Daten, die von allen API-Methoden zurückgegeben werden, definieren und erzwingen, einschließlich Regeln für die Fehlerberichterstattung.
Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind, oder Informationen, die durch Vorschriften wie GDPR oder HIPAA geschützt sind, mit starker Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützt, wenn sie in die Hände eines böswilligen Anwenders oder Bedrohungsakteurs gelangen, selbst wenn der Speicherort dieser Daten als Teil einer Schwachstelle mit übermäßiger Datenexposition nach außen gelangt.
Lesen Sie auf den 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.


Die eigentliche Mechanik hinter dieser Schwachstelle ist ähnlich wie bei anderen, aber exzessive Datenexposition ist in diesem Fall definiert als der Umgang mit gesetzlich geschützten oder hochsensiblen Daten.
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.


Die Schwachstelle "Excessive Data Exposure" unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentliche Mechanik hinter der Schwachstelle ist ähnlich wie bei anderen Schwachstellen, aber exzessive Datenexposition ist in diesem Fall so definiert, dass gesetzlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen umfassen, die oft als PII bezeichnet werden. Oder es kann sich um Informationen der Kreditkartenindustrie (PCI) handeln. Schließlich kann eine übermäßige Datenexposition alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der General Data Protection Regulation (GDPR) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA.
Wie Sie sich vorstellen können, gibt dies Anlass zu großer Sorge, und es ist zwingend erforderlich, dass versierte Entwickler lernen, wie sie diese Fehler, wo immer möglich, ausmerzen können. Wenn Sie bereits bereit sind, es mit einem Datenexpositionsdrachen aufzunehmen, gehen Sie zu unserer gamifizierten Herausforderung:
Wie war Ihr Ergebnis? Lesen Sie weiter und erfahren Sie mehr:
Was sind einige Beispiele für übermäßige Datenbelastung?
Einer der Hauptgründe für die übermäßige Datenexposition ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften für den Endbenutzer offengelegt werden.
Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie dem Benutzer Informationen anzeigen. Für die meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer, z. B. als Teil einer Sitzungs-ID, kann zu großen Problemen führen, sowohl aus Sicherheits- als auch aus rechtlicher Sicht.
Als Beispiel dafür, wie leicht sensible Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IOT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und gesicherte Bereiche, während andere Kameras, die Menschen sehen, auf Wachpersonal oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollen.
Um dem Wächter Zugriff auf autorisierte Kameras zu geben, können Entwickler einen API-Aufruf wie den folgenden verwenden.
/api/sites/111/kameras
Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:
{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}
Oberflächlich betrachtet, scheint dies gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, für die er eine Berechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Anlage enthalten würde. Jeder, der das Netzwerk ausspäht und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, wäre in der Lage, die Standorte und die Nomenklatur jeder Kamera im Netzwerk zu ermitteln. Sie könnten dann ohne Einschränkung auf diese Daten zugreifen.
Eliminieren übermäßiger Datenbelastung
Der größte Schlüssel zur Vermeidung einer übermäßigen Datenexposition ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Generische APIs zu erstellen und es dem Client zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.
Neben dem Verständnis der relevanten Datenschutzbestimmungen ist es auch wichtig, den Prozess zu stoppen, alles mit generischen APIs an einen Benutzer zu senden. Zum Beispiel muss Code wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und ausschließlich diese Informationen senden.
Um sicherzustellen, dass keine geschützten Daten versehentlich weitergegeben werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die Daten, die von allen API-Methoden zurückgegeben werden, definieren und erzwingen, einschließlich Regeln für die Fehlerberichterstattung.
Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind, oder Informationen, die durch Vorschriften wie GDPR oder HIPAA geschützt sind, mit starker Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützt, wenn sie in die Hände eines böswilligen Anwenders oder Bedrohungsakteurs gelangen, selbst wenn der Speicherort dieser Daten als Teil einer Schwachstelle mit übermäßiger Datenexposition nach außen gelangt.
Lesen Sie auf den 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.

Die Schwachstelle "Excessive Data Exposure" unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentliche Mechanik hinter der Schwachstelle ist ähnlich wie bei anderen Schwachstellen, aber exzessive Datenexposition ist in diesem Fall so definiert, dass gesetzlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen umfassen, die oft als PII bezeichnet werden. Oder es kann sich um Informationen der Kreditkartenindustrie (PCI) handeln. Schließlich kann eine übermäßige Datenexposition alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der General Data Protection Regulation (GDPR) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA.
Wie Sie sich vorstellen können, gibt dies Anlass zu großer Sorge, und es ist zwingend erforderlich, dass versierte Entwickler lernen, wie sie diese Fehler, wo immer möglich, ausmerzen können. Wenn Sie bereits bereit sind, es mit einem Datenexpositionsdrachen aufzunehmen, gehen Sie zu unserer gamifizierten Herausforderung:
Wie war Ihr Ergebnis? Lesen Sie weiter und erfahren Sie mehr:
Was sind einige Beispiele für übermäßige Datenbelastung?
Einer der Hauptgründe für die übermäßige Datenexposition ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften für den Endbenutzer offengelegt werden.
Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie dem Benutzer Informationen anzeigen. Für die meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer, z. B. als Teil einer Sitzungs-ID, kann zu großen Problemen führen, sowohl aus Sicherheits- als auch aus rechtlicher Sicht.
Als Beispiel dafür, wie leicht sensible Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IOT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und gesicherte Bereiche, während andere Kameras, die Menschen sehen, auf Wachpersonal oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollen.
Um dem Wächter Zugriff auf autorisierte Kameras zu geben, können Entwickler einen API-Aufruf wie den folgenden verwenden.
/api/sites/111/kameras
Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:
{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}
Oberflächlich betrachtet, scheint dies gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, für die er eine Berechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Anlage enthalten würde. Jeder, der das Netzwerk ausspäht und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, wäre in der Lage, die Standorte und die Nomenklatur jeder Kamera im Netzwerk zu ermitteln. Sie könnten dann ohne Einschränkung auf diese Daten zugreifen.
Eliminieren übermäßiger Datenbelastung
Der größte Schlüssel zur Vermeidung einer übermäßigen Datenexposition ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Generische APIs zu erstellen und es dem Client zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.
Neben dem Verständnis der relevanten Datenschutzbestimmungen ist es auch wichtig, den Prozess zu stoppen, alles mit generischen APIs an einen Benutzer zu senden. Zum Beispiel muss Code wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und ausschließlich diese Informationen senden.
Um sicherzustellen, dass keine geschützten Daten versehentlich weitergegeben werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die Daten, die von allen API-Methoden zurückgegeben werden, definieren und erzwingen, einschließlich Regeln für die Fehlerberichterstattung.
Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind, oder Informationen, die durch Vorschriften wie GDPR oder HIPAA geschützt sind, mit starker Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützt, wenn sie in die Hände eines böswilligen Anwenders oder Bedrohungsakteurs gelangen, selbst wenn der Speicherort dieser Daten als Teil einer Schwachstelle mit übermäßiger Datenexposition nach außen gelangt.
Lesen Sie auf den 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.
Die Schwachstelle "Excessive Data Exposure" unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentliche Mechanik hinter der Schwachstelle ist ähnlich wie bei anderen Schwachstellen, aber exzessive Datenexposition ist in diesem Fall so definiert, dass gesetzlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen umfassen, die oft als PII bezeichnet werden. Oder es kann sich um Informationen der Kreditkartenindustrie (PCI) handeln. Schließlich kann eine übermäßige Datenexposition alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der General Data Protection Regulation (GDPR) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den USA.
Wie Sie sich vorstellen können, gibt dies Anlass zu großer Sorge, und es ist zwingend erforderlich, dass versierte Entwickler lernen, wie sie diese Fehler, wo immer möglich, ausmerzen können. Wenn Sie bereits bereit sind, es mit einem Datenexpositionsdrachen aufzunehmen, gehen Sie zu unserer gamifizierten Herausforderung:
Wie war Ihr Ergebnis? Lesen Sie weiter und erfahren Sie mehr:
Was sind einige Beispiele für übermäßige Datenbelastung?
Einer der Hauptgründe für die übermäßige Datenexposition ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften für den Endbenutzer offengelegt werden.
Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie dem Benutzer Informationen anzeigen. Für die meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer, z. B. als Teil einer Sitzungs-ID, kann zu großen Problemen führen, sowohl aus Sicherheits- als auch aus rechtlicher Sicht.
Als Beispiel dafür, wie leicht sensible Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IOT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und gesicherte Bereiche, während andere Kameras, die Menschen sehen, auf Wachpersonal oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollen.
Um dem Wächter Zugriff auf autorisierte Kameras zu geben, können Entwickler einen API-Aufruf wie den folgenden verwenden.
/api/sites/111/kameras
Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:
{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}
Oberflächlich betrachtet, scheint dies gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, für die er eine Berechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Anlage enthalten würde. Jeder, der das Netzwerk ausspäht und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, wäre in der Lage, die Standorte und die Nomenklatur jeder Kamera im Netzwerk zu ermitteln. Sie könnten dann ohne Einschränkung auf diese Daten zugreifen.
Eliminieren übermäßiger Datenbelastung
Der größte Schlüssel zur Vermeidung einer übermäßigen Datenexposition ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Generische APIs zu erstellen und es dem Client zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.
Neben dem Verständnis der relevanten Datenschutzbestimmungen ist es auch wichtig, den Prozess zu stoppen, alles mit generischen APIs an einen Benutzer zu senden. Zum Beispiel muss Code wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und ausschließlich diese Informationen senden.
Um sicherzustellen, dass keine geschützten Daten versehentlich weitergegeben werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die Daten, die von allen API-Methoden zurückgegeben werden, definieren und erzwingen, einschließlich Regeln für die Fehlerberichterstattung.
Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind, oder Informationen, die durch Vorschriften wie GDPR oder HIPAA geschützt sind, mit starker Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützt, wenn sie in die Hände eines böswilligen Anwenders oder Bedrohungsakteurs gelangen, selbst wenn der Speicherort dieser Daten als Teil einer Schwachstelle mit übermäßiger Datenexposition nach außen gelangt.
Lesen Sie auf den 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
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Quests: Branchenführendes Lernen, damit die Entwickler immer einen Schritt voraus sind und Risiken minimiert werden.
Quests ist eine learning platform , die Entwicklern hilft, Software-Sicherheitsrisiken zu verringern, indem sie ihre Fähigkeiten zur sicheren Programmierung verbessern. Mit kuratierten Lernpfaden, praktischen Herausforderungen und interaktiven Aktivitäten befähigt sie Entwickler, Schwachstellen zu erkennen und zu vermeiden.
Ressourcen für den Einstieg
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Das Jahrzehnt der Defenders: Secure Code Warrior Zehnte Runde
Secure Code WarriorDas Gründungsteam von SCW ist zusammengeblieben und hat das Schiff ein ganzes Jahrzehnt lang durch alle Lektionen, Triumphe und Rückschläge gesteuert. Wir vergrößern uns und sind bereit für unser nächstes Kapitel, SCW 2.0, als führendes Unternehmen im Risikomanagement für Entwickler.