WebSphere Application Server V7 Advanced Security Enhancement, part 1th: (next)

14. Consider authenticating the HTTP link to the WEB server to the WebSphere application server

The WebSphere Application Server Web server plug-in forwards requests from the Web server to the target application server. By default, if the communication to the WEB server is done through HTTPS, the plug-in automatically uses HTTPS when forwarding the request to the application server, thereby protecting its confidentiality.

In addition, it is more prudent to configure the application server (which contains a small embedded HTTP listener) to accept requests only from known WEB servers. This prevents a variety of covert attacks that bypass any security checks in front of the Web server or on the Web server to create a trusted network path. This is unlikely to happen, but it does exist. You can't enumerate all the scenarios, here are some examples:

There is an authentication proxy server that simply sends the user ID as an HTTP hair without sending any authentication information. An intruder who can directly access a WEB container can be anyone with just the same header. (This vulnerability is not available in IBM Tivoli Access Manager WebSEAL.) ）

There is a proxy server that performs important authorization to restrict who can access what applications with a very coarse granularity.

There is a proxy server that performs important audits and does not want it to be bypassed.

As discussed in the previous section, use a client certificate to authenticate to the WEB server.

To create a trusted network path from the Web server to the application server, you need to configure the application Server Web container SSL configuration to use client authentication. Once you have ensured that you are using client authentication, you need to ensure that only trusted Web servers can contact the Web container. To do this, you must restrict the groups that have access by applying the SSL techniques described in Access only using SSL restrictions. Specifically, you need to perform the following actions:

Create a KeyStore and trust repository for the Web container and create a keystore for the Web server plug-in.

Deletes all existing signing certificates from all key stores, including the Trust store. At this point, you cannot use any key store to verify the certificate. This was done on purpose.

Create a self-signed certificate in both key repositories and export only the certificate (not the private key). Be sure to record the expiration time for these certificates. When the plug-in certificate expires, it cannot contact the WEB container! Imports certificates exported from the Web container key repository into the plug-in keystore. Import the plug-in certificate into the Web container Trust repository. Now, each end contains only one signing certificate. This means that only they can be used to validate a certificate-a self-signed certificate created for the other.

Install the newly created keystore into the Web container and Web server plug-in.

15. Do not run the sample in a production environment

The WebSphere Application server comes with several very good examples that demonstrate the various parts of the WebSphere application server. These examples are not intended for use in a production environment. Do not run them in a production environment because they pose a serious security risk. In particular, the SHOWCFG and Snoop Servlet provide external personnel with a wealth of information about your system. This is exactly the information you don't want potential intruders to get. It is easy to solve this problem as long as you are not running server1 in a production environment (it contains these examples). If you are using WebSphere application Server Base, you should actually remove these samples from Server1.