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.



The following configuration is vulnerable to HTTP Verb Tampering:


<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>

By default, the .NET framework allows all HTTP verbs, so even though this configuration denies GETs and POSTs to all users, it does not prevent HEAD requests. It might be possible for an attacker to exercise administrative functionality by substituting GET or POST requests with HEAD requests. In other words, this code satisfies conditions 1 and 2 above. All that remains for HEAD requests to exercise administrative functionality is for the application to carry out commands based on requests that use verbs other than POST.

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