Entwickler meistern Sicherheit: Share & Learn-Reihe – Unsichere Deserialisierung

Je nach Anwendung kann der Prozess der Serialisierung ständig stattfinden. Er beschreibt den Vorgang, bei dem Datenstrukturen oder Objektzustände in ein Format übersetzt werden, das gespeichert oder als Kommunikation übertragen werden kann. Deserialisierung ist das Gegenstück dazu: Die strukturierten Daten werden wieder in das ursprüngliche Objekt oder die ursprüngliche Datenzeichenfolge zurückverwandelt.

Unsichere Deserialisierung kann immer dann auftreten, wenn eine Anwendung deserialisierte Daten als vertrauenswürdig einstuft. Wenn ein Benutzer die neu rekonstruierten Daten manipulieren kann, sind verschiedenste schädliche Aktivitäten möglich – von Code-Injektionen und Denial-of-Service-Angriffen bis hin zur einfachen Änderung von Daten, um sich innerhalb der Anwendung Vorteile zu verschaffen, wie etwa die Senkung eines Preises oder die Erhöhung der eigenen Zugriffsrechte.

In dieser Folge erfahren Sie:

• Wie Angreifer unsichere Deserialisierung ausnutzen
• Warum unsichere Deserialisierung gefährlich ist
• Techniken zur Behebung dieser Schwachstelle.

Wie nutzen Angreifer unsichere Deserialisierung aus?

Heutzutage ist JSON das gängigste Datenformat für die Serialisierung, dicht gefolgt von XML. Viele Programmiersprachen bieten zudem eigene Methoden zur Serialisierung an, die oft mehr Funktionen als JSON oder XML enthalten. In jedem Fall können Probleme auftreten, wenn Entwickler Anwendungen so programmieren, dass sie deserialisierte Daten als vertrauenswürdige Eingabe behandeln, anstatt das bewährte Mantra aus anderen Beiträgen dieser Reihe zu befolgen: „Vertraue niemals Benutzereingaben!“

Benutzereingaben dürfen niemals als vertrauenswürdig gelten, da Benutzer Code in diese Zeichenfolgen einfügen können, der vom empfangenden Server versehentlich ausgeführt werden könnte. Da auch auf rohe deserialisierte Daten manchmal zugegriffen und diese ausgenutzt werden können, müssen sie in dieselbe Kategorie der nicht vertrauenswürdigen Daten fallen.

Wenn beispielsweise eine Foren-Anwendung die PHP-Objektserialisierung verwendet, um ein Cookie mit der Identität und Rolle eines Benutzers zu speichern, kann dieses manipuliert werden. Ein böswilliger Benutzer könnte seine Rolle von „Benutzer“ in „Administrator“ ändern. Alternativ kann er die durch die Datenzeichenfolge gebotene Lücke nutzen, um Code einzuschleusen, der vom Server bei der Verarbeitung der „vertrauenswürdigen“ Daten falsch interpretiert und ausgeführt werden könnte.

Warum ist unsichere Deserialisierung gefährlich?

Zwar erfordert diese Art von Angriff ein gewisses Maß an Geschick seitens des Hackers und manchmal auch „Trial and Error“, während der Angreifer lernt, welche Arten von Code oder Exploits der Server aus seinen manipulierten, deserialisierten Daten akzeptiert. Dennoch ist dies eine häufig ausgenutzte Schwachstelle, da sie Hackern, die sie beherrschen, ein erhebliches Potenzial bietet.

Je nachdem, wie die deserialisierten Daten verwendet werden sollen, können zahlreiche Angriffe eingesetzt werden, von denen viele bereits in früheren Beiträgen behandelt wurden. Unsichere Deserialisierung kann als Einfallstor für Remote-Code-Injektion, Cross-Site Scripting, Denial-of-Service, Hijacking der Zugriffskontrolle sowie natürlich SQL- und XML-Injektionsangriffe dienen. Im Grunde schafft sie einen Ausgangspunkt, erklärt alle deserialisierten Daten für vertrauenswürdig und ermöglicht es Angreifern, diese auszunutzen.

Beseitigung unsicherer Deserialisierung

Die sicherste Maßnahme, die Unternehmen ergreifen können, um unsichere Deserialisierung zu verhindern, besteht darin, Anwendungen die Annahme deserialisierter Daten zu untersagen. Das ist jedoch möglicherweise nicht immer möglich oder realistisch. Keine Sorge: Es gibt weitere Techniken, um sich gegen diese Art von Angriff zu verteidigen.

Falls möglich, können Daten bereinigt werden, etwa durch Beschränkung auf numerische Werte. Dies verhindert zwar nicht zwingend jeden Exploit, unterbindet aber Code-Injektionen. Noch besser ist es, eine Form der Integritätsprüfung für deserialisierte Daten zu verlangen, wie etwa eine digitale Signatur, um sicherzustellen, dass Datenzeichenfolgen nicht manipuliert wurden. Zudem sollten alle Deserialisierungsprozesse isoliert und in einer Umgebung mit eingeschränkten Rechten ausgeführt werden.

Sobald diese Schutzmaßnahmen implementiert sind, sollten Sie alle fehlgeschlagenen Deserialisierungsversuche sowie die Netzwerkaktivitäten von Containern oder Servern, die Daten deserialisieren, protokollieren. Wenn ein Benutzer mehrfach Deserialisierungsfehler in den Protokollen auslöst, ist dies ein starkes Indiz dafür, dass es sich entweder um einen böswilligen Insider handelt oder dessen Zugangsdaten gehackt oder gestohlen wurden. Sie könnten sogar automatische Sperren für Benutzer in Betracht ziehen, die wiederholt Deserialisierungsfehler verursachen.

Welche dieser Werkzeuge Sie auch zur Bekämpfung unsicherer Deserialisierung einsetzen, denken Sie immer daran: Im Kern handelt es sich um Daten, die von einem Benutzer berührt oder manipuliert worden sein könnten. Vertrauen Sie ihnen niemals.

Weitere Informationen zur Verwendung von Komponenten mit bekannten Schwachstellen

Weitere Informationen finden Sie in den Ausführungen von OWASP zur unsicheren Deserialisierung. Sie können Ihr neu erworbenes Wissen zur Verteidigung auch mit dem kostenlosen Showcase der Secure Code Warrior-Plattform auf die Probe stellen, die Cybersicherheitsteams zu erstklassigen Cyber-Experten ausbildet. Um mehr über die Abwehr dieser Schwachstelle und einer Vielzahl weiterer Bedrohungen zu erfahren, besuchen Sie den Secure Code Warrior-Blog.