Serializer deutsch erklärt: Serialisierung in Legacy-Software

Wer nach "Serializer deutsch" sucht, will meist nur eines wissen. Was macht dieses Ding eigentlich? Die kurze Antwort: Ein Serializer verpackt Daten so, dass ein anderes System sie lesen kann.

Auf Deutsch heißt er Serialisierer. Der Vorgang heißt Serialisierung. Beide Begriffe tauchen auf, wenn Entwickler über Schnittstellen, Speicherformate oder Caches sprechen.

Das klingt nach einem Detail für Techniker. In alter Software ist es aber häufig ein wunder Punkt. Selbstgebaute Serialisierer aus den 2000er Jahren verursachen bis heute Sicherheitslücken, Datenfehler und teure Migrationen.

Dieser Artikel erklärt das Konzept verständlich. Und er zeigt, woran Sie erkennen, ob Ihr System davon betroffen ist.

Was ist ein Serializer? Einfach erklärt

Stellen Sie sich einen Umzug vor. Ihr Schrank passt nicht durch die Tür. Also zerlegen Sie ihn, packen die Teile in Kisten und beschriften sie. Am neuen Ort bauen Sie ihn wieder zusammen.

Genau das macht ein Serializer mit Daten.

Innerhalb eines Programms liegen Daten als sogenannte Objekte vor. Ein Objekt ist ein Bündel zusammengehöriger Informationen, etwa ein Kunde mit Name, Adresse und Bestellungen. Dieses Bündel existiert nur im Arbeitsspeicher. Es lässt sich nicht direkt verschicken oder speichern.

Der Serializer wandelt das Objekt in eine Zeichenkette um. Diese Zeichenkette kann in eine Datei geschrieben, über das Netz verschickt oder in einer Datenbank abgelegt werden.

Der umgekehrte Weg heißt Deserialisierung. Aus der Zeichenkette wird wieder ein Objekt. Der Schrank steht wieder.

Die gängigen Formate

JSON ist heute der Standard. Es ist gut lesbar, sparsam und wird von praktisch jeder Programmiersprache verstanden. Wenn Sie eine moderne API anbinden, sprechen Sie meist JSON.

XML war der Standard davor. Es ist ausführlicher und erlaubt strenge Regeln für den Aufbau. In Java-Umgebungen und im Behördenumfeld ist es weiterhin verbreitet.

Binärformate speichern Daten nicht als Text, sondern als kompakte Bytefolge. Sie sind schnell und klein. Dafür kann kein Mensch sie ohne Werkzeug lesen.

Sprachspezifische Formate sind der problematische Fall. PHP hat serialize(), Java hat die Java-Serialisierung, Python hat Pickle. Diese Formate versteht nur die jeweilige Sprache. Genau hier beginnen die Schwierigkeiten.

Warum Serialisierung in Legacy-Software zum Problem wird

In Software, die seit zehn oder fünfzehn Jahren läuft, hat sich beim Thema Serialisierung einiges angesammelt. Vier Muster sehen wir immer wieder.

Selbstgeschriebene Serialisierer

Vor 2010 gab es für viele Sprachen noch keine guten Standardbibliotheken. Also haben Entwickler eigene Lösungen gebaut. Oft funktionierten sie jahrelang problemlos.

Das Problem zeigt sich erst später. Diese Eigenbauten sind nicht dokumentiert. Sie behandeln Sonderfälle unvollständig. Umlaute, Zeilenumbrüche oder leere Werte führen zu stillen Fehlern.

Still bedeutet: Niemand merkt es. Die Daten sind falsch, aber das System läuft weiter.

Unsichere Deserialisierung

Das ist die ernsteste Baustelle. Sprachspezifische Formate speichern nicht nur Daten. Sie speichern auch Anweisungen darüber, welche Objekte gebaut werden sollen.

Wenn ein Angreifer beeinflussen kann, was deserialisiert wird, kann er dem System eigene Anweisungen unterschieben. Im schlimmsten Fall führt der Server fremden Code aus.

Diese Angriffsart hat einen festen Platz in den offiziellen Sicherheitslisten. Für PHP-unserialize() und die Java-Serialisierung gibt es zahlreiche dokumentierte CVE-Einträge. CVE steht für "Common Vulnerabilities and Exposures", eine öffentliche Datenbank bekannter Sicherheitslücken.

Der Klassiker in freier Wildbahn: Ein Session-Cookie enthält serialisierte Daten. Der Browser des Nutzers kann diesen Cookie verändern. Der Server vertraut ihm trotzdem. Mehr dazu lesen Sie in unserem Beitrag über alte Software als Sicherheitsrisiko.

Format-Abhängigkeit bei Upgrades

