json asmx and that pesky d:

Question

I have looked through lots of Posts and have not been successful in determining how to get rid of the pesky d in the response coming from my asmx web service, as in {"d":{"Response":"OK","Auth-Key":"JKPYZFZU"}}.

This is being created by my class 'public Dictionary UserDevice' by returning the Dictionary object.

I would be perfectly happy if the damn thing just wouldn't put it all into the d object!

Answer 1

Basically JSON array notation ['hello'] is valid JavaScript by itself whereas JSON object notation {'d': ['hello'] } is not by itself valid JavaScript. This has the consequence of the array notation being executable which opens up the possibility of XSS attacks. Wrapping your data in an object by default helps prevent this.

You can read more about why it's there in a post by Dave Ward. (edit: as pointed out by @user1334007, Chrome tags this site as unsafe now)

A comment by Dave Reed on that article is particularly informing:

It’s one of those security features that has a very easy to misunderstand purpose. The protection isn’t really against accidentally executing the alert in your example. Although that is one benefit of ‘d’, you’d still have to worry about that while evaluating the JSON to convert it to an object.

What it does do is prevent the JSON response from being wholesale executed as the result of a XSS attack. In such an attack, the attacker could insert a script element that calls a JSON webservice, even one on a different domain, since script tags support that. And, since it is a script tag afterall, if the response looks like javascript it will execute as javascript. The same XSS attack can overload the object or array constructors (among other possibilities) and thereby get access to that JSON data from the other domain.

To successfully pull that off, you need (1) a xss vulnerable site (good.com) — any site will do, (2) a JSON webservice that returns a desired payload on a GET request (e.g. bank.com/getaccounts), (3) an evil location (evil.com) to which to send the data you captured from bank.com while people visit good.com, (4) an unlucky visitor to good.com that just happened to be logged into bank.com using the same browser session.

Protecting your JSON service from returning valid javascript is just one thing you can do to prevent this. Disallowing GET is another (script tags always do GET). Requiring a certain HTTP header is another (script tags can’t set custom headers or values). The webservice stack in ASP.NET AJAX does all of these. Anyone creating their own stack should be careful to do the same.

Answer 2

You are probably using some kind of framework that automatically wraps your web service json responses with the d element.

I know that microsoft's JSON serializer adds the d on the server side, and the client-side AJAX code that deserializes the JSON string expects it to be there.
I think jQuery works this way too.

You can read a little more about this at Rick Strahl's blog

And there is a way for you to return pure json (without the 'd' element) using the WCF "Raw" programming model.