Una comparación sobre ambiente de seguridad entre Java y .NET

Mencionado en The Server Side (.net) por Paul Ballard, un papel de dos estudiantes, Nathanael Paul y David Evans, de la Universidad de Virginia, compara la implementación de políticas de código seguro en Java y en .Net. Con un punto de vista algo "virado al .Net", el documento es minucioso y consistente, por lo que contribuye a alcanzar dominio sobre los potenciales problemas o puntos débiles de las plataformas. Su conclusión es que .Net ofrece un mejor marco de seguridad que Java:

Java and .NET have similar security goals and mechanisms. .NET’s design benefited from past experience with Java. Examples of this cleaner design include the MSIL instruction set, code access security evidences, and the policy configuration. .NET has been able to shield the developer from some of the underlying complexity through their new architecture.

Where Java evolved from an initial platform with limited security capabilities, .NET incorporated more security capability into its original design. With age and new features, much of the legacy code of Java still remains for backwards compatibility including the possibility of a null SecurityManager, and the absolute trust of classes on the bootclasspath. Hence, in several areas .NET has security advantages over Java because of its simpler and cleaner design.

Most of the lessons to learn from Java’s vulnerabilities echo Saltzer and Schroeder’s classic principles, especially economy of mechanism, least privilege and fail-safe defaults. Of course, Java’s designers were aware of these principles, even though in hindsight it seems clear there were occasions where they could
(and should) have been followed more closely than they were. Some areas of design present conflicts between security and other design goals including fail-safe defaults vs. usability and least privilege vs. usability and complexity. For example, the initial stack walk introduced in Java has evolved to a more complex stack walk in both architectures to enable developers limit privileges. In addition, both
platforms default policies could be more restrictive to improve security, but restrictive policies hinder the execution of programs. .NET’s use of multi-level policies with multiple principals provides another example of showing the principles of least privilege and fail-safe defaults in contention with usability and
complexity. Several of the specific complexities that proved to be problematic in Java have been avoided in the .NET design, although .NET introduced new complexities of its own. Despite .NET’s design certainly not being perfect, it does provide encouraging evidence that system designers can learn from past security vulnerabilities and develop more secure systems. We have no doubts, however, that system designers will continue to relearn these principles for many years to come.

No obstante, es necesario recordar que la similitud está en el uso de una máquina virtual, pero que .Net ejecuta múltiples lenguajes sólo sobre Windows, y Java sólo un lenguaje sobre múltiples plataformas. En una decisión de arquitectura, las alternativas por ahora son más amplias sobre Java, sin mencionar la confiabilidad del sistema operativo huésped.