flawopen.com/Java-Deserialisierung/ObjectInputStream-Sicherheit

Ist ObjectInputStream für nicht vertrauenswürdige Daten sicher?

Java-Sicherheitsreferenz

Einfach erklärt

Meistens nein: readObject() rekonstruiert Java-Objekte und kann dabei von Klassen definierte Deserialisierungsmethoden ausführen. Wie ein Formular, dessen Anhänge eigene Startanweisungen ausführen dürfen. Ein bösartiger Stream kann Klassenverhalten erreichen, das der Anwendung bereits zur Verfügung steht. Ob Code ausgeführt wird, hängt von Klassen, Bibliotheken, erreichbaren Pfaden und Eingabegrenzen ab.

RISKANT: native Objekt-Deserialisierung

// Keine vom Angreifer kontrollierten Bytes übergeben.
try (var in = new ObjectInputStream(untrustedStream)) {
    Object value = in.readObject();
    handle(value);
}

SICHERER: festen Datentyp einlesen

// Breites polymorphes Typing für nicht vertrauenswürdige Eingaben deaktivieren.
ObjectMapper mapper = new ObjectMapper();
OrderRequest value = mapper.readValue(
    untrustedBytes, OrderRequest.class
);
validate(value);

Wie die Schwachstelle erreichbar wird

Eine API, Warteschlange, ein Cache oder Dateiimport erhält nutzergesteuerte Bytes. Erreichen sie ObjectInputStream.readObject(), stellt die JVM Objekte aus serialisierbaren Klassen im Prozess wieder her. Eine Gadget-Kette ist ein möglicher Pfad durch deren Verhalten, kein Payload in jedem Stream. Oracle dokumentierte CVE-2015-4852 als konkreten Fall: nicht authentifizierte Angriffe über WebLogic T3 auf aufgeführte Versionen. Das bedeutet nicht, dass jede Verwendung von ObjectInputStream remote erreichbar ist.

Wenn native Serialisierung bleiben muss

✓JSON oder Protocol Buffers mit Schema bevorzugen, in ein festes DTO überführen und Felder sowie Berechtigungen prüfen.
✓Falls unvermeidbar: vor readObject() einen kontextspezifischen ObjectInputFilter setzen und nur exakt nötige Klassen erlauben.
✓Tiefe, Referenzen, Arrays und Stream-Bytes anhand gültiger Eingaben begrenzen. Eine Allowlist allein verhindert keine Ressourcenerschöpfung.
✓Kein breites polymorphes Typing für nicht vertrauenswürdiges JSON aktivieren; beliebige Subtyp-Metadaten können erneut Objekte erzeugen.
✓Java und Abhängigkeiten aktualisieren, unnötige Bibliotheken entfernen und Alt-Streams mit minimalen Rechten sowie Ressourcenlimits verarbeiten.

Häufige Frage

Macht ObjectInputFilter readObject() sicher?

Er senkt das Risiko mit enger Allowlist und Limits vor dem Lesen, ist aber kein universeller Bereiniger. Erlaubte Klassen, ihr Verhalten und die tatsächliche Aktivierung des Filters zählen; Validierung und Autorisierung bleiben nötig. Nutzergesteuerte Daten möglichst nicht nativ serialisieren.

Primärquellen

Siehe auch Unsichere Deserialisierung: Risiken und Schutz Newtonsoft.Json TypeNameHandling: sichere Konfiguration? PHP unserialize() und nicht vertrauenswürdige Daten Python pickle.load(): Risiken nicht vertrauenswürdiger Daten Ist Ruby YAML.load sicher? Psych-Versionen und safe_load .NET BinaryFormatter: Risiken und Migration