Les codeurs conquièrent la sécurité : série Share & Learn - Désérialisation non sécurisée

Je nach Anwendung kann der Prozess der Serialisierung ständig stattfinden. Der Begriff wird immer dann verwendet, wenn Datenstrukturen oder Objektzustände in ein Format übersetzt werden, das gespeichert oder eventuell als Kommunikation versendet werden kann. Die Deserialisierung ist das Gegenteil dieses Prozesses, wobei die nun strukturierten Daten wieder in das Objekt oder den Datenstring zurückverwandelt werden, der sie vor der Speicherung waren.

Eine unsichere Deserialisierung kann immer dann auftreten, wenn eine Anwendung die zu deserialisierenden Daten als vertrauenswürdig behandelt. Wenn ein Benutzer in der Lage ist, die neu rekonstruierten Daten zu ändern, kann er alle Arten von böswilligen Aktivitäten durchführen, z. B. Code-Injektionen, Denial-of-Service-Angriffe oder einfach die Daten ändern, um sich selbst einen Vorteil innerhalb der Anwendung zu verschaffen, z. B. den Preis eines Objekts zu senken oder seine Privilegien zu erhöhen.

In dieser Folge lernen wir:

• Wie Angreifer eine unsichere Deserialisierung ausnutzen können
• Warum unsichere Deserialisierung gefährlich ist
• Techniken, die diese Sicherheitslücke beheben können.

Wie nutzen Angreifer eine unsichere Deserialisierung aus?

Heutzutage ist das beliebteste Datenformat für die Serialisierung von Daten JSON, obwohl XML an zweiter Stelle steht. Etliche Programmiersprachen bieten auch ihre eigenen Methoden zur Serialisierung von Daten an, die oft mehr Funktionen als JSON oder XML enthalten. In jedem Fall kann es zu Problemen kommen, wenn Entwickler Anwendungen so programmieren, dass sie deserialisierte Daten als vertrauenswürdige Eingaben behandeln, anstatt dem alten Mantra aus anderen Blogs in dieser Reihe zu folgen, nämlich: "Traue 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 auch auf deserialisierte Rohdaten manchmal zugegriffen werden kann und diese ausgenutzt werden können, müssen sie in die gleiche nicht vertrauenswürdige Kategorie fallen.

Wenn z. B. eine Forenanwendung die PHP-Objektserialisierung verwendet, um ein Cookie zu speichern, das die Identifikation und die Rolle eines Benutzers enthält, dann kann dieses manipuliert werden. Ein böswilliger Benutzer könnte stattdessen seine "Benutzer"-Rolle in "Admin" ändern. Oder er kann die vom Datenstring bereitgestellte Öffnung nutzen, um Code einzuschleusen, der vom Server bei der Verarbeitung der "vertrauenswürdigen" Daten fehlinterpretiert und ausgeführt werden könnte.

Warum ist unsichere Deserialisierung gefährlich?

Es stimmt, dass diese Art des Angriffs ein gewisses Maß an Geschicklichkeit seitens des Hackers erfordert, und manchmal auch Versuch und Irrtum, während der Angreifer lernt, welche Arten von Code oder Exploits der Server aus seinen manipulierten, deserialisierten Daten akzeptiert. Nichtsdestotrotz ist dies eine häufig ausgenutzte Schwachstelle, weil sie Hackern, die geschickt genug sind, sie zu nutzen, potenzielle Macht verleiht.

Je nachdem, wie die deserialisierten Daten verwendet werden sollen, kann eine beliebige Anzahl von Angriffen, darunter viele, die wir in früheren Blogs behandelt haben, eingesetzt werden. Eine unsichere Deserialisierung kann ein Einfallstor für entfernte Cross-Code-Injection, Cross-Site-Scripting, Denial-of-Service, Hijacking der Zugriffssteuerung und natürlich SQL- und XML-Injection-Angriffe sein. Im Grunde genommen wird ein Startpunkt eröffnet, alle zu deserialisierenden Daten werden als vertrauenswürdig deklariert und die Angreifer können versuchen, sie auszunutzen.

Beseitigung der unsicheren Deserialisierung

Das Sicherste, was Unternehmen tun können, um unsichere Deserialisierung zu verhindern, ist, Anwendungen davon abzuhalten, deserialisierte Daten zu akzeptieren. Das mag jedoch nicht möglich oder realistisch sein, aber keine Sorge, denn es gibt andere Techniken, die zur Verteidigung gegen diese Art von Angriff eingesetzt werden können.

Wenn möglich, können die Daten z. B. auf numerische Werte bereinigt werden. Dies könnte einen Exploit zwar nicht vollständig verhindern, würde aber das Auftreten von Code-Injektionen verhindern. Noch besser wäre es, einfach eine Form der Integritätsprüfung für deserialisierte Daten zu verlangen, z. B. eine digitale Signatur, die sicherstellen könnte, dass die Datenstrings nicht manipuliert wurden. Und alle Deserialisierungsprozesse sollten isoliert und in einer Umgebung mit niedrigen Privilegien ausgeführt werden.

Sobald Sie diese Schutzvorkehrungen getroffen haben, sollten Sie alle fehlgeschlagenen Deserialisierungsversuche sowie die Netzwerkaktivitäten von Containern oder Servern, die Daten deserialisieren, protokollieren. Wenn ein Benutzer mehr als ein paar Deserialisierungsfehler in den Protokollen auslöst, ist das ein guter Hinweis darauf, dass es sich entweder um einen böswilligen Insider handelt oder dass seine Anmeldedaten gehackt oder gestohlen wurden. Sie könnten sogar Dinge wie automatische Sperrungen für Benutzer in Betracht ziehen, die ständig Deserialisierungsfehler auslösen.

Welches dieser Tools Sie auch immer zur Bekämpfung unsicherer Deserialisierung einsetzen, denken Sie daran, dass es sich im Kern um Daten handelt, die von einem Benutzer berührt oder manipuliert worden sein könnten. Vertrauen Sie niemals darauf.

Weitere Informationen zur Verwendung von Komponenten mit bekannten Sicherheitslücken

Als weitere Lektüre können Sie einen Blick darauf werfen, was OWASP über unsichere Deserialisierung sagt. Sie können Ihr neu erworbenes Verteidigungswissen auch mit dem kostenlosen Showcase der Plattform Secure Code Warrior testen, die Cybersecurity-Teams zu den ultimativen Cyber-Kriegern ausbildet. Um mehr über die Beseitigung dieser Schwachstelle und eine Schurkengalerie anderer Bedrohungen zu erfahren, besuchen Sie den BlogSecure Code Warrior .