Prévenir la désérialisation non sécurisée dans Node.js

La sérialisation consiste à convertir un objet JavaScript en un flux d’octets séquentiels afin de l’envoyer sur un réseau ou de l’enregistrer dans une base de données. Elle modifie le format des données d’origine tout en préservant leur état et leurs propriétés, ce qui permet de les recréer au besoin. Grâce à la sérialisation, nous pouvons écrire des données complexes dans des fichiers, des bases de données et la mémoire interprocessus, ainsi que les transmettre entre des composants et sur des réseaux.

La désérialisation est l’inverse de la sérialisation : elle reconvertit les données sérialisées en un objet dans le même état qu’à l’origine. Le problème, c’est que la désérialisation peut être non sécurisée et exposer des données sensibles. La principale cause de la désérialisation non sécurisée est l’absence de protection lors de la désérialisation des entrées utilisateur. Pour l’éviter, il faut veiller à ne désérialiser que des données validées et assainies. 

Les attaquants peuvent exploiter cette vulnérabilité en intégrant du code malveillant à un objet sérialisé qui semble inoffensif, puis en l’envoyant à une application. En l’absence de vérifications de sécurité supplémentaires, l’application web désérialise l’objet reçu et exécute le code malveillant. Un attaquant peut également extraire les données sensibles contenues dans un objet sérialisé.

Les conséquences d’une sérialisation non sécurisée peuvent être graves. Lorsqu’un site web désérialise des données de manière non sécurisée, par exemple, les pirates peuvent manipuler des objets sérialisés et transmettre des données nuisibles au code d’une application. Un attaquant peut même envoyer un objet sérialisé entièrement différent pour accéder à d’autres parties de l’application, la rendant vulnérable à d’autres attaques et à la perte de données.

La désérialisation non sécurisée dans Node.js

node-serialize et serialize-to-js sont des packages Node.js et JavaScript vulnérables à la désérialisation non sécurisée. Contrairement à JSON.parse et JSON.stringify, qui ne sérialisent que des objets au format JSON, ces deux bibliothèques sérialisent presque tous les types d’objets, y compris les fonctions. Cette caractéristique les rend vulnérables à la pollution de prototype, une attaque par injection au cours de laquelle un acteur malveillant prend le contrôle des valeurs par défaut des propriétés d’un objet.

En cas de réussite d’une attaque par pollution de prototype, l’attaquant peut causer d’autres dégâts en modifiant la logique de l’application, en déclenchant l’exécution de code à distance ou une attaque par déni de service (DoS).

Cet article montre comment corriger les vulnérabilités de désérialisation dans Node.js. Nous allons créer du code vulnérable, présenter une attaque, puis corriger les vulnérabilités.

Prérequis

Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

• Node.js installé

• Connaissances en JavaScript

Corriger les vulnérabilités de désérialisation dans Node.js

Commençons par configurer un projet Node.js. Exécutez la commande suivante :

npm init -y

Installez le framework d’application web Express :

npm install express

Installez le package de sérialisation Node.js :

npm install node-serialize

Installez un analyseur de cookies :

npm install cookie-parser

Créez un nouveau fichier server.js et ajoutez le code ci-dessous :

1var express = require('express');
2var cookieParser = require('cookie-parser');
3var escape = require('escape-html');
4var serialize = require('node-serialize');
5var app = express();
6app.use(cookieParser())
7
8app.get('/', function(req, res) {
9	if (req.cookies.profile) {
10		var str = new Buffer(req.cookies.profile, 'base64').toString();
11		var obj = serialize.unserialize(str);
12		if (obj.username) {
13			res.send("Hello " + escape(obj.username));
14		}
15	} else {
16		res.cookie('profile', "eyJ1c2VybmFtZSI6IkpvaG4iLCJnZW5kZXIiOiJNYWxlIiwiQWdlIjogMzV9", {
17			maxAge: 900000,
18			httpOnly: true
19		});
20	}
21	res.send("Welcome to the Serialize-Deserialize Demo!");
22});
23app.listen(3000);
24console.log("Listening on port 3000...");

Dans le fichier ci-dessus, nous utilisons le module non sécurisé node-serialize. Nous lui transmettons également des données non fiables à l’aide de sa fonction unserialize().

Combien de problèmes de sécurité pouvez-vous relever dans le code ci-dessus ? Comment savoir si le code ou les dépendances ajoutées au projet présentent des problèmes de sécurité ? 

C’est là qu’intervient l’extension Snyk Code. Elle est gratuite et rapide à configurer. Dans VS Code, accédez à Extensions (SHIFT+CMD+X), recherchez Snyk, installez l’extension et rejoignez plus de 90 000 développeurs.

Voici une capture d’écran de Snyk Code en action avec l’extrait de code de l’application Express précédente :

