Votre paramètre Json.Net `TypeNameHandling` (Auto) est-il vulnérable aux attaques de données JSON externes ?

Les données JSON externes peuvent-elles constituer une menace avec Json.Net TypeNameHandling défini sur Auto ?

Dans la désérialisation JSON, le paramètre TypeNameHandling de Json. Net joue un rôle crucial dans l’atténuation des menaces potentielles. Cependant, des inquiétudes subsistent concernant la sécurité de l'utilisation de ce paramètre avec les données JSON fournies par l'utilisateur. Examinons le problème et explorons les risques et précautions potentiels.

Les vulnérabilités de TypeNameHandling

Les charges utiles JSON externes peuvent être manipulées pour contenir des propriétés "$type" qui spécifient types pour la désérialisation. Si ces types ne sont pas soigneusement validés, les attaquants peuvent les exploiter pour instancier des objets malveillants appelés « gadgets d'attaque ». Ces gadgets peuvent exécuter des actions malveillantes, telles que l'exécution de code à distance (RCE) ou la manipulation du système de fichiers.

Mesures de protection

Json.Net a mis en place des mesures de protection pour empêcher de telles attaques :

• Ignorance des propriétés inconnues : Il ignore les propriétés inconnues, rendant les charges utiles JSON avec des propriétés "$type" étrangères inoffensives.
• Compatibilité de sérialisation : Lors de la désérialisation de valeur polymorphe, il vérifie si le type résolu correspond à celui attendu. Dans le cas contraire, une exception est levée.

Filles potentielles

Malgré ces mesures, il existe certaines situations dans lesquelles un gadget d'attaque peut encore être construit, même dans l'absence de membres évidents non typés :

• Collections non typées : La désérialisation de collections de types inconnus, telles que ArrayList, List
• Collections semi-typées : Désérialisation de collections dérivées de CollectionBase , qui prennent en charge la validation du type d'exécution, peuvent créer une fenêtre pour la construction de gadgets.
• Base partagée Types : Les membres polymorphes déclarés comme interfaces ou types de base partagés par des gadgets d'attaque (par exemple, ICollection, IDisposable) peuvent introduire des vulnérabilités.
• Interface ISerializing : Les types implémentant ISerializing peuvent involontairement désérialiser des éléments non typés. membres, les exposant à attaque.
• Sérialisation conditionnelle :Les membres marqués comme non sérialisés dans ShouldSerializeAttribute peuvent toujours être désérialisés s'ils sont présents dans la charge utile JSON.

Recommandations

Pour minimiser les risques, tenez compte des recommandations suivantes :

• Valider les types inconnus : Implémentez un SerializationBinder personnalisé pour vérifier les types sérialisés entrants et rejeter ceux non autorisés.
• Évitez les membres non typés : Assurez-vous que vos données le modèle ne contient pas de membres de type objet, dynamique ou autre potentiellement exploitable types.
• Définissez DefaultContractResolver : Envisagez de définir DefaultContractResolver.IgnoreSerializingInterface et DefaultContractResolver.IgnoreSerializingAttribute sur true.
• Code de révision pour les membres non sérialisés : Vérifier que les membres marqués comme non sérialisés ne sont pas désérialisées dans des situations inattendues.

En adhérant à ces bonnes pratiques, vous pouvez réduire considérablement la probabilité que des données JSON externes compromettent votre système grâce à Json.Net TypeNameHandling défini sur Auto.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!