Rich Internet Applications: The Next Frontier of Corporate Development

The next frontier of corporate development may well be Rich Internet Applications. RIAs are Internet applications which do not necessarily run in the browser and are free of user-interface limitations of that environment.

By: Larry Seltzer

The next frontier of corporate development may well be Rich Internet Applications. RIAs are Internet applications which do not necessarily run in the browser and are free of user-interface limitations of that environment. Corporate development went head first into conventional Internet application development before the enormous security implications of that platform were clear. What about RIAs? Is the security picture any better for these platforms?

There are quite a few RIA platforms, but only three of any fame: Adobe's AIR, Microsoft's Silverlight and Oracle's JavaFX. You could make the case that Adobe Flash and Oracle's Java more generally are RIA platforms, but these three are the products marketed for standalone RIA development. AIR is based on the Flash platform and open-source Webkit browser, Silverlight on the .NET framework and JavaFX on Java.

AIR and JavaFX are just a few years old. You can make the case that Java has provided RIAs since 1994. The main innovation in JavaFX is a simpler scripting language. Out-of-browser apps are new to Silverlight 4. Each brings with it many, if not all, security issues of their base platforms.

After examining the products and documentation, it's clear that Adobe has put the most work into security and the documentation of secure practices for administrators and developers. This may be counter-intuitive, as their reputation for security is not a good one lately, and their products are the most-common target out there for attack. But Adobe has adopted several measures in the last year or two to improve the security of their products (most prominently Reader) and these have made a difference. If you are careful and conscientious about your AIR/Flash and application deployments, then you can feel secure about them.

The first thing you need to be concerned about is the security record of the platform.

Flash's record for security vulnerabilities for the last few years is not a happy one. Scores of vulnerabilities have been found and, generally, fixed. Exploit code for Flash vulnerabilities is not hard to find, and its popularity is not hard to explain: Flash can be found on a very high percentage of desktop computers, probably higher than that of Windows. It doesn't get as much attention, but Webkit also has a rich record in recent years of platform vulnerabilities, and some of these may be exploitable through your application.

Java's vulnerability record is also less than stellar; because of a high desktop installation rate, it's an up-and-comer in the exploit world, such as this recent example. JavaFX actually has not a single reported vulnerability, but this doesn't likely mean much, since JavaFX apps can call into Java and avail themselves of Java problems.

Silverlight's record in this regard may be the best of the three. There have been only three reported vulnerabilities in Silverlight, two of them just recently. The total number of reported .NET framework vulnerabilities over the years that could affect Silverlight is hard to number, but it's probably no more than 12 (including the three Silverlight vulnerabilities).

In all three cases, the RIA platform has few reported vulnerabilities, none in JavaFX's case. But vulnerabilities in the base platforms-Flash, .NET and Java-can be exploited through vulnerabilities in your own apps. Even if we can be optimistic about the platform vulnerability records going forward, the real issue in the future may be cross-site scripting, cross-site request forgery and the other sorts of flaws that are extremely common among conventional Web apps. None of the platforms or development tools provides any special help to avoid these errors.

All three of these platforms also share the problem of a proliferation of old, unpatched versions, and the surest way to keep your security tight is to keep your clients updated. Microsoft and Adobe help users with this more than Oracle.

Adobe provides procedures and tools for automating and managing updates through standard group policy mechanisms. Silverlight, in addition to having its own update mechanism, can be updated through WSUS (Windows Server Update Services). Java has an auto-update mechanism and can be installed silently, but Oracle provides no MSI version, making management more difficult. If you have a full-blown patch management system, then all products should be easier to manage.

There are other management issues besides updates, but you don't get a lot of options for them. With Silverlight you can use group policies to control whether clients can play DRM (digital-rights-management) content; set the Silverlight auto-update mechanism to full auto, prompt or no updates; whether to allow Silverlight access to the webcam and microphone; enable or disable use of UDP (user datagram protocol) multicast; and, most importantly, enable or disable the installation of trusted applications. Trusted applications can access local system resources such as the file system. More details can be found in the Silverlight Deployment Guide (Word Document).

The Adobe Flash Player Administration Guide for Flash Player 10.1 is a gold mine of information on controlling installation (including SMS configuration), file formats and network protocols used by the product. By putting a mms.cfg file on client systems you can centrally manage security and other configuration options on them, including a whitelist of domains and IP addresses which Flash/AIR may communicate, and not with any other.

AIR-specific security information is also plentiful, starting with AIR Security Overview and AIR Administrator's Guide. Somewhat surprisingly, all AIR apps have to be code-signed, although a self-signed certificate may be used. This gives administrators the ability to block untrusted code. AIR apps run in sandboxes similar to Flash sandboxes.

Java can be managed with some third-party products, but out-of-the-box management is meager. There is a rich JMX (Java Management eXtensions) API if you want to build your own.

All three platforms default to running programs in a limited sandbox mode but also allow programs to elevate permissions in order to access the file system and other resources. Flash applications can be configured to trust a variety of scopes of content, from specific files or directories all the way up to complete trust. This is a loaded gun, of course, but sometimes you need to trust applications. Trusted apps in Silverlight can also access the local file system and interoperate through COM with native code libraries. This allows you to leverage existing back-end software while using Silverlight as a front-end experience. Trusted JavaFX apps, like all Java apps, have to be digitally signed. If you don't sign the app, then the user will be bombarded with security questions, whereas if it is signed they simply have to say once that they trust the program's publisher.

It's clear that all three platforms have strengths, but from a security standpoint, the picture is strange. Silverlight definitely looks strongest based on real-world experience, but that may just demonstrate a lack of interest due to a lack of market share. JavaFX is not a high-profile system and who knows where it stands now that Oracle controls it, but Java's security record is a mixed bag. Once the thought-or rather, the marketing-was that Java apps were inherently secure, but clearly this is not true and clearly Java VM and Java apps have security problems. Not long ago, Adobe was every security analyst's favorite whipping boy, but Adobe has turned that around and provided customers with the means to secure their Flash and AIR implementations. Adobe's products may or may not be the most secure, but they have put the most work into security.