To continue the Zimbra blog series on Ajax (recent entries include Ajax innovation is about the server, Ajax optimization techniques (presented at OSCON), OpenAjax update, and Ajax’s impact on scaling), we wanted to offer some general thoughts on securing Ajax applications gleaned, of course, from our Zimbra experience.
Ajax security advantages. Less often discussed than Ajax security concerns are inherent security advantages of Ajax clients:
• Dynamic Ajax client download – Ajax client code is downloaded on demand from the trusted server after a particular user logs-in, automatically ensuring client and server versions are in-sync (for public computers, a shift re-load is better in that it overwrites any Ajax code from that website leftover in the browser cache).
• No persistent client caching – An exposure with traditional web clients is that they cache HTML pages that can include user/application data on the client disk during normal operation. This can be a security vulnerability for access from public kiosks or other shared computers. Ajax applications like the Zimbra client cache no user data on disk.
• Server-side control of intranet and Internet mash-ups – Zimlets and other Ajax mash-ups are precluded from accessing arbitrary services on the Internet (unless they open a new iFrame, which can be determined at server deployment time), and must instead (like Java applets) make all invocations back to the originating server (in our case, the Zimbra server). This means the Ajax server can act as a secure, proxy gateway for accessing intranet applications, and can govern which external web services (if any) are accessible for mash-up within the Ajax client.
Ajax security considerations. Subject to the additional precautions enumerated below, Ajax applications can be made as highly-secure as the web technologies upon which the Ajax model is based.
Zimbra provides the following additional guarantees to further secure Zimbra deployments over even public networks, techniques that we beileve are broadly relevant for securing Ajax applications:
• Benign URLs – All Zimbra’s GET-based REST and URL-based APIs are read-only and do not modify data. This ensures that a user (with pre-validated security credentials) cannot be fooled into clicking on a malicious link (that someone sends he or she in an email or posts on his/her external website) that would have harmful side-effects on that user’s data. Again, this is broadly relevant for Ajax applications that potentially display clickable URLs in application data.
• Mash-ups/Zimlet validation – Zimbra’s mash-up architecture does provide the opportunity to introduce server-side Java code (most Zimlets run only on the client side), but the introduction of Zimlets requires server administration privileges. Zimbra recommends only deploying Zimlets that have been certified by Zimbra or else which have been vetted by your security architects internally. The key is to ensure that only trustworthy mash-ups can be deployed with your Ajax application, mash-ups that do not expose additional attack points for malicious users.
The end result is that while an attacker with appropriate security credentials (such as a user’s password) could certainly damage that user’s server-side data, there is no way for them to compromise other user’s data or the server in general. (And, of course, that user could have any damged mailbox state restored to the point before the attack by a Zimbra administrator.)
Stronger network security can be afforded by additional technologies (such as VPNs, Smartcards, etc.), but that’s our recipe in general for leveraging the benefits of Ajax without giving up the security your customers, partners, and business depend on. More detail on the Zimbra-specific approach can be found in the newly updated Zimbra Architecture Overivew (linked within our Community and Product Documentation).
As always, thanks for listening (particularly to my verbose posts).