Coders Conquer Security OWASP Top 10 API Series - Exzessive Datenexposition

Veröffentlicht am 23. September 2020
von Matias Madou, Ph.D.
FALLSTUDIE

Coders Conquer Security OWASP Top 10 API Series - Exzessive Datenexposition

Veröffentlicht am 23. September 2020
von Matias Madou, Ph.D.
Ressource anzeigen
Ressource anzeigen

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.

Ressource anzeigen
Ressource anzeigen

Autor

Matias Madou, Ph.D.

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.

Sie wollen mehr?

Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.

Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.

Blog ansehen
Sie wollen mehr?

Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit

Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.

Ressourcendrehscheibe

Coders Conquer Security OWASP Top 10 API Series - Exzessive Datenexposition

Veröffentlicht am 23. September 2020
Von Matias Madou, Ph.D.

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.

Wir bitten Sie um Ihre Erlaubnis, Ihnen Informationen über unsere Produkte und/oder verwandte Themen der sicheren Codierung zuzusenden. Wir werden Ihre persönlichen Daten immer mit äußerster Sorgfalt behandeln und sie niemals zu Marketingzwecken an andere Unternehmen verkaufen.

Um das Formular abzuschicken, aktivieren Sie bitte "Analytics"-Cookies. Sie können die Cookies wieder deaktivieren, sobald Sie fertig sind.