| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
In a distributed computing system, a significant amount of information is transmitted through networks in the form of messages. Message content is subject to three main types of attacks. Messages might be intercepted and modified for the purpose of changing the affects they have on their recipients. Messages might be captured and reused one or more times for the benefit of another party. Messages might be monitored by an eavesdropper in an effort to capture information that would not otherwise be available. Such attacks can be minimized by using integrity and confidentiality mechanisms.
Integrity mechanisms ensure that communication between entities is not being tampered with by another party, especially one that can intercept and modify their communications. Integrity mechanisms can also be used to ensure that messages can only be used once.
Message integrity is ensured by attaching a message signature to a message. The message signature is calculated by using a one-way hash algorithm to convert the message contents into a typically smaller, fixed-length message digest that is then signed (that is, cryptographically enciphered, typically using a public key mechanism). A message signature ensures that modification of the message by anyone other than the caller will be detectable by the receiver.
In the J2EE architecture, a container serves as an authentication boundary between callers and the components it hosts. Information may flow in both directions on a call (that is, a call may have input, output, or input and output parameters). The deployer is responsible for configuring containers to safeguard interactions between components. A deployer should configure the containers involved in a call to implement integrity mechanisms either because the call will traverse open or unprotected networks or because the call will be made between components that do not trust each other.
The performance cost associated with applying integrity protection to all message communication is as much a property of the operational environment as it is a consequence of the cost of the protection. One way to safeguard the integrity of application messages without unnecessarily limiting the space of operational environments is to capture application-specific knowledge identifying which messages must be integrity protected. The place to capture this information is in the application's deployment descriptor.
Confidentiality mechanisms ensure private communication between entities. Privacy is achieved by encrypting the message contents. Symmetric (or shared secret) encryption mechanisms generally require less computing resources than asymmetric (or public key) mechanisms. It is therefore quite common to use an asymmetric mechanism to secure the exchange of a symmetric encryption key that is then used to encrypt the message traffic.
The deployer is responsible for configuring containers to apply confidentiality mechanisms that ensure sensitive information is not disclosed to third parties. Despite the improved performance of shared secret mechanisms, message encryption costs are significant. They can have an adverse effect on performance when confidentiality mechanisms are applied where they are not needed. The application assembler should supply the deployer with information on those components that should be protected for confidentiality. The deployer then configures the corresponding containers to employ a confidentiality mechanism whenever interactions with these components occurs over open or unprotected networks. In addition to applying confidentiality mechanisms where appropriate, the deployer should configure containers to reject call requests or responses with message content that should be protected but isn't. Message integrity may be verified as a side effect of enforcing confidentiality.
The J2EE platform requires that containers support transport layer integrity and confidentiality mechanisms based on SSL/TLS so that security properties applied to communications are established as a side effect of creating a connection.
It is recommended that the application assembler identify the components with method calls whose parameters or return values should be protected for integrity or confidentiality. The deployment descriptor is used to convey this information. For enterprise beans, this is done in a description subelement of the target EJB component. For servlets and JSP pages, this is done in the transport-guarantee subelement of the user-data-constraint subelement of a security-constraint. In cases where a component's interactions with an external resource are known to carry sensitive information, these sensitivities should be described in the description subelement of the corresponding resource-ref.
In addition to understanding how to configure Web transport guarantees, it is important to understand the properties of HTTP methods and the effects these properties have when following a link from one Web resource to another. When a resource contains links to other resources, the nature of the links determines how the protection context of the current resource affects the protection of requests made to the linked resources.
When a link is absolute (that is, the URL begins with https:// or http://), the HTTP client container will ignore the context of the current resource and access the linked resource based on the nature of the absolute URL. If the URL of the link begins with https://, a protected transport will be established with the server before the request is sent. If the URL of the link begins with http://, the request will be attempted over an insecure transport. When the link is relative, the HTTP client container will protect an access to a linked resource based on whether the resource in which the link occurs was protected.
The application developer should consider these link properties most carefully when a linked request must carry confidential data back to the server. There are a few choices available to ensure security in such cases. For example, an application developer might choose to use secure absolute links to ensure the transport protection of requests that carry confidential data. This solves the security problem at the expense of constraining the application to a very specific naming environment.
When an application opts for portability and uses relative links, another option is for the deployer to configure the application so that wherever there is a confidential interaction from one resource to another, both are deployed with a confidential transport guarantee. This approach ensures that an HTTP client container does not send an unprotected request to a protected resource.
As a related point, the POST method is favored over the GET method for delivering confidential request data, since data sent via GET appears in browser location bars and in both client- and server-side logs.