Observez les flèches violettes et la façon dont elles signalent les problèmes de sécurité potentiels dans ce serveur d’application Express. En examinant attentivement, vous en repérerez d’autres et remarquerez que Snyk Code annote les lignes du fichier `server.js` pour montrer comment du code non sécurisé circule entre différents chemins d’exécution et fichiers de code.

Téléchargez l’extension Snyk pour VS Code, elle est gratuite !

Revenons à l’application web Node.js : le résultat, c’est que le point de terminaison app.get('/', function(req, res) devient vulnérable à la désérialisation non sécurisée. En effet, l’application ajoute les entrées utilisateur à la valeur d’un cookie de préférences déjà sérialisé. 

Pour démontrer la vulnérabilité, exécutez le serveur Express à l’aide de cette commande :

node server.js

Le serveur démarre sur le port 3000. Ouvrez http://localhost:3000/ pour afficher la page et inspecter les cookies, comme indiqué ci-dessous :

Convertissez maintenant le cookie du format base64 au format JSON. Vous pouvez utiliser un outil en ligne comme Code Beautify. Voici le cookie en base64 :

eyJ1c2VybmFtZSI6IkpvaG4iLCJnZW5kZXIiOiJNYWxlIiwiQWdlIjogMzV9

Et voici le cookie défini par le serveur après sa conversion de base64 en JSON :

{"username":"John","gender":"Male","Age": 35}

Pour voir la désérialisation problématique en action, modifions la valeur de l’objet JSON et encodons-le en base64, puis remplaçons la valeur du cookie dans le navigateur par le nouveau cookie.

Modifiez l’objet JSON comme suit :

{"username":"Joe Jones","gender":"Male","Age": 40}

Ouvrez cet outil Base64 pour encoder le JSON. Une fois encodé en base64, il donne :

eyJ1c2VybmFtZSI6IkpvZSBKb25lcyIsImdlbmRlciI6Ik1hbGUiLCJBZ2UiOiA0MH0=

Remplacez maintenant la valeur actuelle du cookie dans le navigateur par la valeur encodée du nouvel objet, puis modifiez la valeur de la réponse HTTP dans le fichier server.js comme suit :

res.send("Welcome to the Insecure Deserialize Demo!");

Lorsque vous redémarrez la connexion et actualisez la page, vous verrez la nouvelle réponse.

Exploiter la vulnérabilité

Exploitons la vulnérabilité pour exécuter du code arbitraire (ACE), en transmettant des données non fiables à la fonction unserialize(). 

Commençons par créer une charge utile avec la fonction serialize() du même module que celui utilisé jusqu’ici. Pour cela, créez un fichier nommé serialize.js et ajoutez-y le code suivant :

1var serialize = require('node-serialize');
2var m = {
3	myOutput: function() {
4		return 'Hello';
5	}
6}
7console.log("Serialized: \n" + serialize.serialize(m) + "\n");

Ce script Node.js va sérialiser notre code. 

Ouvrez maintenant un terminal, accédez au dossier racine et exécutez cette commande :

node serialize.js

Remplacez le paramètre username dans la valeur du cookie par la valeur du paramètre myOutput dans le résultat ci-dessus. Notre nouvel objet dans le cookie devrait maintenant ressembler à ceci :

1{"username":"_$$ND_FUNC$$_function(){ return 'Hello'; }","gender":"Male","Age": 40}

Le résultat ci-dessus nous fournit une charge utile sérialisée à transmettre à la fonction unserialize(). Pour obtenir une ACE, nous devons utiliser une expression de fonction immédiatement invoquée (IIFE) JavaScript afin d’appeler la fonction.

Lorsque nous ajoutons les parenthèses IIFE, (), après le corps de la fonction dans cette charge utile sérialisée, la fonction s’exécute après la création de l’objet. Voici l’objet JSON qui sera alors stocké dans le cookie.

1{
2	"username": "_$$ND_FUNC$$_function(){ return 'Hello'; }()",
3	"gender": "Male",
4	"Age": 40
5};
6

Pour montrer comment cet objet manipulé introduit l’évaluation dynamique de code dans un serveur Node.js en cours d’exécution, nous allons l’utiliser dans notre fichier utilitaire serialize.js. Transmettons cette charge utile à une fonction unserialize(). Modifiez le fichier seralize.js en ajoutant le code suivant :

1var serialize = require('node-serialize');
2var m = {
3	myOutput: function() {
4		return 'Hello';
5	}
6}
7
8console.log("Serialized: \n" + serialize.serialize(m) + "\n");
9
10var km = {
11	"username": "_$$ND_FUNC$$_function(){ return 'Hello'; }()",
12	"gender": "Male",
13	"Age": 40
14};
15console.log(serialize.unserialize(km));

Dans le code ci-dessus, nous avons ajouté une nouvelle variable, km, qui contient une fonction comme valeur de username, transmise à la fonction unserialize().

Exécutez maintenant le script utilitaire à l’aide de la commande suivante pour vérifier si la fonction est exécutée :

node serialize.js

Vous devriez obtenir le résultat suivant :

L’exploitation du processus de sérialisation a réussi ! En tant qu’attaquants capables de contrôler l’entrée de l’objet côté client, nous avons pu le manipuler pour y inclure du code JavaScript qui modifie le champ du nom d’utilisateur.

Corriger la vulnérabilité de désérialisation non sécurisée

Le meilleur moyen de prévenir la désérialisation non sécurisée est d’éviter complètement de désérialiser les entrées utilisateur. La deuxième meilleure solution consiste à vérifier les entrées utilisateur avant de les sérialiser. Nous pouvons utiliser un package appelé Serialize JavaScript pour assainir les entrées dans l’exemple vulnérable ci-dessus.

Commencez par installer serialize-javaScript avec npm :

npm install serialize-javascript

Modifiez le fichier serialize.js en remplaçant son code par celui-ci :

1var serialize = require('serialize-javascript');
2var m = {
3	myOutput: function() {
4		return 'Hello';
5	}
6}
7console.log("Serialized: \n" + serialize(m, {
8	ignoreFunction: true
9}) + "\n");

ignoreFunction garantit que les fonctions utilisées pour exécuter une ACE ne sont pas sérialisées. Exécutez le fichier pour le vérifier :

node serialize.js

Voici le résultat :

Vérifions que le nouveau package serialize-javascript recommandé dans cet article est bien exempt de vulnérabilités, selon les rapports CVE. La commande npm ls ci-dessous montre qu’il a été ajouté au projet, aux côtés du package vulnérable node-serialize :

1$ npm ls
2b@1.0.0 /private/tmp/b
3├── cookie-parser@1.4.6
4├── express@4.18.2
5├── node-serialize@0.0.4
6└── serialize-javascript@6.0.1

Analysons-le ensuite avec le package npm gratuit snyk :

1$ snyk test
2
3Testing /private/tmp/b...
4
5Tested 62 dependencies for known issues, found 1 issue, 1 vulnerable path.
6
7Issues with no direct upgrade or patch:
8  ✗ Arbitrary Code Execution [Critical Severity][https://security.snyk.io/vuln/npm:node-serialize:20170208] in node-serialize@0.0.4
9    introduced by node-serialize@0.0.4
10  No upgrade or patch available
11
12Organization:      lirantal
13Package manager:   npm
14Target file:       package-lock.json

Cela montre que le package npm node-serialize est vulnérable, comme nous l’avons démontré dans cet article, et qu’aucune vulnérabilité de sécurité publiquement connue n’affecte le package npm serialize-javascript recommandé.

Nous vous recommandons vivement de commencer à utiliser Snyk Open Source et d’intégrer le package npm snyk à votre workflow de développement habituel. Pensez à l’ajouter à votre pipeline CI/CD pour éviter l’introduction de nouvelles vulnérabilités de sécurité.

Bonnes pratiques pour éviter les vulnérabilités de désérialisation

La désérialisation des entrées utilisateur peut permettre à des acteurs malveillants d’attaquer un système et d’exposer des données sensibles. Le meilleur moyen de se protéger contre la désérialisation non sécurisée est d’éviter de désérialiser des données provenant de sources non fiables. Si nous devons désérialiser des données, nous devrions mettre en place des mesures de sécurité supplémentaires pour vérifier qu’elles n’ont pas été manipulées.

Nous devrions également assainir les entrées. Pour cela, nous pouvons vérifier si l’objet à sérialiser contient des fonctions et interrompre la sérialisation si c’est le cas.

Désérialisation sécurisée

La sérialisation et la désérialisation sont des processus essentiels qui permettent de transférer facilement des données sur un réseau. Cependant, une désérialisation non sécurisée peut entraîner des vulnérabilités critiques. En injectant des objets sérialisés malveillants dans une application web, généralement sous la forme de données fournies par l’utilisateur puis désérialisées, les attaquants peuvent transmettre des données nuisibles à une application. Ils peuvent ensuite lancer une attaque par injection, exécuter du code à distance ou déclencher une attaque DDoS.

Nous pouvons prévenir les attaques liées à cette vulnérabilité en évitant simplement de désérialiser les entrées utilisateur. Si la désérialisation est nécessaire, nous devrions ajouter des mécanismes de sécurité, tels que des jetons anti-contrefaçon, pour garantir que les données n’ont pas été modifiées.

Consultez le blog de Snyk pour en savoir plus sur la prévention des vulnérabilités de sérialisation et de désérialisation non sécurisées en Java.

Pour protéger votre code contre les vulnérabilités de sérialisation et de désérialisation non sécurisées, ajoutez le plugin Snyk.io à votre IDE.