Qu’est-ce que l’injection JSON ?

L’injection JSON est une vulnérabilité qui permet à un pirate malveillant d’injecter des données malveillantes dans des flux JSON ou d’utiliser des flux JSON malveillants pour modifier le comportement de l’application. Il existe deux types d’injections JSON, côté serveur et côté client :

  • L’injection JSON côté serveur se produit lorsque les données provenant d’une source non fiable ne sont pas nettoyées par le serveur et sont écrites directement dans un flux JSON.
  • L’injection JSON côté client se produit lorsque les données d’une source JSON non approuvée ne sont pas filtrées et sont analysées directement à l’aide de la fonction JavaScript eval .

Gravité: sévérité moyenne
Prévalence: découvert rarement
Portée: peut apparaître dans toutes les applications qui utilisent JSON
Impact technique : élévation de privilèges, scripts intersites
Conséquences dans le pire des cas : compromis complet du système
Solution rapide: nettoyer l’entrée de l’utilisateur, ne pas utiliser la fonction d’évaluation JS

Qu’est-ce que JSON ?

JSON (JavaScript Object Notation) est un format d’échange de données léger utilisé pour la communication entre les applications. Il joue un rôle similaire à XML mais est plus simple et mieux adapté au traitement en JavaScript.

De nombreuses applications Web utilisent ce format pour communiquer et sérialiser/désérialiser des données. Certaines applications Web utilisent également JSON pour stocker des informations importantes, telles que les données utilisateur. JSON est couramment utilisé dans les API RESTful et les applications AJAX.

Qu’est-ce que le piratage JSON ?

Alors que le piratage JSON (un sous-ensemble de l’inclusion de script intersite – XSSI) implique également le format JSON, il s’agit d’une attaque légèrement différente, à certains égards similaire à la falsification de requête intersite (CSRF ) . Les attaquants peuvent utiliser le piratage JSON pour intercepter les données JSON envoyées d’un serveur Web à une application Web. Une attaque de piratage JSON typique pourrait ressembler à ceci :

  1. L’attaquant crée un site Web malveillant contenant une balise de script qui fait référence à une URL de données JSON de l’application Web attaquée et inclut un code pour détourner les données JSON.
  2. Un utilisateur connecté à l’application Web ciblée est amené à visiter le site Web malveillant (généralement en utilisant l’ingénierie sociale).
  3. Étant donné que la politique de même origine (SOP) permet à JavaScript de n’importe quel site Web d’être inclus et exécuté dans le contexte de tout autre site, le navigateur Web de l’utilisateur charge les données JSON dans le contexte du site malveillant.
  4. Le site Web malveillant détourne les données JSON.

Exemple d’attaque par injection JSON côté serveur

Une simple injection JSON côté serveur peut être effectuée en PHP comme suit :

  1. Le serveur stocke les données utilisateur sous forme de chaîne JSON, y compris le type de compte.
  2. Les valeurs de nom d’utilisateur et de mot de passe sont extraites directement des paramètres d’entrée de l’utilisateur sans validation ni nettoyage.
  3. La chaîne JSON est construite à l’aide d’une concaténation simple :
$json_string = '{"accountType":"user","userName":"'.$_GET['userName'].'","pass":"'.$_GET['pass'].'"}';
 
  1. Un utilisateur malveillant ajoute des données à son nom d’utilisateur saisi dans un formulaire de saisie ou livré dans un en-tête HTTP. Ces données sont envoyées au back-end sans être nettoyées :
jean%22,%22typedecompte%22 :%22administrateur%22
  1. La chaîne JSON résultante stockée par le back-end de l’application est :
{
  "accountType":"user",
  "userName":"john",
  "accountType":"administrator",
  "pass":"password"
}
 
  1. Lors de la lecture de la chaîne stockée, l’analyseur JSON ( json_decode ) rencontre deux entrées accountType et accepte la dernière, accordant à john des privilèges d’administrateur sans aucune authentification. Notez que, à proprement parler, le comportement de json_decode n’est pas incorrect – RFC-7159 pour le format JSON stipule que « les noms dans un objet DEVRAIENT être uniques » mais pas qu’ils doivent être uniques, laissant une certaine marge d’interprétation.

Exemple d’attaque par injection JSON côté client

Une simple injection JSON côté client peut être effectuée comme suit :

  1. La chaîne JSON initiale est la même que dans l’exemple précédent.
  2. Le serveur obtient les données JSON, y compris une charge utile malveillante, à partir d’une source non fiable et ne les nettoie pas.
  3. Le client analyse la chaîne JSON à l’aide de eval :
var result = eval("(" + json_string + ")");
document.getElementById("#accountType").innerText = result.account;
document.getElementById("#userName").innerText = result.name; 
document.getElementById("#pass").innerText = result.pass;
 
  1. La valeur accountType injectée par l’attaquant est :
utilisateur"});alert(document.cookie);({"accountType":"utilisateur
  1. La fonction eval exécute l’ appel d’alerte .
  2. L’analyse de la chaîne malveillante entraîne une attaque de script intersite (XSS) ( document.cookie est divulgué).

Conséquences potentielles d’une attaque par injection JSON

Les conséquences de l’injection JSON dépendent fortement de la manière dont les données JSON sont utilisées par l’application Web. Cependant, dans certains cas, ils peuvent être assez graves :

  • Si JSON est utilisé pour stocker des données d’authentification et que l’application est sensible à l’injection JSON côté serveur, l’attaquant peut accéder à un compte administratif dans l’application. Selon les privilèges de ce compte administratif, ils pourraient alors obtenir des données hautement sensibles ou effectuer des actions malveillantes.
  • Si une application Web est vulnérable à l’injection JSON côté client, elle peut être utilisée pour des attaques qui impliquent XSS réfléchi , par exemple, dans des campagnes de phishing ou de spam.

