Was ist Insecure Deserialization?

Serialisierung wandelt Daten oder ein Objekt in eine übertrag- und speicherbare Darstellung um. Deserialisierung rekonstruiert daraus später Werte oder Objekte. Unsichere Deserialisierung liegt vor, wenn eine Anwendung nicht vertrauenswürdige serialisierte Daten verarbeitet und dabei Typen, Eigenschaften oder Nebenwirkungen akzeptiert, die ein Angreifer steuern kann.

Was passiert beim Serialisieren?

Anwendungen serialisieren Sitzungen, Cache-Einträge, Queue-Nachrichten, Cookies, API-Payloads oder gespeicherte Objekte. Ein einfaches Format enthält primitive Werte wie Text und Zahlen. Native Objektformate können zusätzlich Klassennamen, Typinformationen, Referenzen und Objektzustand transportieren. Beim Wiederherstellen erzeugt die Laufzeit Klassen und ruft je nach Plattform Konstruktoren, Setter, Destruktoren oder besondere „magische“ Methoden auf.

Warum ist Deserialisierung gefährlich?

Der Datenstrom sieht passiv aus, kann aber bestimmen, welche Objekte entstehen und welche Methoden indirekt ablaufen. Gefährlich sind öffentliche Cookies oder versteckte Formularfelder, Nachrichten aus weniger vertrauenswürdigen Queues, manipulierte Cache-Einträge und importierte Dateien. Base64 oder Verschlüsselung ohne verifizierte Integrität macht die Daten nicht vertrauenswürdig. Eine Signatur hilft nur, wenn sie vor der Deserialisierung geprüft wird, Schlüssel geschützt sind und kein anderer Weg unsignierte Objekte einschleust.

Was sind Gadget- und POP-Chains?

Ein Gadget ist bereits vorhandener Code in der Anwendung oder einer Bibliothek, der während der Objektverarbeitung eine nützliche Nebenwirkung besitzt – etwa Dateioperation, Prozessstart oder dynamischen Aufruf. Angreifer verketten mehrere Gadgets, indem sie passende Objekte und Eigenschaften serialisieren. In PHP wird dies oft POP-Chain genannt, in Java und .NET meist Gadget Chain. Der Angreifer muss keinen neuen Code hochladen: Er missbraucht vorhandene Klassen. Deshalb kann schon eine neue Bibliothek eine zuvor nicht ausnutzbare Deserialisierung verschärfen.

Welche Auswirkungen gibt es außer Codeausführung?

Ist JSON automatisch sicher?

Reines JSON beschreibt nur Werte und besitzt keine ausführbaren Klassen. Das verhindert viele klassische native Gadget Chains. Unsichere polymorphe Typbindung kann jedoch ein Typfeld aus JSON verwenden, um beliebige Klassen zu erzeugen. Auch Mass Assignment, unerwartete Felder, Prototypmanipulation, fehlende Schema- und Berechtigungsprüfung bleiben möglich. Entscheidend ist nicht die Dateiendung, sondern wie Parser und nachgelagerter Code die Daten interpretieren.

Wie wird das Risiko verhindert?

1. Native Objekte vermeiden: An Vertrauensgrenzen einfache Datenübertragungsobjekte mit explizitem Schema verwenden.
2. Typen begrenzen: Polymorphe oder dynamische Typauflösung deaktivieren; erforderliche Typen eng positiv auflisten.
3. Felder validieren: Datentyp, Wertebereich, Größe, Tiefe und unbekannte Eigenschaften vor Geschäftslogik prüfen.
4. Integrität schützen: Serverseitigen Zustand bevorzugen oder Daten authentisiert signieren; Prüfung vor jedem Parsing mit Nebenwirkungen.
5. Abhängigkeiten reduzieren: Bibliotheken aktuell halten und unnötige Klassen beziehungsweise gefährliche Gadgets entfernen.
6. Isolieren: Unvermeidbare Verarbeitung in einem Prozess mit geringen Rechten, Limits und ohne unnötigen Netzwerkzugriff ausführen.

Codebeispiel: native Objekte durch ein geprüftes Datenschema ersetzen

Verwundbar: Ein Cookie bestimmt, welche PHP-Objekte erzeugt werden.

$state = unserialize(
    base64_decode($_COOKIE['checkout_state'])
);
processCheckout($state);

Sicherer Ansatz: Nur erwartete primitive Werte werden übernommen.

$data = json_decode(
    base64_decode($_COOKIE['checkout_state']),
    true,
    16,
    JSON_THROW_ON_ERROR
);

$validated = validator($data, [
    'cart_id' => ['required', 'uuid'],
    'currency' => ['required', Rule::in(['EUR', 'USD'])],
])->validate();

// Preis, Eigentümer und Berechtigungen serverseitig neu laden
$cart = $request->user()->carts()->findOrFail($validated['cart_id']);

allowed_classes => false kann alten PHP-Code zusätzlich begrenzen, ersetzt aber nicht den Wechsel zu einem expliziten Datenschema. Sicherheitsrelevanter Zustand sollte möglichst gar nicht vom Client stammen.

Wie wird die Schwachstelle getestet?

Tester erkennen Formate an Cookies, Binärdaten, Base64, Typfeldern, Fehlermeldungen und bekannten Framework-Markern. Zunächst werden harmlose Eigenschaften oder Typfehler verändert, um serverseitige Deserialisierung nachzuweisen. Gadget-Suche und Codeausführung erfolgen nur kontrolliert und mit Freigabe, weil schon das Parsen Nebenwirkungen haben kann. Zusätzlich gehören Größenlimits, Signaturprüfung, alternative Eingabekanäle und Abhängigkeitsversionen in die Bewertung.