Web technologies in general are new in the grand scheme of things, but Ajax is no doubt the rookie in the field. That means many developers may not completely understand what can happen with poorly coded Ajax and, of course, all of the people looking to break Ajax.
There are the security folks in the middle trying to figure out what's going on as well. But with Ajax code on both the client and the server, we security types often have a skewed view of what's really happening and end up overlooking otherwise critical security holes.
It's easy to be turned off from the latest news and rants about Ajax security. The sad reality, however, is that there are tons of sitting duck websites and applications out there running Ajax code. But is Ajax the culprit? Not really. Why? Well, blaming many of our Web security woes on Ajax is like blaming the latest version of Windows for all of our network and operating system security holes. Call me a skeptic, but in my work performing security assessments I rarely see a security exploit that's new and sexy. Nearly 100% of the time, it's the same problems being overlooked by the same people. Likewise, when any new technology such as Ajax is implemented and managed the same poor ways, we're going to get the same old results.
What we're seeing is a natural progression of an increased demand for software features, which equals more complexity. That, in turn, leads to greater problems (security in this case). You can apply this to any evolving technology. It's also like our politicians promising "change." The outcome is usually more oversight and bureaucracy, but nothing really gets fixed.
The true issue here is that we're ignoring the problems of the past. It's easy to forget that we usually have the means to fix our current problems. Unfortunately, we tend to want something new to resolve today's issues without actually paying attention to what we have (or have not) learned in the past. The more things change with Web security, politics -- you name it -- the more they should stay the same. But they don't. Hence the problems we have.
Most of my work in assessing Web security lately has involved sites and applications chock-full of Ajax. When scoping the projects, I'd hear about and sometimes see all of the Ajax involved and I would jump for joy. I'd think, "Oh boy, this is going to be a good one -- an easy application to attack and exploit." But in the end, all but a one or two were some of the most secure Web sites/applications I've ever come across. Was I using outdated tools? No, current tools know about Ajax and its inherent vulnerabilities. Maybe it was poor technique on my part. Since manual Web security assessments can be subjective, anything's possible, but I felt confident in my approaches.
Sure, it can be argued that the local code execution of Ajax allows attackers to see more of what's going on, which can lead to more opportunities for exploitation. The spaghetti code resulting from Ajax being everywhere certainly complicates matters as well. But it isn't the "problem" in and of itself.
It's still funny to see the analyst and vendor press releases and marketing tactics clamoring about Ajax insecurities. The fact is, folks, if developers and security professionals learn the basics of Ajax, lock it down within reason, and test for the obvious holes on a consistent basis, that's really all that can be expected. It's all that's needed. Period.
Unfortunately, that is more than what many organizations have in place. The good news is that this is an approach -- and a goal -- that's easily accomplished. It's also an information security philosophy that hasn't changed in a quarter of a century -- and it never will.
Focus on the essentials of Web security and odds are you'll see your Ajax problems disappear. Just as important, test your Web-based systems periodically and after any significant revisions. The OWASP Top Ten Project was created for a reason. These types of best practices have evolved because they've worked well for so many others in so many ways in the past. That's why we need to get back to the basics with security. It just doesn't make any business sense not to.
-----------------------------------------
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored six books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blogkbeaver@principlelogic.com.