Serialisierte Daten liegen oft dauerhaft in der Datenbank. Sessions, Warenkörbe, Konfigurationen, Protokolle.

Wenn Sie nun die PHP- oder Java-Version aktualisieren, ändert sich manchmal das Verhalten des Serialisierers. Alte Datensätze lassen sich dann nicht mehr korrekt einlesen. Das Upgrade läuft technisch durch, aber Daten aus der Vergangenheit sind unlesbar.

Solche Effekte tauchen selten im Test auf. Sie tauchen drei Wochen später beim Kunden auf.

Fehlende Versionierung

Datenstrukturen ändern sich. Ein Kunde bekommt ein neues Feld, ein altes fällt weg.

Gut gebaute Systeme merken sich, nach welcher Version ein Datensatz gespeichert wurde. Legacy-Systeme tun das meist nicht. Das Ergebnis sind Datenbestände, in denen drei verschiedene Strukturen nebeneinander liegen. Welcher Datensatz zu welcher Struktur gehört, weiß niemand mehr.

Woran Sie erkennen, ob Ihr System betroffen ist

Sie müssen kein Entwickler sein, um die richtigen Fragen zu stellen. Diese fünf reichen für ein erstes Bild.

1. Nutzt die Anwendung serialize() oder Java-Serialisierung für Daten, die von außen kommen? Wenn ja, ist eine Prüfung dringend.
2. Liegen serialisierte Daten dauerhaft in der Datenbank? Dann wird jedes Versions-Upgrade zum Risiko.
3. Gibt es einen eigenen Serialisierer im Code? Und weiß noch jemand, wie er funktioniert?
4. Werden Datenformate versioniert? Steht in den Datensätzen, nach welcher Struktur sie gespeichert wurden?
5. Wann wurden die beteiligten Bibliotheken zuletzt aktualisiert? Veraltete Abhängigkeiten sind hier besonders heikel.

Wer diese Fragen dem eigenen Team oder dem Dienstleister stellt, bekommt schnell ein Gefühl für die Lage.

Was Sie konkret tun können

Die gute Nachricht: Serialisierungsprobleme lassen sich schrittweise beheben. Sie brauchen keinen Neubau.

Schritt 1: Bestandsaufnahme

Zuerst wird gesucht, wo im Code serialisiert und deserialisiert wird. Das geht weitgehend automatisiert. Am Ende steht eine Liste aller Stellen mit einer Bewertung des Risikos.

Besonders wichtig ist die Frage: Welche dieser Stellen verarbeiten Daten, die von außen kommen? Cookies, Formulare, Schnittstellen, hochgeladene Dateien.

Schritt 2: Riskante Stellen zuerst absichern

Deserialisierung von Daten aus unsicherer Quelle sollte ersetzt werden. Der übliche Weg führt zu JSON. JSON transportiert nur Daten, keine Anweisungen. Damit entfällt die gefährlichste Angriffsart.

Wo ein Ersatz zu aufwendig ist, hilft eine Signatur. Das System prüft dann, ob die Daten unterwegs verändert wurden.

Schritt 3: Formate vereinheitlichen und versionieren

Danach folgt die Aufräumarbeit. Ein einheitliches Format, klare Regeln, eine Versionsnummer in jedem Datensatz.

Das ist keine spannende Arbeit. Sie zahlt sich aber bei jeder späteren Änderung aus.

Schritt 4: Abhängigkeiten in Ordnung bringen

In modernen PHP-Projekten verwaltet Composer die Bibliotheken. Viele Altprojekte haben das nie eingeführt. Wie Sie Composer nachträglich in ein Legacy-Projekt bringen, haben wir separat beschrieben.

Erst wenn die Abhängigkeiten sauber verwaltet sind, lassen sich Sicherheits-Updates zuverlässig einspielen.

Fazit: Ein kleines Bauteil mit großer Wirkung

Ein Serializer ist unscheinbar. In alter Software ist er trotzdem oft eine der Stellen, an denen sich über Jahre am meisten angesammelt hat.

Die Risiken sind real. Unsichere Deserialisierung gehört zu den wirksamsten Angriffsarten auf Webanwendungen. Und beim nächsten Versions-Upgrade entscheidet oft genau dieses Thema, ob alles glatt läuft.

Der Aufwand für eine Sanierung ist überschaubar, wenn man sie planvoll angeht. Deutlich kleiner jedenfalls als der Aufwand nach einem Vorfall.

Sie wissen nicht, wie Ihre Anwendung mit Serialisierung umgeht? Wir schauen uns das an. Im Rahmen eines Sicherheits-Audits prüfen wir genau solche Stellen. Danach wissen Sie, wo Sie stehen.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos und Sie bekommen eine ehrliche Einschätzung, keine Präsentation.