Events RSS Feed
Who doesn't love AJAX? It alters a site's content without users having to reload. It's rendered the pageview virtually worthless, inspiring Nielsen/BuzzMetrics to pursue a time-based site tracking model for calculating the popularity of sites. And in many ways, its availability is one manner of gauging the hip-with-it-ness of a site.
As with any snazzy and hype-ridden new technology, there is reason to take caution.
Asynchronous JavaScript and XML, otherwise known as AJAX, is the coolest kid in town since Web 2.0. Found on trendy tech-hipster offerings like GMail, it's hard to resist the technology's allure.
Last Wednesday at the Black Hat USA 2007 conference in Las Vegas, SPI Dynamics decided to demonstrate a few fallible characteristics of a site built with AJAX.
SPONSORSHIP
CMSWire speaks to a specific
audience of professionals. You can too.
Advertise here.
Dubbing the AJAX trend "premature AJAX-ulation," SPI focused on the security issues associated with AJAX by building a site called HackerVacations.com, then easily manipulating all the options available to front-end users, including seat selection, flight pricing and others.
SPI's Development Manager Bryan Sullivan explained it thus in an interview with InformationWeek: "Developers write these applications the way they're supposed to be used [...] That's great, except that you've only ever tried to exercise the application the way it's intended to be used."
The point is, hackers aren't interested in using an app the way it's "supposed" to be used. And because JavaScript utilizes the client more readily, anyone seeking to compromise an AJAX-based app has instant access to larger chunks of the app code.
AJAX can also hurt the site ranking of a badly-planned online destination. Search engine spiders typically trawl a URL in order to read the (typically static) content featured there, lending a sense of what your destination focuses on and whether it's more or less relevant to that topic.
But an AJAX-driven URL may display different content over time. And because JavaScript is used to fetch the content, search engines will simply skip that particular information on your URL.
There are solutions to these problems for those still seeking to leap aboard the AJAX train (and what a promising train it is!).
To start with, if your site is mostly content-driven, be selective about what information you'll make dynamic. You'll definitely need the search engine spiders on your side if you want a good, strong PageRank.
Pathfinder also has some good advice. Here are a couple of points:
- Don't put your "crown jewels" in the browser - a little mystery is in order, particularly for AJAX-based sites. Pathfinder recommends using server-side component frameworks like Echo2 or ZK to keep most of your business logic on the server side.
- Obscure your script source code. You can do this manually, or use a code generation framework that produces unreadable code, such as Morfik or GWT. There are issues associated with this option, too -- code generators are vulnerable to decompilers -- so pick your poison with care.
There are definitely benefits, and some cool things you can do, with AJAX. And generally speaking, you're doing a good job if you can carefully define and validate the data parameters accepted by your AJAX-based app.
But be mindful, and use your AJAX sparingly.
Email It
Stumble It
Add RSS
Processing...
On the topic of decompiling, it isn't true that obscured code is "vulnerable" to a decompiler. The reason is that the variable names are altered, comments are removed, and in the case of both Morfik and GWT, a high-level language is converted to JS, so it makes it much more difficult to determine what is going on in the code. For example, when JS is compiled by Morfik or GWT, variable names like timeOfDay are renamed to something like A. You might be able to read through all the code in the framework then the application logic and eventually figure out what A does, but you don't just have one variable you're trying to decode. There will literally be hundreds or thousands of variables with names that won't be helpful that you have to decipher.
Obscured code in general is certainly vulnerable to decompiling. There are different methods of obfuscating code and different modes of doing so. For example, in 'library' mode the naming of any public methods or properties will be preserved. Additionally, any logic that is not nested in protected or private scope blocks will potentially still be exposed or easily deciphered. And these are just the policy level issues.
There are also de-obfuscators both in the market and in the open source realm. They open up a new set of doors.
As a blanket statement, I don't think one can say that obfuscated code is that secure or obscure. Its a case by case situation. There are lots of exceptions and sophisticated hackers are certainly familiar with them.