160 itens encontrados
Vulnerabilidades
Abstract
Permitir que a entrada do usuário altere permissões de arquivo diretamente pode deixar que um invasor acesse recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de File Permission Manipulation ocorrem quando qualquer uma das seguintes condições é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica as permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa entrada de variáveis de ambiente do sistema para definir permissões de arquivo. Se os invasores puderem alterar as variáveis de ambiente do sistema, poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável a Path Manipulation, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrariamente no sistema.


permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[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.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.file_permission_manipulation
Abstract
Permitir que a entrada do usuário altere permissões de arquivo diretamente pode deixar que um invasor acesse recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa a entrada de propriedades do sistema para definir a máscara de permissão padrão. Se os invasores puderem alterar as propriedades do sistema, eles poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.


String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
References
[1] FIO01-J. Create files with appropriate access permissions CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[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.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] 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
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.file_permission_manipulation
Abstract
Permitir que a entrada do usuário altere permissões de arquivo diretamente pode deixar que um invasor acesse recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo: O código a seguir é projetado para definir as permissões de arquivo adequadas para os usuários fazerem upload de páginas da Web por meio de FTP. Ele usa a entrada de uma solicitação HTTP para marcar um arquivo como visualizável para usuários externos.


$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...


No entanto, se um invasor fornecer um valor mal-intencionado para publicReport, como "../../localuser/public_html/.htpasswd", o aplicativo tornará o arquivo especificado como legível para o invasor.

Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para definir a máscara de permissão padrão. Se os invasores puderem alterar o arquivo de configuração, eles poderão usar o programa para obter acesso aos arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.


...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[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.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] 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
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.file_permission_manipulation
Abstract
Permitir que a entrada do usuário altere permissões de arquivo diretamente pode deixar que um invasor acesse recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de File Permission Manipulation ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo 1: O código a seguir usa entrada de variáveis de ambiente do sistema para definir permissões de arquivo. Se os invasores puderem alterar as variáveis de ambiente do sistema, eles poderão usar o programa para obter acesso a arquivos manipulados pelo programa. Se o programa também for vulnerável à Path Manipulation, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.


permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[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.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.file_permission_manipulation
Abstract
Permitir que a entrada do usuário altere permissões de arquivo diretamente pode deixar que um invasor acesse recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de permissões de arquivo ocorrem quando qualquer uma das condições a seguir é atendida:

1. Um invasor pode especificar um caminho usado em uma operação que modifica permissões no sistema de arquivos.

2. Um invasor pode especificar as permissões atribuídas por uma operação no sistema de arquivos.

Exemplo: O código a seguir é projetado para definir as permissões de arquivo adequadas para os usuários fazerem upload de páginas da Web por meio de FTP. Ele usa a entrada de uma solicitação HTTP para marcar um arquivo como visualizável para usuários externos.


...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...


No entanto, se um invasor fornecer um valor mal-intencionado para publicReport, como "../../localuser/public_html/.htpasswd", o aplicativo tornará o arquivo especificado como legível para o invasor.

Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para definir a máscara de permissão padrão. Se os invasores puderem alterar o arquivo de configuração, eles poderão usar o programa para obter acesso aos arquivos manipulados pelo programa. Se o programa também for vulnerável à manipulação de caminho, um invasor poderá usar essa vulnerabilidade para acessar arquivos arbitrários no sistema.


...
mask = config_params['perms']
File.chmod(filename, mask)
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[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.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] 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
[36] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
O programa define uma política entre domínios excessivamente permissiva.
Explanation
Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao alterar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques.

Exemplo 1: O trecho a seguir é um exemplo de uso de um caractere curinga para especificar programaticamente os domínios com os quais o aplicativo tem permissão para se comunicar.


flash.system.Security.allowDomain("*");


O uso de * como argumento para allowDomain() indica que os dados do aplicativo estão acessíveis a outros aplicativos SWF de qualquer domínio.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 942
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
O programa define uma política de cabeçalhos personalizados excessivamente permissiva.
Explanation
Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. A partir do Flash Player 9.0.124.0, a Adobe também introduziu a capacidade de definir quais cabeçalhos personalizados o Flash Player pode enviar entre domínios. No entanto, é preciso ter cuidado ao definir essas configurações porque uma política de cabeçalhos personalizados excessivamente permissiva, quando aplicada junto com a política de vários domínios excessivamente permissiva, permitirá que um aplicativo mal-intencionado envie cabeçalhos de sua escolha para o aplicativo de destino, levando, possivelmente, a um variedade de ataques ou causando erros na execução do aplicativo que não saberá como tratar os cabeçalhos recebidos.

Exemplo 1: A configuração a seguir mostra o uso de um caractere curinga para especificar quais cabeçalhos o Flash Player pode enviar entre domínios.


<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>


Usar * como o valor do atributo de headers indica que qualquer cabeçalho será enviado entre domínios.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
O programa usa entradas de usuário não validadas para se esquivar de restrições de política entre domínios.
Explanation
Por padrão, aplicativos Flash estão sujeitos à Política de Mesma Origem, que garante que dois aplicativos SWF possam acessar os dados um do outro somente se forem provenientes do mesmo domínio. O Adobe Flash permite que os desenvolvedores alterem essa política programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao decidir quem pode influenciar as configurações, pois uma política entre domínios excessivamente permissiva permitirá que um aplicativo mal-intencionado se comunique com o aplicativo vítima de modo impróprio, resultando em falsificação, roubo de dados, retransmissão e outros ataques. Vulnerabilidades de desvio de restrições de política ocorrem quando:

1. Os dados entram no aplicativo por uma fonte não confiável.

2. Os dados são utilizados para carregar ou modificar configuração de política entre domínios.
Exemplo 1: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado como a URL a partir da qual carregar o arquivo de política entre domínios.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
Exemplo 2: O código a seguir usa o valor de um dos parâmetros para o arquivo SWF carregado com o objetivo de definir a lista de domínios confiáveis.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] 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
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
O programa permite que aplicativos SWF HTTP e HTTPS se comuniquem.
Explanation
A partir do Flash Player 7, aplicativos SWF carregados via HTTP não podem acessar dados de aplicativos SWF carregados via HTTPS por padrão. O Adobe Flash permite que os desenvolvedores alterem essa restrição programaticamente ou por meio das configurações apropriadas no arquivo de configuração crossdomain.xml. No entanto, é necessário tomar precauções ao definir essas configurações, pois aplicativos SWF carregados via HTTP estão sujeitos a ataques do tipo MITM (man-in-the-middle) e, portanto, não devem ser confiáveis.

Exemplo: O código a seguir chama allowInsecureDomain(), que desativa a restrição que impede aplicativos SWF carregados via HTTP de acessar os dados de aplicativos SWF carregados via HTTPS.


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[25] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
As informações de depuração ajudam os invasores a aprender sobre o sistema e planejar uma forma de ataque.
Explanation
Se você estiver usando o Blaze DS para realizar o registro em log de eventos inesperados, o arquivo descritor services-config.xml especificará um elemento XML "Logging" para descrever vários aspectos desse registro. Parece o seguinte:

Exemplo:

<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[BlazeDS]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>


Essa tag target usa um atributo opcional denominado level, que indica o nível de log. Se o nível de depuração for definido com um nível muito detalhado, seu aplicativo pode gravar dados confidenciais no arquivo de log.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 11
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[8] Standards Mapping - FIPS200 CM
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-11 Error Handling (P2)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-11 Error Handling
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[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.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
Abstract
Permitir que um invasor controle a string de formato de uma função pode resultar em um buffer overflow.
Explanation
Vulnerabilidades de string de formato ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são transmitidos como o argumento de string de formato para uma função como sprintf(), FormatMessageW() ou syslog().
Exemplo 1: O código a seguir copia um argumento de linha de comando em um buffer usando snprintf().


int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}


Esse código permite que um invasor visualize o conteúdo da pilha e grave nessa pilha usando um argumento de linha de comando que contém uma sequência de diretivas de formatação. O invasor pode ler a partir da pilha fornecendo mais diretivas de formatação, como %x, do que a função utiliza como argumentos a serem formatados. (Neste exemplo, a função não usa argumentos a serem formatados.) Ao usar a diretiva de formatação %n, o invasor pode gravar na pilha, fazendo com que snprintf() grave no argumento especificado o número de bytes cuja saída foi processada até o momento (em vez de ler um valor do argumento, que é o comportamento pretendido). Uma versão sofisticada desse ataque usará quatro gravações escalonadas para controlar completamente o valor de um apontador na pilha.

Exemplo 2: Certas implementações facilitam ainda mais alguns ataques mais avançados, fornecendo diretivas de formato que controlam a localização na memória na qual realizar leituras ou gravações. Um exemplo dessas diretivas é mostrado no código a seguir, escrito para glibc:


printf("%d %d %1$d %1$d\n", 5, 9);


Esse código produz a seguinte saída:


5 9 5 5


Também é possível usar meias-gravações (%hn) para controlar com precisão DWORDS arbitrários na memória, o que reduz significativamente a complexidade necessária para executar um ataque que, de outra forma, exigiria quatro gravações escalonadas, como o mencionado no Example 1.

Exemplo 3: As vulnerabilidades de string de formato simples muitas vezes são resultantes de atalhos aparentemente inofensivos. O uso de alguns desses atalhos é tão arraigado que os programadores talvez nem mesmo percebam que a função que eles estão usando espera um argumento de string de formato.

Por exemplo, a função é syslog() por vezes utilizada da seguinte maneira:


...
syslog(LOG_ERR, cmdBuf);
...


Como o segundo parâmetro para syslog() é uma string de formato, qualquer diretiva de formatação incluída em cmdBuf é interpretada conforme descrito no Example 1.

O código a seguir mostra o uso correto de syslog():


...
syslog(LOG_ERR, "%s", cmdBuf);
...
References
[1] T. Newsham Format String Attacks Guardent, Inc.
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 134
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.4.2 Memory/String/Unmanaged Code Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[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.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.cpp.format_string
Abstract
Um invasor pode controlar o argumento de formato String que permite um ataque muito parecido com um buffer overflow.
Explanation
Vulnerabilidades de string de formato ocorrem quando:

1. Os dados entram em um aplicativo por uma fonte não confiável.



2. Os dados são transmitidos a uma função tal como sprintf(), FormatMessageW(), syslog(), NSLog, ou NSString.stringWithFormatcomo um argumento do formato String
Exemplo 1: O código a seguir utiliza um argumento de linha de comando como um formato String em NSString.stringWithFormat:.


int main(int argc, char **argv){
char buf[128];
...
[NSString stringWithFormat:argv[1], argv[2] ];
}


Esse código permite a um invasor visualizar o conteúdo da pilha e danificá-la ao usar um argumento de linha de comando que contém uma sequência de diretivas de formatação. O invasor pode ler a partir da pilha fornecendo mais diretivas de formatação, como %x, do que a função utiliza como argumentos a serem formatados. (Neste exemplo, a função não usa argumentos a serem formatados.)

O Objective-C dá suporte às bibliotecas C padrão herdadas para que estes exemplos sejam exploráveis caso o seu aplicativo use APIs C.

Exemplo 2: Certas implementações facilitam ainda mais alguns ataques mais avançados, fornecendo diretivas de formato que controlam a localização na memória na qual realizar leituras ou gravações. Um exemplo dessas diretivas é mostrado no código a seguir, escrito para glibc:


printf("%d %d %1$d %1$d\n", 5, 9);


Esse código produz a seguinte saída:


5 9 5 5


Também é possível usar meias-gravações (%hn) para controlar com precisão DWORDS arbitrários na memória, o que reduz significativamente a complexidade necessária para executar um ataque que, de outra forma, exigiria quatro gravações escalonadas, como o mencionado no Example 1.

Exemplo 3: As vulnerabilidades de string de formato simples muitas vezes são resultantes de atalhos aparentemente inofensivos. O uso de alguns desses atalhos é tão arraigado que os programadores talvez nem mesmo percebam que a função que eles estão usando espera um argumento de string de formato.

Por exemplo, a função é syslog() por vezes utilizada da seguinte maneira:


...
syslog(LOG_ERR, cmdBuf);
...


Como o segundo parâmetro para syslog() é uma string de formato, qualquer diretiva de formatação incluída em cmdBuf é interpretada conforme descrito no Example 1.

O código a seguir mostra o uso correto de syslog():


...
syslog(LOG_ERR, "%s", cmdBuf);
...
Exemplo 4: As classes principais da Apple proporcionam rotas interessantes para explorar as vulnerabilidades do formato String.

Por exemplo, a função é String.stringByAppendingFormat() por vezes utilizada da seguinte maneira:


...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:[MyClass
formatInput:inputControl.text]];
...


O stringByAppendingFormat analisará todos os caracteres do formato String contidos na NSString transmitidos a ele.

O código a seguir mostra o uso correto de stringByAppendingFormat():


...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
References
[1] T. Newsham Format String Attacks Guardent, Inc.
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 134
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.4.2 Memory/String/Unmanaged Code Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[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.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.objc.format_string
Abstract
O programa usa uma cadeia de formato indevidamente construída que contém um número de especificadores de conversão diferente do número de argumentos da função. Cadeias de caracteres com formato incorreto podem fazer com que o programa leia dados fora dos limites da memória alocada, o que pode permitir o acesso a informações confidenciais, introduzir comportamentos impróprios ou travar o programa.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa acesse valores fora dos limites da memória alocada.

Exemplo: O exemplo a seguir lê valores arbitrários da pilha, porque o número de especificadores de formato não está alinhado ao número de argumentos transmitidos para a função.

void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 126
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[19] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[20] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[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.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_number_mismatch
Abstract
O programa usa uma cadeia de formato indevidamente construída que contém especificadores de conversão não alinhados aos tipos dos argumentos transmitidos para a função. Cadeias de caracteres com formato incorreto podem fazer com que o programa converta valores incorretamente e possivelmente leia ou grave fora dos limites da memória alocada, o que pode introduzir comportamentos impróprios ou travar o programa.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, uma cadeia de formato indevidamente construída faz com que o programa converta valores de dados ou acesse valores fora dos limites da memória alocada.

Exemplo: O código a seguir converte incorretamente f de um flutuante usando um especificador de formato %d.


void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", f);
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 125, CWE ID 787
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125, [12] CWE ID 787
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125, [2] CWE ID 787
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 10.3
[17] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-3
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[20] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[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.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_type_mismatch
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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: O segmento de código a seguir lê o nome do autor de uma entrada de blog, author, de um formulário HTML e o define no cabeçalho de um 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[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 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 - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] 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
[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.1 APSC-DV-002560 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 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-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 113
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[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 Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[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, Requirement 6.5.2
[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.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[57] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: O segmento de código a seguir lê a localização a partir de uma solicitação HTTP e define-a 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: Este segmento de código lê o local a partir de uma solicitação HTTP e o define como o cabeçalho do campo de localização 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: Este segmento de código lê o nome do autor 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 - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[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 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 - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] 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
[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.1 APSC-DV-002560 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 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-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 113
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - FIPS200 SI
[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 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 - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[20] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] 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
[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.1 APSC-DV-002560 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 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-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[56] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: Este segmento de código lê o local a partir de uma solicitação HTTP e o define como o cabeçalho do campo de localização 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 113
[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 Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A03 Injection
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[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.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 - Web 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.1 APSC-DV-002560 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 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 - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[58] 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: 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 - CIS Azure Kubernetes Service Benchmark 2.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 93
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Top 10 2004 A1 Unvalidated Input
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[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, Requirement 6.5.2
[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.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 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 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 - 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: O segmento de código a seguir 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 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 - 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: O segmento de código a seguir 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 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 - 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: O segmento de código a seguir 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 - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 93
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 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 - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.server.com/login.aspx?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.

...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...


URL: http://www.host.com/election.aspx?poll_id=4567
Link1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">English<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">Spanish<a>

O programador não considerou a possibilidade de que um invasor pudesse fornecer um lang como en&poll_id=1 e, em seguida, conseguisse alterar poll_id à vontade.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 Top 10 2004 A6 Injection Flaws
[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 - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.example.com/login.php?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.

...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...


URL: http://www.example.com?poll_id=4567
Link1: <a href="001">Inglês<a>
Link2: <a href="002">Espanhol<a>

O programador não considerou a possibilidade de que um invasor pudesse fornecer um lang como en&poll_id=1 e, em seguida, fosse capaz de alterar poll_id à vontade.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 Top 10 2004 A6 Injection Flaws
[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 - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Talvez ele obtenha dados somente do primeiro parâmetro
Talvez ele obtenha dados do último parâmetro
Talvez ele obtenha dados de todos os parâmetros e os concatene


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor de aplicativos e da lógica do aplicativo propriamente dito, a seguinte solicitação pode causar confusão para o sistema de autenticação e permitir que um invasor represente outro usuário.
http://www.server.com/login.php?name=alice&name=hacker

Exemplo 2: O código a seguir usa a entrada de uma solicitação HTTP para produzir dois hiperlinks.


<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>


URL: http://www.host.com/election.php?poll_id=4567
Link1: <a href="vote.php?poll_id=4567&candidate=white">Vote no Sr. White<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote na Sra. Green<a>

O programador não considerou a possibilidade de que um invasor pode fornecer uma poll_id como "4567&candidate=green" e, em seguida, a página resultante conterá os seguintes links injetados e, portanto, Sra. Green será sempre votada em um servidor de aplicativo que seleciona o primeiro parâmetro.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote no Sr. White<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote na Sra. Green<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 Top 10 2004 A6 Injection Flaws
[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 - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
Concatenar entradas não validadas em uma URL pode permitir que um invasor substitua o valor de um parâmetro de solicitação. O invasor pode ser capaz de substituir valores de parâmetros existentes, injetar um novo parâmetro ou explorar variáveis fora de alcance direto.
Explanation
Ataques de HPP (Poluição de Parâmetros HTTP) consistem em injetar delimitadores de cadeia de consulta codificados em outros parâmetros existentes. Se um aplicativo Web não limpar corretamente a entrada do usuário, um usuário mal-intencionado poderá comprometer a lógica do aplicativo para realizar ataques no lado do cliente ou no lado do servidor. Ao enviar parâmetros adicionais para um aplicativo Web e se esses parâmetros tiverem o mesmo nome de um parâmetro existente, esse aplicativo Web pode reagir de uma das seguintes maneiras:

Ele pode obter apenas os dados do primeiro parâmetro.
Ele pode obter os dados do último parâmetro.
Ele pode obter os dados de todos os parâmetros e concatená-los.


Por exemplo:
- ASP.NET/IIS usa todas as ocorrências dos parâmetros
- Apache Tomcat usa apenas a primeira ocorrência e ignora outras
- mod_perl/Apache converte o valor em uma matriz de valores

Exemplo 1: Dependendo do servidor do aplicativo e da lógica do próprio aplicativo, esta solicitação pode causar confusão para o sistema de autenticação e permitir a um invasor representar outro usuário.
http://www.server.com/login.php?name=alice&name=hacker

Conforme demonstrado, o invasor já especificou name=alice, mas adicionou name=alice& e, se isso estiver em uso em um servidor que obtém a primeira ocorrência, ele poderá representar alice para obter mais informações sobre a conta dela.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[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 Top 10 2004 A6 Injection Flaws
[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 - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2023 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 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 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
O aplicativo permite que extensões de teclado de terceiros sejam instaladas.
Explanation
As extensões de teclado têm permissão para ler todas as teclas que um usuário pressiona. Os teclados de terceiros são normalmente usados para facilitar a entrada de texto ou para adicionar emojis adicionais, e eles podem registrar em log o que o usuário insere ou até mesmo enviar esses logs para um servidor remoto para processamento. Os teclados mal-intencionados também podem ser distribuídos para atuar como um keylogger e ler todas as teclas pressionadas pelo usuário, a fim de roubar dados confidenciais, como credenciais ou números de cartão de crédito.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] UIApplicationDelegate Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.objc.input_interception_keyboard_extensions_allowed
Abstract
O aplicativo permite que extensões de teclado de terceiros sejam instaladas.
Explanation
As extensões de teclado têm permissão para ler todas as teclas que um usuário pressiona. Os teclados de terceiros são normalmente usados para facilitar a entrada de texto ou para adicionar emojis adicionais, e eles podem registrar em log o que o usuário insere ou até mesmo enviar esses logs para um servidor remoto para processamento. Os teclados mal-intencionados também podem ser distribuídos para atuar como um keylogger e ler todas as teclas pressionadas pelo usuário, a fim de roubar dados confidenciais, como credenciais ou números de cartão de crédito.
References
[1] UIApplicationDelegate Apple
[2] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.swift.input_interception_keyboard_extensions_allowed
Abstract
O programa usa o serviço de backup do Android para salvar dados de aplicativos persistentes em um armazenamento remoto em nuvem.
Explanation
O serviço de backup do Android permite que o aplicativo salve dados persistentes em um armazenamento remoto em nuvem para fornecer um ponto de restauração para os dados do aplicativo no futuro.

Os aplicativos Android podem ser configurados com este serviço de backup, definindo o atributo allowBackupcomo true (o valor padrão) e definindo o atributo backupAgent na tag do <application>.

O Android, entretanto, não garante a segurança dos seus dados durante o uso do backup, já que o armazenamento e transporte em nuvem variam de dispositivo para dispositivo.
References
[1] JavaDoc for Android Android
[2] Android Developers API Guide: Data Backup Android
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M8 Security Misconfiguration
[24] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.insecure_storage_android_backup_storage
Abstract
O programa grava dados no armazenamento externo do dispositivo Android.
Explanation
Arquivos salvos no armazenamento externo são legíveis publicamente e podem ser modificados pelo usuário quando permitem que armazenamento em massa via USB transfira arquivos em um computador. Além disso, os arquivos no cartão de armazenamento externo permanecerão lá até mesmo após a desinstalação do aplicativo que os gravou. Essas limitações podem comprometer informações confidenciais gravadas no armazenamento ou permitir que os invasores injetem dados mal-intencionados no programa, modificando um arquivo externo no qual ele se baseia.

Exemplo 1: No código a seguir, Environment.getExternalStorageDirectory() retorna uma referência ao armazenamento externo do dispositivo Android.

 private void WriteToFile(String what_to_write) {
try{
File root = Environment.getExternalStorageDirectory();
if(root.canWrite()) {
File dir = new File(root + "write_to_the_SDcard");
File datafile = new File(dir, number + ".extension");
FileWriter datawriter = new FileWriter(datafile);
BufferedWriter out = new BufferedWriter(datawriter);
out.write(what_to_write);
out.close();
}
}
}
References
[1] Data Storage
[2] Paul McNamara Latest 'lost' laptop holds treasure-trove of unencrypted ATT payroll data Network World
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 276, CWE ID 313, CWE ID 359, CWE ID 921
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [19] CWE ID 276, [20] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [20] CWE ID 276
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [25] CWE ID 276
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[15] Standards Mapping - FIPS200 MP
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.insecure_storage_android_external_storage
Abstract
O aplicativo torna os dados acessíveis a todos os aplicativos no dispositivo Android.
Explanation
Os dados armazenados no armazenamento interno do Android usando MODE_WORLD_READBLE ou MODE_WORLD_WRITEABLE podem ser acessados por todos os aplicativos no dispositivo. Isso não só nega proteção contra corrupção de dados, como também, no caso de informações confidenciais, viola preocupações com a privacidade e a segurança do usuário.
References
[1] Designing for Security Android
[2] S. Fahl, M. Harbach, T. Muders, M. Smith, L. Baumgartner, B. Friesleben Why Eve and Mallory Love Android:An Analysis of Android SSL (In)Security
[3] OWASP Mobile Security Testing Guide OWASP
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 276, CWE ID 313, CWE ID 359, CWE ID 921
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [19] CWE ID 276, [20] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [20] CWE ID 276
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [25] CWE ID 276
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[62] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.java.insecure_storage_android_world_readable_or_writeable
Abstract
O método identificado armazena dados no conjunto de chaves com um nível de acessibilidade que permite que o item seja armazenado em backup no iCloud e em backups não criptografados do iTunes.
Explanation
Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Os níveis de acessibilidade que não contêm o ThisDeviceOnly serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo estiver ligado e desbloqueado, mas o item de conjunto de chaves será armazenado em backup no iCloud e em backups não criptografados do iTunes:


...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.objc.insecure_storage_externally_available_keychain
Abstract
O método identificado armazena dados no conjunto de chaves com um nível de acessibilidade que permite que o item seja armazenado em backup no iCloud e em backups não criptografados do iTunes.
Explanation
Ao armazenar dados no conjunto de chaves, um nível de acessibilidade, que define quando será possível acessar o item, precisa ser configurado. Os níveis possíveis de acessibilidade incluem:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
Os dados no item de conjunto de chaves não poderão ser acessados após uma reinicialização até que o dispositivo tenha sido desbloqueado uma vez pelo usuário.
Após o primeiro desbloqueio, os dados permanecem acessíveis até a próxima reinicialização. Isso é recomendado para os itens que precisam ser acessados por aplicativos em segundo plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleAlways:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
Os dados no conjunto de chaves só podem ser acessados quando o dispositivo está desbloqueado. Disponível somente se uma senha estiver definida no dispositivo.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo nunca migram para um novo dispositivo. Depois que um backup é restaurado para um novo dispositivo, esses itens estarão ausentes. Nenhum item pode ser armazenado nesta classe em dispositivos sem uma senha. Desabilitar a senha do dispositivo faz com que todos os itens dessa classe sejam excluídos.
Disponível em iOS 8.0 ou posterior.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
Os dados no item de conjunto de chaves sempre podem ser acessados independentemente do dispositivo estar bloqueado.
Isso não é recomendado para uso do aplicativo. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlocked:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo migram para um novo dispositivo ao usar backups criptografados.
Esse é o valor padrão para os itens do conjunto de chaves adicionados sem definir explicitamente uma constante de acessibilidade.
Disponível em iOS 4.0 ou posterior.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
Os dados no item de conjunto de chaves só podem ser acessados quando o dispositivo é desbloqueado pelo usuário.
Isso é recomendado para itens que só precisam ser acessíveis enquanto o aplicativo está em primeiro plano. Os itens com esse atributo não migram para um novo dispositivo. Assim, após a restauração de um backup de um dispositivo diferente, esses itens não estarão presentes.
Disponível em iOS 4.0 ou posterior.

Os níveis de acessibilidade que não contêm o ThisDeviceOnly serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.

Exemplo 1: No exemplo a seguir, o item de conjunto de chaves está protegido o tempo todo, exceto quando o dispositivo estiver ligado e desbloqueado, mas o item de conjunto de chaves será armazenado em backup no iCloud e em backups não criptografados do iTunes:


...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlocked

SecItemAdd(query as CFDictionary, nil)
...
References
[1] Keychain Services Apple
[2] Keychain Item Accessibility Constants Apple
[3] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 312, CWE ID 359
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002475
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[23] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.6, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.2, Requirement 3.4, Requirement 4.2, Requirement 6.5.5, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.3.1, Requirement 3.5.1, Requirement 4.2.2, Requirement 6.2.4, Requirement 8.3.1
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.3 - Sensitive Data Retention, Control Objective 6.1 - Sensitive Data Protection, Control Objective B.2.5 - Terminal Software Design
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.swift.insecure_storage_externally_available_keychain
Abstract
O método identificado configura o cache de resposta HTTP(S) em um armazenamento compartilhado inseguro.
Explanation
As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as sem criptografia em um armazenamento compartilhado inseguro.

Exemplo 1: O código a seguir instala o cache de resposta HTTP(S) no espaço de armazenamento compartilhado:


protected void onCreate(Bundle savedInstanceState) {
...

try {
File httpCacheDir = new File(context.getExternalCacheDir(), "http");
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
HttpResponseCache.install(httpCacheDir, httpCacheSize);
} catch (IOException e) {
Log.i(TAG, "HTTP response cache installation failed:" + e);
}
}

protected void onStop() {
...

HttpResponseCache cache = HttpResponseCache.getInstalled();
if (cache != null) {
cache.flush();
}
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[24] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[25] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.java.insecure_storage_http_response_cache_leak
Abstract
O método identificado executa uma solicitação de URL sem configurar o sistema de carregamento de URL para impedir o armazenamento de cache das respostas HTTP(S).
Explanation
As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.objc.insecure_storage_http_response_cache_leak
Abstract
O método identificado executa uma solicitação de URL sem configurar o sistema de carregamento de URL para impedir o armazenamento de cache das respostas HTTP(S).
Explanation
As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.dataflow.swift.insecure_storage_http_response_cache_leak
Abstract
O aplicativo tenta desabilitar o cache HTTP(S) definindo a capacidade do cache do disco ou da memória como 0. No entanto, não há garantia de que essa configuração será aplicada.
Explanation
As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
Os desenvolvedores podem pensar que ao definir as propriedades diskCapacity ou memoryCapacity da classe URLCache como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.objc.insecure_storage_insufficient_cache_leak_protection
Abstract
O aplicativo tenta desabilitar o cache HTTP(S) definindo a capacidade do cache do disco ou da memória como 0. No entanto, não há garantia de que essa configuração será aplicada.
Explanation
As respostas HTTP(S) podem conter dados confidenciais, como cookies da sessão e tokens de API. O sistema de carregamento de URL armazenará em cache todas as respostas HTTP(S) para fins de desempenho, armazenando-as de forma descriptografada nos arquivos {app ID}/Library/Caches/com.mycompany.myapp/Cache.db*.
Os desenvolvedores podem pensar que ao definir as propriedades diskCapacity ou memoryCapacity da classe URLCache como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] URLCache Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 311, CWE ID 312, CWE ID 313, CWE ID 522
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001350, CCI-002475
[14] Standards Mapping - FIPS200 MP
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M2 Insecure Data Storage
[26] Standards Mapping - OWASP Mobile 2023 M9 Insecure Data Storage
[27] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[37] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 311
[38] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3310 CAT I, APP3340 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001350 CAT II, APSC-DV-002340 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.swift.insecure_storage_insufficient_cache_leak_protection