Concerns for Developing in an AJAX World
Because Cigital spends time helping clients document “technology-specific” security standards, to aid developers and architects, I get asked, “What do you think about [new technology XXXX]” alot. Questions regarding AJAX have crossed the threshold, so I’ll post what I think here.
Quick disclaimer: I make no comment about the technologies or security in a Web 2.0 world (I’ll leave that to Captain Technology Curmudgeon, Scott).
The world still wrestles with how to best use AJAX, so a lot remains in flux. But, I believe if you’ve got teams prototyping its use, you’ll need to consider the following:
1) Picking an AJAX toolkit - There’s a quite a few out there and each covers different ground. What’s more, people are plugging in their own approaches to things (like password management) into toolkits and riding the wave.
People always used to ask, “Websphere or Weblogic?”. I’m no product’s salesman. Usually each possesses strong advantages and disadvantages. I wanted organizations to understand tradeoffs and make an informed decision themselves. One group heard me out, took a look at price, and picked Weblogic. Their rushed decision forced them to need _me_ to implement clustering robust enough to handle the scale they desired; Plain shortsighted.
Just like your choice of containers in the Enterprise Java world, your choice of AJAX toolkits provides much of the backdrop for your software development efforts. Because the toolkit handles a lot of client-server plumbing, the security posture of your application will depend on the toolkit’s implementation. Do not make this choice lightly. Consider elements of security along-side supportability, usability, and the other decision factors.
You need to technically vet the toolkit. As I said in the case of containers, this toolkit will act as a security “table cloth” that could be pulled out from under ALL the applications you implement on top of it. Have your security group leverage any existing threat models it’s constructed for n-tier applications so that they’re not starting their analysis from scratch.
My next entry will indicate what “development scenarios” one should put each toolkit through the paces on in order to help their development teams be productive.
Moral: Spend enough time prototyping with candidate toolkits to make an informed decision about “best for you” and the realities of integration.
2) Exploring Toolkit Architecture - A natural ‘next step’ after #1, perhaps the later stage of a thorough technical assessment into a particular toolkit. Any time you move to a new technology, you need to “get smart”. Most people skip this step unfortunately. An architecture team can save security guys a lot of time by steeping themselves in a technology, writing a primer, and distributing it to developers.
When financial companies started writing their back-ends in Java, they all fell down on String processing. They just weren’t prepared for how differently (and expensively) this ‘new’ technology manipulated strings. I spent a lot of time with development teams showing them, on a whiteboard, how XML-processing affected Java’ memory management–and how to ‘game’ it. You want to “fight these battles” once, centrally, and then share the battle scars before they occur again.
In AJAX, we’re finding toolkits handle different segments of requests client-side and impose differing amounts of requests on client-server interaction. Find out how your candidate toolkits handle requests and which side of the client-server divide weight for those factors affecting security fall. WRITE THIS DOWN. Get an adoption and user’s guide out to your earlier adopter teams. Have them write version 1.1 of the document.
Moral: Share institutional knowledge gained by vetting toolkits.
3) Don’t leave real design time with short-shift to ‘buzzword’ architecture - Selection of a platform, framework, or toolkit (perhaps all three) does not constitute an architecture. Patterns, messaging protocols, threading/event models, state machines, and similar high-brow concepts constitute the language of Design. Design should address both the structure and behavior of a system. Toolkits may help address design concerns and certainly impact design–but they do not themselves constitute the design.
During an architectural analysis of a 1.0 –> 2.0 product transition, the chief architect said, “Well, we’re just going to use struts on top of tomcat, the end. Oh, for authentication we’re using Acegi.” After extended silence I asked, “In terms of how many factors does the authentication decision get made and how will you represent those factors in Acegi and elsewhere?” The answer to these questions plagued their development team for over a month. As it turns out, they couldn’t just ‘outsource’ authorization design to the fine members of the Acegi framework.
“Buzzword” architecture produces no better a result when AJAX makes the list. You still have decide what’s asynchronous and what you’ll make more persistent connections to resolve. The matter of dividing model, view, and controller (especially the last: controller) between components and tiers becomes more difficult. With a distributed application controller, application state transition becomes sticky.
Moral: Don’t let enterprise or application architects off the hook for design because they say [Technology: AJAX] will handle it. Make them specify real design; it’s their job.
More news @ 11…
-jOHN
Technorati Tags: software security, ajax