17

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?

Community
  • 1
C. Ross
  • 1,408
  • 3
  • 13
  • 16
  • This has kinda been discussed before. This answer may answer your question http://security.stackexchange.com/questions/2099/how-to-do-ajax-securely/2109#2109 – Mark Davidson Mar 09 '11 at 14:30
  • cheers @Mark - have closed as duplicate – Rory Alsop Mar 09 '11 at 14:37
  • 2
    @Rory not sure its an exact duplicate... this is kinda more a theoretical question... – AviD Mar 09 '11 at 14:39
  • @Rory, @Mark am I supposed to take this as a no? – C. Ross Mar 09 '11 at 14:40
  • Well @C. Ross judge for yourself if you don't think the answer I posted answers your question. Then please say and we can reopen it. If you simply want a yes or no answer to if AJAX is fundamentally insecure then the brief answer is No not anymore than any normal web page. If your interested in the theory of what could potentially be exploited when using Ajax incorrectly on a page then it might be worth reopening this question. – Mark Davidson Mar 09 '11 at 14:47
  • @Mark Davidson, I'd really like a comparison of the attack surface of Ajax vs a normal web page, I'll rephrase the question that way. – C. Ross Mar 09 '11 at 14:50
  • 2
    And as if by magic - reopened :-) – Rory Alsop Mar 09 '11 at 15:12
  • 1
    AJAX web sites are often more complicated than their non-ajax cousins, this is effectively the only reason they are less secure. – Andrew Russell May 10 '11 at 13:14

4 Answers4

10

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.

nealmcb
  • 20,544
  • 6
  • 69
  • 116
9

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:

  • it increases interface reactivity (user experience is improved);
  • it may reduce network load (many GUI-based operations can be performed on the client without talking to the server);
  • it may reduce computing load (more work for the client machine, less work for the server).

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:

  • From the server point of view, the client is a villain.

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    Wow, it happened: the first time I didnt love one of your answers :). You kinda lost me with the FPS analogy (though it did make me want to go fire up UT...). The main issue I take with your answer, is the assumption that "AJAX... is code on the client side". While not necessarily *wrong*, per se, it is also not accurate, and often the cause of real problems when programmers see it that way. AJAX really encompasses code on the client side, but also the serving "page", and the communication between them. ... – AviD Mar 09 '11 at 18:48
  • `"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. – AviD Mar 09 '11 at 18:49
  • 1
    but unless I'm missing something that isn't any different than any other client side validation. You can do it but as stated above it can't be trusted. On the Ajax side of things, you need to make sure your server validation is really good but that should be the case regardless. So using Ajax isn't any less secure in my opinion. – Casey Mar 10 '11 at 20:15
  • 1
    @Casey, I meant that it is partially *our fault*, by saying it input validation can't be done in AJAX we are confusing the issue. Since AJAX encompasses both the clientside scripts, AND the server code - it's not true that it cant be done. Of course, if you're referring only to the client scripts, of course its true - but that's my point, `"AJAX"` means different things to different people. – AviD Mar 11 '11 at 07:53
8

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".

AviD
  • 72,138
  • 22
  • 136
  • 218
4

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.

Mark Davidson
  • 9,367
  • 6
  • 43
  • 61
iivel
  • 1,583
  • 10
  • 13