Désérialisation non sécurisée : comprendre le risque
Sauvegarder l'état d'une application pour le restaurer plus tard est une opération banale. Mais lorsqu'on restaure des données venues de l'extérieur sans précaution, cette commodité peut se transformer en faille critique, jusqu'à l'exécution de code.
Sérialisation, désérialisation : de quoi parle-t-on ?
La sérialisation consiste à convertir l'état d'une application en un format adapté au transfert ou au stockage (sauvegarder la progression d'un jeu, le contenu d'un éditeur en ligne…). La désérialisation est l'opération inverse : reconstruire l'état à partir de ces données.
Le problème surgit quand l'application désérialise des données contrôlées par l'utilisateur sans les vérifier. Selon le langage et les bibliothèques, un objet malveillant soigneusement forgé peut alors déclencher des comportements inattendus, jusqu'à l'exécution de code à distance. Un risque récurrent en sécurité applicative.
Pourquoi c'est dangereux
Exécution de code
Dans le pire des cas, un objet piégé conduit à l'exécution de code sur le serveur (RCE) et à sa compromission.
Altération d'objets
Modifier les attributs d'un objet désérialisé pour changer des droits, des montants ou un statut.
Déni de service
Forcer la désérialisation de structures coûteuses pour saturer les ressources de l'application.
Une faille discrète
Le format sérialisé est souvent opaque (binaire, encodé) : la faille passe facilement inaperçue lors d'une revue rapide.
Où le risque se cache
Les données sérialisées circulent souvent à des endroits insoupçonnés : cookies, jetons, champs cachés, files de messages, caches, paramètres d'API. Dès qu'une de ces sources est contrôlable par l'utilisateur et désérialisée sans contrôle, le risque existe. C'est l'une des raisons pour lesquelles il ne faut jamais accorder une confiance aveugle aux données entrantes, un principe commun à l'injection SQL comme au XSS.
Le principe : ne pas désérialiser de données non fiables
La meilleure protection est d'éviter de désérialiser des données issues de sources non fiables. Quand c'est inévitable, on privilégie des formats de données simples (comme du JSON traité par un parseur strict) plutôt que la sérialisation native d'objets, on vérifie l'intégrité des données (signature), on restreint les types autorisés (liste blanche) et on applique le moindre privilège. Ces protections se valident par un test d'intrusion.
Se protéger, étape par étape
Éviter la désérialisation non fiable
Ne pas désérialiser de données provenant directement de l'utilisateur quand on peut l'éviter.
Préférer des formats simples
Utiliser des formats de données (JSON) avec un parseur strict plutôt que la sérialisation native d'objets.
Vérifier l'intégrité
Signer les données sérialisées légitimes pour détecter toute altération avant de les traiter.
Restreindre les types
Limiter par liste blanche les classes/types autorisés à la désérialisation.
Cloisonner & limiter
Appliquer le moindre privilège pour réduire l'impact d'une exploitation réussie.
Pourquoi se faire accompagner par BCIT ?
Repérer les points sensibles
Nous identifions les flux de désérialisation exposés dans votre application.
Des correctifs concrets
Des recommandations adaptées à votre langage et à vos bibliothèques.
Une approche d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Restaurez vos données sans ouvrir de brèche
Prenons 15 minutes pour évaluer vos usages de sérialisation et sécuriser les flux à risque.
Désérialisation non sécurisée : comprendre le risque
Sauvegarder l'état d'une application pour le restaurer plus tard est une opération banale. Mais lorsqu'on restaure des données venues de l'extérieur sans précaution, cette commodité peut se transformer en faille critique, jusqu'à l'exécution de code.
Sérialisation, désérialisation : de quoi parle-t-on ?
La sérialisation consiste à convertir l'état d'une application en un format adapté au transfert ou au stockage (sauvegarder la progression d'un jeu, le contenu d'un éditeur en ligne…). La désérialisation est l'opération inverse : reconstruire l'état à partir de ces données.
Le problème surgit quand l'application désérialise des données contrôlées par l'utilisateur sans les vérifier. Selon le langage et les bibliothèques, un objet malveillant soigneusement forgé peut alors déclencher des comportements inattendus, jusqu'à l'exécution de code à distance. Un risque récurrent en sécurité applicative.
Pourquoi c'est dangereux
Exécution de code
Dans le pire des cas, un objet piégé conduit à l'exécution de code sur le serveur (RCE) et à sa compromission.
Altération d'objets
Modifier les attributs d'un objet désérialisé pour changer des droits, des montants ou un statut.
Déni de service
Forcer la désérialisation de structures coûteuses pour saturer les ressources de l'application.
Une faille discrète
Le format sérialisé est souvent opaque (binaire, encodé) : la faille passe facilement inaperçue lors d'une revue rapide.
Où le risque se cache
Les données sérialisées circulent souvent à des endroits insoupçonnés : cookies, jetons, champs cachés, files de messages, caches, paramètres d'API. Dès qu'une de ces sources est contrôlable par l'utilisateur et désérialisée sans contrôle, le risque existe. C'est l'une des raisons pour lesquelles il ne faut jamais accorder une confiance aveugle aux données entrantes, un principe commun à l'injection SQL comme au XSS.
Le principe : ne pas désérialiser de données non fiables
La meilleure protection est d'éviter de désérialiser des données issues de sources non fiables. Quand c'est inévitable, on privilégie des formats de données simples (comme du JSON traité par un parseur strict) plutôt que la sérialisation native d'objets, on vérifie l'intégrité des données (signature), on restreint les types autorisés (liste blanche) et on applique le moindre privilège. Ces protections se valident par un test d'intrusion.
Se protéger, étape par étape
Éviter la désérialisation non fiable
Ne pas désérialiser de données provenant directement de l'utilisateur quand on peut l'éviter.
Préférer des formats simples
Utiliser des formats de données (JSON) avec un parseur strict plutôt que la sérialisation native d'objets.
Vérifier l'intégrité
Signer les données sérialisées légitimes pour détecter toute altération avant de les traiter.
Restreindre les types
Limiter par liste blanche les classes/types autorisés à la désérialisation.
Cloisonner & limiter
Appliquer le moindre privilège pour réduire l'impact d'une exploitation réussie.
Pourquoi se faire accompagner par BCIT ?
Repérer les points sensibles
Nous identifions les flux de désérialisation exposés dans votre application.
Des correctifs concrets
Des recommandations adaptées à votre langage et à vos bibliothèques.
Une approche d'ensemble
De la sécurité applicative aux audits, toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Restaurez vos données sans ouvrir de brèche
Prenons 15 minutes pour évaluer vos usages de sérialisation et sécuriser les flux à risque.