LLM · tout ou partie
1. Sérialiser et désérialiser : de quoi parle-t-on ?
La sérialisation consiste à transformer une structure de données en une représentation pouvant être enregistrée ou transmise. La désérialisation réalise l’opération inverse : elle reconstitue une structure de données exploitable par le programme. Prenons un tableau associatif PHP :
$utilisateur = [
'nom' => 'Alice',
'connecte' => true
];La fonction serialize($utilisateur) produit :
a:2:{s:3:"nom";s:5:"Alice";s:8:"connecte";b:1;}Cette chaîne décrit un tableau (a) contenant deux éléments, leurs noms, leurs types et leurs valeurs. Par exemple, s:5:"Alice" représente une chaîne de cinq octets et b:1 un booléen vrai.
Données structurées en mémoire (tableaux, objets, chaînes, entiers, booléens…) → sérialisation → suite d’octets stockable ou transmissible → désérialisation → données structurées.
Le format de lecture doit correspondre au format d’écriture.
En PHP, les fonctions générales sont serialize() et unserialize(). D’autres formats existent, notamment JSON, avec json_encode() et json_decode().
Attention : sérialiser n’est ni chiffrer ni protéger l’intégrité des données.
2. Pourquoi les sessions PHP utilisent-elles la sérialisation ?
HTTP est un protocole sans état : deux requêtes successives ne conservent pas automatiquement les variables d’une application. Les sessions permettent de maintenir un état côté serveur, généralement associé à un identifiant transmis par un cookie. Une application peut ainsi enregistrer :
session_start();
$_SESSION['utilisateur'] = 'Alice';
$_SESSION['connecte'] = true;En fin de requête, PHP peut sérialiser ces données et les enregistrer dans le stockage de session. Lors d’une requête suivante, session_start() permet de retrouver et de désérialiser les données correspondantes. L’écriture peut aussi être déclenchée explicitement avec session_write_close().
Le navigateur conserve habituellement l’identifiant de session, pas le contenu complet de $_SESSION.
3. Le gestionnaire de sérialisation
Le paramètre PHP session.serialize_handler détermine le format utilisé pour encoder et décoder les données de session.
| Valeur | Fonction |
|---|---|
php | Format historique des sessions, avec délimitation des noms de variables |
php_binary | Variante historique préfixant chaque nom par un octet indiquant sa longueur |
php_serialize | Utilise le format général produit par serialize() pour l’ensemble des données de session |
Exemple de configuration :
session.serialize_handler = phpCes formats ne sont pas interchangeables. Une session enregistrée dans un format ne peut pas être supposée lisible correctement avec un autre.
À retenir : le gestionnaire de sérialisation définit comment représenter les données, pas où les stocker.
4. Ne pas confondre avec le gestionnaire de stockage
PHP possède un autre paramètre :
session.save_handler = filesIl indique le mécanisme de conservation des sessions : fichiers locaux par défaut, ou autre système via une extension ou un gestionnaire adapté.
| Paramètre | Question à laquelle il répond |
|---|---|
session.serialize_handler | Comment encoder et décoder les données ? |
session.save_handler | Comment enregistrer et récupérer les données ? |
session.save_path | Où les conserver, selon le gestionnaire choisi ? |
Ainsi, une application peut sérialiser ses sessions au format php_serialize et les stocker dans des fichiers.
5. Quels sont les enjeux de sécurité ?
La désérialisation mérite une attention particulière, car elle consiste à interpréter des données pour reconstituer des structures internes.
Avec unserialize(), des données manipulées par un attaquant peuvent notamment provoquer l’instanciation d’objets PHP et déclencher certains mécanismes applicatifs, comme les méthodes magiques. Dans un contexte vulnérable, cela peut conduire à une exploitation.
Pour les sessions PHP, un autre problème possible est l’incohérence entre les formats de sérialisation. Par exemple :
ini_set('session.serialize_handler', 'php');
session_start();Changer dynamiquement le format ne constitue pas en soi une vulnérabilité. En revanche, des changements de gestionnaire dans certaines conditions peuvent exposer des défauts du moteur PHP.
Le cas CVE-2026-115560
Selon l’avis PHP du 23 octobre 2026, ce risque d’exécution de code à distance exige la combinaison suivante :
session.serialize_handlervaut initialementphp_binaryouphp_serializedans la configuration ;- le code le remplace par
phpavecini_set()avantsession_start(); - le suivi de progression des téléversements reste activé.
L’équipe PHP recommande cette atténuation, à appliquer dans la configuration PHP :
session.upload_progress.enabled = 0Les applications qui ne changent jamais de gestionnaire à l’exécution ne remplissent pas ces conditions. Au 27 octobre 2026, l’avis annonce une correction dans le cycle habituel, sans préciser de version corrigée pour cette CVE. Suivre les mises à jour officielles ; cette atténuation ne remplace pas les correctifs de sécurité du moteur PHP.
6. Les bonnes pratiques
- Utiliser un format cohérent pendant tout le cycle de vie des sessions.
- Éviter de modifier dynamiquement
session.serialize_handlersans nécessité. - Ne jamais transmettre de données non fiables à
unserialize(), même avecallowed_classes. Pour un échange de données avec l’utilisateur, préférer un format comme JSON. - Maintenir PHP et ses extensions à jour.
- Protéger les identifiants de session, notamment avec des cookies
Secure,HttpOnlyet une politiqueSameSiteadaptée. - Désactiver les fonctionnalités PHP inutilisées, en tenant compte des dépendances applicatives.
En résumé
Sérialiser, c’est transformer des données structurées en une représentation enregistrable. Désérialiser, c’est reconstruire ces données.
Le gestionnaire de sérialisation choisit le format de représentation, tandis que le gestionnaire de stockage choisit comment les données sont conservées.
Et en sécurité, la règle fondamentale reste la même : une donnée désérialisée peut avoir des conséquences sur le fonctionnement du programme. Sa provenance, son format et les mécanismes qui l’interprètent doivent donc être maîtrisés.