
A08:2021 - Software- und Datenintegritätsfehler
Celia CatalánAktie
Beschreibung der Schwachstelle
Diese Art von Verwundbarkeit zeigt sich, wenn die Anwendung nicht angemessen gegen die Manipulation von kritischen Daten oder Softwarekomponenten geschützt ist, was zu Datenveränderungen, Phishing-Angriffen oder der Einspeisung von nicht autorisiertem Code führen kann. Diese Kategorie umfasst speziell Risiken wie das Fehlen von Integrität bei Software-Updates, externen Bibliotheken oder kritischen Datenkonfigurationen.
Auswirkungen
Die Auswirkungen dieser Schwachstelle auf die Systeme und Anwendungen, in denen sie vorhanden ist, umfassen Folgendes:
- Code-Injektionen: Angreifer können Software und Anwendungen kompromittieren, indem sie Code injizieren, der im System ausgeführt wird. Dies könnte zu unbefugtem Zugriff, Datenlecks oder einer Veränderung der Funktionalität des Systems führen.
- Engagement der Software-Lieferkette: Wenn ein Angreifer es schafft, eine Abhängigkeit oder Bibliothek zu kompromittieren, die von mehreren Organisationen verwendet wird, kann die Auswirkung weitreichend sein und zahlreiche Anwendungen betreffen, die von diesem Bestandteil abhängen.
- Privilegieneskalations- oder Denial-of-Service-Angriffe: Es ist möglich, kritische Systemeinstellungen zu ändern oder Schwachstellen einzuführen, die eine Erhöhung der Privilegien ermöglichen, wodurch die Infrastruktur gefährdet oder deren ordnungsgemäße Funktion beeinträchtigt wird.
Beziehung zu anderen Schwachstellen der OWASP Top Ten
- A06:2021 - Verwundbare und veraltete Komponenten: Diese Schwachstelle steht in engem Zusammenhang mit der Verwendung von unsicheren oder veralteten Komponenten, da der Mangel an Softwareintegrität häufig verwundbare Abhängigkeiten umfasst.
- A07:2021 - Identifizierungs- und Authentifizierungsfehler: Wenn die Authentifizierungseinstellungen nicht angemessen geschützt sind, können Angreifer Schwächen in der Datenintegrität ausnutzen, um diese Mechanismen zu manipulieren.
- A09:2021 - Sicherheitsprotokollierung und Überwachungsfehler: Das Fehlen einer angemessenen Überwachung kann dazu führen, dass Fehler in der Integrität von Software oder Daten unbemerkt bleiben, was das Risiko einer Ausnutzung erhöht.
Praxisbeispiel
Unsichere Deserialisierung
Die unsichere Deserialisierung tritt auf, wenn eine Website von Benutzern kontrollierte Daten deserialisiert. Dies kann es einem Angreifer ermöglichen, serialisierte Objekte zu manipulieren, um schädliche Daten in den Code der Anwendung einzufügen.
In einigen Fällen kann der Angreifer ein serialisiertes Objekt durch eines einer völlig anderen Klasse ersetzen. Besorgniserregend ist, dass jedes Objekt einer auf der Website verfügbaren Klasse deserialisiert und instanziiert wird, unabhängig von der Klasse, die ursprünglich erwartet wurde. Aus diesem Grund wird unsichere Deserialisierung auch als "Objektinjektionsanfälligkeit" bezeichnet.
Ein Objekt einer unerwarteten Klasse könnte eine Ausnahme auslösen, aber in vielen Fällen ist der Schaden bereits entstanden. Tatsächlich werden viele Angriffe, die auf Deserialisierung basieren, abgeschlossen, bevor der Prozess endet. Das bedeutet, dass der Deserialisierungsprozess selbst den Angriff auslösen kann, selbst wenn die Funktionalität der Website nicht direkt mit dem bösartigen Objekt interagiert. Daher können auch Websites, die Sprachen mit strenger Typisierung verwenden, anfällig für diese Techniken sein.
Manipulation von serialisierten Objekten
Das Ausnutzen einiger Deserialisierungsanfälligkeiten kann so einfach sein wie das Ändern eines Attributs in einem serialisierten Objekt. Da der Zustand des Objekts erhalten bleibt, ist es möglich, die serialisierten Daten zu analysieren, um relevante Attributwerte zu identifizieren und zu ändern. Anschließend kann das bösartige Objekt über den Deserialisierungsprozess an die Website gesendet werden. Dies ist der erste Schritt in einem grundlegenden Deserialisierungsangriff.
Im Allgemeinen gibt es zwei Ansätze zur Manipulation von serialisierten Objekten. Man kann das Objekt direkt in seiner Byte-Stream-Form bearbeiten oder ein kleines Skript in der entsprechenden Sprache schreiben, um das neue Objekt selbst zu erstellen und zu serialisieren. Letzterer Ansatz ist oft einfacher, wenn man mit binären Serialisierungsformaten arbeitet.
Änderung der Attribute der serialisierten Objekte
Beim Manipulieren der Daten, solange der Angreifer ein gültiges serialisiertes Objekt beibehält, wird der Deserialisierungsprozess ein Objekt auf dem Server mit den modifizierten Attributwerten erstellen.
Als Beispiel: Man greift mit gültigen Benutzeranmeldeinformationen ohne Berechtigungen auf eine Website zu, und die Website generiert ein Sitzungscookie, wie im folgenden Bild zu sehen ist:
Gegenmaßnahmen
- Digitale Signaturen oder ähnliche Mechanismen verwenden, um zu überprüfen, dass die Software oder die Daten aus der ursprünglichen Quelle stammen und nicht verändert wurden.
- "Es muss sichergestellt werden, dass Bibliotheken und Abhängigkeiten, wie npm oder Maven, aus vertrauenswürdigen Repositories bezogen werden. Wenn die Anwendung ein hohes Risikoprofil hat, kann in Betracht gezogen werden, ein internes vertrauenswürdiges Repository zu hosten."
- Sicherheitswerkzeuge für die Software-Lieferkette verwenden, wie OWASP Dependency Check oder OWASP CycloneDX, um zu überprüfen, dass die Komponenten keine bekannten Schwachstellen enthalten.
- Einen Überprüfungsprozess für Änderungen am Code und an der Konfiguration einrichten, um die Möglichkeit zu minimieren, schädlichen Code oder Konfigurationen in die Pipeline einzuführen.
- Sicherstellen, dass die CI/CD-Pipeline über die angemessene Trennung, Konfiguration und Zugriffskontrolle verfügt, um die Integrität des Codes zu gewährleisten, der durch die Build- und Bereitstellungsprozesse fließt.
- Sicherstellen, dass nicht signierte oder unverschlüsselte serialisierte Daten nicht an unzuverlässige Clients gesendet werden, ohne dass eine Art von Integritätsprüfung oder digitaler Signatur vorhanden ist, um Manipulation oder Reproduktion der serialisierten Daten zu erkennen.