Billy Hoffman and Bryan Sullivan from SPI Dynamics gave one of the more entertaining talks today. The title is an allusion to peoples willingness to apply new technology before they fully understand it. Instead of laughing at silly web 2.0 developers they decided to build their own AJAXified website by consulting the resources that any programmer would: AJAX books, blogs, and forums. What they ended up with was hackervactations.com… a security hole riddled gem built on good intentions.

For their presentation they demonstrated how easily you could hammer on the site using something like Firebug. Any piece of code on the client side can’t be trusted. You can throw in a break point anywhere and manipulate any variable. So if something like the ticket price is stored locally, you can modify it before it gets debited. We learned long ago not to do this in HTML forms, but it’s the same problem all over again disguised by new technology.

Another common practice is dumping all of the functions into one common.js file. Find something like an admin function and you can call that from anywhere. You could also create a race condition. Say one function adds an item and updates the cart total; the other debits your account and ships the order. If you call the two functions with a slight offset you could interleave their actions: add an item to your cart, debit the 0 total from your account, update it with actual total, and ship the item.

Their last example involved trusting the client to do final data formatting. Using two GET requests they were able to dump the entire database. In a JSON object they could add as many SQL queries as they want without having to worry about matching the number of arguments like you would in standard injection.

There were a couple final thoughts: These problems stem from putting too much trust in the client. That doesn’t bode well for offline technologies like Google Gears where everything has to be on the client or Silverlight which makes it difficult to know whether your code is going to the client or the server. Lastly, if you’re worried about premature AJAX-ulation, abstinence may be the best solution.