Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java EE .Net security interoperability

Secure your Java EE .Net interoperable solution

By Marina Fisher, Ray Lai, Sonu Sharma and Laurence Moroney, JavaWorld.com, 06/05/06

Security exploits and vulnerabilities are often causes of huge financial loss and disruption of business services. The Computer Security Institute has reported a worldwide financial loss of circa 30 million that resulted from viruses, unauthorized access, and theft of proprietary information in 2005, a .3 million loss (compared to 5 million loss in 2003) due to denial-of-service attacks, and an average 55,552 (2005) loss per incident for proprietary information theft in 2003. A business application that was considered "secure" running on a Unix or Windows platform (for example, protected by firewall and anti-virus application) is not necessarily vulnerability-free when exchanging sensitive business data with another business application running on a different platform. This is because the interoperable solution is exposed to security vulnerabilities if one of the applications (either the sender or recipient) is exploited or is being attacked by hackers.

There are historic incidents of vulnerabilities in the Windows platform (such as flaw authentication) or Java platform (such as a flaw in the JVM). These incidents are critical and can become the Achilles' heel (a critical problem that causes financial loss or disruption to the business service) for the mission-critical Java EE .Net interoperable solutions. Although the individual vulnerability incident may not be a direct root cause to security exploits of a Java EE .Net interoperable solution, any vulnerability exposed on either Solaris OE, Unix, Linux, or Windows platforms becomes a "weakest link" to the security of the interoperable solution.

Web Services Interoperability (WS-I) identifies the following security threats that can impact Java EE .Net interoperability:

• Message alteration: Changing the message header or body during the transit
• Attachment alteration: Changing the SOAP attachment during the transit
• Confidentiality: The capability to ensure no unauthorized access is made to the message
• Falsified messages: The message is falsified by using a different identity of the sender
• Man-in-the-middle: The message is being spoofed or tampered with during transit
• Principal spoofing: The information about the user or subject is being spoofed during transit
• Repudiation: The sender or recipient denied or repudiated about the message being sent or received
• Forged claims: The claim about sending the message is forged by tampering with the message content
• Message replay (or replay of message parts): The message was once spoofed and modified for resending the message
• Denial of service: A malicious action to replay a message continuously or to overload the target service provider until the service provider is out of service

To make a Java EE .Net interoperable solution secure by default, security architects and developers should consider the following security requirements:

• Always customize security settings. Do not take the default security settings of vendor products in the operating environment. Many business applications are not designed and deployed with security by default—they are designed with unused system services turned on when deployed, which may be open to security exploits and vulnerabilities that can severely impact the interoperable solution.
• Use open standards for interoperability. Web Services Security is currently an open standard for SOAP-based Web services. WS-I Basic Security Profile (BSP) 1.0 addresses these security threats. In essence, BSP 1.0 extends Web Services Security to handle SOAP attachments. These standards ensure that the applications are interoperable.
• Use strong authentication mechanisms.
• Use secure transport mechanisms. Use of secure transport mechanisms such as Secure Socket Layer/Transport Layer Security (SSL/TLS) should address principal spoofing.
• Use digital signature. Use of digital signature should address the security risks of message alteration, attachment alteration, confidentiality, repudiation, and forged claims. Signing the SOAP message header once, creation time, and optional user data over a secure transport layer such as SSL/TLS are able to address the security risk of message replay.
• Use encryption. Use of encryption should address the security risks of confidentiality.

This article discusses different technologies (such as authentication in the presentation tier) and the open standards (such as Web Services Security) where Java and .Net applications can interact.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.