Reino: Security Features

La seguridad de un software no es un software de seguridad. Nos preocupamos de cuestiones como la autenticación, el control de acceso, la confidencialidad, la criptografía y la gestión de privilegios.

HTTP Verb Tampering

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

Abstract

Las restricciones de seguridad que especifican los verbos HTTP permiten a menudo más acceso del previsto.

Explanation

Los mecanismos de autenticación y autorización de una aplicación se pueden omitir con la manipulación del verbo HTTP cuando:
1) Se usa un control de seguridad que enumera los verbos HTTP.
2) El control de seguridad no bloquea los verbos que no figuran en la lista.
3) La aplicación actualiza su estado en función de las solicitudes GET u otros verbos HTTP arbitrarios.

La siguiente configuración es vulnerable a la manipulación de verbos HTTP:


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

Por defecto, el marco .NET admite todos los verbos HTTP, por lo que aunque esta configuración sí rechaza solicitudes GET y POST a todos los usuarios, no detiene solicitudes HEAD. Es posible que un atacante ejecute funciones administrativas sustituyendo las solicitudes GET o POST por solicitudes HEAD. En otras palabras, este código cumple las condiciones 1 y 2 anteriores. Todo lo que queda para que las solicitudes HEAD puedan ejecutar funciones administrativas es que la aplicación ejecute comandos en las solicitudes que contengan verbos distintos de POST.

En esencia, esta vulnerabilidad es el resultado de un intento de crear una lista de denegación, una directiva que especifica lo que los usuarios no pueden hacer. Las listas denegación rara vez logran el efecto deseado.

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 - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165

[8] Standards Mapping - FIPS200 CM

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

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

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

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

[13] 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[29] 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

desc.config.dotnet.http_verb_tampering

Abstract

Las restricciones de seguridad que especifican los verbos HTTP permiten a menudo más acceso del previsto.

Explanation

Los mecanismos de autenticación y autorización de una aplicación se pueden omitir con la manipulación del verbo HTTP cuando:
1) Se usa un control de seguridad que enumera los verbos HTTP.
2) El control de seguridad no bloquea los verbos que no figuran en la lista.
3) La aplicación actualiza su estado en función de las solicitudes GET u otros verbos HTTP arbitrarios.

La mayoría de las implementaciones de Java EE permiten métodos HTTP que no se enumeran explícitamente en la configuración. Por ejemplo, la siguiente restricción de seguridad se aplica al método HTTP GET pero no a otros verbos HTTP:


    <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>

Dado que los verbos como HEAD no se definen explícitamente en una etiqueta <http-method> en esta configuración, es posible ejercer la funcionalidad administrativa sustituyendo las solicitudes GET o POST por solicitudes HEAD. Para que las solicitudes HEAD ejerzan funcionalidad administrativa, se debe cumplir la condición 3: la aplicación debe ejecutar comandos basados en verbos distintos de POST. Algunos servidores web/de aplicaciones aceptarán verbos HTTP no estándar arbitrarios y responderán como si se les hubiera dado una solicitud GET. Si ese es el caso, un atacante podría ver páginas administrativas usando un verbo arbitrario en una solicitud.

Por ejemplo, las solicitudes GET de cliente normalmente son así:


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

En un ataque de manipulación de verbos HTTP, un atacante sustituiría GET por algo como FOO.


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

En esencia, esta vulnerabilidad es el resultado de un intento de crear una lista de denegación, una directiva que especifica lo que los usuarios no pueden hacer. Las listas denegación rara vez logran el efecto deseado.