No clear winner in .NET/J2EE security race

Security managers generally don't get much of a say in which development environment -- .NET or J2EE -- their organizations choose.

It's probably just as well. There's no clear winner in the .NET/J2EE security race, just different sets of challenges in how Microsoft and Sun tackle the same security challenges and which security weaknesses remain in each platform.

Both sides agree they're roughly equal when it comes to user authentication and authorization. Microsoft claims superiority in its support for Web services and its ability to fine-tune exactly which resources a piece of code can access. Sun claims stricter support for standards and that applications written in Java have been hit by fewer viruses and other attacks than Windows platforms.

.NET has pluses for all-Windows shops that understand the terminology and architecture of .NET, while J2EE might be easier to secure for organizations with deep backgrounds in object-oriented development and that run critical applications on multiple platforms, says Vince Dovydaitis, engineering director at Foliage Software Systems Inc., a software development and integration firm in Burlington, Mass. J2EE has better capabilities for securing remote communications, he says, while .Net makes it easier to fine-tune user-based and role-based authorization.

First, some definitions: Both .NET and J2EE are frameworks or sets of software tools for developing, deploying and managing applications that share information over the World Wide Web. Both frameworks assume their applications will run on multiple platforms, from servers to PCs to handhelds to mobile phones.

While .NET is driven and controlled by Microsoft, J2EE (Java 2 Platform, Enterprise Edition) is backed primarily by Sun Microsystems Inc. and supported by a number of other vendors, including (most prominently) IBM. .NET grew out of Microsoft's heritage as a vendor of Windows-based operating systems and development tools, while J2EE has a heavier reliance on Java's object-orientation and cross-platform capabilities.

The basic security model for both platforms is a version of the "sandbox" first popularized by Java, says Dovydaitis. A sandbox is the set of functions or resources a piece of code is allowed to access, which helps enforce security by restricting the code to its sandbox. .NET enforces the boundaries of the sandbox with a Common Language Runtime (CLR); in J2EE, the same function is provided by the Java Virtual Machine. (Both the CLR and the Java Virtual Machine provide a mechanism for running code across multiple platforms.) Microsoft defines its sandbox as an "application domain" while the Java term is "protection domain." The code being protected is called an "assembly" in .NET and a "JAR" (Java Archive) in J2EE.

.NET's CLR is more vulnerable than Java's Virtual Machine, he says, because much of .NET's integrity checking is done by the compiled code itself, while in Java the error checking is done by the Virtual Machine, which is harder to crack. On the other hand, he says, .NET's application domains do a better job of enforcing security, because the code and objects in one domain can only communicate with other code and objects in their domain – unless developers go to the trouble of coding remote procedure calls. If you work in an environment where developers are often forced to cobble together applications without much planning, this could come in handy.

Each framework has different ways for identifying the source (or author) of a section of code and thus the sandbox in which it may play. Here, .NET gets the edge because of its support for "strong-named" assemblies, says Dovydaitis, because the strong names include not only the name of the code but information about its version, as well as the digital signature of its author. (Doing the same thing in Java, he says, requires custom coding.) When it comes to secure communications among applications or servers, he says, Java provides more flexibility in how to configure security capabilities such as SSL (Secure Sockets Layer) and the Kerberos authentication protocol.

Microsoft and Sun claim they are roughly equivalent in the areas of user authentication and authorization, allowing developers to include in their code "declarations" about what roles or other identification users must have to access certain messages or code.

Glen Martin, a J2EE market strategist with Sun, claims that Microsoft's implementation "doesn't actually comply to the Kerberos standard" and that customers can be locked in due to the non-standard implementation. He also says Java has a better track record in fighting buffer-overflow attacks. In these, a hacker takes control of an application or computer by flooding a buffer or temporary storage area for data, and manipulates the pointers in a program that tell the microprocessor which area of memory to access next. Since Java doesn't use pointers, he says, its been immune to that entire class of attacks.

.Net gives developers much more flexibility than J2EE in defining which types of evidence a code assembly must present in order to access certain resources, and it gives them more flexibility in creating very specific sets of permissions to meet their specific security needs, according to Mike Kass, Microsoft .NET Framework product manager. .NET also gives administrators the ability to control access to more functions than J2EE, he says.

One clear area of difference is in the platform's support for securing Web services -- the use of standards such as HTTP and XML to link applications or computers over the Web. Kass boasts that unlike J2EE, .NET supports the proposed WS-Security (Web Services Security) standard. According to Martin, Sun will wait until a firm Web services security standard actually appears before supporting it. Security for these rival development platforms is a work in progress and (as the vendors themselves admit) there's no clear winner. Your best bet: Wait to see which contender winds up hosting your most business-critical applications, and then learn how to tweak that platform for security.