Advanced Security enhancement in WebSphere application Server V7, V8, and V8.5 II

Advanced Security Considerations

Brief introduction

The 1th part explains how the IBM WebSphere application Server V7.0 and later versions consider the default security security principles at design time. The goal is to give the product a reasonable level of security by default in the most common configurations and simpler environments (although this goal is not yet perfectly implemented). The previous article finally describes many of the important infrastructure-based preventative security measures already used in WebSphere application Server. This article describes other preventative measures based on your application, and then discusses some important considerations.

Although the information in this article is based on IBM WebSphere application Server V7, V8.0, and V8.5, most of the issues discussed also apply to V6.1. For a particular version of the problem, we will specifically point out. If you use the previous version of WebSphere application Server, refer to earlier articles because of the significant version differences that can lead to differences between articles.
Configuration file Notes

If you are familiar with the WebSphere application Server before V8.5, you will know that you must create one or more profiles. The profile may be a application Server (or Base) configuration file, a deployment Manager profile, and so on. In the remainder of this article, these configuration files are referred to as "full" profiles. This distinction is made to compare these profiles with the new configuration file (Liberty configuration file) in V8.5. This article also provides some recommendations that are specific to the new Liberty configuration file.

Application-based preventative measures
Configuration measures

So far, this article focuses on the basic steps you can take to create a secure IBM WebSphere application Server infrastructure. This is obviously important, but it's not enough to focus on the infrastructure. Now that the infrastructure has been strengthened, it is important to look at what the application needs to do to ensure security. Of course, applications must take advantage of the infrastructure provided by WebSphere application Server, but application developers must also perform (or avoid) some other actions to improve the security of the application as much as possible.

Do not set the document root of the WEB server to WAR

Carefully check that each servlet alias is secure

Do not provide servlet through class name

Do not place sensitive information in the WAR root directory

To define a default error handler

Consider disabling file services and directory browsing

Enable Session security

Attention to custom JMX network access

To help you relate these measures to specific attack categories, each measure uses the tag described in part 1th to indicate the category of attack.

1. Do not set the Web server's document ROOT to WAR

The WAR file contains application code and a large amount of sensitive information. Only part of the information that is available to the WEB is content. Therefore, it is not appropriate to set the Web server document root to the WAR root directory. If you do this, the WEB server will provide all the contents of the WAR file without explanation. This can lead to the provision of code, unprocessed JSPs, and other content to end users. (This is useful only when the WEB server and application server are put together, which is not usually the case if you follow the guidance given in part 1th.) ）

2. Carefully check that each servlet alias is secure

WebSphere Application Server protects the servlet through a URL. Each URL to be protected must be specified in the Web.xml file that describes the application. If the servlet has more than one alias (that is, more than one URL accesses the same servlet class), or if there are many servlet, it is easy to forget the protection of an alias. This needs to be handled with caution. Because WebSphere application Server protects URLs rather than the underlying classes, intruders can circumvent your security measures even if only one servlet URL is unsafe. To mitigate this threat, you should use wildcard characters to protect the servlet as much as possible. If that is not appropriate, you should double-check the Web.xml file again before deploying.

The APAR PK83258 (in the WebSphere application Server versions 7.0.0.7 and 6.1.0.27) checks the head request authorization as it treats a GET request, blocking the vulnerability to some extent.

When you specify authorization constraints for the servlet, make sure that no methods are listed, or that all the methods of the servlet are listed very carefully (most likely in multiple constraints), such as Get, POST, put, head, and so on. For each Java EE specification, if the authorization constraint explicitly lists the method, there is no authorization constraint for the method not mentioned! This is particularly dangerous for methods such as head, which, by default, gets the required headers by calling get, which in effect calls the Getting method, but does not check its authorization constraints. The Web.xml code in Listing 1 is unsafe, and the code in Listing 2 is safe.

Listing 1. web.xml– not safe.

<security-constraint>
        <web-resource-collection>
            <web-resource-name>myservlet</ web-resource-name>
            <url-pattern>/myservlet</url-pattern>
            
 
Listing 2. web.xml– Security
 
<security-constraint>
    <web-resource-collection>
        <web-resource-name>myservlet</ web-resource-name>
        <url-pattern>/myservlet</url-pattern>
    </web-resource-collection >
    <auth-constraint>
        <role-name>arole</role-name>
    </auth-constraint>
</security-constraint>
 
The following method can be obtained from each web.xml to ensure that permissions are restricted:
 
Define a preliminary security constraint, such as the one shown in Listing 3. This indicates that all URLs (unless overridden by a more specific pattern) are limited to the noaccess role. noaccess role names can be previously bound to the None special role.
 
Listing 3
 
<security-constraint>
    <web-resource-collection>
        <web-resource-name>defaultdeny</ web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>NoAccess</role-name>
    </auth-constraint>
</ Security-constraint>
 
If you are using a form-based login, you should define loose constraints that allow the WEB container to display a login page (and the necessary graphics, and so on) to any user, even if the unauthenticated user sees it (listing 4). AllUsers role names can be previously bound to the Everyone special role.
Listing 4
 
<security-constraint>
    <web-resource-collection>
        <web-resource-name>loginform</ web-resource-name>
        <url-pattern>/Login.jsp</url-pattern>
        <url-pattern>/images/*. gif</url-pattern>
        <url-pattern>/css/*.css</url-pattern>
        
 
See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/