As Eric stated in the previous post, there are no new security threats introduced by Ajax. As the XMLHttpRequest object (the core of AJAX) exists since 1999, we can say that the security has been around since 7 years now. And nobody has really complained about it. Some of us have used OWA (Outlook Web Access) and didn't complained about security threats. Well, OWA is using the XMLHttpRequest object and thus AJAX since the beginning.
As AJAX moves around the XMLHttpRequest, this is the only point which can introduce security threats. By default, web browsers have a very strict way to control what resources can be accessed using JavaScript. As XMLHttpRequest is a part of JavaScript it complies to these rules.
Chapter 3 of our book has a section called "Connecting to Remote Servers and JavaScript Security" that covers what I am about to say below. The threats Eric mentioned (SQL injection etc.) are handled in each example of the book.
By default, when you load a file on the client side, the JavaScript within this file obeys the rules imposed to the parent file. By default the page loaded from the server is allowed to make requests using the XMLHttpRequest object only to the original server. There are some problems related to cross-domain requests using the XMLHttpRequest. Unfortunatelly browsers handle this type of requests differently.
Here is an exercpt from the book about this topic:
"Internet Explorer is a friendly kind of web browser; which means that is arguably less secure, but more functional. It has a security model based on zones. The four zones are Internet, Local intranet, Trusted sites, and Restricted sites. Each zone has different security settings, which you can change going to Tools | Internet Options | Security. When accessing a web resource, it will be automatically assigned to one of the security zones, and the specific security options will be applied.
The default security options may vary depending on your system. By default, Internet Explorer will give full privileges to scripts loaded from a local file resource (not through a web server, not even the local web server). So if you try to load c:\ajax\... the script will run smoothly (before execution, you may be warned that the script you are loading has full privileges). If the JavaScript code was loaded through HTTP (say,
http://localhost/ajax/..../ping.html), and that JavaScript code tries to make an HTTP request to another server, Internet Explorer will automatically display a confirmation box, where the user is asked to give permission for that action.
Firefox and Mozilla-based browsers have a more restrictive and more complicated security model, based on privileges. These browsers don't display a confirmation window automatically; instead, your JavaScript code must use a Mozilla specific API to ask about performing the required actions. If you are lucky the browser will display a confirmation box to the user, and depending on user's input, it will give the permission (or not) to your JavaScript code. If you aren't lucky, the Mozilla-based browser will ignore your code request completely. By default, Mozilla-based browsers will listen to privilege requests asked from local (
file:///) resources, and will ignore completely requests from scripts loaded through HTTP, unless these scripts are signed (these are the default settings that can be changed manually, though). Learn more about signing scripts for Mozilla browsers at
http://www.mozilla.org/projects/security/components/ signed-scripts.html."
I hope that this answer along with Eric's answer give you an idea on how AJAX is handled in security scenarios.
Best regards,
Bogdan