AJAX and security

AJAX and security

what's different is that in a traditional web application (CGI, Java, PHP, etc) you know that your internal functions really are internal, they can't be called without going though your main pages, and you can do your input validation in those main pages.

With AJAX, those 'internal' functions are being called over the Internet by your app running on the client. At that point they are no longer internal, they are exposed to the world and each one needs to do it's own input validation from scratch, they can't assume _any_ filtering by the rest of the app.

unfortunantly the people pushing the AJAX approach tend to ignore this fact, they treat all the little helper programs as if they were only going to receive input from the app, and so they tend to have lots of problems as a result.

it's not that these vunerabilities are unique to AJAX, it's just that the opportunity to make these sorts of mistakes are much more common, and the prevaling mindset isn't prompting people to look out for them (after all, if the server side is written in Java it must be safe, right? ;-)

a suitably paranoid and carefully written AJAX app can be just as safe as any other app (in fact, since each function tends to be called as it's own URL there are forces pushing for better seperation of different functions into different, small, easily checked programs rather then throwing everything into one large, complex, monolithic program), but without the extra care it is far more likely to have security holes in it

<security rant>

the key thing to remember is that any input any routine receives over a communication channel needs to be treated with suspicion, it doesn't matter what you _intend_ to have come over that channel, the fact that that channel is external to your routine makes any data that comes over it suspect.

it doesn't matter if that channel is the Internet, a call across a local network, a modem line, or a file written to the disk by another program, a unix socket, or anything else you want to name. you can't really _know_ that the source of the data is the program that you think it is.

Even encryption is of limited help here, if the other endpoint gets comprimised the new owner of it has access to everything on that machine, including any encryption keys stored there, and the ability to initiate traffic from that 'trusted' IP address.

there have been servers comprimised via certificate authenticated SSH (without there being any known bugs in the SSH software) a remote machine gets comprimised and then that machine is 'trusted' (becouse it presents a known cert and IP) to the real target machine.

this does mean that layered, component software requires more checks then monolithic applications, but it also means that the bad guy has more things they have to go through, and as the bad guy is working on breaking each of the layers, you have more chances to catch him and respond (even if each layer is vunerable to the exact same bug you buy a little time as the bad guy has to learn what the next layer is)

remember, that if your component is only supposed to be connected to by your own application (and has network defenses in place to help enforce this), invalid input to your component isn't just a typo to be corrected or silently ignored, it's an indication of an active attacker who has already broken through your first line(s) of defense and you should start setting off alarms (this is assuming your other components are written properly, if they aren't this is an indication of bugs in those components, which are probably still worth setting off alarms for :-)

with AJAX your internet exposed components probably don't have the benifit of being able to say that they only get connected to by your own stuff, so you can't set off as many alarms (although in a suitably important application you could do things with client certs issued to each machine during a login or registration process, at which time invalid input with a valid cert indicates a compramised client machine)

</security rant>

David Lang