InfoCenter Home > 6.6.18.6: Avoiding known security risks in the runtime environment
Securing the properties filesWebSphere 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:
Securing properties files on Windows NTTo secure the properties files on Windows NT, follow this procedure for each file:
Securing properties files on UNIX systemsThis 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:
Risks illustrated by example applicationsThe 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. In WebSphere, Web resources are not protected by default. Additionally, the WebSphere example applications install some demonstration servlets that perform administrative tasks. Because Web resources are not secured by default, and because these servlets perform work usually reserved for administrators, they represent a possible security problem, particularly for production applications. The following describes some user practices and their potential risks. When applicable, it uses components of the example application to illustrate the point. Serving static HTML filesPurpose: This servlet serves static HTML pages. For example, the "file" servlet in the default configuration under Web application called "examples" serves static pages from the application's document directory (e.g., <WAS_HOME>/hosts/default_host/examples/web). If you access http://<host>/webapp/examples/index.html, this servlet is invoked to serve the page. Security consideration: If you place a file containing confidential information within these directories, someone who knows the filename but does not have access to it through the operating system can invoke this servlet to obtain the file. Solution: Protect all the files by protecting the URI associated with the "file" servlet. Such a URI typically ends with a "/" (e.g., /webapp/examples/). Alternatively, if you want to protect only certain files (e.g., /webapp/examples/test.html) served by this servlet, then protect the files individually. To do this, you must:
Invoker ServletPurpose: 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 pagePurpose: 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. The Web application "admin"Purpose: To administer WebSphere configuration. Security consideration: Currently, security is not supported for this feature, even if you have enabled security. If you install this application, anyone can change the configuration, even if WebSphere security is enabled. Solution: The "admin" Web application should not be installed in a production environment. Avoiding other known security risksThis 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.
|
| ||
|