1437 itens encontrados
Vulnerabilidades
Abstract
O código de depuração pode afetar o desempenho ou disponibilizar dados confidenciais a um invasor.
Explanation
Uma prática comum de desenvolvimento é adicionar um código de “backdoor” projetado especificamente para fins de depuração ou de testes, sem o objetivo de implementá-lo com o aplicativo. Quando esse tipo de código for deixado acidentalmente no aplicativo, o aplicativo estará sujeito a modos de interação imprevistos. Os pontos de entrada de backdoor representam riscos de segurança, uma vez que não são considerados durante o projeto ou os testes do aplicativo e estão fora das condições operacionais esperadas.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 489
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3), 14.2.2 Dependency (L1 L2 L3)
[4] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[5] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
desc.semantic.golang.go_bad_practices_leftover_debug_code
Abstract
Um endpoint GraphQL é criado com o GraphiQL habilitado.
Explanation
O GraphiQL é uma ferramenta no navegador que aproveita o mecanismo de introspecção de esquema do GraphQL para fornecer uma interface gráfica para desenvolvimento e teste da API do GraphQL. O GraphiQL auxilia os usuários na exploração de esquemas do GraphQL, bem como na composição e execução de consultas do GraphQL.

Não é recomendado permitir acesso ao GraphiQL em produção, pois habilitar a introspecção de seus esquemas do GraphQL por meio do GraphiQL pode representar um risco para sua postura geral de segurança. Um invasor pode usar o GraphiQL e a introspecção para obter os detalhes de implementação de um esquema do GraphQL que permitem realizar um ataque mais direcionado. Os esquemas do GraphQL podem vazar informações, como campos usados internamente, descrições e notas de descontinuação, que podem não ser destinadas ao consumo público.

Exemplo 1: O código a seguir inicializa um endpoint do GraphQL.js com o GraphiQL habilitado por padrão:

app.use('/graphql', graphqlHTTP({
schema
}));
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 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 A05 Security Misconfiguration
[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.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.javascript.graphql_bad_practices_graphiql_enabled
Abstract
Um endpoint GraphQL é criado com o GraphiQL habilitado.
Explanation
O GraphiQL é uma ferramenta no navegador que aproveita o mecanismo de introspecção de esquema do GraphQL para fornecer uma interface gráfica para desenvolvimento e teste da API do GraphQL. O GraphiQL auxilia os usuários a explorar esquemas do GraphQL, bem como compor e executar consultas do GraphQL.

Não é recomendado permitir acesso ao GraphiQL em produção, pois habilitar a introspecção de seus esquemas do GraphQL por meio do GraphiQL pode representar um risco para sua postura geral de segurança. Um invasor pode usar o GraphiQL e a introspecção para obter os detalhes de implementação de um esquema do GraphQL que permitem realizar um ataque mais direcionado. Os esquemas do GraphQL podem vazar informações, como campos usados internamente, descrições e notas de descontinuação, que não são destinadas ao consumo público.

Exemplo 1: O código a seguir inicializa um endpoint do GraphQL com o GraphiQL habilitado:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
'graphql',
schema = schema,
graphiql = True
))
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 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 A05 Security Misconfiguration
[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.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.graphql_bad_practices_graphiql_enabled
Abstract
Um endpoint GraphQL é criado sem desabilitar a introspecção de esquema.
Explanation
O recurso de introspecção do GraphQL permite que qualquer pessoa consulte um servidor GraphQL para obter informações sobre o esquema atual. Uma parte interessada pode emitir consultas de introspecção do GraphQL para recuperar uma visão completa das operações, tipos de dados, campos e documentação disponíveis de um esquema.

A introspecção do GraphQL oferece uma utilidade significativa no contexto de desenvolvimento e compartilhamento de informações sobre APIs do GraphQL. A introspecção é um recurso poderoso do GraphQL que pode facilitar a integração com várias ferramentas. Por exemplo, um IDE pode aproveitar a introspecção de esquema para fornecer recursos aprimorados que desenvolvem e testam APIs do GraphQL.

No entanto, permitir que qualquer pessoa consulte seus esquemas do GraphQL em produção pode representar um risco para sua postura geral de segurança. Um invasor pode usar a introspecção para obter os detalhes de implementação de um esquema do GraphQL que permitem realizar um ataque mais direcionado. Os esquemas do GraphQL podem vazar informações, como campos usados internamente, descrições e notas de descontinuação, que podem não ser destinadas ao consumo público.

Exemplo 1: O seguinte código inicializa um endpoint GraphQL Hot Chocolate com a introspecção de esquema habilitada por padrão:

services
.AddGraphQLServer()
.AddQueryType<Query>()
.AddMutationType<Mutation>();
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 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 A05 Security Misconfiguration
[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.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.graphql_bad_practices_introspection_enabled
Abstract
Um endpoint GraphQL é criado sem desabilitar a introspecção de esquema.
Explanation
O recurso de introspecção do GraphQL permite que qualquer pessoa consulte um servidor GraphQL para obter informações sobre o esquema atual. Uma parte interessada pode emitir consultas de introspecção do GraphQL para recuperar uma visão completa das operações, tipos de dados, campos e documentação disponíveis de um esquema.

A introspecção do GraphQL oferece uma utilidade significativa no contexto de desenvolvimento e compartilhamento de informações sobre APIs do GraphQL. A introspecção é um recurso poderoso do GraphQL que pode facilitar a integração com várias ferramentas. Por exemplo, um IDE pode aproveitar a introspecção de esquema para fornecer recursos aprimorados que desenvolvem e testam APIs do GraphQL.

No entanto, permitir que qualquer pessoa consulte seus esquemas do GraphQL em produção pode representar um risco para sua postura geral de segurança. Um invasor pode usar a introspecção para obter os detalhes de implementação de um esquema do GraphQL que permitem realizar um ataque mais direcionado. Os esquemas do GraphQL podem vazar informações, como campos usados internamente, descrições e notas de descontinuação, que podem não ser destinadas ao consumo público.

Exemplo 1: O código a seguir inicializa um endpoint GraphQL.js com a introspecção de esquema habilitada por padrão:

app.use('/graphql', graphqlHTTP({
schema
}));
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 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 A05 Security Misconfiguration
[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.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.graphql_bad_practices_introspection_enabled
Abstract
Um endpoint GraphQL é criado sem desabilitar a introspecção de esquema.
Explanation
O recurso de introspecção do GraphQL permite que qualquer pessoa consulte um servidor GraphQL para obter informações sobre o esquema atual. Qualquer parte interessada pode emitir consultas de introspecção do GraphQL para recuperar uma visão completa de operações, tipos de dados, campos e documentação disponíveis de um esquema.

A introspecção do GraphQL oferece uma utilidade significativa no contexto de desenvolvimento e compartilhamento de informações sobre APIs do GraphQL. A introspecção é um recurso poderoso do GraphQL que pode facilitar a integração com várias ferramentas. Por exemplo, um IDE pode aproveitar a introspecção de esquema para fornecer recursos aprimorados que desenvolvem e testam APIs do GraphQL.

No entanto, permitir que qualquer pessoa consulte seus esquemas do GraphQL em produção pode representar um risco para sua postura geral de segurança. Um invasor pode usar a introspecção para obter os detalhes de implementação de um esquema do GraphQL que permitem realizar um ataque mais direcionado. Os esquemas do GraphQL podem vazar informações, como campos usados internamente, descrições e notas de descontinuação, que não são destinadas ao consumo público.

Exemplo 1: O código a seguir inicializa um endpoint GraphQL com a introspecção de esquema habilitada por padrão:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
'graphql',
schema = schema
))
References
[1] OWASP OWASP Cheat Sheet Series: GraphQL Cheat Sheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 94
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 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 A05 Security Misconfiguration
[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.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.python.graphql_bad_practices_introspection_enabled
Abstract
Um objeto Metadata do Google Remote Procedure Call (gRPC) é criado com base em uma fonte não confiável, o que pode permitir que um invasor controle campos de protocolo críticos.
Explanation
A classe Metadata é frequentemente usada para armazenar dados de cabeçalho para um protocolo subjacente usado pelo Google Remote Procedure Call (gRPC). Quando o protocolo subjacente é HTTP, o controle dos dados em um objeto Metadata pode tornar o sistema vulnerável à Manipulação de Cabeçalho HTTP. Outros vetores de ataque são possíveis e são baseados principalmente no protocolo subjacente.

Exemplo 1: O código a seguir mostra dados não confiáveis usados como entrada para um objeto Metadata do gRPC.


...
String? evnVar = System.Environment.GetEnvironmentVariable("evnVar ");
Metadata headers = new Metadata();
headers.Add("field", evnVar);
CallOptions callOptions = new CallOptions(headers);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.dotnet.grpc_metadata_manipulation
Abstract
Um objeto Metadata do Google Remote Procedure Call (gRPC) é criado com base em uma fonte não confiável, o que pode permitir que um invasor controle campos de protocolo críticos.
Explanation
A classe Metadata é frequentemente usada para armazenar dados de cabeçalho para um protocolo subjacente usado pelo Google Remote Procedure Call (gRPC). Quando o protocolo subjacente é HTTP, o controle dos dados em um objeto Metadata pode tornar o sistema vulnerável à Manipulação de Cabeçalho HTTP. Outros vetores de ataque são possíveis e são baseados principalmente no protocolo subjacente.

Exemplo 1: O código a seguir mostra dados controláveis pelo usuário usados como entrada para um objeto Metadata do gRPC.


...
String badData = getUserInput();
Metadata headers = new Metadata();
headers.put(Metadata.Key.of("sample", Metadata.ASCII_STRING_MARSHALLER), badData);
...
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - FIPS200 SI
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[7] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.java.grpc_metadata_manipulation
Abstract
O programa permite que um invasor controle componentes principais do cluster Hadoop no qual o aplicativo cliente é executado.
Explanation
Erros de controle de cluster Hadoop ocorrem quando:

- Os dados entram em um programa por uma fonte não confiável.

- Os dados são consumidos pelos componentes principais do cluster Hadoop, como NameNode, DataNode e JobTraker, para alterar o estado do cluster.

Clusters Hadoop são um ambiente hostil. Quando configurações de segurança de proteção do acesso não autorizado a nós de cluster não são definidas corretamente, um invasor pode ser capaz de assumir o controle da infraestrutura. Isso resulta na possibilidade de que todos os dados fornecidos pelo cluster Hadoop sejam adulterados.

Exemplo 1: O código a seguir mostra um envio de Job em um aplicativo de cliente típico que usa entradas da linha de comando na máquina mestre do cluster Hadoop:


public static void run(String args[]) throws IOException {

String path = "/path/to/a/file";
DFSclient client = new DFSClient(arg[1], new Configuration());
ClientProtocol nNode = client.getNameNode();

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
Abstract
O Job enviado a um cluster Hadoop pode ser adulterado em um ambiente hostil.
Explanation
Erros de manipulação de trabalhos Hadoop ocorrem quando:

- Os dados entram em um programa por uma fonte não confiável.

- Os dados são usados para especificar um valor de JobConf que controla um trabalho de cliente.

Clusters Hadoop são um ambiente hostil. Quando configurações de segurança de proteção do acesso não autorizado ao HDFS em máquinas de cluster não são definidas corretamente, um invasor pode ser capaz de assumir o controle. Isso resulta na possibilidade de que todos os dados fornecidos pelo cluster Hadoop sejam adulterados.

Exemplo 1: O código a seguir mostra um envio de Job em um aplicativo de cliente típico que usa entradas da linha de comando na máquina mestre do cluster Hadoop:


public void run(String args[]) throws IOException {

String inputDir = args[0];
String outputDir = args[1];

// Untrusted command line argument
int numOfReducers = Integer.parseInt(args[3]);
Class mapper = getClassByName(args[4]);
Class reducer = getClassByName(args[5]);

Configuration defaults = new Configuration();
JobConf job = new JobConf(defaults, OptimizedDataJoinJob.class);
job.setNumMapTasks(1);
// An attacker may set random values that exceed the range of acceptable number of reducers
job.setNumReduceTasks(numOfReducers);

return job;
}
Exemplo 2: O código a seguir mostra um caso em que um invasor controla o trabalho em execução a ser desativado por meio de argumentos de linha de comando:


public static void main(String[] args) throws Exception {

JobID id = JobID.forName(args[0]);
JobConf conf = new JobConf(WordCount.class);
// configure this JobConf instance
...
JobClient.runJob(conf);
RunningJob job = JobClient.getJob(id);
job.killJob();

}
References
[1] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[5] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[6] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_job_manipulation
Abstract
O escape está desabilitado em um modelo Handlebars, o que pode levar a várias novas vulnerabilidades.
Explanation
O escape padrão executado nos modelos do Handlebars ajuda a proteger o aplicativo contra invasores. Isso pode impedir muitos vetores de ataque em diferentes tipos de vulnerabilidades. A proteção mais proeminente é contra certos tipos de ataques de cross-site scripting. Neste aplicativo, este mecanismo de proteção está especificamente desabilitado.

Exemplo 1: O exemplo a seguir mostra o escape do modelo Handlebars desabilitado.

let template = Handlebars.compile('{{foo}}', { noEscape: true })
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 554
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (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 A05 Security Misconfiguration
[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 1.2 Requirement 6.3.1.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.handlebars_misconfiguration_escaping_disabled
Abstract
Protótipos são permitidos em um modelo Handlebars, abrindo a porta para vulnerabilidades de Prototype Pollution.
Explanation
Os modelos Handlebars não podem acessar os protótipos de um objeto, pois tornam o aplicativo suscetível a ataques de Prototype Pollution.

Os ataques de Prototype Pollution ocorrem quando um usuário mal-intencionado pode controlar funções ou propriedades nos protótipos de objetos. Controlar os protótipos de um objeto que é passado para um modelo permite muitas vulnerabilidades, incluindo Dynamic Code Evaluation, Cross-Site Scripting e Remote Code Execution.

Exemplo 1: No exemplo a seguir da configuração de modelos Handlebars, os métodos de protótipo são permitidos por padrão, assim como a função especial __defineGetter__.

let template2 = Handlebars.compile('{{foo}}')
console.log(template2({ foo: argument }, {
allowProtoMethodsByDefault: true,
allowedProtoMethods: {
__defineGetter__: true
}
}))
References
[1] Handlebars Runtime Options: Options to Control Prototype Access Handlebars
[2] Mahmoud Gamal Handlebars template injection and RCE in a Shopify app
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.javascript.handlebars_misconfiguration_prototypes_allowed
Abstract
Incluir um script de outro domínio significa que a segurança dessa página da Web depende da segurança do outro domínio.
Explanation
Incluir conteúdo executável de outro site é uma proposta arriscada. Isso vincula a segurança do seu site à segurança do outro site.

Exemplo 1: Considere a seguinte tag script.

<script src="http://www.example.com/js/fancyWidget.js"></script>


Se essa tag aparecer em um site diferente de www.example.com, esse site dependerá de www.example.com para apresentar o código correto e não mal-intencionado. Se os invasores puderem comprometer www.example.com, eles poderão alterar o conteúdo de fancyWidget.js para corromper a segurança do site. Por exemplo, eles poderiam adicionar código a fancyWidget.js para roubar dados confidenciais de um usuário.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494, CWE ID 829
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.3 Dependency (L1 L2 L3), 14.2.4 Dependency (L2 L3)
[7] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[8] Standards Mapping - OWASP Mobile 2024 M7 Insufficient Binary Protections
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2
[10] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[11] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Process Validation
desc.content.html.hardcoded_domain
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation ocorrem quando:

1. Os dados entram em um aplicativo Web por meio de uma fonte não confiável, mais frequentemente em uma solicitação HTTP.


2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, Header Manipulation é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Header Manipulation é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos servidores de aplicativos modernos de hoje impedem a injeção de caracteres mal-intencionados nos cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O seguinte código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();

RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}


Supondo que um par nome/valor consista em author e Jane Smith, a resposta HTTP incluindo este cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base em entrada de usuário não validada, um invasor pode enviar um par nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local será afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques como Cross-Site Request Forgery, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Open Redirect: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos e estruturas de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Microsoft .NET Framework converterão caracteres CR, LF e NULL em %0d, %0a e %00 quando estes forem enviados ao método HttpResponse.AddHeader(). Se você estiver usando o .NET Framework mais recente que impede a definição de cabeçalhos com caracteres de nova linha, talvez o seu aplicativo não seja vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para Author.Text não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation
Abstract
Incluir dados não validados em um cabeçalho de resposta HTTP pode possibilitar ataques de envenenamento de cache, cross-site scripting, desfiguração entre usuários ou sequestro de página.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado contra caracteres mal-intencionados.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de um formulário HTML e o define em um cabeçalho de cookie de uma resposta HTTP.


...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.

EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cobol.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação da Web.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de um formulário da Web e o define em um cabeçalho de cookie de uma resposta HTTP.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1/1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem validação.

Tal como acontece com muitas vulnerabilidades de segurança de software, Header Manipulation é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos servidores de aplicativos modernos de hoje impedirão a injeção de caracteres mal-intencionados nos cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o 'content-type' de uma solicitação HTTP e o define no cabeçalho de uma nova solicitação HTTP.


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});


Como o valor do cabeçalho 'Content-Type' é formado por entrada de usuário não validada, ele pode ser manipulado por agentes mal-intencionados para explorar vulnerabilidades, executar ataques de injeção de código, expor dados confidenciais, permitir a execução de arquivos maliciosos ou acionar situações de negação de serviço, apresentando riscos significativos à segurança e à estabilidade do aplicativo.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, cross-site scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou Open Redirect.
Explanation
Vulnerabilidades de Header Manipulation ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.


Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques como a Falsificação de Solicitações entre Sites, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Standards Mapping - Common Weakness Enumeration CWE ID 113
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade de criação de respostas HTTP arbitrárias do invasor permite uma variedade de ataques resultantes, incluindo: envenenamento de cache da Web e do navegador, cross-site scripting e sequestro de página.


Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.


2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir considera que name e value podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...


Considerando um par de nome/valor que consiste em author e Jane Smith, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base na entrada de usuário não validada, um invasor pode enviar um par de nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas no seguinte formato:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.objc.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, as versões recentes de PHP gerarão a criação de um cabeçalho e de um aviso e de interrupção quando novas linhas são passadas para a função header(). Se a sua versão de PHP impedir a definição de cabeçalhos com novos caracteres de linha, seu aplicativo não estará vulnerável à Divisão de resposta HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e a define no campo de localização de cabeçalho de uma resposta HTTP.


<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.sql.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e a define no campo de localização de cabeçalho de uma resposta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. No pior dos casos, um invasor pode fornecer conteúdo especialmente concebido a fim de imitar o comportamento do aplicativo, mas, redirecionando informações privadas, como números de conta e senhas para o invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome da autora de um blog, author, a partir de uma solicitação HTTP e o usa em uma solicitação GET em outra parte do site.


author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")


Supondo que uma cadeia composta por caracteres alfanuméricos, como "Jane Smith", seja enviada na solicitação, a resposta HTTP pode assumir esta forma:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...


No entanto, uma vez que o valor da URL é formado por entradas de usuário inválidas, a resposta só manterá esta forma se o valor enviado para AUTHOR_PARAM não contiver quaisquer caracteres CR e LF. Se um invasor enviar uma cadeia maliciosa, como "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...", então a resposta HTTP seria dividida em duas respostas neste formato:


POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker

POST /index.php HTTP/1.1
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se a resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo malicioso até que a entrada de cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation ou open redirect.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, o Play Framework lançará uma exceção se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impedir a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não será vulnerável à HTTP Response Splitting. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Cookie Manipulation ou Open Redirects e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.


2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir considera que name e value podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:


...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...


Considerando um par de nome/valor que consiste em author e Jane Smith, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:


HTTP/1.1 200 OK
...
author:Jane Smith
...


No entanto, como o valor do cabeçalho é formado com base na entrada de usuário não validada, um invasor pode enviar um par de nome/valor mal-intencionado, como HTTP/1.1 200 OK\r\n...foo e bar, e a resposta HTTP seria dividida em duas respostas no seguinte formato:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.swift.header_manipulation
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos servidores de aplicativos modernos impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. No entanto, os servidores que dão suporte ao ASP clássico muitas vezes não têm esse mecanismo de proteção.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.abap.header_manipulation_cookies
Abstract
A inclusão de dados não validados nos cookies pode levar a Header Manipulation de resposta HTTP e permitir envenenamento de cache, cross-site scripting, desfiguração entre usuários, invasão de página, manipulação de cookie ou Open Redirect.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Os dados entram em um aplicativo Web por meio de uma fonte não confiável, mais frequentemente em uma solicitação HTTP.



2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.



Assim como ocorre com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, não um fim em si. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques como Cross-Site Request Forgery, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de Cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos servidores de aplicativos modernos de hoje impedirão a injeção de caracteres mal-intencionados nos cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, de uma solicitação HTTP, e o define em um cabeçalho de cookie de uma resposta HTTP.


...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta só manterá esse formato se o valor enviado para author não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que fará com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local será afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Enviando uma solicitação que resulta em duas respostas (a resposta pretendida do servidor e a resposta gerada pelo invasor), um invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, direcione indevidamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.apex.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dotnet.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Amit Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] Diabolic Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.cfml.header_manipulation_cookies
Abstract
A inclusão de dados não validados nos cookies pode levar a Header Manipulation de resposta HTTP e permitir envenenamento de cache, cross-site scripting, desfiguração entre usuários, invasão de página, manipulação de cookie ou Open Redirect.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Assim como ocorre com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, não um fim em si. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques como a Falsificação de Solicitações entre Sites, os invasores podem alterar, acrescentar ou até mesmo sobrescrever os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (alimentação de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos servidores de aplicativos modernos de hoje impedem a injeção de caracteres mal-intencionados nos cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta só manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor pode fazer uma única solicitação a um servidor vulnerável que faz com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, ele continuará recebendo o conteúdo mal-intencionado até que a entrada do cache seja removida, embora apenas o usuário da instância do navegador local seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, há grande variedade de conteúdo mal-intencionado que eles podem fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo da Web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, um invasor pode aproveitar a mesma vulnerabilidade raiz para redirecionar ao invasor conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 113
[2] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[52] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Algumas pessoas acham que, no mundo móvel, vulnerabilidades clássicas de aplicativos Web, como manipulação de cabeçalhos e cookies, não fazem sentido -- por que um usuário atacaria ele próprio? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos que são baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 2: O código a seguir adapta o Example 1 à plataforma Android.


...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);

...
Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.java.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Cross-User Defacement: Um invasor pode fazer uma única solicitação a um servidor vulnerável que fará com que o servidor crie duas respostas. A segunda delas pode ser mal interpretada como resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa capacidade de convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança do aplicativo. Na pior das hipóteses, um invasor pode fornecer conteúdo especialmente criado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de conta e senhas, de volta ao invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.javascript.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.php.header_manipulation_cookies
Abstract
A inclusão de dados não validados em um cabeçalho de resposta HTTP pode permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cabeçalho de resposta HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho é um meio para um fim, e não um fim por si só. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho de resposta HTTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e a define no campo de localização de cabeçalho de uma resposta HTTP.


location = req.field('some_location')
...
response.addHeader("location",location)


Supondo que uma cadeia de caracteres que consiste em caracteres alfanuméricos padrão, como "index.html", seja enviada na solicitação, a resposta HTTP, incluindo este cookie, pode ter a seguinte forma:


HTTP/1.1 200 OK
...
location: index.html
...


No entanto, como o valor da localização é formado por entrada de usuário não validada, a resposta só manterá essa forma se o valor enviado para some_location não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:


HTTP/1.1 200 OK
...
location: index.html

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. No pior dos casos, um invasor pode fornecer conteúdo especialmente concebido a fim de imitar o comportamento do aplicativo, mas, redirecionando informações privadas, como números de conta e senhas para o invasor.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.python.header_manipulation
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como cache-poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation ou open redirect.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a cookie manipulation é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de cookie manipulation também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impedir a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não será vulnerável à HTTP Response Splitting. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Cookie Manipulation ou Open Redirects e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.scala.header_manipulation_cookies
Abstract
A inclusão de dados não validados em Cookies pode resultar na manipulação de cabeçalho de Respostas HTTP, além de permitir ataques como envenenamento de cache, Cross-Site Scripting, desfiguração entre usuários, sequestro de páginas, manipulação de cookies ou redirecionamento aberto.
Explanation
Vulnerabilidades de Manipulação de Cookie ocorrem quando:

1. Dados entram em um aplicativo Web através de uma fonte não confiável, mais frequentemente uma solicitação HTTP.

2. Os dados são incluídos em um cookie HTTP enviado para um usuário da Web sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a manipulação de cookie é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cookie HTTP.

Manipulação de Cookie: Em combinação com ataques, como falsificação de solicitações entre sites, os invasores podem alterar, adicionar ou até mesmo substituir os cookies de um usuário legítimo.

Sendo cabeçalhos de Resposta HTTP, ataques de manipulação de cookie também podem resultar em outros tipos de ataques, como:

Divisão de Respostas HTTP:
Um dos ataques mais comuns de Manipulação de Cabeçalho é a Divisão de Respostas HTTP. Para montar uma exploração bem-sucedida de Divisão de Respostas HTTP, o aplicativo deve permitir entradas que contenham caracteres de CR (retorno de carro, também especificado por %0d ou \r) e LF (avanço de linha, também especificado por %0a ou \n) no cabeçalho. Esses caracteres não só dão controle aos invasores sobre os cabeçalhos restantes e o corpo da resposta que o aplicativo pretende enviar, como também lhes permite criar respostas adicionais totalmente sob seu controle.

Muitos dos modernos servidores de aplicativos de hoje impedirão a injeção de caracteres mal-intencionados em cabeçalhos HTTP. Por exemplo, versões recentes do Apache Tomcat lançarão uma IllegalArgumentException se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.

Exemplo 1: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.


...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...


Supondo que uma string formada por caracteres alfanuméricos padrão, como "Jane Smith", seja enviada na solicitação, a resposta HTTP que inclui esse cookie pode assumir o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para AUTHOR_PARAM não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:


HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...


Claramente, a segunda resposta é completamente controlada pelo invasor e pode ser construída com qualquer conteúdo de cabeçalho e corpo desejado. A capacidade do invasor de construir respostas HTTP arbitrárias permite uma grande variedade de ataques resultantes, entre eles: desfiguração entre usuários, envenenamento de cache da Web e do navegador, Cross-Site Scripting e sequestro de páginas.

Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.

Envenenamento de Cache: O impacto de uma resposta construída de maneira mal-intencionada pode ser ampliado quando ela é armazenada em cache por um cache de Web utilizado por vários usuários ou até mesmo pelo cache do navegador de um único usuário. Se uma resposta for armazenada em um cache da Web compartilhado, como aqueles comumente encontrados em servidores proxy, todos os usuários desse cache continuarão a receber o conteúdo mal-intencionado até que a entrada do cache seja removida. Da mesma forma, se a resposta for armazenada em cache no navegador de um usuário individual, esse usuário continuará a receber o conteúdo mal-intencionado até que a entrada do cache seja removida, embora nesse caso somente o usuário da instância local do navegador seja afetado.

Cross-Site Scripting: Depois que os invasores controlam as respostas enviadas por um aplicativo, eles podem escolher dentre grande variedade de conteúdo mal-intencionado para fornecer aos usuários. Cross-Site Scripting é uma forma comum de ataque em que JavaScript mal-intencionado ou outro código incluído em uma resposta é executado no navegador do usuário. A variedade de ataques com base em XSS é quase ilimitada, mas costuma incluir a transmissão de dados privados, como cookies ou outras informações de sessão, para o invasor, o redirecionamento da vítima para um conteúdo web controlado pelo invasor ou a realização de outras operações mal-intencionadas na máquina do usuário, sob a aparência do site vulnerável. O vetor de ataque mais comum e perigoso contra os usuários de um aplicativo vulnerável usa JavaScript para transmitir informações de sessão e autenticação de volta ao invasor, que pode em seguida assumir o controle total sobre a conta da vítima.

Sequestro de Páginas: Além de usar um aplicativo vulnerável para enviar conteúdo mal-intencionado a um usuário, a mesma vulnerabilidade raiz também pode ser aproveitada para redirecionar ao invasor o conteúdo confidencial gerado pelo servidor e destinado ao usuário. Ao enviar uma solicitação que resulta em duas respostas, isto é, a resposta pretendida do servidor e a resposta gerada pelo invasor, esse invasor pode fazer com que um nó intermediário, como um servidor proxy compartilhado, oriente incorretamente ao invasor uma resposta gerada pelo servidor para o usuário. Como a solicitação feita pelo invasor gera duas respostas, a primeira é interpretada como uma resposta à solicitação do invasor, enquanto a segunda permanece no limbo. Quando o usuário faz uma solicitação legítima através da mesma conexão TCP, a solicitação do invasor já está aguardando e é interpretada como uma resposta à solicitação da vítima. Em seguida, o invasor envia uma segunda solicitação para o servidor, à qual o servidor proxy responde com a solicitação gerada pelo servidor para a vítima, comprometendo assim qualquer informação confidencial nos cabeçalhos ou no corpo da resposta destinada à vítima.

Redirecionamento Aberto: Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
References
[1] A. Klein Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics
[2] D. Crab HTTP Response Splitting
[3] Standards Mapping - Common Weakness Enumeration CWE ID 113
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[10] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.vb.header_manipulation_cookies
Abstract
Incluir dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para vazar o conteúdo do e-mail para eles mesmos ou usar o servidor de correio como um bot de spam.
Explanation
As vulnerabilidades de SMTP Header Manipulation ocorrem quando:

1. Os dados entram em um aplicativo por meio de uma fonte não confiável, mais frequentemente, uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado a um servidor de correio sem validação.

Como acontece com muitas vulnerabilidades de segurança de software, SMTP Header Manipulation é um meio para um fim, não um fim por si só. Em sua raiz, a vulnerabilidade é direta: um invasor passa dados mal-intencionados para um aplicativo vulnerável e o aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques de SMTP Header Manipulation mais comuns é distribuir e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo 1: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cookie é formado por uma entrada de usuário não validada, a resposta só manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Parabéns!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP serão:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


De fato, isso permite que um invasor crie mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

1. Dados entram em um aplicativo através de uma fonte não confiável, mais frequentemente uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de Cabeçalho SMTP é usado para distribuir emails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo 1: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

1. Dados entram em um aplicativo através de uma fonte não confiável, mais frequentemente uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de cabeçalho SMTP é para o uso da distribuição de e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo 1: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
A inclusão de dados não validados em um cabeçalho SMTP pode permitir que invasores adicionem cabeçalhos arbitrários, como CC ou BCC, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.
Explanation
Vulnerabilidades de Manipulação de Cabeçalho SMTP ocorrem quando:

1. Dados entram em um aplicativo através de uma fonte não confiável, mais frequentemente uma solicitação HTTP em um aplicativo Web.

2. Os dados são incluídos em um cabeçalho SMTP enviado para um servidor de e-mail sem ser validado.

Tal como acontece com muitas vulnerabilidades de segurança de software, a Manipulação de Cabeçalho SMTP é um meio para um fim, e não um fim em si mesma. Em sua raiz, a vulnerabilidade é simples e direta: um invasor transmite dados mal-intencionados a um aplicativo vulnerável, e esse aplicativo inclui os dados em um cabeçalho SMTP.

Um dos ataques mais comuns de Manipulação de cabeçalho SMTP é para o uso da distribuição de e-mails de spam. Se um aplicativo contiver um formulário vulnerável "Fale conosco" que permite definir o assunto e o corpo do e-mail, um invasor poderá definir qualquer conteúdo arbitrário e injetar um cabeçalho CC com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.

Exemplo 1: O seguinte segmento de código lê o assunto e o corpo de um formulário "Fale conosco":


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


Supondo que uma string formada por caracteres alfanuméricos padrão, como "A página não funciona", seja enviada na solicitação, os cabeçalhos SMTP podem assumir o seguinte formato:


...
subject: [Contact us query] Page not working
...


No entanto, como o valor do cabeçalho é construído a partir de uma entrada de usuário não validada, a resposta apenas manterá esse formato se o valor enviado para subject não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


Isso permitirá efetivamente que um invasor elabore mensagens de spam ou envie e-mails anônimos entre outros ataques.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
Não use realloc() para redimensionar buffers que armazenam informações confidenciais. A função pode deixar uma cópia dessas informações confidenciais retida na memória, onde elas não podem ser sobrescritas.
Explanation
As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função realloc() costuma ser usada para aumentar o tamanho de um bloco de memória alocada. Muitas vezes, essa operação requer a cópia do conteúdo do bloco de memória antigo em um bloco novo e maior. Essa operação deixa o conteúdo do bloco original intacto, mas inacessível ao programa, impedindo que ele consiga limpar dados confidenciais da memória. Se mais tarde um invasor puder examinar o conteúdo de um despejo de memória, os dados confidenciais poderão ficar expostos.

Exemplo 1: O código a seguir chama realloc() em um buffer contendo dados confidenciais:


plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);


Há uma tentativa de limpar os dados confidenciais da memória, mas, como realloc() é usado, uma cópia dos dados ainda pode ser exposta na memória originalmente alocada para plaintext_buffer.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 244
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 8.3.6 Sensitive Private Data (L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection
Abstract
Não use VirtualLock para bloquear páginas que contêm dados confidenciais. A função nem sempre é implementada.
Explanation
As vulnerabilidades de inspeção de heap ocorrem quando dados confidenciais, como uma senha ou uma chave de criptografia, podem ser expostos a um invasor porque não foram removidos da memória.

A função VirtualLock destina-se a bloquear páginas na memória para impedir que elas sejam paginadas no disco. No entanto, no Windows 95/98/ME, a função é implementada apenas como rascunho e não tem nenhum efeito.

References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 591
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[11] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection_swappable_memory
Abstract
Definir X-XSS-Protection como 1; mode=block para todas as versões do Internet Explorer provoca uma possível vulnerabilidade de cross-site scripting nas versões mais antigas do navegador.
Explanation
X-XSS-Protection é um cabeçalho HTTP introduzido pela Microsoft e, desde então, adotado por outros navegadores. Ele se destinava a ajudar a impedir que ataques de Cross-Site Scripting sejam bem sucedidos, mas, inadvertidamente, levou a uma vulnerabilidade que tornava vulneráveis sites seguros[1]. Por isso, isso não deve ser utilizado em versões mais antigas do Internet Explorer e deve ser desabilitado mediante a definição do cabeçalho como 0.

Exemplo 1: O seguinte configura incorretamente o middleware Helmet em um aplicativo Express para ativar isso em todas as versões do Internet Explorer:


var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...
References
[1] Eduardo Vela Nava, David Lindsay Abusing Internet Explorer 8's XSS Filters
[2] Standards Mapping - Common Weakness Enumeration CWE ID 554
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 CM
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (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 A05 Security Misconfiguration
[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 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.helmet_misconfiguration_insecure_xss_filter
Abstract
O programa cria um campo de formulário oculto.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1:

HtmlInputHidden hidden = new HtmlInputHidden();


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
O programa cria um campo de formulário oculto.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1:

Hidden hidden = new Hidden(element);


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - Common Weakness Enumeration CWE ID 472
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[8] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[9] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[10] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[32] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[33] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
Um campo de formulário oculto é usado.
Explanation
Os programadores geralmente confiam no conteúdo de campos ocultos, esperando que os usuários não sejam capazes de visualizar esses campos ou de manipular seu conteúdo. Os invasores violarão essas suposições. Eles vão examinar os valores gravados em campos ocultos e alterá-los ou substituir o conteúdo por dados de ataque.

Exemplo 1: Uma tag <input> do tipo hidden indica o uso de um campo oculto.

<input type="hidden">


Se campos ocultos contiverem informações confidenciais, estas serão armazenadas em cache da mesma forma que o restante da página. Isso pode fazer com que informações confidenciais sejam escondidas no cache do navegador sem o conhecimento do usuário.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 472
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[3] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[4] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[5] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[6] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[7] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[8] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[9] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[10] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[11] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[12] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[13] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[14] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002485 CAT I
[31] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[32] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de criação de scripts entre sites.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] HttpResponse.AppendHeader Method
[4] How to prevent cross-site scripting security issues
[5] HOW TO: Disable the Documentation Protocol for ASP.NET Web Services
[6] Configuring Services Using Configuration Files
[7] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[15] Standards Mapping - FIPS200 CM
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[23] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[25] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[26] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.dotnet.html5_xss_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.

Exemplo 1: O seguinte código configura um aplicativo protegido do Spring Security para desabilitar a proteção XSS:

<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.java.html5_cross_site_scripting_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.
O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] Node.js Security Checklist
[4] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 CM
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[18] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[19] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dataflow.javascript.html5_cross_site_scripting_protection
Abstract
O cabeçalho X-XSS-Protection é explicitamente desabilitado, o que pode aumentar o risco de ataques de cross-site scripting.
Explanation
O cabeçalho X-XSS-Protection normalmente é habilitado por padrão em navegadores modernos. Quando o valor do cabeçalho está definido como false (0), a proteção contra cross-site scripting está desabilitada.

O cabeçalho pode ser definido em vários locais e deve ser verificado no que se refere a problemas de configuração imprópria e adulteração mal-intencionada.
References
[1] IE8 Security Part IV: The XSS Filter
[2] OWASP OWASP Secure Headers Project
[3] django-secure
[4] SECURE_BROWSER_XSS_FILTER
[5] Standards Mapping - Common Weakness Enumeration CWE ID 554, CWE ID 1173
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[11] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[13] Standards Mapping - FIPS200 CM
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 14.1.3 Build (L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[21] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[24] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.structural.python.html5_cross_site_scripting_protection
Abstract
Um nome de banco de dados SQL da Web que seja fácil de adivinhar pode levar ao roubo e à corrupção de dados por pessoas não autorizadas.
Explanation
Uma das características do HTML5 é a capacidade de armazenar dados em um banco de dados SQL do lado do cliente. A principal informação necessária para iniciar a gravação e a leitura do banco de dados é o nome dele. Portanto, é crucial que o nome do banco de dados seja uma cadeia única diferente para cada usuário. Se o nome do banco de dados for fácil de adivinhar, terceiros não autorizados, como outros usuários, podem ser capazes de roubar dados confidenciais ou corromper as entradas do banco de dados.
Exemplo 1: O código a seguir usa um nome de banco de dados fácil de adivinhar:


...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...


Este código será executado com sucesso, mas qualquer pessoa que possa adivinhar o nome do banco de dados como 'mydb' pode acessá-lo.
References
[1] HTML5 Security Cheatsheet
[2] Standards Mapping - Common Weakness Enumeration CWE ID 330
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[11] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7 - Use of Cryptography
[28] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Predictable Resource Location (WASC-34)
[37] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.javascript.html5_easy_to_guess_database_name
Abstract
A validação HTML5 de campos de formulário de entrada está desabilitada.
Explanation
O HTML5 fornece uma nova habilidade de realizar uma validação simples de campos de formulário de entrada. É possível especificar se um campo de formulário de entrada é necessário com o uso do atributo required. Especificar o tipo de campo garante que a entrada seja verificada com relação ao seu tipo. É possível até mesmo fornecer um atributo pattern personalizável que verifica a entrada em relação a uma expressão regular. No entanto, essa validação é desabilitada com a adição de um atributo novalidate a uma tag de formulário e de um atributo formnovalidate a uma tag de entrada de envio.

Exemplo 1: O exemplo a seguir desabilita a validação de formulário por meio de um atributo novalidate.


<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
Exemplo 2: O exemplo a seguir desabilita a validação de formulário por meio de um atributo formnovalidate.


<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>


Formulários HTML com validação desabilitada não são de fácil utilização e podem expor o servidor a vários tipos de ataques. Entradas não verificadas resultam são a causa raiz de vulnerabilidades, como criação de scripts entre sites, controle de processos e SQL Injection.
References
[1] HTML5 form novalidate Attribute W3Schools
[2] HTML5 input formnovalidate Attribute W3Schools
[3] Standards Mapping - Common Weakness Enumeration CWE ID 1173
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[19] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[20] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.content.html.html5_form_validation_turned_off
Abstract
O programa define uma Política de Abertura de Origens Cruzadas (COOP) excessivamente permissiva
Explanation
Tornou-se importante impor a privacidade dos dados de um determinado documento da Web devido à existência de explorações de canais laterais resultantes de vulnerabilidades como Spectre e Meltdown. A Política de Abertura de Origens Cruzadas (COOP) foi criada para ajudar a prevenir a exposição de informações confidenciais devido a ataques de canal lateral. Especificamente, o COOP pode impor o isolamento do grupo de contexto de navegação de um documento em relação a outros documentos externos, como pop-ups.

Exemplo 1: O código a seguir mostra uma configuração COOP insegura de "unsafe-none" na estrutura do Django. Isso pode permitir que um documento externo acesse os dados privados do grupo de contexto de navegação de um documento de origem devido a um ataque de canal lateral.


SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'
References
[1] Eiji Kitamura, Domenic Denicola Why you need "cross-origin isolated" for powerful features
[2] Standards Mapping - Common Weakness Enumeration CWE ID 346
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[7] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.6 - Web Software Attack Mitigation
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.python.html5_insecure_cross_origin_opener_policy