🧨 JSON Jamboree – Quand un fichier bien formé devient une arme


🌞 Le cahier de vacances des parseurs

Après l’épisode XML piégé, place à son cousin moderne : JSON.
Léger, pratique, adoré des devs… mais sous ses airs cool, il peut faire tomber un ERP, saturer un serveur Cloud, ou corrompre des données critiques.

C’est l’été, les parasols sont de sortie, et les ERP dorment paisiblement…
Mais chez SecuSlice, on révise nos classiques de la sécurité.

💡 Spoiler :

  • Pas de DTD ? Pas grave.
  • Pas de balises ? Pas grave non plus.
  • Avec un JSON bien foireux, on peut quand même mettre à genoux un parseur ou pousser un ERP dans ses retranchements.

🎯 Punchline SecuSlice

“Le JSON, c’est comme la glace italienne : tout le monde l’adore…
mais si tu laisses fondre sur ton serveur, ça fait un beau carnage.”
🍦💥


⚠️ Avertissement SecuSlice :
Encore une fois, les techniques et payloads présentés dans cet article sont destinés uniquement à un usage pédagogique et en laboratoire.
Ne testez jamais ces attaques sur un environnement de production ou un système dont vous n’êtes pas responsable.
L’exploitation non autorisée de ces techniques est illégale et peut entraîner des poursuites pénales.

1️⃣ Environnement & Contexte 🌐

🛒 Flux fonctionnel

Le scénario reste proche de celui de notre épisode XML :

  1. Site marchand génère un fichier JSON contenant la liste des commandes confirmées
  2. Dépôt automatique du JSON dans un répertoire d’échange partagé
  3. ERP lit le fichier, met à jour les statuts de commandes, et déclenche la facturation

Exemple JSON normal :

json
{
  "commandes": [
    {
      "id": "CMD12345",
      "client": "Durand",
      "montant": 250.00,
      "statut": "Confirmée"
    }
  ]
}

💡 A priori, tout va bien : le fichier est simple, lisible, et le traitement ERP se déroule sans problème.


🏗️ Infrastructure & Plateformes

