Verb tampering via misconfigured security constraint - Vulnerability Database

Verb tampering via misconfigured security constraint

Description

This web application uses a security-constraint configuration that specifies individual HTTP methods (such as GET or POST) within the http-method element. This approach creates a security vulnerability because Java Servlet specifications apply constraints only to the explicitly listed methods, leaving all other HTTP methods unrestricted. For example, if only GET is protected, methods like POST, PUT, DELETE, or HEAD remain accessible without authentication, allowing attackers to bypass access controls through HTTP verb tampering.

Example vulnerable configuration:

 <security-constraint>
        <web-resource-collection>
          <web-resource-name>adminres</web-resource-name>
          <url-pattern>/admin/*</url-pattern>
          <http-method>GET</http-method>
        </web-resource-collection>
        <auth-constraint>
                <role-name>admin</role-name>
        </auth-constraint>
 </security-constraint>

In this example, an attacker can use HEAD, POST, or other HTTP methods to access resources under /admin/* without authentication, completely bypassing the intended security constraint.

Remediation

Remove all http-method elements from your security-constraint configurations. When no HTTP methods are specified, the security constraint applies to all HTTP methods by default, providing comprehensive protection.

Step-by-step remediation:
1. Locate all security-constraint sections in your web.xml deployment descriptor
2. Remove any http-method elements from each web-resource-collection
3. Verify that the url-pattern and auth-constraint elements remain intact
4. Test the application to ensure all HTTP methods are properly protected

Example corrected configuration:

<security-constraint>
        <web-resource-collection>
          <web-resource-name>adminres</web-resource-name>
          <url-pattern>/admin/*</url-pattern>
          <!-- No http-method elements - protects ALL methods -->
        </web-resource-collection>
        <auth-constraint>
                <role-name>admin</role-name>
        </auth-constraint>
 </security-constraint>

Alternative approach: If you need to allow specific methods while blocking others, use http-method-omission to explicitly list methods that should NOT be protected, though the safest approach remains protecting all methods.