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
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:
- Open the Windows Explorer for a view of the files and directories
on the machine.
- Locate and right-click the file to be protected.
- On the resulting menu, click Properties.
- On the resulting dialog, click the Security tab.
- Click the Permissions button.
- Remove the Everyone entry.
- Remove any other users or groups who should not
be granted access to the file.
- 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:
- Go to the directory where the properties files reside.
- Ensure that the desired user (in this case, root) owns each file and
that the owner's permissions are appropriate (for example, rw-).
- Delete any permissions given to the "group".
- 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.
|