A good response to the eweek Ajax security article
Over on port80software there is a great response to the eweek article on Ajax Security. Check it out here: http://www.port80software.com/200ok/archive/2006/08/04/2424.aspx. The article sounds just like me when I talk in front of user groups!
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for building Dynamic Web Pages
People think Ajax is this new big security threat. When you stand back and look at an Ajax application, you have a form submission to the server. The server has no clue what in the world it is interacting with. There is no special "Hey I am Ajax boolean" (unless you coded one in the header!)
So everything still applies with normal traditional postback model. Check for injections (SQL, JavaScript, VBScript, HTML, etc.) People say but I can see the XMLHtpRequest Object and I say I can see your form with he method, fields, and action! What is the difference. I can spoof an XMLHtttpRequest Object and I can spoof a form submission.
The last is my business logic is out in the open. WHY did YOU put it there than? Do you put your business logic for the post back model on the client too. So what in the world changed? If security is a BIG deal, than use the client as the "visual rendering" part of the application.
I am working on a large article that covers these topics in detail. We will see if it ever reaches the light of day since I am busy as can be lately.
Eric
Eric, you're absolutely right. There's only really one newish issue, and that's JSON injection, which is really about JS command injection, an old friend.
So basically, what we need is for people to understand that JS does not provide a htmlentities() escaping function, and they must escape data regardless. Prototype has this function (
string.escapeHTML()) which does a moderately awful job in ISO 8859-1, and the other Ajax frameworks should all provide one as well. However, compared to PHP's htmlentities() which can handle other encodings, Prototype's function is too simplistic. Therefore, in my personal opinion, escaping should be done on the server, where there is far more smarts than is the case today. But no one has written this (yet).
I'd really like to see all examples which take dynamic input from the server or from the user to be retrofitted with safety. Escaping data is not optional, so it deserves to be in every Ajax book.
The problem with many apps I've reviewed is that they only want to write the functionality once. If they have written it in the client side layer, those folks are loathe to replicate the logic back on the server. This applies to some very big and very "enterprise" apps, including Tibco GI. For these type of apps (notably marketing themselves as 100% client side) they see the server as this evil thing. It's not. Such folks are doomed to repeat the mistakes of the mid 90's again.
I'm writing a book on Ajax Security, and the topic of where business logic should reside is covered off in there. I hope your article does see the light of day as you're extremely respected for your work on Ajax in Action, and getting this message through is extremely important.
AH! I forgot the JSON part that you mentioned. Wrote that comment at 4AM after my animals choose to freak out.
Using an outside source for JSON is like stepping off a curb on a busy street at a cross walk. You are hoping that a guy abides by the law that he stops at the cross walk when you are in it. But he might be on his cell, eatting fast food (real fast food <-bad joke), or just likes to hit things and run you over. Now hat is the smae thing with a external JSON that you have to evaluate with script tags. You have to trust that that source is not full of ads, pop ups, redirect links, etc.
Now I could say, go use a webservice instead with the server or use a proxy on the server to get this webservice. That webservice too could be full of the same crap just in XML format. So yes we need to escape the code as you mentioned. The other thing is trust. Can we trust that X server is going to always prove Y serice with no Z effects.
Why do books and articles tend to leave this out. Common Sense, Page Space, and time are major factors. I know why I talk to user groups I stress validation, injection, and trust.
Good Luck on the book, I do not wish writing a book on anyone!
Eric