This is a place for us to start seriously talking about vendors. Who's great, who's not, what's it cost, how does it relate to their competitors and would we buy it? A place to talk about snakeoil, and brilliant products alike. Marketing fluff is forbidden.

I want to use the following on one of my sites http://www.ajaxim.com/ and was wondering if I take all the measures to sanitize and validate the information being send to the server does that protect me? I know since its client-side all security done to the JS app can be tampered with, but what other security issues can an AJAX app such as this otherwise cause to my site? I haven't dabbled with AJAX much so still learning of its potential risks. Thanks in advance.

You should always fully-validate everything on the server to prevent abuse (if possible - see below).

Remember, AJAX is just JavaScript - a dynamic, client-side feature of web applications. Users are free to turn it off and therefore you should never depend on it for things such as security.

Since you are dealing with a 3rd-party product you may not be able to validate everything on the server-side. In that case, there are still some options available depending on your situation:

++++ Configure your web server to only allow HTTP requests that are X MB or less in size.

++++ Use client-side SSL certificates.

++++ Configure your firewall to only allow certain IP blocks.

Please note that on the server-side an AJAX application is no different than any other HTTP application. HTTP requests come in, get processed, and output is rendered. It doesn't matter if the end-user is loading a traditional page, performing an AJAX call, or hitting your server with a Perl script.

So if you're find with running a completely insecure IM system, go for it, just make sure you put it on a completely separate domain to the rest of your system.

Also, my 5 minute audit found that integration with existing auth systems is probably dangerous, since there are a few cases where the username is used unsanitised in SQL statements; it's not exploitable with the system being stand-alone since you can't register them, but if you populated the db with users from another system, you could get pwned. This goes for running it on the same box as other PHP scripts too, since the input for that bug comes from $_SESSION['username'].

And given the amount of xss/csrf, a review of the admin functionality would be in order to make sure it doesn't get your server pwned.

So unless you're going to do an audit the code properly, I wouldn't deploy it, but given I just realised how old this thread is, maybe you already have.