By Rick Cook, CIO.com,
Ajax (Asynchronous JavaScript and XML), the technology of choice today for building powerful, interactive Web applications, comes at a price. If developers aren't careful they will pay that price in security.
Most developers writing Ajax applications don't work for software companies, but inside large enterprises. Unfortunately a lot of the Ajax community doesn't understand the potential risks, security experts say.
"We're not seeing security consciousness with developers, we're not seeing it with the people writing frameworks, and we're not seeing it with the quality-assurance testers," says Billy Hoffman, lead researcher at security firm SPIdynamics. "Developers assume the client is going to work a certain way and they don't think about what happens if the client doesn't work like that."
But the bad guys do think about security weaknesses, and they're getting progressively better at exploiting them via Ajax.
For the most part, Ajax doesn't present new security problems--although there are a few new types. Mostly it presents old challenges in new ways, says Pete Lindstrom, a senior analyst for Burton Group. First, Ajax can offer a considerably larger attack surface for old vulnerabilities. Also, the lack of familiarity with Ajax security can compound that problem.
The trouble with Ajax
As compared to Web 1.0 applications, Web 2.0 technologies such as Ajax in effect split an application, to offload a lot of the processing onto the client browser. This makes for a more flexible, responsive application, but it also exposes functionality previously handled on the server.
"The big change is that the amount of logic and smarts that is no longer on the server can expose immature applications to problems," says Kevin Henrickson, director of engineering at Zimbra, which makes an Ajax-based e-mail application.
This split is the main reason Ajax applications have a much larger attack surface than older Web applications.
"From a security standpoint this [division] introduces two flavors of problems," says Brian Chess, chief scientist and a founder of security firm Fortify Software. "First, it's a more complex system. You've got these two smart things interacting and there's more room for all kinds of errors." What's more, "because we have a much richer client interface we have much harder applications to test," Chess adds.
Top mistakes to prevent
The first rule of Ajax security, Henrickson says, is protect the server. "That's where you enforce your security. At the end of the day you can't trust the client," he says. "You have to have a way of ensuring that the person is authenticated and that the person making the request is the one you want getting data."
Dan Cornell, a principal in security firm Denim Group, agrees. "Organizations shouldn't trust any information from the Web client requests," he says. "It's dangerous to put the application state out on the client side. There's always a problem with things like cookies and hidden fields, but it's an even bigger problem with Ajax. You always need to verify what's coming in from the client side."
These experts say enterprises must watch out for several common errors in Ajax development:
-- Trusting the browser. It's a fundamental principle of Web security that validation and other security-related measures should be handled on the server, not the browser. In Ajax, that means, among other things, authenticating the user and checking authorization as part of every transaction, not just at the beginning of a session.
-- Insufficient checking. Check everything that comes in from the browser and everything that goes out from the server. Look carefully for the possibility of old standbys like buffer overflow and SQL injection. Be especially careful of JavaScript being sent to the server.
-- Exposing the inner workings of the program. Another principle of Web security is that you conceal the state and structure of the program from the client. Ajax applications that violate this rule make it easier for bad guys to do SQL injection attacks and other exploits.
"A lot of people don't realize that all the functionality they're exposing can be called individually," says Bryan Sullivan, senior research engineer at SPIdynamics. "When the whole process happens in a single call to the server, you're probably more secure than when you make each function publicly visible. Then a function can be called out of order or omitted."
"When the API exposes data to the user, it should only expose what they need," Henrickson says. "It shouldn't be sending back everything about the message or doing a database call. You should check and make sure all the parameters are valid, trusting nothing."
For example, Henrickson says, Zimbra's product translates all the data sent to the client into JavaScript object notation (JSON). That way the client can't see the internal structure of how the server part of the application stores data.
-- Dangers to legacy applications. Using Ajax to access existing server applications requires careful analysis. For example, a lot of Web applications put their authentication in the server's middleware. If the Ajax application bypasses the middleware to get direct access to the database, you've got a new vulnerability.
Cornell cites the example of a Denim client who had an application where users were only supposed to be able to search their own region. This was properly enforced in the original application, he said, but then Ajax was added. "On Ajax they hadn't implemented their authorization tests," he says.
-- Ajax because we can. Ajax is a hot technology, and developers love hot. That can lead to people using it where it isn't really necessary.
"Because these technologies are so new and so poorly understood, people and organizations are very focused on, 'How can we do this?'" says Cornell. "They're not asking, 'How can we do this properly, and is this something we should be doing?'"
Locking up security
Code testing becomes considerably more difficult under Ajax. The multiplicity of pieces and the potential for convoluted application logic make it much more important that the whole be carefully checked.
"Ajax applications are harder to test," says SPIdynamics' Sullivan, for reasons including the fact that they make so many calls to the server side. "Most testers use the product the same way the user does. They fire up their Web browser and use the application like a user, and if it crashes they report back."
That's fine for usability testing, Sullivan says, but it doesn't always expose the vulnerabilities. "We need a mindset shift on the part of the quality-assurance tester. They have to test like hackers," he says.
Like any software technology, the recipe for secure Ajax starts with designing and building inherently secure applications. Testing is critical, but you can't test in security.
"You need to have a mandate from management that says security is a priority," Chess says. "If management sends that message and means it, the people responsible for development will figure out what they need, what tools they need, and make sure to do the vulnerability analysis."
Copyright © 2007 IDG. All rights reserved.