Les codeurs conquièrent la série des 10 meilleures API de l'OWASP en matière de sécurité : exposition excessive des données

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.