Les codeurs conquièrent la sécurité : Série "Partageons et apprenons" - Désérialisation non sécurisée

En fonction de l'application, le processus de sérialisation peut se produire en permanence. C'est le terme utilisé pour décrire chaque fois que des structures de données ou des états d'objets sont traduits dans un format qui peut être stocké ou éventuellement envoyé en tant que communication. La désérialisation est l'inverse de ce processus : elle prend les données désormais structurées et les retransforme en l'objet ou la chaîne de données qu'elles étaient avant d'être stockées.

La désérialisation non sécurisée peut se produire lorsqu'une application traite les données désérialisées comme des données de confiance. Si un utilisateur est en mesure de modifier les données nouvellement reconstruites, il peut effectuer 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 se donner un avantage au sein de l'application, par exemple en abaissant le prix d'un objet ou en élevant ses privilèges.

Dans cet épisode, vous apprendrez

• Comment les attaquants peuvent exploiter une désérialisation non sécurisée
• Pourquoi la désérialisation non sécurisée est dangereuse
• Techniques permettant de 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 des données est JSON, bien que XML le suive de près. De nombreux langages de programmation proposent également leurs propres méthodes de sérialisation des données, qui contiennent souvent plus de fonctionnalités que JSON ou XML. Dans tous les cas, des problèmes peuvent survenir si les développeurs programment des applications qui traitent les données désérialisées comme des données fiables, au lieu de suivre le vieux mantra des autres blogs de cette série, à savoir : "Ne faites jamais confiance aux données de l'utilisateur !"

L'entrée utilisateur n'est jamais fiable car l'utilisateur peut insérer du code dans ces chaînes, qui pourrait être accidentellement exécuté par le serveur récepteur. Et comme les données brutes désérialisées peuvent parfois être consultées et exploitées, elles doivent être classées dans la même catégorie de non-confiance.

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 peut changer son rôle "utilisateur" en "administrateur". Il peut également utiliser l'ouverture fournie par la chaîne de données pour injecter du code, qui pourrait être mal interprété et exécuté par le serveur lorsqu'il traite les 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 minimum de compétences de la part d'un pirate, et parfois des essais et des erreurs pendant que l'attaquant apprend quels types de code ou d'exploits le serveur acceptera à partir de ses données manipulées et désérialisées. Cela dit, il s'agit d'une vulnérabilité couramment exploitée en raison de la puissance potentielle qu'elle confère aux pirates suffisamment habiles pour l'utiliser.

Selon la manière dont les données désérialisées sont censées être utilisées, un certain nombre d'attaques, dont beaucoup ont été abordées dans les blogs précédents, peuvent être employées. Une désérialisation non sécurisée peut être une passerelle vers l'injection de code croisé à distance, le scriptage intersite, le déni de service, le détournement de contrôle d'accès et, bien sûr, les attaques par injection SQL et XML. En fait, elle ouvre un point de lancement, déclare que toutes les données désérialisées sont fiables et laisse les attaquants essayer de les exploiter.

Élimination de la désérialisation non sécurisée

La chose la plus sûre que les organisations puissent faire pour empêcher une désérialisation non sécurisée est d'empêcher les applications d'accepter des données désérialisées. Il se peut toutefois que cela ne soit pas possible ou réaliste, mais ne vous inquiétez pas, car il existe d'autres techniques qui peuvent être employées pour se défendre contre ce type d'attaque.

Si possible, les données peuvent être nettoyées et transformées en valeurs numériques. Cela n'empêchera peut-être pas totalement un exploit, mais empêchera les injections de code de se produire. Il est encore mieux d'exiger une forme de contrôle d'intégrité des données désérialisées, telle qu'une signature numérique, qui pourrait garantir que les chaînes de données n'ont pas été manipulées. Tous les processus de désérialisation doivent être isolés et exécutés dans un environnement à faibles privilèges.

Une fois ces protections mises en place, veillez à enregistrer toutes les tentatives de désérialisation qui ont échoué, ainsi que l'activité du réseau provenant des conteneurs ou des serveurs qui désérialisent les données. Si un utilisateur déclenche plus de deux erreurs de désérialisation dans les journaux, c'est une bonne indication qu'il s'agit d'un initié malveillant ou que ses informations d'identification ont été piratées ou volées. Vous pouvez même envisager des mesures telles que le verrouillage automatique des utilisateurs qui déclenchent constamment des erreurs de désérialisation.

Quels que soient les outils que vous utilisez pour lutter contre la désérialisation non sécurisée, n'oubliez pas qu'il s'agit de données qui ont pu être touchées ou manipulées par un utilisateur. Ne vous y fiez jamais.

Plus d'informations sur l'utilisation de composants dont les vulnérabilités sont connues

Pour en savoir plus, vous pouvez consulter ce que dit l'OWASP à propos de la désérialisation non sécurisée. Vous pouvez également mettre à l'épreuve vos nouvelles connaissances en matière de défense grâce à la vitrine gratuite de la plateforme Secure Code Warrior , qui forme les équipes de cybersécurité pour qu'elles deviennent les meilleurs cyber-guerriers. Pour en savoir plus sur la manière de vaincre cette vulnérabilité et d'autres menaces, visitez le blogSecure Code Warrior .