Servlet security constraints - summary and recommendations

When a request URI is matched by more than one constrained url-pattern, the contraints that apply to the request are those associated with the best matching url-pattern. The servlet matching rules as defined in, SRV.11 "Mapping Requests To Servlets", are used to determine the best matching url-pattern to the request URI. No protection requirements apply to a request URI that is not matched by a constrained url-pattern. The HTTP method of the request plays no role in selecting the best matching url-pattern for a request.

The Servlet constraint grammar provides the ability to list the HTTP methods for which the protection requirements defined in a constraint apply. When HTTP methods are listed within a constraint definition, the protections defined by the constraint are applied only to the listed methods. When HTTP methods are not listed within a constraint, the protections defined by the constraint apply to the complete set of HTTP (extension) methods. When constraints with different protection requirements apply to the same combination of url-pattern and http-method, the rules for combining the protection requirements are as defined in SRV12.7.1 "Combining Constraints".

Please consider the following recommendations. They are offered with no assurances or guarantees. Comments and suggested improvements are welcome.

  • Recommendation 1: Do not list HTTP methods within constraint definitions unless you must differentiate the protection afforded to methods at the associated patterns. Listing methods will render as unprotected (by the constraint), all non-listed methods of the (effectively) infinite set of possible HTTP (extension) methods. The following is an example of a constraint that lists the GET method and thus defines no protection on any of the other possible HTTP methods.
    <security-constraint>
      <display-name>Don't enumerate Http Methods</display-name>
      <web-resource-name>C1</web-resource-name>
      <web-resource-collection>
          <url-pattern>/acme/\*</url-pattern>
          <http-method>GET</http-method>
      </web-resource-collection>
      <auth-constraint>
        <role-name>road-runner</role-name>
      </auth-constraint>
    </security-constraint>
    
  • Recommendation 2: If you list HTTP methods within constraint definitions, define constraints that identify the protection requirements corresponding to all the specific HTTP methods that you want to permit with or without constraint at the corresponding url-patterns.

    <security-constraint>
      <display-name>allow unprotected GET</display-name>
      <web-resource-name>C2</web-resource-name>
      <web-resource-collection>
          <url-pattern>/acme/\*</url-pattern>
          <http-method>GET</http-method>
      </web-resource-collection>
    </security-constraint>
    
    <security-constraint>
      <display-name>require authentication for POST</display-name>
      <web-resource-name>C3</web-resource-name>
      <web-resource-collection>
         <url-pattern>/acme/\*</url-pattern>
         <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
        <role-name>road-runner</role-name>
      </auth-constraint>
    </security-constraint>
    
  • Recommendation 3: if you follow recommendation 2, then define complementary constraints that combine to prohibit access for all (other) HTTP methods at the constrained patterns. An auth-constraint that names an ungranted role will combine to prohibit access where it is not otherwise permitted.

    <security-constraint>
      <display-name>backstop constraint for all other methods</display-name>
      <web-resource-name>C4</web-resource-name>
      <web-resource-collection>
          <url-pattern>/acme/\*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <role-name>ungranted-role</role-name>
      </auth-constraint>
    </security-constraint>
    
  • Recommendation 4: To disallow specific HTTP methods, define an excluding auth-constraint (naming no roles) and list the HTTP methods that are to be excluded. Associate this excluding auth-constraint with all the url-patterns occurring in all other constraints. If you want to extend these exclusions to the unconstrained parts of your application, also include the url-pattern "/".

    <security-constraint>
      <display-name>Preclude access to TRACE and HEAD</display-name>
      <web-resource-name>C1</web-resource-name>
      <web-resource-collection>
         <url-pattern>/</url-pattern>
         <url-pattern>/acme/\*</url-pattern>
         <http-method>TRACE</http-method>
         <http-method>HEAD</http-method>
      </web-resource-collection>
      <auth-constraint/>
    </security-constraint>
    
  • Recommendation 5: To impose a default access denied semantic, define an excluding auth-constraint (naming no roles) and associate it with the url-pattern "/". Do not list any HTTP methods in the constraint.

    <security-constraint>
      <display-name>Switch from Constraint to Permission model (where everything is denied by default)</display-name>
      <web-resource-name>C1</web-resource-name>
      <web-resource-collection>
         <url-pattern>/</url-pattern>
      </web-resource-collection>
      <auth-constraint/>
    </security-constraint>
    
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

monzillo

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today