La désérialisation non sécurisée : notions et impact

Quand deux parties d’un système s’échangent des données, il faut souvent transformer un objet complexe en un texte ou une suite d’octets qui voyage facilement, puis le reconstituer à l’arrivée. C’est comme démonter un meuble pour le transporter et le remonter chez soi grâce à la notice. Ces deux opérations s’appellent la sérialisation et la désérialisation. Le danger apparaît quand c’est un inconnu qui fournit les pièces et dicte, d’une certaine façon, ce qui sera remonté.

Sérialiser et désérialiser, en clair

Une application manipule des objets : un utilisateur avec son nom, ses préférences, son panier. Pour les stocker dans un cookie, les transmettre à une autre application ou les enregistrer, elle les sérialise : elle les convertit en un format textuel ou binaire. À la réception, elle les désérialise : elle reconstruit l’objet d’origine.

Il existe de nombreux formats. Certains, comme JSON, sont limités aux données simples : textes, nombres, listes. D’autres, propres à un langage de programmation, sont plus puissants : ils décrivent aussi le type des objets à recréer, et peuvent déclencher du code pendant la reconstruction. C’est cette puissance qui crée le danger.

Où est le problème ?

La reconstruction d’un objet à partir de données externes n’est pas qu’un « remplissage de cases » : selon le format et le langage, le processus peut invoquer automatiquement des méthodes des classes de l’application (des fonctions de « réveil » ou de « nettoyage » appelées lors de la reconstruction). Si le format laisse l’émetteur choisir quelle classe instancier, quelqu’un qui contrôle les données choisit, en pratique, quel code de l’application sera exécuté et avec quelles valeurs.

Analogie : vous remontez un meuble avec la notice fournie par un inconnu. Si la notice vous demande d’assembler, à un moment, une pièce qui déclenche un mécanisme, vous l’exécutez sans le savoir. Le risque ne vient pas de l’idée de notice, mais du fait de faire confiance à une notice qui n’est pas la vôtre.

Les impacts possibles

Ce dernier cas est celui qui a fait la réputation de la faille. Il dépend de l’existence, dans l’application et ses bibliothèques, de classes dont les méthodes peuvent être enchaînées de façon dangereuse : c’est pourquoi une bibliothèque vulnérable (leçon précédente) peut rendre une application exploitable sans qu’une seule ligne de son propre code soit en cause.

Reconnaître le risque

Un auditeur y pense lorsqu’il observe :

• un cookie ou un paramètre dont la valeur ressemble à un objet encodé (une longue chaîne qui n’est pas du simple texte, parfois encodée de façon à être transportable), et qui est renvoyée au serveur ;
• une API qui accepte des objets complexes dans un format propre à un langage ;
• des messages échangés entre composants (files de messages, tâches planifiées) sans vérification d’origine ;
• des fichiers de session ou de cache lus et reconstruits sans protection d’intégrité ;
• des messages d’erreur qui mentionnent des mécanismes de reconstruction d’objets.

La confirmation de l’existence d’une faille demande une grande prudence, car les tests peuvent déstabiliser le serveur. En audit réel, on privilégie la revue de configuration et de code (boîte grise ou blanche) et on convient avec le client des conditions d’un éventuel test pratique, dans un environnement de recette plutôt qu’en production.

Défendre : changer la manière d’échanger

• Ne jamais désérialiser des données non fiables avec un format capable d’instancier des objets arbitraires. C’est la règle numéro un.
• Préférer des formats de données simples (comme JSON) qui ne décrivent que des valeurs, et reconstruire les objets soi-même à partir de champs validés.
• Signer les données qui doivent voyager chez le client (par exemple, avec un code d’authentification de message dont la clé reste côté serveur) pour détecter toute modification ; mieux, ne rien stocker de sensible chez le client, et garder l’état dans la session côté serveur.
• Liste blanche de types autorisés lorsqu’on ne peut pas faire autrement.
• Exécuter avec le moindre privilège : un processus de désérialisation isolé et limité réduit l’impact.
• Tenir à jour les bibliothèques : beaucoup de corrections visent précisément ces mécanismes.
• Surveiller les exceptions de désérialisation, qui peuvent signaler des tentatives.
• Limiter la taille et la profondeur des données acceptées pour éviter le déni de service.

// À éviter : reconstruire un objet complet depuis une donnée fournie par le client
// $profil = unserialize(base64_decode($_COOKIE['profil']));

// À préférer : des données simples, validées champ par champ
$donnees = json_decode($_POST['profil'] ?? '', true);
$nom = is_array($donnees) && is_string($donnees['nom'] ?? null) ? substr($donnees['nom'], 0, 80) : '';
$profil = new Profil($nom);   // l'objet est construit par l'application

À vous de jouer

Exercice de raisonnement, sans aucune manipulation d’objet piégé.

1. Une application stocke dans un cookie un objet sérialisé contenant le nom de l’utilisateur et son rôle, sans aucune signature. Quels risques identifiez-vous ?
2. Proposez deux corrections alternatives.
3. Rédigez le constat correspondant, en précisant ce qui a été observé et ce qui n’a pas été testé et pourquoi.

Vous avez maintenant fait le tour des grandes familles de failles web. Il reste à transformer vos constats en actions : c’est l’objet du dernier chapitre, le rapport et la remédiation.