Coders erobern Sicherheit: OWASP Top 10 API-Serie – Übermäßige Datenfreigabe

Die Schwachstelle der übermäßigen Datenpreisgabe unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass sie eine ganz bestimmte Art von Daten betrifft. Die eigentlichen Mechanismen hinter der Schwachstelle ähneln anderen, aber übermäßige Datenpreisgabe ist in diesem Fall dadurch definiert, dass sie gesetzlich geschützte oder hochsensible Daten betrifft. Dies kann jegliche personenbezogene Daten umfassen, die oft als PII bezeichnet werden. Oder es könnte sich um Informationen aus der Zahlungskartenindustrie (PCI) handeln. Schließlich kann übermäßige Datenpreisgabe alle Informationen beinhalten, die Datenschutzgesetzen unterliegen, wie etwa der Datenschutz-Grundverordnung (DSGVO) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den Vereinigten Staaten.

Wie Sie sich vorstellen können, ist dies ein Grund zur großen Sorge, und es ist unerlässlich, dass versierte Entwickler lernen, wie sie diese Fehler wo immer möglich beseitigen können. Wenn Sie bereit sind, es mit einem Datenpreisgabe-Drachen aufzunehmen, besuchen Sie unsere spielerische Challenge:

Wie hoch war Ihre Punktzahl? Lesen Sie weiter und erfahren Sie mehr:

Was sind einige Beispiele für übermäßige Datenpreisgabe?

Einer der Hauptgründe für übermäßige Datenpreisgabe 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 Endbenutzer offengelegt werden.

Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor Informationen für Benutzer angezeigt werden. Bei den meisten generischen Daten ist dies selten ein Problem. Aber die Offenlegung von gesetzlich geschützten oder sensiblen Daten gegenüber Benutzern, beispielsweise als Teil einer Sitzungs-ID, kann sowohl aus Sicherheits- als auch aus rechtlicher Sicht zu großen Problemen führen.

Als Beispiel dafür, wie leicht sensible Daten versehentlich geteilt werden können, beschreibt der OWASP-Bericht ein Szenario, in dem ein Sicherheitsmitarbeiter 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 erfassen, auf Sicherheitskräfte oder Vorgesetzte mit höheren Berechtigungen beschränkt sein sollten.

Um dem Sicherheitsmitarbeiter Zugriff auf autorisierte Kameras zu gewähren, können Entwickler einen API-Aufruf wie den folgenden verwenden.

/api/sites/111/cameras

Als Antwort würde die App Details zu den Kameras, die der Sicherheitsmitarbeiter sehen darf, im folgenden Format senden:

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

Oberflächlich betrachtet scheint dies einwandfrei zu funktionieren. Der Sicherheitsmitarbeiter, der die grafische Benutzeroberfläche der App nutzt, würde nur die Kamera-Feeds sehen, für die er eine Zugriffsberechtigung hat. Das Problem ist, dass aufgrund des verwendeten generischen Codes die tatsächliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Einrichtung enthalten würde. Jeder, der das Netzwerk überwacht und diese Daten abfängt oder das Konto des Sicherheitsmitarbeiters kompromittiert, könnte die Standorte und Bezeichnungen jeder Kamera im Netzwerk herausfinden. Sie könnten dann uneingeschränkt auf diese Daten zugreifen.

Übermäßige Datenpreisgabe eliminieren

Der wichtigste Schlüssel zur Vermeidung von übermäßiger Datenpreisgabe ist das Verständnis der Daten und der sie umgebenden Schutzmaßnahmen. Das Erstellen generischer APIs und das Überlassen der Datensortierung an den Client vor der Anzeige für Benutzer ist eine gefährliche Entscheidung, die zu vielen vermeidbaren Sicherheitsverletzungen führt.

Neben dem Verständnis der relevanten Datenschutzmaßnahmen ist es auch wichtig, den Prozess des Sendens aller Daten an einen Benutzer mit generischen APIs zu stoppen. Beispielsweise sollten Codes wie to_json() und to_string() vermieden werden. Stattdessen sollte der Code gezielt 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 übermäßig geteilt werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Dieser sollte die von allen API-Methoden zurückgegebenen Daten definieren und durchsetzen, einschließlich Regeln für die Fehlerberichterstattung.

Schließlich sollten alle Daten, die als PII oder PCI klassifiziert sind oder durch Vorschriften wie DSGVO oder HIPAA geschützt sind, durch eine starke Verschlüsselung gesichert werden. Selbst wenn der Speicherort dieser Daten im Rahmen einer Schwachstelle durch übermäßige Datenpreisgabe preisgegeben wird, gibt es auf diese Weise eine gute sekundäre Verteidigungslinie, die die Daten schützen sollte, selbst wenn sie in die Hände eines böswilligen Benutzers oder Angreifers gelangen.

Besuchen Sie die Secure Code Warrior-Blogseiten für weitere Einblicke in diese Schwachstelle und wie Sie Ihr Unternehmen und Ihre Kunden vor den verheerenden Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Secure Code Warrior-Schulungsplattform ausprobieren, um all Ihre Cybersicherheitsfähigkeiten geschärft und auf dem neuesten Stand zu halten.