Fear, Uncertainty and Doubt in Web 2.0

Posted: August 4th, 2006
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

If you are protecting your intellectual property of Web development — your code out there on the Net — well then, yes, Ajax is certainly more insecure.  In a server-side app, you will hide much of your hard work in .PHP, .ASPX, .JSP, etc., files that are executed before delivered over the network.  Unless something explicit dumps unexecuted server code to the browser, your hard work is relatively safe.  But, by employing the Ajax pattern and moving the majority of code to the client side in the form of JavaScript, you are indeed presenting your hard work for inspection or theft to anyone who can view source or cache explore.  Yet, before you consider source reengineering as your worst security challenge, remember that some sites (hopefully, not yours) just plain give away secrets of execution in code or other security factoids that lead to blatant insecurity.  Don’t sweat Ajax attack vectors if you have a comment in a form like:

(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?!?!?!?

The reality is that the attack surface that Ajax exposes is no more than most Web  sites and apps, unless there is logic in the JavaScript.  If your JavaScript is all UI and you don’t divulge information via comments or other things in that JavaScript, there is no more attack surface than a non-Ajax implementation.  You still have a URL, a query string or posted values, and cookies (as well as other headers) as your attack surface.  Ajax does not change the fundamentals of technology at that level.

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.”

Hello? Inside the application?  When I view Amazon.com or any other site, I am inside their application, by this way of thinking.  What does http://www.fakesite.com/doit.aspx?id=5&view=new&userReturn=false do?  They see your parameters!!!  They can fiddle with them!!! Your URLs are function names even in most styles of Web pages.  If you provide raw access to private, server-side variables using a JavaScript library, you, my friend, need to be ridiculed as a Web developer newbie.  This honestly is no different than using posted variables with no checks, keeping register globals on in PHP or all sorts of dumb things you can do to any simple server-side app.  If someone is that green, ANY TECHNOLOGY THEY USE WILL BE INSECURE (you are pro, I am sure this does not apply to you, fair reader).

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?

– Port80




2 Comments on “Fear, Uncertainty and Doubt in Web 2.0”