Désérialisation

hacking

Définition

La désérialisation non sécurisée est une classe de vulnérabilité survenant lorsqu'une application reconstruit un objet à partir d'un flux de données sérialisées provenant d'une source non fiable, sans validation suffisante, permettant à un attaquant de forger un objet malveillant capable de déclencher l'exécution de code arbitraire lors de sa reconstruction. Ce type de faille touche de nombreux langages, notamment Java avec les classes ObjectInputStream, PHP avec la fonction unserialize, Python avec le module pickle, et .NET avec BinaryFormatter, et figure dans le classement OWASP Top 10 sous la catégorie A08:2021 relative à l'intégrité des logiciels et des données. L'exploitation repose souvent sur des chaînes de gadgets, combinaisons de classes légitimes présentes dans les bibliothèques de l'application, détournées de leur usage prévu pour aboutir à une exécution de commande. En défense, la première mesure consiste à éviter la désérialisation de données non fiables lorsque cela est possible, en privilégiant des formats structurés sans exécution comme JSON avec schéma strict. Lorsque la désérialisation reste nécessaire, l'usage de listes blanches de classes autorisées, la signature cryptographique des données sérialisées, et la mise à jour des bibliothèques concernées limitent l'exposition. La surveillance des erreurs de désérialisation et l'analyse comportementale des processus applicatifs complètent la détection de tentatives d'exploitation.

Fonctionnement technique

Les vulnérabilités de désérialisation exploitent la reconversion d'objets sérialisés (format binaire ou texte) en objets exécutables dans la mémoire de l'application. Lorsqu'une application désérialise des données contrôlées par un attaquant sans validation, celui-ci peut manipuler les propriétés des objets reconstitués pour déclencher des actions non prévues, allant de la modification de données à l'exécution de code arbitraire (RCE).

L'exploitation repose sur les « gadget chains » : des séquences de méthodes existantes dans les bibliothèques du classpath qui, lorsqu'elles sont invoquées automatiquement pendant la désérialisation (constructeurs, destructeurs, méthodes magiques), exécutent du code arbitraire. En Java, les classes comme InvokerTransformer (Apache Commons Collections), TemplatesImpl (JDK) ou BeanFactory forment des chaînes d'exploitation connues.

En PHP, les méthodes magiques __wakeup(), __destruct() et __toString() sont invoquées automatiquement lors de la désérialisation via unserialize(). En Python, le module pickle exécute du code arbitraire via __reduce__(). En .NET, les BinaryFormatter et DataContractSerializer sont vulnérables avec les bonnes gadget chains (ysoserial.net).

Cas d'usage

La vulnérabilité Log4Shell (CVE-2021-44228) est l'exemple le plus impactant de désérialisation Java : Log4j interprétait les lookups JNDI dans les messages de log, permettant à un attaquant de charger et exécuter une classe Java arbitraire depuis un serveur LDAP distant. Des millions de serveurs Java étaient vulnérables.

Les applications web Java utilisant des ViewStates, des sessions sérialisées, des messages JMS ou des API acceptant des objets sérialisés sont des cibles fréquentes. En PHP, les CMS comme WordPress, Drupal et Magento ont connu des vulnérabilités de désérialisation critiques via les cookies de session ou les uploads de données sérialisées.

Outils et implémentation

ysoserial (Java) génère des payloads de désérialisation pour de nombreuses bibliothèques vulnérables. ysoserial.net est l'équivalent pour .NET. PHPGGC (PHP Generic Gadget Chains) génère des payloads PHP pour les frameworks majeurs (Laravel, Symfony, WordPress). pimpmykali intègre ces outils dans les distributions de pentest.

Pour la détection, Burp Suite avec l'extension Java Deserialization Scanner détecte les endpoints vulnérables. SerializationDumper analyse les flux de sérialisation Java. Semgrep et CodeQL détectent les patterns de désérialisation dangereuse dans le code source lors des revues de sécurité.

Défense / Bonnes pratiques

La règle d'or est de ne jamais désérialiser des données provenant de sources non fiables. Remplacez la sérialisation binaire par des formats de données simples comme JSON, XML ou Protocol Buffers qui ne permettent pas l'exécution de code. Si la sérialisation native est inévitable, implémentez un filtrage par whitelist des classes autorisées.

En Java, utilisez les ObjectInputFilter (JDK 9+) pour restreindre les classes désérialisables. Configurez -Djdk.serialFilter pour définir une politique globale. En PHP, évitez unserialize() avec des données utilisateur et utilisez json_decode() à la place. En Python, n'utilisez jamais pickle pour des données non fiables.

Maintenez vos dépendances à jour pour éliminer les gadget chains connues. Surveillez les indicateurs d'exploitation : exceptions de désérialisation dans les logs, requêtes contenant des signatures de flux sérialisés (ac ed 00 05 en Java, O:XX en PHP), et connexions JNDI/LDAP/RMI sortantes non autorisées. Déployez un WAF avec des règles de détection de payloads de désérialisation.

Articles associés

Voir nos articles détaillés sur ce sujet.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis