Reino: Security Features

Segurança de software não é o mesmo que software de segurança. Aqui, estamos interessados em tópicos como autenticação, controle de acesso, confidencialidade, criptografia e gestão de privilégios.

HTTP Verb Tampering

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

Abstract

As restrições de segurança que especificam verbos HTTP geralmente permitem mais acesso do que o pretendido.

Explanation

Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.

A configuração a seguir é vulnerável a adulteração de verbo HTTP:


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

Por padrão, o .NET Framework permite todos os verbos HTTP e, portanto, mesmo que essa configuração negue GETs e POSTs para todos os usuários, que não impede solicitações HEAD. Talvez seja possível para um invasor usufruir de funcionalidades administrativas substituindo solicitações GET ou POST por solicitações HEAD. Em outras palavras, esse código satisfaz as condições 1 e 2 mencionadas anteriormente. Para que solicitações HEAD usufruam de funcionalidades administrativas, basta que o aplicativo realize comandos com base em solicitações que utilizam verbos diferentes de POST.

Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.

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

As restrições de segurança que especificam verbos HTTP geralmente permitem mais acesso do que o pretendido.

Explanation

Os mecanismos de autenticação e autorização de um aplicativo podem ser contornados com adulteração dos verbos HTTP quando:
1) Ele usa um controle de segurança que lista os verbos HTTP.
2) O controle de segurança falha em bloquear verbos que não estão listados.
3) O aplicativo atualiza seu estado com base em solicitações GET ou outros verbos HTTP arbitrários.

A maioria das implementações Java EE permite métodos HTTP que não estão explicitamente listados na configuração. Por exemplo, a seguinte restrição de segurança é aplicada ao método HTTP GET, mas não a outros 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>

Uma vez que verbos como HEAD não são explicitamente definidos em uma tag <http-method> nessa configuração, pode ser possível exercer a funcionalidade administrativa substituindo as solicitações GET ou POST por solicitações HEAD. Para que as solicitações HEAD exerçam a funcionalidade administrativa, a condição 3 deve ser mantida - o aplicativo deve executar comandos baseados em verbos diferentes de POST. Alguns servidores web/de aplicativos aceitarão verbos HTTP não padrão arbitrários e responderão como se tivessem recebido uma solicitação GET. Se for esse o caso, um invasor poderá ver as páginas administrativas usando um verbo arbitrário em uma solicitação.

Por exemplo, uma solicitação GET típica do cliente se parece com:


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

Em um ataque de adulteração de verbo HTTP, um invasor substituirá GET por algo como FOO


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

Basicamente, essa vulnerabilidade é o resultado de uma tentativa de criar uma lista de negação - uma política que especifica o que os usuários não têm permissão para fazer. Listas de negação raramente alcançam o efeito pretendido.