CRV2 SecDepConfig

Secure Deployment Configuration

Web applications do not execute in isolation. They typically are deployed within an application server framework, running within an operating system on a physical host, within a network.

Secure operating system configuration (also called hardening) is not typically within the scope of code review. For more information, see the Center for Internet Security operating system benchmarks.

Networks today consist of much more than routers and switches providing transport services. Filtering switches, VLANs (virtual LANs), firewalls, WAFs (Web Application Firewall), and various middle boxes (e.g. reverse proxies, intrusion detection and prevention systems) all provide critical security services when configured to do so. This is a big topic, but outside the scope of this web application code review guide. For a good summary, see the SANS (System Administration, Networking, and Security) Institute Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches.

Application server frameworks have many security related capabilities. These capabilities are enabled and configured declaratively. Declarative configuration is usually done via static configuration files, typically in XML format, but may also be expressed as annotations within the code.

Some security capabilities are accessible from within a Java program. Programmatic security is done within the web application, using framework specific or standard Java EE APIs.

Declarative Configuration

When implemented using the Java Enterprise Edition (JEE) framework, the JEE security model may be used. JEE uses a role-based security model, in which access to application resources is granted based on the security role. The security role is a logical grouping of principals (authenticated entities, usually a user), and access is declared by specifying a security constraint on the role.

Deployment Descriptor Configuration

The constraints and roles are expressed as deployment descriptors expressed as XML elements. Different types of components use different formats, or schemas, for their deployment descriptors:

• Web components may use a web application deployment descriptor in the file web.xml
• Enterprise JavaBeans components may use an EJB deployment descriptor named META-INF/ejb-jar.xml

In summary, the deployment descriptor can define resources (e.g. servlets accessible via a specific URL), which roles are authorized to access the resource, and how access is constrained (e.g. via GET but not POST).

