Sérialisation
Infrastructure
Transformer une donnée en mémoire (objet, structure, liste, graphe de références) en une suite d'octets ou de texte qu'on peut stocker ou transmettre, pour la reconstruire à l'identique ailleurs ou plus tard. L'opération inverse s'appelle la désérialisation.
Texte ou binaire : JSON, XML ou YAML se lisent à l'œil nu et se déboguent avec un éditeur. Protobuf, MessagePack ou CBOR sont plus compacts et plus rapides à traiter, mais un humain n'y lit rien.
Le sens dangereux : Désérialiser des données non fiables avec un format capable de recréer des objets arbitraires (pickle en Python, sérialisation native Java) peut mener à l'exécution de code à distance. Vingt ans de métier apprennent qu'un format capable de reconstruire n'importe quel objet finit toujours, un jour, par reconstruire le shell de quelqu'un d'autre.
Schéma et versions : Si l'émetteur renomme un champ, le récepteur ne le retrouve plus. Les formats à schéma (Protobuf, Avro) encadrent cette évolution avec des champs numérotés et des valeurs par défaut.
Forme canonique : Pour signer ou hacher une donnée sérialisée, il faut une représentation unique : ordre des clés, espaces et encodage des nombres doivent être fixés. C'est le rôle de DER pour ASN.1 ou de JCS pour JSON.
Ce qui arrive si on s'en passe
Sans sérialisation, l'état en mémoire ne dure que le temps du processus : un redémarrage, un plantage ou une mise à jour efface les objets en cours, et aucune reprise n'est possible depuis un point enregistré. Deux programmes ne peuvent pas non plus échanger une structure. Il faut alors la reconstituer à la main, souvent en mettant bout à bout des champs séparés par un caractère arbitraire. Ce procédé n'a aucune règle d'échappement : une valeur qui contient le séparateur décale les champs suivants, et une donnée fournie par l'utilisateur peut ainsi en remplacer une autre à la relecture. Les références partagées et les cycles d'un graphe sont perdus ou dupliqués, si bien que l'objet reconstruit ne correspond plus à l'original. Enfin, sans format stable, il est impossible de conserver ou de comparer des états successifs, et l'analyse après coup ne dispose d'aucune trace exploitable.
Explication de la marmotte
Imagine que tu veux envoyer un château de Lego à un copain qui habite loin. Impossible de le glisser tel quel dans une enveloppe. Alors tu le démontes et tu notes, brique par brique, où chacune doit aller. Ton copain reçoit le sachet de briques avec la notice, puis il reconstruit exactement le même château. Un ordinateur fait pareil avec les informations qu'il manipule : il les transforme en une longue suite de petits morceaux pour pouvoir les ranger dans un fichier ou les envoyer à un autre ordinateur, qui les remonte ensuite. Seul piège : il faut pouvoir faire confiance à la notice reçue, sinon on risque de monter n'importe quoi.
Où ce terme est utilisé
- Désérialisation non sécurisée et chaîne de gadgets (3 occurrences)
- Formats, bibliothèques et API : rendre la crypto utilisable (2 occurrences)
- Les poids d'un modèle sont un artefact logiciel (2 occurrences)
- Requête d'autorisation poussée et signée (PAR, JAR) (2 occurrences)
- Apprentissage automatique et réseaux de neurones, attaques du modèle (1 occurrence)
- ASI05 : exécution de code inattendue par un agent (1 occurrence)
- ASLR DEP NX canaries et CFI contre les exploits mémoire (1 occurrence)
- Certificate pinning : risques et rotation des certificats (1 occurrence)
- Chiffrer et authentifier en une seule construction (1 occurrence)
- Comment bloquer les requêtes côté serveur et la désérialisation (1 occurrence)