Kingdom: Security Features

Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management.

HTTP Verb Tampering

C#/VB.NET/ASP.NET
Java/JSP

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 the previously mentioned conditions 1 and 2. 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 deny list--a policy that specifies what users are not allowed to do. Deny lists rarely achieve their intended effect.

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 288, CWE ID 302

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287

[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287

[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287

[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287

[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287

[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [25] CWE ID 306

[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165

[9] Standards Mapping - FIPS200 CM

[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)

[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement

[13] Standards Mapping - OWASP API 2023 API5 Broken Function Level Authorization

[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)

[15] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls

[16] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration

[17] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management

[18] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration

[19] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration

[20] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration

[21] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4

[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control

[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control

[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls

[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II

[47] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)

[48] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.config.dotnet.http_verb_tampering

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 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 to 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 deny list--a policy that specifies what users are not allowed to do. Deny lists rarely achieve their intended effect.