There are a couple of web sites reporting about security issues that hackers can use to invoke AJAX methods or use the JSON output to get data from other web applications. Specificallly, these attacks use HTTP GET requests invoked via an HTML <script src=""> include element to circumvent the "same origin policy" enforced by browsers (which limits JavaScript objects like XmlHttpRequest to only calling URLs on the same domain that the page was loaded from), and then look for ways to exploit the JSON payload content. The use of HTTP POST is only working if you are in the same domain, which does not mean this is not a dangerous security issue if used in web sites where different users can access data (i.e. spaces.live.com, blogger.com,...); there it is very easy to run HTTP POST with XmlHttpRequest object in the same domain (see Google XSS bug [1]).
Ajax.NET Professional [2] includes a number of security built-in features that prevent it from being susceptible to these types of JSON hijacking attacks:
AjaxMethods in AjaxPro are using HTTP POST
Script files loaded via an HTML <script src=""> element within a browser can only be retreived via HTTP GET verb request. AjaxPro is using HTTP POST for every data exchange, only generated JavaScript proxy files can be requests using HTTP GET. There is no built-in support to invoke AjaxMethods with HTTP GET.
Methodname is placed in HTTP headers
AjaxPro must get the name of the method that has to be invoked on the server-side code. This string value is placed in the HTTP headers (X-AjaxPro-Method) and cannot be set by HTML <script src=""> elements within a browser. To set a HTTP header value you could use the XmlHttpRequest object, but because HTTP POST requests are not working from different origins they are blocked by all web browsers already on the client-side JavaScript code. Other frameworks are adding method names and method arguments in the URL which is very easy to hack.
PrincipalPermission attributes on AjaxMethods
A simple protection agains non-authenticated users is to add a PrincipalPermission attribute to your AjaxMethods. The use of this attributes doesn't differ to the common use of this attribute somewhere else in the .NET framework (i.e. combined with FormsAuthentication in ASP.NET).
Unique client token
There is a possibility to add a token to each request. This token is unique to each client and will be embedded in the html output of the ASP.NET page. Each AJAX request must add this value to the HTTP header values. Because the token is client dependent it is not possible to take it to another client.
Key-/CryptProvider*
Another security built-in feature are the CryptProviders. With this feature you can crypt your JSON message from and to the web server. A very simple web application could display an image with an keyword on it. This keyword will be entered by the user once a new web browser session is started. With this in-memory keyword the crypt provider can do any type of encryption like RSA or Blowfish encryption, the keyword will never be transmitted over the HTTP connection. Instead of displaying and image you could create once the user will register for the service and send it by mail.
I hope this will clear your questions and help you to decide which AJAX framework to use. If you have any more question feel free to contact me, of course. One more note at the end: don't trust any framework to let your web application protect automatically without your help.
*) In the current release there is a small bug which will be corrected this weekend.