Ajax application security critical, experts warn

By Jennette Mullaney, Assistant Editor 06 Sep 2007 | SearchSoftwareQuality.com

Software quality news and advice Digg This!     StumbleUpon     Del.icio.us

Ajax application security is slowly becoming a priority, but much of the information about Ajax security is inadequate, incorrect or simply unavailable. Those warnings come from SPI Dynamics' Bryan Sullivan, development manager and SPI Labs' team leader, and Billy Hoffman, resident Ajax security expert and lead research engineer at SPI Labs.

Sullivan and Hoffman have been advocating Ajax security for years. The two decided to consult popular Ajax books, articles, forums and the like and to build an Ajax application accordingly. The resulting application was "very pretty" and "horribly insecure," said Sullivan. "The popular advice turned out to be really, really horrible."

New book on Ajax security Sullivan and Hoffman have set about to properly educate professionals on Ajax security. To that end, they have written a book, Ajax Security, that will be available in December of 2007. However, SearchSoftwareQuality.com readers can download an exclusive copy of "Chapter 6: Transparency in Ajax Applications." "Most books either don't talk about [Ajax security] at all or relegate it to an appendix.And the advice their giving isn't very good," said Hoffman. "This is the first good book on Ajax security," Sullivan added modestly.

The duo presented their masterpiece at the Black Hat USA security conference several weeks ago. Their presentation, entitled, amazingly, "Premature Ajax-ulations," countered popular Ajax lore with practical advice. Here is what they found.

Ajax is not inherently insecure, but ignoring security makes it so
Ajax has all the problems of traditional Web security, Hoffman said. Those problems are magnified and multiplied in Ajax applications. Increased complexity, scripts running on the client side and a larger attack surface mean that traditional Web security solutions need to be escalated to address these greater risks.

Hoffman and Sullivan stressed their love for Google Maps and other Ajax-enabled applications. A primary problem, they said, is that Ajax growth exceeds Ajax security.

"The extra attack surface from Ajax is not from anything in the architecture but because you're adding functionality," Sullivan said. As your mouse glides smoothly over a Google Map, the application behind it is hard at work, constantly sending messages back and forth from the server to the client.

"Ajax is really cool. You just have to pay an extra price for the extra functionality," Sullivan said. That "extra price" includes following basic application security best practices and cultivating communication among development, QA and testing teams. Many of those security practices should already be familiar.

Input validation, whitelisting are extremely effective security measures
"My single best suggestion is to validate your input," Sullivan said. Doing so eliminates 80% of vulnerabilities right off the bat, same as it does for traditional applications. "Just look at the surface message parameters as other input, and validate as if it was coming through a form code," he explained. Common attacks such as SQL injection and cross-site scripting (XSS) can be virtually eliminated with proper input validation, he said.

However, it's important to use the right kind of input validation, emphasized Hoffman. Blacklisting is ineffectual because it's reactive. Whitelisting is proactive, Hoffman explained, using a ZIP code entry as an example. A ZIP code is five digits and doesn't include letters or symbols. If a whitelist encounters anything other than five digits, it will reject the entry.

For added security, a blacklist may be layered upon a whitelist. "And the reason that works is because the whitelist drastically reduces what you're going to get," Hoffman said. After whitelisting, "you're dealing with such a small subset that your blacklist can actually be effective."

Validate on the server side, not client side
There is another huge factor to consider when validating input for Ajax applications. "All of this validation has to take place on the server side or else it's useless," said Sullivan. The reason for this is because "the client is evil."

Developers, testers and QA need to labor under that assumption if they want secure Ajax applications, Sullivan said. Such a large percentage of Ajax functionality is executed on the client side that trusting the client simply is not an option.

"You can't trust anything that happens on the client side. Ever," Hoffman said. "If I could sit down with every Web developer in the world, that's what I'd tell them."

Communication key
If developers, QA and testers aren't all on the same level, vulnerabilities multiply. A developer may want to use one small feature of a large framework for his application, Hoffman postulated. So the developer has "brought this giant monster into the application for this mall part of functionality, but the developer forgets to turn off the other features," he said.

If that application is sent off to QA as is, QA may have no idea that these extra features are there. Testers ignore these extra features because they don't know they're there, then the application is released with a whole set of functions that haven't been tested by anyone, Hoffman said. Hackers discover these holes and exploit them.

Ajax application security Ajax security -- A reality check  Testing for security in the age of Ajax programming  Podcast -- Ajax security: A dynamic approach Helping Ajax developers prevent exploits

Those situations can be avoided if security is considered along every step of the software development life cycle (SDLC) and if the various teams are aware of what the others are doing, Hoffman added. "We can talk about tools, but communication and understanding are what's needed," he said.

Hoffman suggests augmenting existing business processes. "You already have a mechanism for QA to talk to developers, for designers to talk to implementers. And when QA is building their test plan, they're already in communication with development," he said.

As for the testing team, Sullivan advised security testers to "stop testing the way a user would test and start testing the way a hacker would test."

Tags: Software security testing and techniques,  Building security into the SDLC (Software development life cycle),  Software quality management,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Software security testing and techniques Web server weaknesses you don't want to overlook Using firewalls for software testing: Pros and cons Beating software's cross-site scripting, authentication problems Free Web proxy security tools software testers should get to know How to get management on board with Web 2.0 security issues Web application security best practices: Tips on implementation Testing strategies for complex environments How to make your software tamperproof Ways to approach application performance testing on a tight budget How can I tell if my software security has been breached? Building security into the SDLC (Software development life cycle) Problems caused by skipping analysis stage of SDLC Inexpensive phase of SDLC to catch and fix bugs GatherSpace beefs up cloud-based requirements management ALM: Best of breed vs. complete systems Software development life cycle phases, iterations, explained step by step The role of quality assurance (QA) pros in software security Common software security risks and oversights Why the quality assurance department should be involved in testing How to develop secure applications Secure software development practices 'not rocket science' Software quality management VisibleThread aims to boost IT documentation quality, improve processes Winning responses to "Why is QA always the bottleneck?" Using virtual lab management tools to stop developer, QA conflicts VMLogix LabManager adds support for vSphere 4, Hyper-V R2 Surgient 7's self-provisioning promises software testers quick IT resource access Transitioning from AJAX to .NET what changes to expect in RIA's The QA team's role in application performance evaluation and management Adaptation in project management through agile Budget-friendly Web app performance testing, monitoring tips New requirements definition tools focus on chronic flaws

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary