Les développeurs à l'assaut de la sécurité : Série Partage & Apprentissage - Désérialisation non sécurisée

Selon l'application, le processus de sérialisation peut se produire en permanence. C'est le terme utilisé pour décrire la conversion de structures de données ou d'états d'objets dans un format pouvant être stocké ou transmis lors d'une communication. La désérialisation est l'inverse de ce processus : elle reprend les données structurées pour les transformer à nouveau en l'objet ou la chaîne de données initiale avant leur stockage.

La désérialisation non sécurisée peut survenir dès lors qu'une application considère les données en cours de désérialisation comme étant fiables. Si un utilisateur est en mesure de modifier les données nouvellement reconstruites, il peut mener toutes sortes d'activités malveillantes, telles que des injections de code, des attaques par déni de service ou simplement modifier les données pour obtenir un avantage au sein de l'application, comme réduire le prix d'un article ou élever ses privilèges.

Dans cet épisode, nous apprendrons :

• Comment les attaquants exploitent la désérialisation non sécurisée
• Pourquoi la désérialisation non sécurisée est dangereuse
• Les techniques pour corriger cette vulnérabilité.

Comment les attaquants exploitent-ils la désérialisation non sécurisée ?

De nos jours, le format de données le plus populaire pour la sérialisation est le JSON, bien que le XML arrive en deuxième position. De nombreux langages de programmation proposent également leurs propres méthodes de sérialisation, souvent plus riches en fonctionnalités que le JSON ou le XML. Dans tous les cas, des problèmes peuvent survenir si les développeurs programment des applications pour traiter les données désérialisées comme des entrées fiables, au lieu de suivre le mantra rappelé dans les autres articles de cette série : « Ne faites jamais confiance aux entrées utilisateur ! »

Les entrées utilisateur ne doivent jamais être considérées comme fiables, car l'utilisateur peut insérer du code dans ces chaînes, qui pourrait être exécuté accidentellement par le serveur destinataire. Comme les données brutes désérialisées peuvent parfois être accessibles et exploitées, elles doivent être classées dans la même catégorie de données non fiables.

Par exemple, si une application de forum utilise la sérialisation d'objets PHP pour enregistrer un cookie contenant l'identification et le rôle d'un utilisateur, celui-ci peut être manipulé. Un utilisateur malveillant pourrait remplacer son rôle « utilisateur » par « administrateur ». Il peut également utiliser la faille offerte par la chaîne de données pour injecter du code, qui pourrait être mal interprété et exécuté par le serveur lors du traitement des données « fiables ».

Pourquoi la désérialisation non sécurisée est-elle dangereuse ?

Il est vrai que ce type d'attaque nécessite un certain niveau de compétence de la part d'un pirate, et parfois des essais et erreurs pour découvrir quels types de code ou d'exploits le serveur acceptera à partir de données désérialisées manipulées. Cela dit, il s'agit d'une vulnérabilité couramment exploitée en raison de la puissance qu'elle confère aux pirates suffisamment qualifiés pour l'utiliser.

Selon l'utilisation prévue des données désérialisées, de nombreuses attaques, dont beaucoup ont été abordées dans nos précédents articles, peuvent être employées. La désérialisation non sécurisée peut servir de passerelle vers l'injection de code à distance, le cross-site scripting (XSS), le déni de service, le détournement de contrôle d'accès et, bien sûr, les injections SQL et XML. Elle crée essentiellement un point de lancement, déclare toutes les données désérialisées comme fiables et permet aux attaquants de tenter de les exploiter.

Éliminer la désérialisation non sécurisée

La mesure la plus sûre que les organisations puissent prendre pour prévenir la désérialisation non sécurisée consiste à empêcher les applications d'accepter des données désérialisées. Cela peut ne pas être toujours possible ou réaliste, mais rassurez-vous, d'autres techniques peuvent être employées pour se défendre contre ce type d'attaque.

Si possible, les données peuvent être assainies pour ne conserver que des valeurs numériques. Cela ne stoppera peut-être pas totalement une exploitation, mais empêchera les injections de code. Mieux encore, il suffit d'exiger une forme de vérification d'intégrité des données désérialisées, telle qu'une signature numérique, pour garantir que les chaînes de données n'ont pas été manipulées. Enfin, tous les processus de désérialisation doivent être isolés et exécutés dans un environnement à privilèges restreints.

Une fois ces protections en place, assurez-vous de journaliser toutes les tentatives de désérialisation échouées, ainsi que l'activité réseau provenant des conteneurs ou des serveurs qui désérialisent les données. Si un utilisateur déclenche plusieurs erreurs de désérialisation dans les journaux, c'est un signe fort qu'il s'agit soit d'un utilisateur interne malveillant, soit que ses identifiants ont été piratés ou volés. Vous pourriez même envisager des mesures telles que le verrouillage automatique des utilisateurs qui déclenchent constamment des erreurs de désérialisation.

Quel que soit l'outil que vous utilisez pour lutter contre la désérialisation non sécurisée, rappelez-vous qu'il s'agit fondamentalement de données qui ont pu être touchées ou manipulées par un utilisateur. Ne leur faites jamais confiance.

En savoir plus sur l'utilisation de composants présentant des vulnérabilités connues

Pour aller plus loin, consultez les recommandations de l'OWASP sur la désérialisation non sécurisée. Vous pouvez également mettre vos nouvelles compétences défensives à l'épreuve avec la démonstration gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir des experts en la matière. Pour en savoir plus sur la neutralisation de cette vulnérabilité et d'une multitude d'autres menaces, visitez le blog de Secure Code Warrior.