Pourquoi JSON.stringify n'est pas aussi inoffensif qu'il y paraît
Les développeurs utilisent JSON.stringify quotidiennement pour sérialiser des données, envoyer des objets, stocker l'état dans des fichiers ou conserver des configurations. Cependant, cet appel apparemment anodin à JSON.stringify peut entraîner une désérialisation non sécurisée si les données sont réintégrées ultérieurement sans validation.
Le problème ne vient pas de JSON.stringify lui-même, mais de son utilisation abusive. Lorsque l'on sérialise des objets complexes (notamment avec des prototypes ou des instances de classe) et que l'on les désérialise ensuite aveuglément en utilisant JSON.analyser, vous risquez de donner vie à des charges utiles malveillantes dans votre application.
En JavaScript, il est facile de supposer que ce qui est sérialisé est sûr car c'est « juste JSON.” Mais JSON est une donnée, pas une logique. Si des attaquants contrôlent ces données, ils peuvent exploiter les limites de confiance de votre code. C'est là que commence la désérialisation non sécurisée.
Erreurs courantes des développeurs qui permettent une désérialisation non sécurisée
La désérialisation non sécurisée découle généralement d'habitudes qui semblent anodines lors des revues de code. Mais lorsque JSON.stringify est utilisé sans précaution, la surface d'attaque s'étend.
Pratique dangereuse : sérialisation des entrées utilisateur non validées
⚠️Mise en garde: Ce modèle sérialise les entrées contrôlées par l'attaquant sans aucune validation. Il peut entraîner une désérialisation non sécurisée si les données sont ultérieurement approuvées.
// Node.js example
const userData = req.body; // attacker-controlled
fs.writeFileSync('userdata.json', JSON.stringify(userData));
⚠️Mise en garde: La désérialisation des mêmes données sans validation peut réintroduire la charge utile dans votre application.
const input = JSON.parse(fs.readFileSync('userdata.json'));
doSomething(input); // Trusting it blindly
Modèle dangereux : réutilisation de JSON au-delà des limites de confiance
Le JSON sérialisé créé dans un service (environnement de développement) est réutilisé dans un autre (environnement de production), sans validation. Ce phénomène se produit souvent dans les outils internes ou les microservices.
Exemple Python de risque silencieux :
⚠️Mise en garde: Les étapes de sérialisation et de désérialisation ci-dessous gèrent les données potentiellement non fiables sans validation.
import json
def save_user_input(data):
with open('input.json', 'w') as f:
f.write(json.dumps(data))
def process_input():
with open('input.json') as f:
data = json.loads(f.read())
execute_logic(data) # Dangerous if data structure is assumed
Les deux exemples sérialisent et désérialisent les données contrôlées par l'utilisateur sans appliquer de schéma. Ceci constitue un terrain propice aux exploits de désérialisation non sécurisée déclenchés par une utilisation imprudente de JSON.
Risques réels dans Pipelines: Du code à CI/CD Flux de désérialisation
Maintenant, prenez ce comportement dans un pipeline. Lorsque JSON.stringify est mal utilisé dans CI/CD En utilisant des workflows, vous exposez votre processus de build à des risques de désérialisation non sécurisée. Cela se produit souvent avec les métadonnées d'artefacts, les structures de test et les instantanés de configuration.
Commun CI/CD pièges:
- Génération d'artefacts non sécurisée : les artefacts de build incluent des objets sérialisés qui sont réutilisés dans plusieurs tâches sans validation.
- Variables d'environnement sérialisées : les équipes stockent les variables d'environnement sous forme de JSON sérialisé et les réutilisent dans plusieurs étapes, voire plusieurs projets.
- Données de test injectées : données de test désérialisées provenant de données non fiables commits ou branches exécutées sans vérification de type.
Ces modèles permettent aux attaquants d'injecter facilement des charges utiles dans des fichiers de confiance. pipelines en utilisant une logique de chaîne JSON manipulée.
⚠️Mise en garde:Ce workflow transmet des données sérialisées sans validation. Si test-runner.js ne valide pas les entrées, il risque une désérialisation non sécurisée.
# YAML example in GitHub Actions
steps:
- name: Load test data
run: |
echo '${{ secrets.TEST_JSON }}' > test.json
node test-runner.js test.jsonIf test-runner.js charge et analyse JSON sans validation, cela peut déclencher une désérialisation non sécurisée.
Sécurisation de JSON.stringify avec validation et analyse sécurisée
La solution ne consiste pas à éviter JSON.stringify, mais à l'utiliser avec prudence et à appliquer des contrôles de sécurité cohérents. Correctement utilisé, il est sûr, mais dans les environnements modernes. pipelines, les hypothèses se brisent rapidement.
Pratiques DevSecOps pour sécuriser JSON.stringify:
- Utilisez des schémas JSON pour valider les données sérialisées et désérialisées.
- Appliquez un typage strict, évitez le typage canard ou les hypothèses sur les formes des objets.
- Utilisez des bibliothèques d’analyse sécurisées qui prennent en charge l’application de schéma ou les protections de type.
- Traitez les données sérialisées comme non fiables, même si elles proviennent d’un référentiel fiable.
- Instrument pipelines pour détecter rapidement les modèles JSON.stringify risqués.
Bonne pratique : Cet exemple utilise la validation du schéma JSON pour éviter toute désérialisation non sécurisée. Exemple d'utilisation ajv dans Node.js :
const Ajv = require("ajv");
const ajv = new Ajv();
const schema = { type: "object", properties: { id: { type: "number" } }, required: ["id"] };
const validate = ajv.compile(schema);
const input = JSON.parse(fs.readFileSync('input.json'));
if (!validate(input)) throw new Error("Invalid input");
La désérialisation sécurisée signifie valider avant Confiant. Ne vous fiez pas à JSON. Les valeurs par défaut de Stringify garantissent votre sécurité ; définissez ce à quoi ressemble la sécurité.
Détection des risques de sérialisation avec Xygeni
L'audit manuel ne permet pas de détecter grand-chose. Xygéni apporte une visibilité sur la façon dont JSON.stringify est utilisé dans votre base de code et pipelines.
Ce que fait Xygeni :
- Traces JSON.stringify utilisation du code source au déploiement.
- Détecte les flux de désérialisation non sécurisés, en particulier dans les microservices et pipeline étapes.
- Sérialisation des données non sécurisées telles que les variables d'environnement, les entrées utilisateur ou les artefacts.
- Alertes sur les écarts de modèle, indiquant quand les données sérialisées changent de forme ou franchissent les limites de confiance.
Ce type de visibilité est essentiel pour gérer les risques de désérialisation non sécurisée introduits par JSON.stringify, en particulier dans CI/CD systèmes dans lesquels les données sérialisées se déplacent rapidement et silencieusement.
Sécurisation de JSON.stringify : votre bouclier contre la désérialisation non sécurisée
JSON.stringify n'est pas non plus non sécurisé en soi. Cependant, utilisé sans précaution, il devient la porte d'entrée vers une désérialisation non sécurisée.
Si vous êtes un développeur travaillant avec JSON :
- Auditez votre utilisation de celui-ci à travers les services, pipelines, et outils.
- Traitez les données désérialisées comme non fiables.
- Appliquez la validation de schéma, appliquez les types et intégrez la sécurité dans votre CI/CD.
Et ne vous arrêtez pas aux meilleures pratiques, utilisez Xygeni pour tracer, détecter et arrêter les risques de désérialisation non sécurisée avant qu'ils n'atteignent la production. La sérialisation n'est pas neutre. Faites en sorte que votre utilisation JSON.stringify garantir.