The following example web component descriptor, included in the "web.xml" file, defines a Catalog servlet, a "manager" role, a SalesInfo resource within the servlet accessible via GET and POST requests, and specifies that only users with "manager" role, using SSL and successfully using HTTP basic authentication should be granted access:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
   http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" version=?2.5?>

    <display-name>A Secure Application</display-name>
    <servlet>
      <servlet-name>catalog</servlet-name>
      <servlet-class>com.mycorp.CatalogServlet</servlet-class>
      <init-param>
        <param-name>catalog</param-name>
        <param-value>Spring</param-value>
      </init-param>

      <!-- Define Security Roles -->
      <security-role-ref>
        <role-name>MGR</role-name>
        <role-link>manager</role-link>
      </security-role-ref>
    </servlet>

    <security-role>
      <role-name>manager</role-name>
    </security-role>
    <servlet-mapping>
      <servlet-name>catalog</servlet-name>
      <url-pattern>/catalog/*</url-pattern>
    </servlet-mapping>

    <!-- Define A Security Constraint -->
    <security-constraint>

    <!-- Specify the Resources to be Protected -->
    <web-resource-collection>
      <web-resource-name>SalesInfo</web-resource-name>
      <url-pattern>/salesinfo/*</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
     </web-resource-collection>

    <!-- Specify which Users Can Access Protected Resources -->
    <auth-constraint>
      <role-name>manager</role-name>
    </auth-constraint>

    <!-- Specify Secure Transport using SSL (confidential guarantee) -->
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>

    <!-- Specify HTTP Basic Authentication Method -->
    <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>file</realm-name>
    </login-config>
</web-app>

Security roles can also be declared for enterprise Java beans in the "ejb-jar.xml" file. For example:

 <ejb-jar>
    <assembly-descriptor>
        <security-role>
            <description>The single application role</description>
            <role-name>TheApplicationRole</role-name>
        </security-role>
    </assembly-descriptor>
</ejb-jar>

For beans, however, rather than specifying access to resources within servlets, access to bean methods is specified. The following example illustrates several types of method access constraints for several beans:

<ejb-jar>
    <assembly-descriptor>
        <method-permission>
            <description>The employee and temp-employee roles may access any
                method of the EmployeeService bean </description>
            <role-name>employee</role-name>
            <role-name>temp-employee</role-name>
            <method>
                <ejb-name>EmployeeService</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean </description>
            <role-name>employee</role-name>
            <method>
                <ejb-name>AardvarkPayroll</ejb-name>
                <method-name>findByPrimaryKey</method-name>
            </method>
            <method>
                <ejb-name>AardvarkPayroll</ejb-name>
                <method-name>getEmployeeInfo</method-name>
            </method>
            <method>
                <ejb-name>AardvarkPayroll</ejb-name>
                <method-name>updateEmployeeInfo</method-name>
                <method-params>
                    <method-param>java.lang.String</method-param>
                </method-params>
            </method>
        </method-permission>
        <method-permission>
            <description>The admin role may access any method of the
                EmployeeServiceAdmin bean </description>
            <role-name>admin</role-name>
            <method>
                <ejb-name>EmployeeServiceAdmin</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>Any authenticated user may access any method of the
                EmployeeServiceHelp bean</description>
            <unchecked/>
            <method>
                <ejb-name>EmployeeServiceHelp</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <exclude-list>
            <description>No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment</description>
            <method>
                <ejb-name>EmployeeFiring</ejb-name>
                <method-name>fireTheCTO</method-name>
            </method>
        </exclude-list>
    </assembly-descriptor>
</ejb-jar>

Source: JBoss Enterprise Application Platform Common Criteria Certification 5
             Security Guide

If XML deployment descriptors are used to secure the application, code review should include the "web.xml" and "ejb-jar.xml" files to ensure that access controls are properly applied to the correct roles, and authentication methods are as expected.

Annotations

JEE annotations for security are defined in the javax.annotation.security package. The available annotations are:

@DeclareRoles
@DenyAll - no roles may invoke the method
@PermitAll - all roles may invoke the method
@RolesAllowed - roles permitted to invoke the method
@RunAs - dynamically run the method as a particular role

For example, the following code snippet allows employees and managers to add movies to the persistent store, anyone to list movies, but only managers may delete movies:

public class Movies {

    private EntityManager entityManager;

    @RolesAllowed({"Employee", "Manager"})
    public void addMovie(Movie movie) throws Exception {
        entityManager.persist(movie);
    }

    @RolesAllowed({"Manager"})
    public void deleteMovie(Movie movie) throws Exception {
        entityManager.remove(movie);
    }

    @PermitAll
    public List<Movie> getMovies() throws Exception {
        Query query = entityManager.createQuery("SELECT m from Movie as m");
        return query.getResultList();
    }
}

Code review should look for such annotations. If present, ensure they reflect the correct roles and permissions, and are consistent with any declared role permissions in the "ejb-jar.xml" file.

Framework Specific Configuration

Some application server frameworks offer additional or enhanced security configurations. Consult the documentation for the particular framework you are using. Information on some of the more common frameworks follow.

Apache Tomcat

The Tomcat server.xml file defines many security related parameters:

• Server - shutdown port
• Connectors - maxPostSize, maxParameterCount, server, SSLEnabled, secure, ciphers
• Host - autoDeploy, deployOnStartup, deployXML
• Context - crossContext, privileged, allowLinking

The server.xml file should be reviewed to ensure security related parameters are configured as expected.

Jetty

Jetty adds several security enhancements:

• Limiting form content
• Obfuscating passwords

The maximum form content size and number of form keys can be configured at server and web application level in the "jetty-web.xml" file:

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
 
  ...
  
  <Set name="maxFormContentSize">200000</Set>
  <Set name="maxFormKeys">200</Set>
</Configure>    

<configure class="org.eclipse.jetty.server.Server">
 
  ...
 
  <Call name="setAttribute">
    <Arg>org.eclipse.jetty.server.Request.maxFormContentSize</Arg>
    <Arg>100000</Arg>
   </Call>
  <Call name="setAttribute">
    <Arg>org.eclipse.jetty.server.Request.maxFormKeys</Arg>
    <Arg>2000</Arg>
   </Call>
</configure>      

Jetty also supports the use of obfuscated passwords in jetty XML files where a plain text password is usually needed. Here's an example setting the password for a JDBC Datasource with obfuscation (the obfuscated password is generated by Jetty org.eclipse.jetty.util.security.Password utility):

<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
   <Arg></Arg>
   <Arg>jdbc/DSTest</Arg>
   <Arg>
     <New class="com.jolbox.bonecp.BoneCPDataSource">
       <Set name="driverClass">com.mysql.jdbc.Driver</Set>
       <Set name="jdbcUrl">jdbc:mysql://localhost:3306/foo</Set>
       <Set name="username">dbuser</Set>
       <Set name="password">
          <Call class="org.eclipse.jetty.util.security.Password" name="deobfuscate">
                <Arg>OBF:1ri71v1r1v2n1ri71shq1ri71shs1ri71v1r1v2n1ri7</Arg>
          </Call>
       </Set>
       <Set name="minConnectionsPerPartition">5</Set>
       <Set name="maxConnectionsPerPartition">50</Set>
       <Set name="acquireIncrement">5</Set>
       <Set name="idleConnectionTestPeriod">30</Set>
    </New>
  </Arg>
</New>

JBoss AS

JBoss Application Server, like Jetty, allows password obfuscation (called password masking in JBoss) in its XML configuration files. After using JBoss password utility to create password mask, replace any occurrence of a masked password in XML configuration files with the following annotation:

<annotation>@org.jboss.security.integration.password.Password
                     (securityDomain=MASK_NAME,methodName=setPROPERTY_NAME)
</annotation>

See Masking Passwords in XML Configuration in the JBoss AS Security Guide.

Oracle WebLogic

WebLogic server supports additional deployment descriptors in the "weblogic.xml" file:

• externally-defined - role to principal mappings are externally defined in WebLogic Admin Console
• run-as-principal-name - assign a principal to a role when running as that role
• run-as-role-assignment - contains the run-as-principal-name descriptor
• security-permission - contains security-permission-spec descriptor
• security-permission-spec - specify application permissions as per Java policy file syntax
• security-role-assignment - explicitly assign principals to a role

More information on WebLogic additional deployment descriptors may be found at weblogic.xml Deployment Descriptors.

Programmatic Configuration

The JEE API for programmatic security consists of methods of the EJBContext interface and the HttpServletRequest interface. These methods allow components to make business-logic decisions based on the security role of the caller or remote user.