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.
The most obvious security issue for Ajax applications is that the associated source code is inherently downloaded to the browser for interpretation. This is a concern for any application logic that contains intellectual property that the author does not want to share with the world: while obviscation and minimization (white space removal, shortening identifier) can certainly render JavaScript much harder to read (and debug), developers should consider Ajax applications to be like HTML in that others will be able to examine the fruits of your labor. The only real alternative is to either (1) limit log-in to the application to trusted users/partners (in this way only licensed/authorized users get to download the Ajax application logic); or else (2) keep closely-held algorithms on the server-side, and simply invoke them via web services from the Ajax client. All this is not an issue for the Zimbra Ajax Client, since it is, after all, open source.
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:
• Use SSL/TLS (i.e., HTTPS) – In addition to protecting the privacy/integrity XML/JSON HTTP communications to/from the Ajax client, SSL/TLS encryption limits access to the Ajax source code itself to only those that have legitimate log-ins (as per above), since no-one snooping on the network can see the app. logic. Moreover, SSL/TLS protects the Ajax application (JavaScript, CSS, etc.) from potential security attacks while it is in route to the user’s browser.
• No server-side interpretation of JavaScript or other client-submitted code – Zimbra receives vanilla XML requests from the browser client that are validated and then processed by Zimbra server-side Java code. No JavaScript flows from client to server, and there is no server-side interpretation of any application data (e.g., message bodies). In fact, there is no JavaScript execution on the server period. This ensures that there is no way for even a hostile Ajax client with an authentication credentials to inject malicious code for execution on the server-side.
• Limited or no client-side interpretation of JavaScript within user data – The Zimbra Ajax client is, of course, an Email application that runs within the confines of the web browser. There is an additional risk, then, to displaying the contents of rich HTML messages that themselves contain JavaScript, in that JavaScript within the message might somehow be able to make malicious calls to the Zimbra server (it is generally precluded from making invocations to other sites). Zimbra blocks any “risky” HTML, first on the server and then again (for extra protection) on the client. When a rich HTML message contains any suspect JavaScript, simply better to err on the side of caution. For most Ajax applications, simply maintaining a strict separation of code from data (and never interpretting JavaScript that is included within user data) protects against such attacks.
• 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).
Comments are closed.