L’environnement multi-stack hébergeant ce flux JSON est le même que pour XML, et chaque stack a ses propres points faibles :

  1. 💻 Windows (ERP .NET / C#)
    • Lecture du JSON avec Newtonsoft.Json ou System.Text.Json
    • Fichiers posés sur un partage SMB
  2. 🐧 Linux (PHP / Python / Middleware)
    • Parsing avec json_decode() ou json.loads()
    • Souvent aucune limite de taille ni de profondeur
  3. ☁️ Cloud (AWS / Azure / GCP)
    • Fichiers dans S3 / Blob Storage
    • Traitement via Lambda / Functions / App Service
  4. 🏢 IBM i (AS/400)
    • JSON traité par des jobs RPG/COBOL ou via PASE
    • Parseurs basics souvent sans gestion d’erreurs évoluée
  5. 🌐 Web (Node.js / Express / Python)
    • JSON reçu via API REST ou webhook
    • Vulnérable aux DoS mémoire si JSON volumineux
  6. ☕ Java (Spring, Tomcat, WebLogic)
    • Désérialisation JSON via Jackson / Gson
    • Surface de risque RCE si désérialisation non contrôlée

🎯 Surface d’attaque JSON

Contrairement à XML :

  • ❌ Pas de DTD ni XXE
  • ✅ Mais 3 risques majeurs :
  1. 📈 DoS mémoire (Billion Nesting)
    • Profondeur récursive → saturation CPU/RAM
  2. 💀 Désérialisation dangereuse
    • Jackson / Gson / Fastjson → exécution de code ou RCE
  3. 🎲 Injection logique & corruption
    • Valeurs extrêmes, types inattendus → overflow, crash ERP, calculs faussés

💡 Retex SecuSlice :

Un fichier JSON malveillant est souvent plus discret qu’un XML piégé :
Pas de balises suspectes, facile à injecter, et les parseurs l’avalent sans broncher… jusqu’au crash. 💥


2️⃣ Scénario d’attaque n°1 – JSON piégé “simple” 🐣

2.1. Flux normal

Voici un exemple de JSON sain, généré par le site marchand :

json
{
  "commandes": [
    {
      "id": "CMD12345",
      "client": "Durand",
      "montant": 250.00,
      "statut": "Confirmée"
    }
  ]
}

Comportement ERP :

  • ✅ Lecture → ✅ Mise à jour du statut → ✅ Facturation → ✅ Archive du fichier

2.2. JSON piégé n°1 : Billion Nesting (DoS mémoire)

Un attaquant remplace le fichier par un JSON profondément imbriqué :

json
{
  "commande": {
    "sub1": {
      "sub2": {
        "sub3": {
          "sub4": {
            "sub5": {
              "sub6": {
                "sub7": {
                  "sub8": {}
                }
              }
            }
          }
        }
      }
    }
  }
}

💥 Effet concret :

  • Le parseur tente de lire récursivement toutes les clés
  • Sur des parseurs non protégés (Node.js, Python, PHP), la pile exploseERP planté
  • Variante : fichiers de plusieurs centaines de MoDoS disque/mémoire

2.3. JSON piégé n°2 : Valeurs extrêmes / Overflow

Autre méthode pour casser le traitement ERP :

  • Injecter des valeurs numériques massives
  • Ou des types inattendus pour casser la logique

Exemple :

json
{
  "commandes": [
    {
      "id": "CMD99999",
      "client": "Dupont",
      "montant": 999999999999999999999999999999,
      "statut": true
    }
  ]
}

💥 Effet concret :

  • Le montant provoque un overflow si l’ERP stocke en int32 ou float limité
  • Le champ statut de type booléen peut casser un mapping attendu en string
  • Résultat :
    1. Erreur de parsing JSON
    2. Blocage du job ERP ou rollback des traitements

2.4. Impact concret sur l’ERP

  • Blocage immédiat ou crash silencieux
  • Files d’attente saturées si le job retente en boucle
  • Perte ou corruption de données si l’ERP écrit en base partiellement
  • Pas d’alerte si aucun monitoring sur parsing JSON

Retex SecuSlice :

“Un JSON bien foireux peut suffire à planter un ERP, sans exploit complexe, juste en jouant sur la taille et la structure.”


3️⃣ Scénario d’attaque n°2 – Désérialisation & Injection logique 🎯

3.1 Objectif de l’attaquant

Un fichier JSON piégé peut servir à :

  1. 📤 Exfiltrer ou manipuler des données dans l’ERP
  2. 💀 Déclencher une exécution de code (RCE) via désérialisation dangereuse
  3. 🎲 Modifier la logique métier pour détourner le workflow (commandes, statuts)

3.2 Exemple 1 – Désérialisation Java (RCE) ☕

Si l’ERP ou le middleware en Java utilise Jackson ou Gson pour convertir JSON → Objet :

json
{
  "@class": "java.lang.ProcessBuilder",
  "command": ["calc.exe"]
}

💥 Effet concret :

  • Si la désérialisation polymorphique est activée :
    • Jackson instancie ProcessBuilder
    • Et exécute la commande → RCE sur le serveur ERP
  • Cas réels : CVE-2017-7525 (Jackson) et Fastjson ≤1.2.68

3.3 Exemple 2 – Désérialisation PHP / Python

  • PHP : si le JSON est converti en objet puis passé à unserialize()
  • Python : avec pickle après un json.loads() mal géré

Payload conceptuel :

json
{
  "malice": "__import__('os').system('touch /tmp/pwned')"
}

💥 Effet concret :

  • Exécution de commandes côté serveur
  • Persistance si l’attaquant dépose un webshell ou un binaire

3.4 Exemple 3 – Injection logique métier 🎲

Au-delà du RCE, JSON permet de fausser les traitements ERP :

json
{
  "commandes": [
    {
      "id": "CMD1337",
      "client": "Inconnu",
      "montant": 0,
      "statut": "Livrée",
      "droits": ["admin", "superuser"]
    }
  ]
}

💥 Effet concret :

  • Si l’ERP fait confiance au JSON :
    1. La commande passe à Livrée sans facturation
    2. Les champs inattendus (droits) peuvent être interprétés par erreur
    3. Risque de fraude ou altération de données si non filtré

3.5 Kill Chain SecuSlice 🔗

Attaquant
    ↓
JSON piégé (RCE ou injection)
    ↓
ERP parse et désérialise
    ↓
→ Crash ou DoS
→ RCE (prise de contrôle serveur)
→ Détournement logique (statuts / données)

Retex SecuSlice :

“Avec JSON, on passe facilement du bug rigolo au pentest qui ouvre un shell.
Les parseurs sont permissifs… et les devs souvent trop confiants.”


4️⃣ Analyse multi-plateformes & Faiblesses 🔍


💻 Windows (.NET / ERP C#)

⚡ Points faibles JSON :

  • Désérialisation avec Newtonsoft.Json ou System.Text.Json
  • TypeNameHandling ou dynamic → RCE si mal configuré
  • Overflow possible sur des int ou decimal en parsing

💥 Impact concret :

  • RCE si désérialisation polymorphique activée
  • Blocage ERP avec JSON gigantesque (DoS mémoire)
  • Logs Event Viewer saturés si parsing en boucle

🐧 Linux (PHP / Python / Middleware)

⚡ Points faibles JSON :

  • PHP : json_decode() renvoie un objet → risque si passé à unserialize()
  • Python : json.loads() puis usage avec eval ou pickle derrière = porte ouverte
  • JSON volumineux = DoS CPU/RAM sur scripts non optimisés

💥 Impact concret :

  • RCE par injection de code si mauvaises pratiques
  • DoS silencieux sur job cron ou ETL
  • Corruption partielle de données ERP

☁️ Cloud (AWS / Azure / GCP)

⚡ Points faibles JSON :

  • Parsing via Lambda / Functions / App Service
  • JSON imbriqué profond = consommation CPU/RAMDoS économique
  • Accès à d’autres services Cloud si désérialisation dangereuse

💥 Impact concret :

  • Timeout des Functions → traitements perdus
  • Facture Cloud qui explose 💸
  • Possibilité de pivot vers d’autres API Cloud internes

🏢 IBM i (AS/400)

⚡ Points faibles JSON :

  • Parsing basique via QSYS2.JSON_TABLE ou libs RPG
  • Très peu de gestion d’erreurs avancée
  • Overflow ou JSON mal formé = job planté

💥 Impact concret :

  • Job RPG/COBOL arrêté → file d’attente bloquée
  • Crash silencieux nécessitant intervention manuelle
  • Risque de perte de commandes si batch interrompu

🌐 Web (Node.js / Python / PHP)

⚡ Points faibles JSON :

  • Node.js / express.json() vulnérable aux gros payloads
  • Pas de limitation de taille → JSON bomb
  • Risque injection logique sur API REST si absence de validation

💥 Impact concret :

  • Site e-commerce ou API saturée
  • Possibilité de bypass authentification via JSON mal formé
  • Logs web qui explosent → invisibilité du bug réel

☕ Java (Spring / Tomcat / WebLogic)

⚡ Points faibles JSON :

  • Jackson / Gson / Fastjson vulnérables à la désérialisation RCE
  • JSON profond = OOM JVM (OutOfMemoryError)
  • Injection logique si mappage automatique vers objets sensibles

💥 Impact concret :

  • RCE serveur → accès complet SI
  • Crash JVM → ERP indisponible
  • Corruption des données métier si JSON non validé

Vue multi-plateformes & Faiblesses JSON 🔍

🖥️ Plateforme⚔️ Vecteur d’attaque💥 Impact
💻 Windows (.NET / ERP)Désérialisation JSON dangereuse + JSON Bomb (DoS)RCE serveur + blocage ERP
🐧 Linux (PHP / Python / Middleware)JSON volumineux ou profond + injection logiqueDoS CPU/RAM + corruption données ERP
☁️ Cloud (AWS / Azure / GCP)JSON bomb via Lambda/Functions + DoS économiqueTimeouts + surcoût Cloud 💸
🏢 IBM i (AS/400)JSON mal formé ou overflow numériqueJob RPG/COBOL planté + perte de commandes
🌐 Web (Node.js / Python / PHP)JSON bomb + injection logique API RESTDoS site/API + altération des flux
Java (Spring / Tomcat / WebLogic)Désérialisation Jackson/Gson + JSON profondRCE serveur + crash JVM (OOM)

💡 Analyse SecuSlice :

“Le JSON a l’air plus simple que XML… mais il casse plus vite les parseurs Cloud et ouvre la porte aux RCE côté serveur.”
Les stack Windows et Java sont les plus à risque pour la désérialisation,
alors que Cloud et Web sont les champions du DoS silencieux.


6️⃣ Point de situation & Conclusion SecuSlice 📊


🕰️ Historique

Les attaques par fichier piégé sont des classiques intemporels :

  • XML : XXE, Billion Laughs, injection DTD → connus depuis +15 ans
  • JSON : plus récent, mais amplifié par l’essor des APIs REST et microservices

Elles ont en commun :

  • La confiance aveugle dans un fichier d’intégration
  • L’absence de validation stricte
  • Le parseur qui avale tout… jusqu’au crash ou à l’exploit 😏

⚡ Situation actuelle

Bonne nouvelle : en 2025, beaucoup de stacks modernes limitent le risque :

  • Frameworks récents plus sécurisés par défaut
    • PHP 8 désactive XXE et impose exceptions en parsing JSON
    • Node.js limite taille des payloads
    • Jackson & Gson patchés pour désérialisation RCE
  • API Gateway / WAF filtrent déjà les payloads trop gros
  • DevSecOps / CI-CD intègrent des tests de parsing sécurisé

Mais la réalité terrain SecuSlice :

  • 🏚️ ERP legacy + jobs batch = surface d’attaque intacte
  • 📝 Scripts maison sans limite de taille/profondeur = vulnérabilité persistante
  • ☁️ Cloud → un JSON bomb peut encore provoquer un DoS économique silencieux

🎯 Conclusion pédagogique

  • Les attaques XML / JSON piégées sont moins visibles mais toujours possibles
  • Le vrai risque en 2025 :
    • Désérialisation dangereuse → RCE côté serveur
    • DoS silencieux sur Cloud ou microservices
    • Injection logique dans les ERP qui font encore “confiance” aux fichiers entrants

💡 Punchline finale SecuSlice

“Même en 2025, un seul fichier JSON malveillant peut réveiller les fantômes de 2010…
Testez en lab, surveillez vos flux, et rappelez à vos parseurs qui est le patron !”
💥

🧨 JSON Jamboree – Quand un fichier bien formé devient une arme
Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Retour en haut