InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.18: Securing applications >
6.6.18.6: Avoiding known security risks in the runtime environment

6.6.18.6: Avoiding known security risks in the runtime environment

Securing the properties files

WebSphere Application Server depends on several configuration files created during installation. These files contain password information and should be protected accordingly. Although the files are protected to a limited degree during installation, this basic level of protection is probably not sufficient for your site. You should ensure that these files are protected in compliance with the policies of your site.

The files are found in the bin and properties subdirectories in the WebSphere <product_installation_root>. The configuration files include:

  • In the bin directory: admin.config
  • In the properties directory:
    • sas.server.props
    • sas.client.props
    • sas.server.props.future

Note   Failure to adequately secure these files can lead to a breach of security in your WebSphere applications.

Securing properties files on Windows NT

To secure the properties files on Windows NT, follow this procedure for each file:

  1. Open the Windows Explorer for a view of the files and directories on the machine.
  2. Locate and right-click the file to be protected.
  3. On the resulting menu, click Properties.
  4. On the resulting dialog, click the Security tab.
  5. Click the Permissions button.
  6. Remove the Everyone entry.
  7. Remove any other users or groups who should not be granted access to the file.
  8. Add the users who should be allowed to access the file. At minimum, add the identity under which the administrative server runs.

Securing properties files on UNIX systems

This procedure applies only to the ordinary UNIX filesystem. If your site uses access-control lists, secure the files by using that mechanism.

For example, if your site's policy dictates that the only user who should have permission to read and write the properties files is the root user, to secure the properties files on a UNIX system follow this procedure for each file:

  1. Go to the directory where the properties files reside.
  2. Ensure that the desired user (in this case, root) owns each file and that the owner's permissions are appropriate (for example, rw-).
  3. Delete any permissions given to the "group".
  4. Delete any permissions given to the "world".
Any site-specific requirements can affect the desired owner, group and corresponding privileges.

Risks illustrated by example applications

The level of security appropriate to a resource varies with the sensitivity of the resource. Information considered confidential or secret deserves a higher level of security than public information, and different enterprises will assess the same information differently. Therefore, a security system needs to be able to accommodate a wide range of needs. What is reasonable in one environment can be considered a breach of security in another.

The following describes some user practices and their potential risks. When applicable, it uses components of the example application to illustrate the point.

Invoker Servlet

Purpose: The invoker servlet serves servlets by class name. For example, if you invoke /servlet/com.test.HelloServlet, the invoker will load the servlet class (if it is in its classpath) and execute the servlet.

Security consideration: By using this servlet, a user can access any other servlet in the application, without going through the proper channels. For example, if /servlet/testHello is a URI associated with com.test.HelloServlet, and if that URI is protected, user must be authenticated to invokes /servlet/testHello, but any user can invoke /servlet/com.test.HelloServlet, circumventing the security on the URI. This is a security exposure if you have secured servlets installed in the system.

Solution: Avoid installing this servlet in your configuration.

An application's error page

Purpose: In case of application errors, users are redirected to an error page associated with the Web application. This can be any type of Web resource to which customers should be redirected in case of an error.

Security consideration: This page should be unprotected. If it is protected, the server cannot authenticate the user from the context and therefore cannot send the user to the error page when an error occurs.

Solution: Do not secure these resources.

The web application "examples"

Purpose: This application is available as part of the default installation.

Security consideration: The servlets available in this application can export sensitive information, for example, the configuration of your server.

Solution: The "examples" Web application should not be installed in a production environment.

Avoiding other known security risks

This file addresses specific problem areas. As always, periodically check the product Web site Library page for the latest information. See also the product Release Notes.

  • To avoid a security risk, ensure that the WebSphere Application Server document root and the Web server document root are different. Keep your JSP files in the WebSphere Application Server document root or it will be possible for users to view the source code of the JSP files.

    WebSphere Application Server checks browser requests against its list of virtual hosts. If the host header of the request does not match any host on the list, WebSphere Application Server lets the Web server serve the file. Suppose the requested file is a JSP file in the Web server document root -- the JSP file is served as a regular file.

    This problem has been noticed in scenarios using Netscape Enterprise Server. Due to the nature of the problem, it is possible that other Web server brands are susceptible.
  • Microsoft Internet Information Server users:
    To use the Microsoft Internet Information Server with security enabled, in combination with IBM WebSphere Application Server security, you need to:
    • Configure IIS authentication settings to Anonymous.
    • Disable NTLM (Windows NT Challenge/Response) in the Microsoft Management Console
    • Disable Basic Authentication on the Microsoft Management Console
    Look for the setting on the Directory Security tab of the WWW Services properties.

    Problems are common when Internet Information Server NTLM is enabled along with IBM WebSphere Application Server security. The above settings are recommended to avoid problems.
  • Users of Distinguish Names (DN) in LDAP:
    Make sure you use Distinguished Names (DNs) that your directory service product supports. Although WebSphere Application Server security supports valid LDAP DNs, some directory-service products support only a subset. For example, testing revealed that some directory services do not support all valid LDAP DNs. Specifically, a valid DN of the form OID.9.2.x.y.z=foo was rejected by one or more of the supported directory services.

    Also, directory services vary in how they represent DNs, and DNs are both case- and space-sensitive. In some cases, this leads to situations in which a user enters a valid DN and is authenticated but is still refused access. This problem is often solved by using the Common Name (the short name) rather than the full Distinguished Name.
  • Users of digital certificates with European characters:
    If you use the iKeyman GUI tool to obtain manage certificates that contain European characters in names, the GUI will not display them. For example, a digital certificate contains the name of the company that owns the certificate and the name of the company that issued the certificate. In the US, there are companies that use symbols instead of letters in their names, like @Home and $mart $hopper. European characters in certificate names will not be displayed by the GUI.
Go to previous article: Specifying user IDs for the server and administrator with the Web console Go to next article: Protecting individual application components and methods

 

 
Go to previous article: Specifying user IDs for the server and administrator with the Web console Go to next article: Protecting individual application components and methods