Security Aspects When Using HTTP and Web Container Tracing 

The HTTP Provider and Web Container services on the J2EE Engine provide options to configure the generation of traces that can be used for debugging problems with HTTP communication, or in Web applications that are deployed. Enabling tracing for any of these services can result in security-sensitive data being written to the corresponding trace files. Examples of security-sensitive data can be user credentials (username and password) being transmitted as request parameters, credentials that are passed as HTTP headers, the session ID being encoded in the URL, and so on.

HTTP and Web Container tracing is disabled by default. Therefore, you should carefully consider your security policy and the mechanisms your application uses to pass the security-sensitive data throughout the request-response cycle before enabling it. If you have debugged a problem and have used tracing for that, you have to apply security measures that prevent unauthorized access to information contained in it. By default, a certain level of security is provided as only users with administrative rights (at operating system level) can read files existing on the J2EE Engine’s file system.

Tracing HTTP Requests and Responses

You can enable tracing for HTTP communication using the HttpTrace property of the HTTP Provider Service as described in Enabling HTTP Traces. The following table summarized the security risks associated with each of the values of this property:

Property Value	Security Risk
enable or enableHex	Security-sensitive information that is being passed as HTTP headers or with the body of the message is written to the trace file in plain text, or in hexadecimal format, respectively.
enableHeaders or enableHexHeaders	Only security-sensitive data that is passed as HTTP headers is traced.

 

Web Container Traces

You can enable tracing for the Web Container using the TraceLevel property of the Web Container Service as described in Enable and Configure Tracing for Web Applications. In this case, any security-sensitive information that your application handles (passed as request/response attributes, stored in an HTTP session object, and so on) is written to the trace file.