Possible Duplicate:
How to do Ajax securely?
At my workplace many people believe that AJAX is fundamentally insecure. I am under the impression that AJAX is exactly as secure as any other page load, it depends on how you code the call/page.
Is there a fundamental security flaw in AJAX? How does the attack surface of AJAX class (regardless of XML or JSON) differ from a standard, synchronous web application?
Short answer: You are correct, it depends on how you code the page.
Bit longer answer:
There is nothing inherently insecure about AJAX, for the most part it is susceptible to most of the same threats and attacks as regular webpages.
However, there are also a few attacks that are AJAX-specific, but again it depends on how you code it. But that doesnt make it "fundamentally insecure".
However, there is often a different, subtle issue at play: while (most) programmers eventually grokked the fact that anything "hidden" in the webpage, or in the communication between browser and server, are not protected from the user (though it took way too long for the grokking to go mainstream), it is still a popular notion that AJAX calls are somehow "special". Thus, these will often be misused... For example, I still see many a site with SSL on all regular pages, but the actual sensitive data flows freely over AJAX over non-encrypted HTTP.
In short, to some extent your cowirkers opinions are also partially at fault here - expecting AJAX to be somehow "special".
The answer depends on what assets you're trying to protect and your threat model.
If you're worried about the user attacking your web page content and the AJAX code in it and discovering something in the page that you didn't want them to know, then it is true that AJAX is insecure, since the user has physical access to the environment that the web page runs in. An example of this is the gaming example that Thomas describes in one of the other answers. If the page implements a game interface and includes information on where other players are, then the user can figure all that out and "see thru walls" and could cheat.
On the other hand if you're worried about the user attacking your server, and you assume the user can modify anything in the web page and associated code, and you take proper precautions to protect your server against anything the user can do under those circumstances, then as others have noted AJAX is just as secure as any other good programming technique, and it mostly depends on your server side code, as always. Update: But doing so can be tricky, and as @iivel points out, an OWASP page explains the various things you'll want to watch out for: Testing for AJAX Vulnerabilities (OWASP-AJ-001)
This all applies to other client-side techniques like Flash or Java applets or Silverlight, etc. Heck, it also applies to Word or PDF - if you put content in there (like meta information on who the author or owner of the software is, or content that is "erased" by overlaying it with digital white-out) that you don't think people will see or you didn't even remember that it gets included automatically, then you'll be sadly disappointed when a savvy user looks at the bits.
It's really important to think carefully about your threat model and whether your tools address it.
AJAX means: "a web page with some code in it -- and I mean it". There is no clear distinction between AJAX and a "normal" page, since normal pages may also have scripting elements in them. AJAX is more a way of stating that you intend to push some parts of your application into the client browser.
A Web-based application runs over the union of the server and the client. It is tempting to have the client do a bit more than just display pages sent by the server, because:
An analogy can be made with online gaming, e.g. with FPS games. Several users shoot at each other. The server keeps track of where everybody is and who kills who. For such games, interface reactivity is of paramount importance; hence, it is completely unimaginable that the server computes everything, and just sends frames to display to the client. Instead, clients must do the heavy 3D rendering work, and the server simply sends level maps and player position updates.
At that point, security comes into play, because of the fundamental rule:
In the gaming analogy, this means that the server must trust the client code: for 3D rendering, the client must know the level map and the position of all the other players. It would be easy, for a modified client, to display the map to the player, and pinpoint the other players. Actually, there are many cheaters out there, and game engines use sophisticated code obfuscation techniques to try to deter the majority of cheaters (because cheaters kill the fun, and without the fun the players leave).
This illustrates the thing about AJAX security: since it is code which runs on the client side, whatever it does cannot be trusted by the server, even if the user is duly authenticated (knowing who does it does not make it automatically legitimate). This is usually not a problem for GUI-related interactions -- unless there are security issues about the GUI, such as the "level map display" feature in the gaming analogy. The proper way to analyze security of Web-based applications is to assume that every single byte that the server emits is known the client, and every byte from the client is potentially malicious.
As an rough example, consider SQL injection. One way to avoid SQL injection attacks is to make sure that the data element you plug in your request has no unescaped special character. This validation step MUST be done on the server. You cannot securely do that in AJAX, since whatever AJAX does can be bypassed by the client.
"Input validation... cannot [be] securely done in AJAX" is probably the reason @C.Ross's coworkers think AJAX is insecure, and the inverse is probably the reason AJAX-heavy apps usually are insecure.
"AJAX" means different things to different people.
OWASP has a good article on this subject. The major issue with AJAX being a wider attack surface, along with some attacks that are only realistically possible on AJAX applications (JSON hacks, or client event hacking).
Testing for AJAX Vulnerabilities (OWASP-AJ-001)
http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html
By the asyncronous nature of the application, and therefore the required services, more areas are succeptible to attack. The data structures and event methods themselves are also more succeptible to attack than a round trip from post typically would be.
