This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

CRV2 SecDepConfig

From OWASP
Revision as of 00:39, 31 December 2013 by Jerry Kickenson (talk | contribs)

Jump to: navigation, search

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.

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 followng example web component descriptor 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>

Apache Tomcat

Microsoft IIS

Oracle WebLogic

IBM WebSphere AS

Jetty

JBoss AS

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.