Coders Conquer Security OWASP Top 10 API-Serie — Übermäßiges Datenrisiko

Die Sicherheitslücke wegen übermäßiger Datenexposition unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass es sich um eine ganz bestimmte Art von Daten handelt. Die eigentliche Mechanik hinter der Sicherheitslücke ist ähnlich wie bei anderen, aber eine übermäßige Datenexposition wird in diesem Fall so definiert, dass rechtlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen beinhalten, die oft als PII bezeichnet werden. Oder es könnte Informationen aus der Zahlungskartenbranche oder PCI beinhalten. Schließlich kann ein übermäßiger Datenverlust alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der Allgemeinen Datenschutzverordnung (DSGVO) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den Vereinigten Staaten.

Wie Sie sich vorstellen können, gibt dies Anlass zu großer Besorgnis, und es ist unerlässlich, dass versierte Entwickler lernen, diese Fehler zu beheben, wo immer dies möglich ist. Wenn du bereits bereit bist, es mit einem Drachen aufzunehmen, der das Risiko von Daten gefährdet, dann nimm an unserer spielerischen Herausforderung teil:

Was war dein Ergebnis? Lesen Sie weiter und erfahren Sie mehr:

Was sind einige Beispiele für übermäßiges Datenrisiko?

Einer der Hauptgründe für ein übermäßiges Datenrisiko 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 den Endbenutzern zugänglich gemacht werden.

Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie Benutzern Informationen anzeigen. Bei den meisten generischen Daten ist dies selten ein Problem. Die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer beispielsweise als Teil einer Sitzungs-ID kann jedoch sowohl aus sicherheitstechnischer als auch aus rechtlicher Sicht zu großen Problemen führen.

Als Beispiel dafür, wie leicht vertrauliche 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 sichere Bereiche, während andere Kameras, die Personen beobachten, angeblich nur Wachpersonal oder Aufsichtspersonen mit höheren Berechtigungen zur Verfügung stehen sollen.

Um dem Wachmann Zugriff auf autorisierte Kameras zu gewähren, 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 das gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, zu deren Anzeige er berechtigt ist. Das Problem ist, dass aufgrund des verwendeten generischen Codes die eigentliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Einrichtung enthalten würde. Jeder, der das Netzwerk ausspioniert und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, könnte die Standorte und die Nomenklatur für jede Kamera im Netzwerk herausfinden. Sie könnten dann uneingeschränkt auf diese Daten zugreifen.

Beseitigung übermäßiger Datenrisiken

Der wichtigste Schlüssel zur Vermeidung übermäßiger Datenexposition ist ein Verständnis der Daten und der Schutzmaßnahmen, die sie umgeben. Generische APIs zu erstellen und es dem Kunden zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Wahl, die zu vielen vermeidbaren Sicherheitsverletzungen führt.

Neben dem Verständnis der relevanten Datenschutzmaßnahmen ist es auch wichtig, den Prozess zu beenden, bei dem alles mit generischen APIs an einen Benutzer gesendet wird. Beispielsweise 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 diese Informationen ausschließlich senden.

Um sicherzustellen, dass keine geschützten Daten versehentlich zu oft geteilt werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Er sollte definieren und durchsetzen, dass Daten über alle API-Methoden zurückgegeben werden, einschließlich Regeln für die Fehlerberichterstattung.

Schließlich sollten alle Daten, die als PII- oder PCI-Daten eingestuft werden, oder Informationen, die durch Vorschriften wie die DSGVO oder HIPAA geschützt sind, mit einer starken Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützen sollte, wenn der Speicherort dieser Daten als Teil einer Sicherheitslücke wegen übermäßiger Datensicherheit herauskommt, selbst wenn sie in die Hände eines böswilligen Benutzers oder Bedrohungsakteurs gelangen.

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.