Filed under: Uncategorized
The more we read articles like today’s mention in eWEEK about Ajax (http://www.eweek.com/article2/0,1895,1998795,00.asp), the more we see the natural technology cycle revealing itself.
After a new product launch, it would seem that most technology is adopted by those of us on the cutting edge (the innovators and early adopters; stand tall, be proud) and is often raved about for its new possibilities or just its plain newness. However, it is just newness — and because of that newness, a technology is not well understood at the outset by the market, leading to the influence of FUD factors (fear, uncertainty and doubt). Also, because it is new and all the details/vectors for issues have not been worked out, the technology may be rough around the edges, feature incomplete and green, thus contributing to more FUD. Finally, in the rush to produce new technologies, security is often not thought out because of the impulse to gain that coveted “first mover” status in the market… All of this adds up to MAJOR FUD.
Now, here come these new eWEEK quotes in print, straight out of the mouths of hackers trying to make names for themselves at Black Hat in Vegas this week, ringing the “Ajax is insecure, Batman!” alarm bell. OK, folks. Ajax, like all new stuff, has its problems. We get it. New technologies, standing on the shoulders of giants, and new approaches often mean the system and implications of new features have not been fully fleshed out, and there is the real possibility of a new hole or attack vector being introduced. But, where is the new data here from eWEEK? What is scary or groundbreaking in this prognostication about the coming Ajax Armageddon?
I guess some questions beg answers. What are we really protecting? What is less secure now with Ajax in the mix?
Backend FUD with Ajax
If you are protecting access to your backend database, stored credit cards, application or personal data, etc., then we say Ajax is no more insecure that your server-side app because all the things you are protecting are on the server in the first place. Someone still has to inject SQL, dump your source files, exploit a server bug, exploit a logic bug, etc. to get at your data treasure-trove.
However, how does Ajax make that more likely? It’s only more likely if you are not sanitizing your input strings, not checking your referers, not doing all things you were supposed to do if the application logic was being done server-side in the first place. If you just decided to forgo these things because of Ajax, well then, yes, you are more insecure right now: but did the technology make you do that? If you have no idea what I am talking about here, could it be your server app is just as vulnerable? Security overlooked is insecurity, no matter the implementation details.
Frontend FUD with Ajax
(Yes, it does happen.) If so, your page has larger security issues to deal with first!
Ajax and any technology can always be made more secure, and malicious hackers will always try to break the locks. Your best solution then is to make life rougher for source sifters, digital thieves, and other dastardly villains of this sort. Obfuscate, remove white space, dump comments… do what the w3compiler does. That’s one reason why we built the tool. At first, Port80 Software noticed customers were all about buying the client-side, pre-deployment code optimization tool for speed. Now, with the rise of Ajax, we see more w3compiler real-world value in source code and related intellectual property protection. Unfortunately, these benefits are a bit at odds with each other, as more IP obfuscation may bloat your code footprint, reducing delivery speed. It is a balancing act, depending on whether performance or security matter most to your Web site or application.
Yes, there is some truth to the Ajax insecurity claims. Truth in that any new technology exposes unintended consequences/challenges and also truth in the sense that, if you are already securing your code, the “newness” of Ajax may mean you simply have to port some server-side security logic/best practices to the new Ajax implementation… which leads us back to eWEEK: that article doesn’t really speak to the reader about these truths:
< RANT time >
eWEEK should be ashamed of statements like:
“By exploiting shortcomings in Ajax programmers’ work, hackers may also be able to gain access to Web applications themselves and wreak havoc with online businesses.”
OK, I know fear mongering sells magazines, but let’s rephrase that to ridicule eWEEK properly:
“Bad guys can do bad things if they can get into your site because you didn’t do things right.”
Could you not say this about ANYTHING in the world, technology or otherwise?!?!?!?
You can see eWEEK’s clear misunderstanding here:
“Now [an attacker] is inside your application and can create a pipeline that allows them to see all the function names, variables and parameters of your site,” Hoffman said.”
You may change the style of the attack surface, you may add more moving parts, but it is still the same… it’s all about inputs. You must know them. However they are implemented, you must clean inputs or you can never ever trust them, Ajax or not.
< /RANT over >
We kid eWEEK, and there is no harm intended here: you guys are just part of the cycle of technology. You are helping evolve Ajax with the tough love of FUD.
If the technology is legitimate, people will enter the space and try to clean-up the FUD spillage by offering new products, utilities, articles, or new versions of the technology that rectify the problems. We sell a few ourselves and will sell some new ones quite soon. After a while, these band-aids become less needed as the ideas are incorporated into the best practices and core technology itself. However, usually by then, the technology is no longer new but now old, tried and true — and there should be less FUD smog in the air.
Of course, then that cycle begins over and over again because we can’t really be using that LAME OLD stuff, can we?
2 Comments »