ABSTRACT

Security constraints that specify HTTP verbs often allow more access than intended.

EXPLANATION

An application's authentication and authorization mechanisms can be bypassed with HTTP verb tampering when:
1) It uses a security control that lists HTTP verbs.
2) The security control fails to block verbs that are not listed.
3) The application updates its state based on GET requests or other arbitrary HTTP verbs.



Most Java EE implementations implementations allow HTTP methods that are not explicitly listed in the configuration. For example the following security constraint is applied to the HTTP GET method but not other HTTP verbs:


<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>


Since verbs like HEAD are not explicitly defined in an <http-method> tag in this configuration, it might be possible to exercise administrative functionality by substituting GET or POST requests with HEAD requests. For HEAD requests to exercise administrative functionality, condition 3 must hold - the application must carry out commands based on verbs other than POST. Some web/application servers will accept arbitrary non-standard HTTP verbs and respond as if they were given a GET request. If that is the case, an attacker would be able to view administrative pages by using an arbitrary verb in a request.

For example, a typically client GET requests looks like:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com


In an HTTP Verb Tampering attack, an attacker would substitute GET with something like FOO

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com


At its core, this vulnerability is the result of an attempt to create a blacklist--a policy that specifies what users are not allowed to do. Blacklists rarely achieve their intended effect.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A10 Insecure Configuration Management

[2] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A6 Security Misconfiguration

[3] Arshan Dabirsiaghi - Aspect Security Bypassing Web Authentication and Authorization with HTTP Verb Tampering

[4] Standards Mapping - FIPS200 - (FISMA) CM

[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 288

[6] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) Insufficient Authentication

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.10