J'ai regardé à travers beaucoup de messages et n'ai pas réussi à déterminer comment se débarrasser de la satanée d dans la réponse provenant de mon service web asmx, comme dans {"d": { "Réponse": "OK", "Auth-Key": "JKPYZFZU"}}.json asmx et que diablotin d:
Ceci est créé par ma classe 'public Dictionary UserDevice' en retournant l'objet Dictionary.
Je serais parfaitement heureux si la foutue chose ne voulait tout simplement pas tout mettre dans l'objet d!
Vous utilisez probablement un type d'infrastructure qui enveloppe automatiquement les réponses json de votre service Web avec l'élément d.
Je sais que le sérialiseur JSON de microsoft ajoute le d du côté serveur, et le code AJAX côté client qui désérialise la chaîne JSON s'attend à ce qu'il soit là.
Je pense que jQuery fonctionne de cette façon aussi.
Vous pouvez lire un peu plus à ce sujet à Rick Strahl's blog
Et il y a un moyen pour vous de revenir JSON pur (sans l'élément « d ») en utilisant le WCF "Raw" programming model.
Fondamentalement, la notation de tableau JSON ['hello'] valide JavaScript par lui-même alors que la notation d'objet JSON {'d': ['hello'] } n'est pas en soi JavaScript valide. Ceci a pour conséquence que la notation de tableau est exécutable ce qui ouvre la possibilité d'attaques XSS. Envelopper vos données dans un objet par défaut permet d'éviter cela.
Vous pouvez en savoir plus sur pourquoi il est là dans un post by Dave Ward. (modifier: comme l'a souligné @ user1334007, Chrome balises de ce site comme dangereux maintenant)
Un commentaire par Dave Reed sur cet article est particulièrement informe:
Il est l'une de ces fonctions de sécurité qui a un très facile à but mal compris. La protection n'est pas vraiment contre exécuter accidentellement l'alerte dans votre exemple. Bien que ce soit un avantage de 'd', vous devez toujours vous en préoccuper tout en évaluant le JSON pour le convertir en objet.
Ce qu'il fait est d'empêcher la réponse JSON d'être exécuté en gros à la suite d'une attaque XSS. Dans une telle attaque, l'attaquant pourrait insérer un élément de script qui appelle un service Web JSON, même un sur un domaine différent, puisque les balises de script le permettent. Et, puisqu'il s'agit d'une balise de script afterall, si la réponse ressemble à javascript, elle s'exécutera en javascript. La même attaque XSS peut surcharger les constructeurs d'objets ou de tableaux (parmi d'autres possibilités) et obtenir ainsi l'accès à ces données JSON à partir de l'autre domaine.
Pour tirer avec succès que, vous avez besoin (1) un site vulnérable XSS (good.com) - tout site fera, (2) un webservice JSON qui retourne une charge utile désirée sur une requête GET (par exemple, banque .com/getaccounts), (3) un mauvais emplacement (evil.com)à qui envoyer les données que vous avez capturées de bank.com alors que les gens visitent good.com, (4) un visiteur malchanceux à good.com que juste arrivé à être connecté en banque.com en utilisant la même session de navigateur .
La protection de votre service JSON contre le retour de javascript valide est juste une chose que vous pouvez faire pour éviter cela. Interdire GET est un autre (les balises de script font toujours GET). Un autre en-tête HTTP est (les balises de script ne peuvent pas définir d'en-têtes ou de valeurs personnalisés). La pile de service Web dans ASP.NET AJAX fait tout cela. N'importe qui créant leur propre pile devrait faire attention à faire la même chose.
Nous vous remercions de votre réponse rapide! Je ne sais pas pourquoi je n'ai pas trouvé cet article. Malheureusement, je communique avec un appareil qui n'est pas un navigateur et qui n'est donc pas vulnérable aux attaques. Dommage que Microsoft ne nous a pas donné un moyen facile de contourner leur solution "utile". –
Ironiquement, ce site a été marqué par Chrome comme étant plein de logiciels malveillants. – d512
PIA, mais je vais devoir faire cette route! –
Je me sens un peu bête de poser la question ici, mais qu'est-ce que «PIA» signifie? :) – gillyb
Douleur dans le cul! Parfois appelé PITA. –