Programmierer erobern Sicherheit: Share & Learn-Reihe — Unsichere Deserialisierung

Je nach Anwendung kann der Serialisierungsprozess ständig stattfinden. Mit diesem Begriff wird beschrieben, wann immer Datenstrukturen oder Objektzustände in ein Format übersetzt werden, das gespeichert oder möglicherweise als Kommunikation gesendet werden kann. Deserialisierung ist das Gegenteil von diesem Prozess, bei dem die jetzt strukturierten Daten wieder in das Objekt oder die Datenfolge umgewandelt werden, die sie vor der Speicherung waren.

Eine unsichere Deserialisierung kann immer dann auftreten, wenn eine Anwendung Daten, die deserialisiert werden, als vertrauenswürdig behandelt. Wenn ein Benutzer in der Lage ist, die neu rekonstruierten Daten zu ändern, kann er alle Arten von bösartigen Aktivitäten ausführen, z. B. Codeinjektionen, Denial-of-Service-Angriffe oder einfach das Ändern der Daten, um sich innerhalb der Anwendung einen Vorteil zu verschaffen, z. B. den Preis eines Objekts zu senken oder seine Rechte zu erweitern.

In dieser Folge werden wir lernen:

• Wie Angreifer die unsichere Deserialisierung ausnutzen können
• Warum unsichere Deserialisierung gefährlich ist
• Techniken, mit denen diese Sicherheitsanfälligkeit behoben werden kann.

Wie nutzen Angreifer die unsichere Deserialisierung aus?

Heutzutage ist JSON das beliebteste Datenformat für die Serialisierung von Daten, obwohl XML knapp an zweiter Stelle steht. Nicht wenige Programmiersprachen bieten auch ihre eigenen Methoden zur Serialisierung von Daten an, die oft mehr Funktionen als JSON oder XML enthalten. In jedem Fall können Probleme auftreten, wenn Entwickler Apps so programmieren, dass sie deserialisierte Daten als vertrauenswürdige Eingabe behandeln, anstatt dem alten Mantra aus anderen Blogs dieser Reihe zu folgen, nämlich: „Vertraue niemals Benutzereingaben!“

Benutzereingaben sind niemals vertrauenswürdig, da der Benutzer Code in diese Zeichenfolgen einfügen kann, der versehentlich vom empfangenden Server ausgeführt werden könnte. Und da manchmal auch auf deserialisierte Rohdaten zugegriffen und diese ausgenutzt werden können, müssen sie in dieselbe Kategorie fallen, die nicht vertrauenswürdig ist.

Wenn beispielsweise eine Forenanwendung die PHP-Objektserialisierung verwendet, um ein Cookie zu speichern, das die Identifizierung und Rolle eines Benutzers enthält, kann dies manipuliert werden. Ein böswilliger Benutzer könnte stattdessen seine „Benutzer“ -Rolle in „Admin“ ändern. Oder sie können die durch die Datenzeichenfolge bereitgestellte Öffnung verwenden, um Code einzufügen, der möglicherweise falsch interpretiert und vom Server bei der Verarbeitung der „vertrauenswürdigen“ Daten ausgeführt wird.

Warum ist unsichere Deserialisierung gefährlich?

Es stimmt, dass diese Art von Angriff von einem Hacker ein gewisses Maß an Geschick erfordert und manchmal auch Versuch und Irrtum, während der Angreifer anhand seiner manipulierten, deserialisierten Daten lernt, welche Arten von Code oder Exploits der Server akzeptiert. Allerdings handelt es sich um eine häufig ausgenutzte Sicherheitslücke, da sie Hackern, die geschult genug sind, sie auszunutzen, potenzielle Möglichkeiten bietet.

Je nachdem, wie die deserialisierten Daten verwendet werden sollen, können beliebig viele Angriffe eingesetzt werden, darunter viele, die wir in früheren Blogs behandelt haben. Unsichere Deserialisierung kann ein Einfallstor für Cross-Code-Injection, Cross-Site-Scripting, Denial-of-Service, Zugriffskontroll-Hijacking und natürlich SQL- und XML-Injection-Angriffe sein. Es eröffnet quasi einen Startpunkt, erklärt alle Daten, die deserialisiert werden, als vertrauenswürdig und ermöglicht es den Angreifern, sie auszunutzen.

Beseitigung unsicherer Deserialisierung

Das sicherste Mittel, das Unternehmen tun können, um eine unsichere Deserialisierung zu verhindern, besteht darin, Anwendungen daran zu hindern, deserialisierte Daten zu akzeptieren. Das ist vielleicht nicht möglich oder realistisch, aber keine Sorge, denn es gibt andere Techniken, die zur Abwehr dieser Art von Angriffen eingesetzt werden können.

Wenn möglich, können Daten in so etwas wie numerische Werte bereinigt werden. Dies könnte einen Exploit nicht vollständig verhindern, würde aber das Auftreten von Codeinjektionen verhindern. Noch besser ist es, einfach irgendeine Form der Integritätsprüfung anhand deserialisierter Daten wie einer digitalen Signatur vorzuschreiben, wodurch sichergestellt werden könnte, dass Datenstrings nicht manipuliert wurden. Und alle Deserialisierungsprozesse sollten isoliert sein und in einer Umgebung mit niedrigen Rechten ausgeführt werden.

Sobald Sie diese Schutzmaßnahmen eingerichtet haben, sollten Sie alle fehlgeschlagenen Deserialisierungsversuche sowie Netzwerkaktivitäten protokollieren, die von Containern oder Servern ausgehen, die Daten deserialisieren. Wenn ein Benutzer mehr als ein paar Deserialisierungsfehler in den Protokollen auslöst, ist das ein gutes Zeichen dafür, dass es sich entweder um einen böswilligen Insider handelt oder dass seine Anmeldeinformationen gehackt oder gestohlen wurden. Sie könnten sogar Dinge wie automatische Sperren für Benutzer in Betracht ziehen, die ständig Deserialisierungsfehler auslösen.

Unabhängig davon, welche dieser Tools Sie zur Bekämpfung der unsicheren Deserialisierung einsetzen, denken Sie daran, dass es sich im Kern um Daten handelt, die möglicherweise von einem Benutzer bearbeitet oder manipuliert wurden. Vertraue ihm niemals.

Weitere Informationen zur Verwendung von Komponenten mit bekannten Sicherheitslücken

Zur weiteren Lektüre können Sie sich ansehen, was OWASP sagt über unsichere Deserialisierung. Sie können Ihr neu gewonnenes Defensivwissen auch auf die Probe stellen mit dem kostenlose Vitrine der Secure Code Warrior-Plattform, die Cybersicherheitsteams zu ultimativen Cyberkriegern ausbildet. Um mehr über die Beseitigung dieser Sicherheitslücke und eine Galerie mit anderen Bedrohungen zu erfahren, besuchen Sie die Blog von Secure Code Warrior.