Bien que l’injection de JSON en soi puisse ne pas sembler très dangereuse, il ne s’agit souvent que d’une étape dans une chaîne d’attaques plus longue, de sorte que dans certains cas, elle peut avoir de graves conséquences, pouvant aller jusqu’à la compromission complète du système.

Comment détecter les vulnérabilités d’injection JSON ?

La meilleure façon de détecter les vulnérabilités d’injection JSON varie selon qu’elles sont déjà connues ou inconnues.

  • Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, il peut suffire d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est sensible à l’injection JSON, vous pouvez supposer que votre logiciel est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) pour les applications Web ou un analyseur de réseau pour les systèmes et applications en réseau.
  • Si vous développez votre propre logiciel ou souhaitez avoir la possibilité de trouver des vulnérabilités d’injection JSON jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité d’injection JSON pour être certain qu’elle existe. Cela nécessite soit d’effectuer un pentesting manuel avec l’aide de chercheurs en sécurité, soit d’utiliser un outil d’analyse des vulnérabilités qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités d’injection JSON dans les applications Web ?

Comme pour la plupart des vulnérabilités, la clé pour maintenir la sécurité des applications Web et empêcher les injections JSON est de nettoyer les données. Cela s’applique aux injections JSON côté serveur et côté client.

Pour empêcher les injections JSON côté serveur, nettoyez toutes les données avant de les sérialiser en JSON. Par exemple, si vous utilisez Java, une bonne option pour nettoyer les données JSON consiste à utiliser le OWASP JSON Sanitizer disponible sur GitHub . Une pratique encore meilleure consiste à ne jamais écrire de données JSON manuellement, mais toujours à utiliser des fonctions d’infrastructure qui effectuent la désinfection.

La meilleure façon d’empêcher les injections JSON côté client est de ne jamais utiliser la fonction eval pour évaluer les données JSON. Chaque fois que vous utilisez la fonction eval avec des données non fiables contenant du code JavaScript, ce code sera exécuté – et il pourrait être malveillant. Pour éliminer ce risque, utilisez plutôt JSON.parse .

Comment atténuer les attaques par injection JSON ?

  • La seule façon d’éviter les graves conséquences des injections JSON côté serveur, en plus de les rechercher au début du cycle de développement, est de concevoir des applications de manière à ce qu’elles ne chargent pas d’informations sensibles, telles que des informations de compte et des privilèges, à partir de données contrôlées par l’utilisateur ou données JSON autrement non fiables.
  • Vous pouvez éliminer complètement le risque d’injections JSON côté client en appliquant la politique de sécurité du contenu , qui empêche par défaut l’utilisation de eval . Cela oblige les développeurs à utiliser la méthode JSON.parse plus sûre à la place.

Les attaques par injection JSON se produisent lorsque des données JSON non épurées contenant une charge utile malveillante sont acceptées et analysées par une application Web ou un navigateur. Les attaques par injection JSON côté serveur sont possibles si les données d’entrée ne sont pas filtrées par le serveur et sont écrites directement dans un flux JSON. Les attaques par injection JSON côté client sont possibles si les données JSON entrantes ne sont pas filtrées et sont analysées directement à l’aide de la fonction JavaScript eval.

Le piratage JSON se produit lorsqu’une page Web malveillante amène le navigateur Web de la victime à récupérer des données JSON à partir d’une application Web ciblée. Le navigateur Web transmet ensuite les données JSON à un serveur Web contrôlé par l’attaquant.

Les injections JSON ne sont pas très courantes et moins dangereuses que l’injection SQL ou d’autres vulnérabilités graves, mais elles peuvent toujours être utilisées dans des chaînes d’attaque qui conduisent à d’autres attaques plus dangereuses, telles que les scripts intersites (XSS).

ClassificationIDENTIFIANT
CAPEC153
CWE74, 116
WASC20
OWASP 2021A3
{"cpt":"service","style":"9","columns":"3","show":"6","order":"DESC","orderby":"DESC"}

Nos Services en Cybersécurité

Protégez-vous maintenant !

Forfait Évaluation de la surface d’attaque

La cible de cette évaluation de la surface d’attaque est les ressources réseau, les systèmes et les terminaux. Il n’y a pas de ciblage des membres ou des employés des organisations à des fins d’ingénierie sociale.

Forfait Évaluation de la vulnérabilité

Nous sommes en mesure de fournir des évaluations de vulnérabilité des applications web , des serveurs connectés à Internet et des gammes de réseaux connectés à Internet .

Analyse de vulnérabilité

Cycuri propose des analyses de vulnérabilité ponctuelles ou régulières de votre périmètre externe, de vos applications Web ou de votre réseau interne.

Forfait Évaluation WordPress

Nos services d’évaluation WordPress professionnelle sont populaires auprès de tous ceux qui souhaitent un examen par un tiers indépendant de leur posture de sécurité.

Test d’intrusion d’application Web

Que votre application Web soit destinée aux employés, B2B ou B2C, il existe un niveau de confiance inhérent qui est supposé lorsque les utilisateurs sont autorisés à entrer, naviguer et utiliser des applications et/ou des portails d’applications.

Test d’intrusion Black-Box externe

Un test d’intrusion externe Black-Box imite les actions d’un adversaire réel en tentant d’exploiter les faiblesses de la sécurité du réseau sans les dangers d’une menace réelle.

Injection JSON