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