102 elementos encontrados
Debilidades
Abstract
Si se permite que la entrada de usuario modifique directamente los permisos de archivo, un atacante podría acceder a los recursos del sistema protegidos de otra forma.
Explanation
Se producen errores File Permission Manipulation cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo 1: El siguiente código utiliza la entrada de las variables de entorno del sistema para establecer los permisos de archivo. Si los atacantes pueden modificar las variables de entorno del sistema, pueden utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a Path Manipulation, un atacante puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del 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 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.2
[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.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.file_permission_manipulation
Abstract
Si se permite que la entrada de usuario modifique directamente los permisos de archivo, un atacante puede acceder a los recursos del sistema protegidos de otra forma.
Explanation
Se producen errores de File Permission Manipulation cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo 1: el siguiente código utiliza la entrada desde las propiedades del sistema para establecer la máscara de permisos predeterminada. Si los atacantes pueden modificar las propiedades del sistema, pueden utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a la manipulación de rutas de acceso, un usuario malintencionado puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del 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 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.java.file_permission_manipulation
Abstract
Si se permite que la entrada de usuario modifique directamente los permisos de archivo, un atacante puede acceder a los recursos del sistema protegidos de otra forma.
Explanation
Se producen errores de manipulación de permisos de archivo cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo: el siguiente código se ha diseñado para establecer los permisos de archivo adecuados para los usuarios que cargan las páginas web a través de FTP. Utiliza la entrada de una solicitud HTTP para marcar un archivo como visible para los usuarios externos.


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


Sin embargo, si un usuario malintencionado proporciona un valor malicioso para publicReport como, por ejemplo, "../../localuser/public_html/.htpasswd", la aplicación hará que el archivo especificado sea legible para el usuario malintencionado.

Ejemplo 2: el siguiente código utiliza la entrada desde un archivo de configuración para establecer la máscara de permisos predeterminada. Si los usuarios malintencionados pueden modificar el archivo de configuración, pueden utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a la manipulación de rutas de acceso, un usuario malintencionado puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del 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 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.php.file_permission_manipulation
Abstract
Si se permite que la entrada de usuario modifique directamente los permisos de archivo, un atacante puede acceder a los recursos del sistema protegidos de otra forma.
Explanation
Se producen errores de File Permission Manipulation cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo 1: El siguiente código utiliza la entrada de las variables de entorno del sistema para establecer los permisos de archivo. Si los atacantes pueden modificar las variables de entorno del sistema, pueden utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a Path Manipulation, un atacante puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del 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 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.2
[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.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.file_permission_manipulation
Abstract
Si se permite que la entrada de usuario modifique directamente los permisos de archivo, un atacante puede acceder a los recursos del sistema protegidos de otra forma.
Explanation
Se producen errores de manipulación de permisos de archivo cuando se cumplen algunas de las siguientes condiciones:

1. Un atacante puede especificar una ruta de acceso utilizada en una operación que modifica los permisos del sistema de archivos.

2. Un atacante puede especificar los permisos asignados por una operación en el sistema de archivos.

Ejemplo: el siguiente código se ha diseñado para establecer los permisos de archivo adecuados para los usuarios que cargan las páginas web a través de FTP. Utiliza la entrada de una solicitud HTTP para marcar un archivo como visible para los usuarios externos.


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


Sin embargo, si un usuario malintencionado proporciona un valor malicioso para publicReport como, por ejemplo, "../../localuser/public_html/.htpasswd", la aplicación hará que el archivo especificado sea legible para el usuario malintencionado.

Ejemplo 2: el siguiente código utiliza la entrada desde un archivo de configuración para establecer la máscara de permisos predeterminada. Si los atacantes pueden modificar el archivo de configuración, podrían utilizar el programa para obtener acceso a los archivos que el programa ha manipulado. Si el programa también es vulnerable a la manipulación de rutas de acceso, un usuario malintencionado puede utilizar esta vulnerabilidad para obtener acceso a archivos arbitrarios del 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 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.ruby.file_permission_manipulation
Abstract
Al permitir que un usuario malintencionado controle la cadena de formato de una función, se puede producir un buffer overflow.
Explanation
Las vulnerabilidades de cadena de formato se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.



2. Los datos se transfieren como argumento de cadena de formato a una función, como sprintf(), FormatMessageW() o syslog().
Ejemplo 1: el siguiente código copia un argumento de línea de comandos en un búfer mediante snprintf().


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


Este código permite a un usuario malintencionado ver el contenido de la pila y escribir en esta mediante el argumento de línea de comandos que contiene una secuencia de directivas de formato. El atacante puede leer desde la pila proporcionando más directivas de formato como, por ejemplo, %x, que la función utiliza como argumentos a los que aplicar un formato. (En este ejemplo, la función no utiliza ningún argumento al que se le vaya aplicar un formato.) Mediante la directiva de formato %n, el usuario malintencionado puede escribir en la pila lo que provoca que snprintf() escriba la salida de un número de bytes hasta el momento en el argumento especificado (en lugar de leer un valor del argumento, que es el comportamiento previsto). Una versión sofisticada de este ataque utilizará cuatro operaciones de escritura escalonadas para controlar por completo el valor de un puntero en la pila.

Ejemplo 2: determinadas implementaciones realizan ataques más avanzados de forma más fácil al proporcionar directivas de formato que controlan la ubicación en la memoria para leer esta o escribir en ella. A continuación se muestra un ejemplo de estas directivas con el siguiente código, escrito para glibc:


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


Este código genera la siguiente salida:


5 9 5 5


También se pueden utilizan medias operaciones de escritura (%hn) para controlar elementos DWORDS arbitrarios en la memoria, lo que reduce considerablemente la complejidad necesaria para ejecutar un ataque que, de otro modo, requeriría cuatro operaciones de escritura escalonadas como la que se menciona en el Example 1.

Ejemplo 3: las vulnerabilidades de cadena de formato sencillo a menudo proceden de atajos aparentemente inofensivos. El uso de estos atajos está tan arraigado que es posible que los programadores ni siquiera se den cuenta de que la función que están utilizando espera un argumento de cadena de formato.

Por ejemplo, la función syslog() se usa a menudo de la siguiente forma:


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


Como el segundo parámetro en syslog() es una cadena de formato, todas las directivas de formato incluidas en cmdBuf se interpretan como se describe en el Example 1.

El siguiente código muestra un uso correcto 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 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.cpp.format_string
Abstract
Un atacante puede controlar el argumento de cadena de formato que permite un ataque muy similar a un desbordamiento de búfer.
Explanation
Las vulnerabilidades de cadena de formato se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.



2. Los datos se pasan como argumento de cadena de formato a una función como sprintf(), FormatMessageW(), syslog(), NSLog o NSString.stringWithFormatEjemplo 1: el código siguiente utiliza un argumento de línea de comandos como una cadena de formato en NSString.stringWithFormat:.


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


Este código permite a un usuario malintencionado ver el contenido de la pila y dañarla mediante un argumento de línea de comandos que contenga una secuencia de directivas de formato. El atacante puede leer desde la pila proporcionando más directivas de formato como, por ejemplo, %x, que la función utiliza como argumentos a los que aplicar un formato. (En este ejemplo, la función no utiliza ningún argumento al que se le vaya aplicar un formato.)

Objective-C es compatible con las bibliotecas estándar de C heredadas, por lo que los ejemplos siguientes son aprovechables si la aplicación utiliza las API de C.

Ejemplo 2: determinadas implementaciones realizan ataques más avanzados de forma más fácil al proporcionar directivas de formato que controlan la ubicación en la memoria para leer esta o escribir en ella. A continuación se muestra un ejemplo de estas directivas con el siguiente código, escrito para glibc:


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


Este código genera la siguiente salida:


5 9 5 5


También se pueden utilizan medias operaciones de escritura (%hn) para controlar elementos DWORDS arbitrarios en la memoria, lo que reduce considerablemente la complejidad necesaria para ejecutar un ataque que, de otro modo, requeriría cuatro operaciones de escritura escalonadas como la que se menciona en el Example 1.

Ejemplo 3: las vulnerabilidades de cadena de formato sencillo a menudo proceden de atajos aparentemente inofensivos. El uso de estos atajos está tan arraigado que es posible que los programadores ni siquiera se den cuenta de que la función que están utilizando espera un argumento de cadena de formato.

Por ejemplo, la función syslog() se usa a menudo de la siguiente forma:


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


Como el segundo parámetro en syslog() es una cadena de formato, todas las directivas de formato incluidas en cmdBuf se interpretan como se describe en el Example 1.

El siguiente código muestra un uso correcto de syslog():


...
syslog(LOG_ERR, "%s", cmdBuf);
...
Ejemplo 4: las clases principales de Apple proporcionan vías interesantes para explotar las vulnerabilidades de la cadena de formato.

Por ejemplo, la función String.stringByAppendingFormat() se usa a menudo de la siguiente forma:


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


stringByAppendingFormat analiza los caracteres de la cadena de formato contenidos en la NSString pasados a ella.

El siguiente código muestra un uso correcto 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 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.objc.format_string
Abstract
El programa usa una cadena de formato incorrecto que tiene un número de especificadores de conversión distinto del de los argumentos de la función. Las cadenas de formato incorrecto pueden hacer que el programa lea datos fuera de los límites de la memoria asignada, lo que puede dar acceso a información confidencial, introducir un comportamiento incorrecto o bloquear el programa.
Explanation
El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa pueda acceder a valores fuera de los límites de la memoria asignada.

Ejemplo: el siguiente lee valores arbitrarios desde la pila porque el número de especificadores de formato no se corresponde con el número de argumentos transferidos a la función.

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
El programa usa una cadena de formato incorrecto con especificadores de conversión que no corresponden a los tipos de argumentos transferidos a la función. Las cadenas incorrectas pueden hacer que el programa convierta valores incorrectamente y que lea o escriba fuera de los límites de memoria asignada, lo que introduciría un comportamiento incorrecto o bloquearía el programa.
Explanation
El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa convierta incorrectamente valores de datos o que tenga acceso a valores fuera de los límites de la memoria asignada.

Ejemplo: el código siguiente convierte incorrectamente f desde un flotador usando un 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
Si se incluye un script de otro dominio, la seguridad de esta página web dependerá de la seguridad del otro dominio.
Explanation
Incluir contenido ejecutable de otro sitio web es una proposición arriesgada. Vincula la seguridad de nuestro sitio con la seguridad del otro sitio.

Ejemplo: Observe la siguiente etiqueta script.

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


Si esta etiqueta aparece en otro sitio web distinto de www.example.com, este sitio dependerá de www.example.com para suministrar código válido y malintencionado. Si los atacantes consiguen comprometer www.example.com, podrán alterar el contenido de fancyWidget.js para trastornar la seguridad del sitio. Podrían, por ejemplo, añadir código a fancyWidget.js para robar los datos confidenciales de un usuario.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 494, CWE ID 829
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.3 Dependency (L1 L2 L3), 14.2.4 Dependency (L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[13] Standards Mapping - OWASP Mobile 2024 M7 Insufficient Binary Protections
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-PLATFORM-2
[15] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[16] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[30] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
[31] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Process Validation
desc.content.html.hardcoded_domain
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.abap.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, cross-site scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u open redirect.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos de hoy impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojan una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo 1: El siguiente código establece un encabezado HTTP cuyo nombre y valor podría controlar un atacante:


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

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


Suponiendo que un par de nombre/valor consta de author y Jane Smith, la respuesta HTTP que incluye este encabezado podría tener la siguiente forma:


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


Sin embargo, debido a que el valor del encabezado se forma a partir de una entrada de usuario no validada, un atacante podría enviar un par de nombre/valor malicioso, como HTTP/1.1 200 OK\r\n...foo y bar, por lo que la respuesta HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como Cross-Site Request Forgery, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Open Redirect: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede ayudar a los ataques de suplantación de identidad.
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 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.apex.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchas de las estructuras y los servidores de aplicaciones actuales impiden la introducción de código malintencionado en los encabezados HTTP. Por ejemplo, las versiones recientes de .NET Framework de Microsoft convertirán los caracteres CR, LF y NULL a %0d, %0a y %00 cuando se envíen al método HttpResponse.AddHeader(). Si utiliza la versión más reciente de .NET que impide establecer encabezados con nuevos caracteres de línea, es posible que la aplicación no sea vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para Author.Text no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.dotnet.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede provocar ataques como el envenenamiento de caché, los Cross-Site Scripting (XSS), la degradación de usuarios o el secuestro de páginas.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin que se hayan validado para comprobar que existe código malintencionado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, de un formulario HTML y lo establece en un encabezado de cookies de una respuesta HTTP.


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

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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.cobol.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos tienen acceso a una aplicación web a través de una fuente que no es de confianza; la mayoría de las veces mediante una solicitud web.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, desde un formulario web y lo establece como encabezado de cookie de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1/1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.cfml.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o ataques de redireccionamiento abierto.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin validación.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo: El siguiente segmento de código lee el 'tipo de contenido' de una solicitud HTTP y lo establece en un encabezado de una nueva solicitud 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);
});


Debido a que el valor del encabezado de tipo de contenido está formado por una entrada de usuario no validada, puede ser manipulado por personas malintencionadas para explotar vulnerabilidades, ejecutar ataques de inyección de código, exponer datos confidenciales, habilitar la ejecución de archivos maliciosos o desencadenar situaciones de denegación de servicio, lo que representa riesgos significativos para la seguridad y la estabilidad de la aplicación.
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 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.dart.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, cross-site scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u open redirect.
Explanation
Se producen vulnerabilidades Header Manipulation cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.


Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como la falsificación de solicitudes entre sitios, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Open Redirect: Si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede contribuir a los ataques de suplantación de identidad.
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 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.golang.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.java.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: envenenamiento de caché de web y explorador, scripts de sitios y suplantación de páginas.


Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.javascript.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: en el siguiente segmento de código se asume que name y value pueden ser controlados por un usuario malintencionado. El código establece un encabezado HTTP cuyo nombre y valor son controlados por un usuario malintencionado:


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


Si se asume un par de nombre/valor que consiste en author y Jane Smith, la respuesta de HTTP incluida en este encabezado podría tomar la siguiente forma:


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


Sin embargo, debido a que el valor del encabezado se forma con entradas del usuario sin validar, los usuarios malintencionados pueden enviar un par de nombre/valor malintencionado, como HTTP/1.1 200 OK\r\n...foo y bar, y la respuesta de HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.objc.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de PHP generarán una advertencia y detendrán la creación de encabezados cuando las líneas nuevas se pasen a la función header() . Si su versión de PHP impide la configuración de los encabezados con los nuevos caracteres de línea, la aplicación no será vulnerable a la División de respuestas HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


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


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.php.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta 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;
...


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.sql.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


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


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.python.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo utiliza en una solicitud GET para otra parte del sitio.


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


Suponiendo que se envía en la solicitud una cadena formada por caracteres alfanuméricos estándar, tales como “Julia Díaz”, la respuesta HTTP podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la dirección URL se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...", la respuesta HTTP se dividiría en dos respuestas de la siguiente forma:


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

POST /index.php HTTP/1.1
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.ruby.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation u Open Redirect.
Explanation
Las vulnerabilidades de Header Manipulation se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de Header Manipulation es HTTP Response Splitting. Para realizar un ataque de HTTP Response Splitting con éxito, la aplicación debe permitir entradas que contengan los caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, Play Framework arrojará una excepción si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.
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 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.scala.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.


2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: en el siguiente segmento de código se asume que name y value pueden ser controlados por un usuario malintencionado. El código establece un encabezado HTTP cuyo nombre y valor son controlados por un usuario malintencionado:


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


Si se asume un par de nombre/valor que consiste en author y Jane Smith, la respuesta de HTTP incluida en este encabezado podría tomar la siguiente forma:


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


Sin embargo, debido a que el valor del encabezado se forma con entradas del usuario sin validar, los usuarios malintencionados pueden enviar un par de nombre/valor malintencionado, como HTTP/1.1 200 OK\r\n...foo y bar, y la respuesta de HTTP se dividiría en dos respuestas de la siguiente forma:


HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.swift.header_manipulation
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP, sin embargo, los servidores que admiten aplicaciones ASP clásicas a menudo carecen de ese mecanismo de protección.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.vb.header_manipulation
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.abap.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca Header Manipulation de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u Open Redirect.
Explanation
Se producen vulnerabilidades de manipulación de cookies cuando ocurre lo siguiente:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.



2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.



Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como Cross-Site Request Forgery, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Al tratarse de un encabezado de respuesta HTTP, los ataques de manipulación de cookies también pueden provocar otros tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, como el valor de la cookie se compone de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para author no contiene ningún carácter CR ni LF. Si un atacante envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP se dividiría en dos respuestas con el siguiente formato:


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

HTTP/1.1 200 OK
...


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y de la Web, Cross-Site Scripting y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Open Redirect: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede ayudar a los ataques de suplantación de identidad.
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 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.1 - Web 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.apex.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.dotnet.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.cfml.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca Header Manipulation de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies u Open Redirect.
Explanation
Se producen vulnerabilidades de manipulación de cookies cuando ocurre lo siguiente:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Cookie Manipulation: Cuando se combina con ataques como la falsificación de solicitudes entre sitios, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Al tratarse de un encabezado de respuesta HTTP, los ataques de manipulación de cookies también pueden provocar otros tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de Header Manipulation es la división de respuesta HTTP. Para realizar un ataque de división de respuesta HTTP con éxito, la aplicación debe permitir entradas que contengan caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación pretende enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernos de hoy impiden la inyección de caracteres malintencionados en los encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, como el valor de la cookie se compone de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un atacante envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP se dividiría en dos respuestas con el siguiente formato:


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

HTTP/1.1 200 OK
...


Claramente, el atacante controla la segunda respuesta, y esta se puede crear con cualquier contenido de cuerpo y encabezado deseado. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: El impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilizan varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes adquieren el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, un atacante puede aprovechar la misma vulnerabilidad de raíz para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas (la respuesta prevista del servidor y la respuesta generada por el atacante), un atacante puede hacer que un nodo intermedio, como un servidor proxy compartido, desvíe al atacante una respuesta generada por el servidor destinada al usuario. Como la solicitud realizada por el atacante genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del atacante, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del atacante ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El atacante envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar toda la información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Open Redirect: Si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede contribuir a los ataques de suplantación de identidad.
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 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry 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.1 - Web Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 HTTP Response Splitting (WASC-25)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 HTTP Response Splitting
desc.dataflow.golang.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo 1: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la manipulación de encabezados y cookies no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 2: el siguiente código adapta el Example 1 a la 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);

...
Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.java.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Cross-User Defacement: Un atacante puede realizar una única solicitud en un servidor vulnerable que haga que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparte la misma conexión TCP con el servidor. Esto se puede lograr si se convence al usuario de que envíe la solicitud malintencionada por sí mismo o de forma remota en situaciones donde el atacante y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque y hacer que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un atacante puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación, pero que redirija información privada, como los números de cuenta y las contraseñas, al atacante.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.javascript.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: El segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.php.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en un encabezado de respuesta HTTP puede habilitar el envenenamiento de caché, la desfiguración de usuarios de sitio (cross-user defacement), el secuestro de páginas, la manipulación de cookies o redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de encabezado se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en un encabezado de respuesta HTTP que se envía a un usuario web sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado de respuesta HTTP.

Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el siguiente segmento de código lee la ubicación desde una solicitud HTTP y establece en un encabezado el campo de ubicación de una respuesta HTTP.


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


Si una cadena compuesta por caracteres alfanuméricos, como “index.html”, se envía en la solicitud, la respuesta HTTP que incluye esta cookie podría mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor de la ubicación se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para some_location no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", la respuesta HTTP debería dividirse en dos respuestas de la siguiente forma:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.python.header_manipulation
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar Cache-Poisoning, Cross-Site Scripting, Cross-User Defacement, Page Hijacking, Cookie Manipulation u Open Redirect.
Explanation
Las vulnerabilidades de Cookie Manipulation se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, Cookie Manipulation es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Cookie Manipulation: Cuando se combina con ataques como Cross-Site Request Forgery, los usuarios malintencionados pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de Cookie Manipulation también pueden provocar otro tipos de ataques como:

HTTP Response Splitting:
Uno de los ataques más comunes de Header Manipulation es HTTP Response Splitting. Para realizar un ataque de HTTP Response Splitting con éxito, la aplicación debe permitir entradas que contengan los caracteres CR (retorno de carro, también expresado como %0d o \r) y LF (avance, también expresado como %0a o \n) en el encabezado. Estos caracteres no solo proporcionan a los atacantes el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permiten crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a HTTP Response Splitting. Sin embargo, si solo se filtran los caracteres de nueva línea, la aplicación puede quedar expuesta a ataques de Cookie Manipulation u Open Redirect, por lo que hay que tener cuidado al establecer encabezados HTTP con entrada del usuario.
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 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.1 - Web 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.scala.header_manipulation_cookies
Abstract
La inclusión de datos sin validar en las cookies puede hacer que se produzca la manipulación de encabezados de respuesta HTTP y habilitar el envenenamiento de caché, Cross-Site Scripting, la desfiguración de usuarios de sitios, el secuestro de páginas, la manipulación de cookies o el redireccionamiento abierto.
Explanation
Las vulnerabilidades de manipulación de cookies se producen cuando:

1. Los datos entran en una aplicación web a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP.

2. Los datos se incluyen en una cookie HTTP que se envía a un usuario web sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de cookies es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en una cookie HTTP.

Manipulación de cookies: Cuando se combina con ataques como el de falsificación de solicitud de Cross-Site Scripting, los atacantes pueden cambiar, agregar o incluso sobrescribir las cookies de un usuario legítimo.

Como encabezado de respuesta HTTP, los ataques de manipulación de cookies pueden también provocar otro tipos de ataques como:

División de respuesta HTTP:
Uno de los ataques más comunes de manipulación de encabezado es la división de la respuesta HTTP. Para realizar un ataque de división de la respuesta HTTP con éxito, la aplicación debe permitir la entrada que contiene los caracteres CR (retorno de carro, también dado por %0d o \r) y LF (avance, también dado por %0a o \n) en el encabezado de línea. Estos caracteres no solo proporcionan a los usuarios malintencionados el control de los encabezados restantes y del cuerpo de la respuesta que la aplicación tiene intención de enviar, sino que también les permite crear respuestas adicionales completamente bajo su control.

Muchos de los servidores de aplicaciones modernas de hoy en día impedirán la inyección de caracteres malintencionados en encabezados HTTP. Por ejemplo, las versiones recientes de Apache Tomcat arrojarán una IllegalArgumentException si intenta establecer un encabezado con caracteres prohibidos. Si el servidor de aplicaciones impide que los encabezados se configuren con caracteres de nueva línea, la aplicación no será vulnerable a la división de respuesta HTTP. Sin embargo, únicamente el filtrado de caracteres de nueva línea puede hacer que una aplicación sea vulnerable a la manipulación de cookies o los redireccionamientos abiertos, por lo que todavía debe tenerse cuidado al establecer encabezados HTTP con la entrada del usuario.

Ejemplo: el segmento de código siguiente lee el nombre del autor de una entrada de blog, author, de una solicitud HTTP y lo establece en un encabezado de cookies de una respuesta HTTP.


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


Suponiendo que se envía una cadena formada por caracteres alfanuméricos estándar tales como “Julia Díaz” en la solicitud, la respuesta HTTP con esta cookie incluida podría tener el formato siguiente:


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


Sin embargo, dado que el valor de la cookie se compone de la entrada del usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para AUTHOR_PARAM no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, por ejemplo, "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a continuación, se dividiría la respuesta HTTP en dos respuestas de la forma siguiente:


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

HTTP/1.1 200 OK
...


Claramente, el usuario malintencionado controla la segunda respuesta y se puede crear con cualquier contenido del cuerpo y encabezado deseados. La capacidad del usuario malintencionado para crear respuestas HTTP arbitrarias permite utilizar una serie de ataques resultantes, entre los que se incluyen: la desfiguración de usuarios de sitios, el envenenamiento de caché del explorador y la Web, los scripts de sitios (Cross-Site Scripting) y el secuestro de páginas.

Desfiguración de usuarios de sitios (cross-user defacement): Un atacante podrá realizar una única solicitud en un servidor vulnerable que hará que el servidor cree dos respuestas, la segunda de las cuales se puede interpretar erróneamente como respuesta a una solicitud diferente, posiblemente una realizada por otro usuario que comparta la misma conexión TCP con el servidor. Esto puede conseguirse si se convence al usuario para que envíe él mismo la solicitud malintencionada, o bien, de forma remota, en situaciones donde el usuario malintencionado y el usuario comparten una conexión TCP común al servidor, como un servidor proxy compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad para convencer a los usuarios de que la aplicación ha sufrido un ataque, haciendo que los usuarios pierdan confianza en la seguridad de la aplicación. En el peor de los casos, un usuario malintencionado puede proporcionar contenido especialmente diseñado para imitar el comportamiento de la aplicación pero que redirija la información privada, como los números de cuenta y las contraseñas, al usuario malintencionado.

Envenenamiento de caché: el impacto de una respuesta diseñada de forma malintencionada se puede ampliar si se almacena en caché mediante una caché web que utilicen varios usuarios o incluso la caché del explorador de un único usuario. Si una respuesta se almacena en una caché web compartida, como las que se encuentran comúnmente en los servidores proxy, todos los usuarios de esa caché seguirán recibiendo el contenido malintencionado hasta que se elimine la entrada de caché. De forma similar, si la respuesta se almacena en la caché del explorador de un usuario individual, ese usuario seguirá recibiendo el contenido malintencionado hasta que se elimine la entrada de caché, aunque solo el usuario de la instancia del explorador local se verá afectado.

Cross-Site Scripting: Una vez que los atacantes obtienen el control de las respuestas que envía una aplicación, pueden proporcionar a los usuarios una amplia variedad de contenido malintencionado. Cross-Site Scripting es una forma común de ataque donde se ejecuta el código JavaScript malintencionado u otro código incluido en una respuesta del explorador del usuario. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable. El tipo de ataque más común y peligroso contra los usuarios de una aplicación vulnerable utiliza JavaScript para transmitir la información de sesión y autenticación al atacante que, posteriormente, puede tomar el control completo de la cuenta de la víctima.

Secuestro de páginas: Además de utilizar una aplicación vulnerable para enviar contenido malintencionado a un usuario, la misma vulnerabilidad de raíz también se puede aprovechar para redirigir al atacante el contenido confidencial generado por el servidor y destinado al usuario. Al enviar una solicitud que da como resultado dos respuestas, la respuesta deseada desde el servidor y la respuesta que genera el atacante, este puede hacer que un nodo intermedio, como un servidor proxy compartido, suministre al atacante una respuesta generada por el servidor para el usuario. Dado que la solicitud realizada por el usuario malintencionado genera dos respuestas, la primera se interpreta como una respuesta a la solicitud del usuario malintencionado, mientras que la segunda permanece en el limbo. Cuando el usuario realiza una solicitud legítima a través de la misma conexión TCP, la solicitud del usuario malintencionado ya está en espera y se interpreta como una respuesta a la solicitud de la víctima. El usuario malintencionado envía entonces una segunda solicitud al servidor, a la que el servidor proxy responde con la solicitud que el servidor genera destinada a la víctima, lo que puede afectar a cualquier información confidencial de los encabezados o del cuerpo de la respuesta destinada a la víctima.

Redireccionamiento abierto: si se permite la entrada sin validar para controlar la dirección URL utilizada en un redireccionamiento, se puede facilitar la realización de ataques de suplantación de identidad.
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 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.1 - Web 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.vb.header_manipulation_cookies
Abstract
Incluir datos no validados en un encabezado SMTP puede permitir que los atacantes agreguen encabezados arbitrarios, como CC o BCC, que pueden usar para filtrar el contenido del correo hacia ellos mismos o para utilizar el servidor de correo como un bot de spam.
Explanation
Se producen vulnerabilidades de SMTP Header Manipulation cuando:

1. Los datos entran en una aplicación a través de un origen no confiable, más frecuentemente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado SMTP enviado a un servidor de correo sin haber sido validados.

Al igual que con muchas vulnerabilidades de seguridad de software, SMTP Header Manipulation es un medio para lograr un fin, no un fin en sí mismo. En esencia, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de SMTP Header Manipulation se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado puede definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: El siguiente segmento de código lee el asunto y el cuerpo de un formulario de contacto:


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


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


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


Sin embargo, como el valor del encabezado se construye a partir de la entrada de usuario sin validar, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un atacante envía una cadena maliciosa, como "¡¡Felicitaciones!! ¡¡Ha ganado la lotería!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", los encabezados SMTP tendrían el siguiente formato:


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


Esto permite que un atacante genere mensajes de spam o envíe correos electrónicos anónimos, entre otros 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 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 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formulario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: el siguiente fragmento de código lee el asunto y el cuerpo de un formulario de contacto:


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


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


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


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros 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 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 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: el siguiente fragmento de código lee el asunto y el cuerpo de un formulario de contacto:


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


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


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


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros 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 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 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
La inclusión de datos sin validar en un encabezado SMTP puede permitir a los usuarios malintencionados agregar encabezados arbitrarios, como CC o BCC, que pueden utilizar para acceder al contenido del correo o utilizar el servidor de correo como un bot de correo no deseado.
Explanation
Las vulnerabilidades de manipulación de encabezado SMTP se producen cuando:

1. Los datos entran en una aplicación a través de una fuente no confiable, de forma más frecuente en una solicitud HTTP en una aplicación web.

2. Los datos se incluyen en un encabezado HTTP que se envía a un servidor de correo sin haber sido validado.

Al igual que con muchas vulnerabilidades de seguridad de software, la manipulación de encabezado SMTP es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación vulnerable y la aplicación incluye los datos en un encabezado SMTP.

Uno de los ataques más comunes de manipulación de encabezado SMTP se utiliza para distribuir mensajes de correo electrónico no deseado. Si una aplicación contiene un formario de contacto vulnerable que permite definir el asunto y el cuerpo del mensaje de correo electrónico, un usuario malintencionado podrá definir cualquier contenido arbitrario e inyectar un encabezado CC con una lista de direcciones a las que enviar correo no deseado de forma anónima, ya que el correo electrónico se enviará desde el servidor de la víctima.

Ejemplo: el siguiente fragmento de código lee el asunto y el cuerpo de un formulario de contacto:


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)


Si una cadena compuesta por caracteres alfanuméricos estándar, como “La página no funciona”, se envía en la solicitud, los encabezados SMTP podrían mostrarse de la siguiente forma:


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


Sin embargo, dado que el valor del encabezado se crea a partir de la entrada de un usuario no validado, la respuesta solo mantendrá esta forma si el valor introducido para subject no contiene ningún carácter CR ni LF. Si un usuario malintencionado envía una cadena malintencionada, como "¡Felicidades! ¡¡Ha ganado la lotería!!\r\ncc:victim1@mail.com,victim2@mail.com ...", entonces los encabezados SMTP tendrían la siguiente forma:


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


En la práctica, esto permitirá a un usuario malintencionado elaborar mensajes de correo no deseado o enviar mensajes anónimos entre otros 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 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 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.server.com/login.aspx?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.

...
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">inglés<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después pueda modificar el poll_id a su antojo.
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 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.example.com/login.php?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.

...
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">English<a>
Link2: <a href="002">Español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después modifique poll_id a su antojo.
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 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un atacante suplante a otro usuario.
http://www.server.com/login.php?name=alice&name=hacker

Ejemplo 2: el siguiente código utiliza la entrada de una solicitud HTTP para representar dos hipervínculos.


<%
...
$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 al Sr. Pérez<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote a la Sra. González<a>

El programador no ha pensado en la posibilidad de que un usuario malintencionado proporcione un identificador de voto (poll_id) como "4567&candidato=gonzález" y, entonces, la página resultante contenga los siguientes vínculos insertados y, por tanto, la Sra. González reciba los votos en un servidor de aplicaciones que recopile el primer parámetro.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote al Sr. Pérez<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote a la Sra. González<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 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos


Por ejemplo:
- ASP.NET/IIS utiliza todas las apariciones de los parámetros
- Apache Tomcat utiliza solo la primera aparición e ignora las demás.
- mod_perl/Apache convierte el valor en una matriz de valores

Ejemplo 1: según el servidor de aplicaciones y la lógica de la propia aplicación, la siguiente solicitud podría provocar confusión en el sistema de autenticación y permitir que un usuario malintencionado suplante a otro usuario.
http://www.server.com/login.php?name=alice&name=hacker

Como se muestra aquí, el usuario malintencionado ya ha especificado name=alice, pero ha agregado un name=alice& adicional, y si se utiliza en un servidor que tome la primera repetición, podría suplantar a alice para obtener más información sobre su cuenta.
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 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
La aplicación permite la instalación de extensiones de teclado de terceros.
Explanation
Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas 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
La aplicación permite la instalación de extensiones de teclado de terceros.
Explanation
Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas 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
Una aplicación que realiza una búsqueda LDAP de devolución de objetos permitirá a los atacantes controlar la respuesta LDAP para ejecutar código arbitrario en el servidor.
Explanation
Un atacante capaz de manipular una respuesta LDAP, ya sea modificando la entrada en reposo o interceptando y modificando la respuesta sobre la marcha (ataque "man-in-the-middle") podrá inyectar atributos especiales de Java en la entrada LDAP. Al realizar una búsqueda de devolución de objetos, los atributos de Java se decodifican como objetos Java mediante la deserialización de Java o la eliminación de referencias de JNDI, lo que permite a los atacantes conseguir la ejecución remota de código en el servidor de aplicaciones que realiza la búsqueda.

La aplicación realiza una búsqueda de devolución de objetos estableciendo returningObjectFlag en true en la instancia de javax.naming.directory.SearchControls pasada al método search o mediante el uso de una función de biblioteca que establece esta marca en su nombre.

En este caso, la aplicación está utilizando el módulo de autorización de Spring Security LDAP que realiza búsquedas de devolución de objetos y, por lo tanto, es vulnerable a LDAP Entry Poisoning.

Ejemplo: El archivo de configuración de Beans siguiente configura la aplicación para utilizar el módulo LDAP de Spring Security como el proveedor de autenticación.


<beans ... >
<authentication-manager>
<ldap-authentication-provider
user-search-filter="(uid={0})"
user-search-base="ou=users,dc=example,dc=org"
group-search-filter="(uniqueMember={0})"
group-search-base="ou=groups,dc=example,dc=org"
group-role-attribute="cn"
role-prefix="ROLE_">
</ldap-authentication-provider>
</authentication-manager>
</beans>
References
[1] Introducing JNDI Injection and LDAP Entry Poisoning OpenText Fortify
[2] A Journey from JNDI/LDAP manipulation to remote code execution dream land BlackHat
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 20
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[17] Standards Mapping - FIPS200 SI
[18] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[22] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[23] Standards Mapping - OWASP Top 10 2010 A1 Injection
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[29] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] 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
[40] 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
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.configuration.java.ldap_entry_poisoning
Abstract
El nivel de privilegio elevado necesario para realizar operaciones como, por ejemplo, chroot() debe descartarse justo después de que se realice la operación.
Explanation
Cuando un programa llama a una función con privilegios como, por ejemplo, chroot(), debe adquirir primero el privilegio root. Una vez completada la operación con privilegios, el programa debería descartar el privilegio root y restablecer el nivel de privilegios del usuario que realiza la llamada.
Ejemplo: el siguiente código llama a chroot() para restringir la aplicación a un subconjunto del sistema de archivos por debajo de APP_HOME a fin de impedir que un atacante utilice el programa para obtener acceso a los archivos ubicados en otra ubicación. A continuación, el código abre el archivo especificado por el usuario y procesa su contenido.


...
chroot(APP_HOME);
chdir("/");

FILE* data = fopen(argv[1], "r+");
...


La limitación del proceso en el directorio principal de la aplicación antes de abrir los archivos es una medida de seguridad valiosa. Sin embargo, la ausencia de una llamada a setuid() con valores distintos a cero implica que la aplicación sigue funcionando con los privilegios root innecesarios. Cualquier ataque con éxito que lleve a cabo un usuario malintencionado contra la aplicación puede provocar ahora un ataque de extensión de privilegios debido a que todas las operaciones maliciosas se realizarán con el privilegio de superusuario. Si la aplicación cambia al nivel de privilegios de un usuario que no sea root, los posibles daños se reducen considerablemente.
References
[1] A. Chuvakin Using Chroot Securely
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 272
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [22] CWE ID 269
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381, CCI-002233, CCI-002235
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1), CM-7 Least Functionality (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege, CM-7 Least Functionality
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.3 Access Control Architectural Requirements (L2 L3), 1.4.3 Access Control Architectural Requirements (L2 L3), 10.2.2 Malicious Code Search (L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 7.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 7.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3500 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3500 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3500 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3500 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3500 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3500 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3500 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000500 CAT II, APSC-DV-000510 CAT I, APSC-DV-001500 CAT II
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.controlflow.cpp.least_privilege_violation
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: El siguiente código de aplicación web intenta leer un valor de un objeto de solicitud. A continuación, se registra el valor.


...
DATA log_msg TYPE bal_s_msg.

val = request->get_form_field( 'val' ).

log_msg-msgid = 'XY'.
log_msg-msgty = 'E'.
log_msg-msgno = '123'.
log_msg-msgv1 = 'VAL: '.
log_msg-msgv2 = val.

CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
I_S_MSG = log_msg
EXCEPTIONS
LOG_NOT_FOUND = 1
MSG_INCONSISTENT = 2
LOG_IS_FULL = 3
OTHERS = 4.
...


Si un usuario envía la cadena "FOO" para val, se registrará la entrada siguiente:


XY E 123 VAL: FOO


Sin embargo, si un usuario malintencionado envía la cadena "FOO XY E 124 VAL: BAR", se registrará la entrada siguiente:


XY E 123 VAL: FOO XY E 124 VAL: BAR


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.abap.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var val:String = String(params["username"]);
var value:Number = parseInt(val);
if (value == Number.NaN) {
trace("Failed to parse val = " + val);
}


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


Failed to parse val=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", se registrará la entrada siguiente:


Failed to parse val=twenty-one

User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos se introducen en una aplicación desde una fuente no fiable.

2. Los datos se escriben en una aplicación o en un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


...
string val = (string)Session["val"];
try {
int value = Int32.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val= " + val);
}
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Failed to parse val=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", se registrará la entrada siguiente:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.log_forging
Abstract
La escritura de una entrada de usuario no validada en los archivos de registro puede permitir a un usuario malintencionado falsificar contenido malicioso en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos escritos en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. En función de la naturaleza de la aplicación, los archivos de registro se pueden revisar manualmente según sea necesario o analizar automáticamente de forma selectiva mediante herramientas que buscan en los registros tendencias o puntos de datos importantes.

El análisis de los archivos de registro puede verse entorpecido o las conclusiones basadas en los datos de registro pueden ser incorrectas si se permite a un usuario malintencionado proporcionar datos en la aplicación que se registran posteriormente de forma exacta. Un usuario malintencionado puede insertar entradas falsas en el registro incluyendo caracteres de separador de entradas de registro en los datos. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor caso, un usuario malintencionado introduce código u otros comandos en el archivo de registro y aprovecha una vulnerabilidad de la utilidad de procesamiento de registros [2].

Ejemplo: el siguiente código de una secuencia de comandos CGI acepta una cadena enviada por el usuario e intenta convertirla en el valor de entero largo que representa. Si el valor no se analiza como un entero, su valor se registra con un mensaje de error que indica lo sucedido.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
syslog(LOG_INFO,"Illegal value = %s",val);
...



Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


Illegal value=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one\n\nINFO: User logged out=evil", se registrará la entrada siguiente:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, el atacante puede utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias. Para que un ataque de falsificación de registro de este tipo sea eficaz, el usuario malintencionado debe identificar primero formatos de entrada de registro válidos, pero esto a menudo se puede realizar mediante pérdidas de información del sistema en la aplicación de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cpp.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En los casos menos graves, un atacante podría insertar entradas falsas en el archivo de registro, proporcionando a la aplicación una entrada que incluya caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante podría inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor de un formulario HTML. A continuación, se registra el valor.


...
01 LOGAREA.
05 VALHEADER PIC X(50) VALUE 'VAL: '.
05 VAL PIC X(50).
...

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

EXEC DLI
LOG
FROM(LOGAREA)
LENGTH(50)
END-EXEC.
...


Si un usuario envía la cadena "FOO" para VAL, se registrará la entrada siguiente:


VAL: FOO


Sin embargo, si un usuario malintencionado envía la cadena "FOO VAL: BAR", se registrará la entrada siguiente:


VAL: FOO VAL: BAR


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cobol.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.


2. Los datos se escriben en una aplicación o un archivo de registro del sistema.


Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un formulario web. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


<cflog file="app_log" application="No" Thread="No"
text="Failed to parse val="#Form.val#">


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0a%22Information%22%2C%2C%2202/28/01%22%2C%2214:53:40%22%2C%2C%22User%20logged%20out:%20badguy%22", se registrará la entrada siguiente:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

"Information",,"02/28/01","14:53:40",,"User logged out: badguy"


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando ocurre lo siguiente:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos, ver transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: El siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
name := r.FormValue("name")
logout := r.FormValue("logout")
...
if (logout){
...
} else {
log.Printf("Attempt to log out: name: %s logout: %s", name, logout)
}
}


Si un usuario envía la cadena "twenty-one" para logout y pudo crear un usuario con nombre "admin", se registrará la siguiente entrada:


Attempt to log out: name: admin logout: twenty-one


Sin embargo, si un usuario malintencionado es capaz de crear un nombre de usuario "admin+logout:+1+++++++++++++++++++++++", se registrará la siguiente entrada:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo 1: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
log.info("Failed to parse val = " + val);
}
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Failed to parse val=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", se registrará la entrada siguiente:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la falsificación de registros no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 2: el siguiente código adapta el Example 1 a la plataforma Android.


...
String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}
...
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 117
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 AU, SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[17] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[18] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[25] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo 1: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var val = url.parse(request.url, true)['query']['val'];
if (isNaN(val)){
console.log("INFO: Failed to parse val = " + val);
}
...
}
...
http.createServer(listener).listen(8080);
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Failed to parse val = twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", se registrará la entrada siguiente:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.log_forging
Abstract
La función identificada escribe la entrada del usuario sin validar en el registro. Un usuario malintencionado podría aprovechar las ventajas de este comportamiento para falsificar las entradas del registro o insertar contenido malintencionado en el registro.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. En función de la naturaleza de la aplicación, los archivos de registro se pueden revisar manualmente según sea necesario o analizar automáticamente de forma selectiva mediante herramientas que buscan en los registros tendencias o puntos de datos importantes.

El análisis de los archivos de registro puede verse entorpecido o las conclusiones basadas en los datos de registro pueden ser incorrectas si se permite a un usuario malintencionado proporcionar datos en la aplicación que se registran posteriormente de forma exacta. Un usuario malintencionado puede insertar entradas falsas en el registro incluyendo caracteres de separador de entradas de registro en los datos. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor caso, un usuario malintencionado introduce código u otros comandos en el archivo de registro y aprovecha una vulnerabilidad de la utilidad de procesamiento de registros [2].

Ejemplo 1: el siguiente código de una secuencia de comandos CGI acepta una cadena enviada por el usuario e intenta convertirla en el valor de entero largo que representa. Si el valor no se analiza como un entero, su valor se registra con un mensaje de error que indica lo sucedido.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
NSLog("Illegal value = %s",val);
...



Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Illegal value=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one\n\nINFO: User logged out=evil", se registrará la entrada siguiente:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, el atacante puede utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias. Para que un ataque de falsificación de registro de este tipo sea eficaz, el atacante debe identificar primero formatos de entrada de registro válidos, pero esto a menudo se puede realizar mediante pérdidas de información del sistema en la aplicación de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


<?php
$name =$_GET['name'];
...
$logout =$_GET['logout'];

if(is_numeric($logout))
{
...
}
else
{
trigger_error("Attempt to log out: name: $name logout: $val");
}
?>


Si un usuario envía la cadena "twenty-one" para logout y pudo crear un usuario con nombre "admin", se registrará la siguiente entrada:


PHP Notice: Attempt to log out: name: admin logout: twenty-one


Sin embargo, si un usuario malintencionado es capaz de crear un nombre de usuario "admin+logout:+1+++++++++++++++++++++++", se registrará la siguiente entrada:


PHP Notice: Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


name = req.field('name')
...
logout = req.field('logout')

if (logout):
...
else:
logger.error("Attempt to log out: name: %s logout: %s" % (name,logout))


Si un usuario envía la cadena "twenty-one" para logout y pudo crear un usuario con nombre "admin", se registrará la siguiente entrada:


Attempt to log out: name: admin logout: twenty-one


Sin embargo, si un usuario malintencionado es capaz de crear un nombre de usuario "admin+logout:+1+++++++++++++++++++++++", se registrará la siguiente entrada:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo 1: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


...
val = req['val']
unless val.respond_to?(:to_int)
logger.info("Failed to parse val")
logger.info(val)
end
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Failed to parse val
INFO: twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", se registrará la entrada siguiente:


INFO: Failed to parse val
INFO: twenty-one

INFO: User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.log_forging
Abstract
La función identificada escribe la entrada del usuario sin validar en el registro. Un usuario malintencionado podría aprovechar las ventajas de este comportamiento para falsificar las entradas del registro o insertar contenido malintencionado en el registro.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. En función de la naturaleza de la aplicación, los archivos de registro se pueden revisar manualmente según sea necesario o analizar automáticamente de forma selectiva mediante herramientas que buscan en los registros tendencias o puntos de datos importantes.

El análisis de los archivos de registro puede verse entorpecido o las conclusiones basadas en los datos de registro pueden ser incorrectas si se permite a un usuario malintencionado proporcionar datos en la aplicación que se registran posteriormente de forma exacta. Un usuario malintencionado puede insertar entradas falsas en el registro incluyendo caracteres de separador de entradas de registro en los datos. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor caso, un usuario malintencionado introduce código u otros comandos en el archivo de registro y aprovecha una vulnerabilidad de la utilidad de procesamiento de registros [2].

Ejemplo 1: El siguiente código acepta una cadena enviada por el usuario e intenta convertirla en el valor de entero que representa. Si el valor no se analiza como un entero, su valor se registra con un mensaje de error que indica lo sucedido.


...
let num = Int(param)
if num == nil {
NSLog("Illegal value = %@", param)
}
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


INFO: Illegal value = twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one\n\nINFO: User logged out=evil", se registrará la entrada siguiente:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Claramente, el atacante puede utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias. Para que un ataque de falsificación de registro de este tipo sea eficaz, el atacante debe identificar primero formatos de entrada de registro válidos, pero esto a menudo se puede realizar mediante pérdidas de información del sistema en la aplicación de destino.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.log_forging
Abstract
Si se escribe una entrada del usuario sin validar en los archivos de registro se puede permitir que un atacante falsifique las entradas del registro o que inserte contenido malintencionado en los registros.
Explanation
Las vulnerabilidades de falsificación del registro se producen cuando:

1. Los datos entran en una aplicación desde una fuente no confiable.

2. Los datos se escriben en una aplicación o un archivo de registro del sistema.

Las aplicaciones normalmente utilizan los archivos de registro para almacenar un historial de sucesos o transacciones para su revisión posterior, la recopilación de estadísticas o la depuración. Dependiendo de la naturaleza de la aplicación, la tarea de revisar los archivos de registro se puede realizar manualmente según sea necesario o automatizar con una herramienta que obtenga automáticamente los registros de eventos importantes o la información de tendencias.

La interpretación de los archivos de registro se puede impedir o dirigir de manera incorrecta si un usuario malintencionado puede suministrar datos a la aplicación que posteriormente se registra literalmente. En el caso más benigno, un usuario malintencionado puede insertar entradas falsas en el archivo de registro proporcionando a la aplicación la entrada que incluya los caracteres apropiados. Si el archivo de registro se procesa automáticamente, el atacante puede inutilizar el archivo dañando el formato de este o con una inyección de caracteres inesperados. Un ataque más sutil puede implicar sesgar las estadísticas del archivo de registro. Los archivos de registro falsificados o de otro modo dañados, se pueden utilizar para cubrir las pistas de un usuario malintencionado o incluso para implicar a otra parte encargada de un acto malintencionado [1]. En el peor de los casos, un usuario malintencionado puede inyectar código u otros comandos en el archivo de registro y aprovechar una vulnerabilidad de la utilidad de procesamiento del registro[2].

Ejemplo: el siguiente código de aplicación web intenta leer un valor entero de un objeto de solicitud. Si el valor no se puede analizar como un entero, se registra la información con un mensaje de error que indica qué ha ocurrido.


...
Dim Val As Variant
Dim Value As Integer
Set Val = Request.Form("val")
If IsNumeric(Val) Then
Set Value = Val
Else
App.EventLog "Failed to parse val=" & Val, 1
End If
...


Si un usuario envía la cadena "twenty-one" para val, se registrará la entrada siguiente:


Failed to parse val=twenty-one


Sin embargo, si un usuario malintencionado envía la cadena "twenty-one%0a%0a+User+logged+out%3dbadguy", se registrará la entrada siguiente:


Failed to parse val=twenty-one

User logged out=badguy


Claramente, los atacantes pueden utilizar este mismo mecanismo para insertar las entradas del registro arbitrarias.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[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 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 117
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 AU, SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, 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 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, 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 8.4 - Activity Tracking, 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, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[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-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.vb.log_forging
Abstract
La ejecución de comandos IMAP procedentes de un origen que no es de confianza puede provocar que el servidor IMAP ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos IMAP se producen cuando un atacante puede influir en los comandos enviados a un servidor de correo IMAP.

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando IMAP, el usuario malintencionado es capaz de ordenar al servidor que lleve a cabo acciones malintencionadas, como enviar correo no deseado.

Ejemplo 1: el siguiente código utiliza un parámetro de solicitud HTTP para diseñar un comando CREATE que se envía al servidor IMAP. Un atacante puede utilizar este parámetro para modificar el comando enviado al servidor e inyectar nuevos comandos utilizando caracteres CRLF.


...
final String foldername = request.getParameter("folder");
IMAPFolder folder = (IMAPFolder) store.getFolder("INBOX");
...
folder.doCommand(new IMAPFolder.ProtocolCommand() {
@Override
public Object doCommand(IMAPProtocol imapProtocol) throws ProtocolException {
try {
imapProtocol.simpleCommand("CREATE " + foldername, null);
} catch (Exception e) {
// Handle Exception
}
return null;
}
});
...
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 3.0
[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 - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.java.mail_command_injection_imap
Abstract
La ejecución de comandos POP3 procedentes de un origen que no es de confianza puede provocar que el servidor POP3 ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos POP3 se producen cuando un atacante puede influir en los comandos enviados a un servidor de correo POP3.

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando POP3, el usuario malintencionado es capaz de ordenar al servidor que lleve a cabo acciones malintencionadas, como enviar correo no deseado.

Example 1: el siguiente código utiliza un parámetro de solicitud HTTP para diseñar un comando USER y PASS que se envía al servidor POP3. Un atacante puede utilizar este parámetro para modificar el comando enviado al servidor e inyectar nuevos comandos utilizando caracteres CRLF.


...
String username = request.getParameter("username");
String password = request.getParameter("password");
...
POP3SClient pop3 = new POP3SClient(proto, false);
pop3.login(username, password)
...
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 3.0
[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 - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[26] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.java.mail_command_injection_pop3
Abstract
La ejecución de comandos SMTP desde una fuente que no es de confianza puede hacer que el servidor SMTP ejecute comandos maliciosos en nombre de un atacante.
Explanation
Este tipo de vulnerabilidades puede ocurrir cuando: Las vulnerabilidades de Command Injection de SMTP ocurren cuando un atacante puede influir en los comandos enviados a un servidor de correo SMTP.

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena, o como parte de ella, que representa un comando que la aplicación ejecuta.

3. Al ejecutar el comando SMTP, el atacante puede indicarle al servidor que lleve a cabo acciones maliciosas, como enviar spam.

Ejemplo 1: El siguiente código utiliza un parámetro de solicitud HTTP para crear un comando VRFY que se envía al servidor SMTP. Un atacante podría usar este parámetro para modificar el comando enviado al servidor e inyectar nuevos comandos usando caracteres CRLF.


...
c, err := smtp.Dial(x)
if err != nil {
log.Fatal(err)
}
user := request.FormValue("USER")
c.Verify(user)
...
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 3.0
[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 - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[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 API 2023 API3 Broken Object Property Level Authorization
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[25] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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
[37] 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
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.golang.mail_command_injection_smtp
Abstract
La ejecución de comandos SMTP desde un origen que no es de confianza puede provocar que el servidor SMTP ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos SMTP se producen cuando un atacante puede influir en los comandos enviados a un servidor de correo SMTP.

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando SMTP, el usuario malintencionado es capaz de ordenar al servidor que lleve a cabo acciones malintencionadas, como enviar correo no deseado.

Ejemplo 1: el siguiente código utiliza un parámetro de solicitud HTTP para diseñar un comando VRFY que se envía al servidor SMTP. Un atacante puede utilizar este parámetro para modificar el comando enviado al servidor e inyectar nuevos comandos utilizando caracteres CRLF.


...
String user = request.getParameter("user");
SMTPSSLTransport transport = new SMTPSSLTransport(session,new URLName(Utilities.getProperty("smtp.server")));
transport.connect(Utilities.getProperty("smtp.server"), username, password);
transport.simpleCommand("VRFY " + user);
...
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 3.0
[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 - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] 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
[39] 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
[40] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[41] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.java.mail_command_injection_smtp
Abstract
La ejecución de comandos SMTP desde un origen que no es de confianza puede provocar que el servidor SMTP ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de comandos SMTP se producen cuando un atacante puede influir en los comandos enviados a un servidor de correo SMTP.

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando SMTP, el usuario malintencionado es capaz de ordenar al servidor que lleve a cabo acciones malintencionadas, como enviar correo no deseado.

Ejemplo 1: el siguiente código utiliza un parámetro de solicitud HTTP para diseñar un comando VRFY que se envía al servidor SMTP. Un atacante puede utilizar este parámetro para modificar el comando enviado al servidor e inyectar nuevos comandos utilizando caracteres CRLF.


...
user = request.GET['user']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
session.docmd("VRFY", user)
...
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 3.0
[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 - Common Weakness Enumeration CWE ID 88, CWE ID 93, CWE ID 147
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [25] CWE ID 077
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [17] CWE ID 077
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [16] CWE ID 077
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.3 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.2 Sanitization and Sandboxing Requirements (L1 L2 L3)
[26] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[27] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[38] 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
[39] 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
[40] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 078
[41] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 078
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002510 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002510 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Mail Command Injection (WASC-30)
desc.dataflow.python.mail_command_injection_smtp
Abstract
Es posible que el programa elimine la referencia de un puntero nulo porque no comprueba el valor de devolución de una función que puede que devuelva un valor null.
Explanation
Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.
Ejemplo 1: el siguiente código no comprueba si la cadena devuelta por la propiedad Item es null antes de llamar a la función miembro Equals(), lo que podría provocar una eliminación de referencia de un valor null.


string itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...


La defensa tradicional de este código de error es la siguiente:

"Sé que el valor solicitado siempre existirá porque... Si no existe, el programa no puede presentar el comportamiento deseado, por lo que no importa si gestiono el error o solo permito que el programa se anule mediante la eliminación de la referencia de un valor null".

Sin embargo, los usuarios malintencionados son expertos en buscar rutas inesperadas a través de programas, sobre todo, cuando se producen excepciones.
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[15] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[40] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.dotnet.missing_check_against_null
Abstract
Es posible que el programa elimine la referencia de un puntero nulo porque no comprueba el valor de devolución de una función que puede que devuelva un valor null.
Explanation
Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.
Ejemplo 1: el siguiente código no comprueba si la asignación de memoria se realizó correctamente antes de intentar usar el puntero devuelto por malloc().


buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);


La defensa tradicional de este código de error es la siguiente:

"Si se agota la memoria del programa, este presentará errores. No importa si administro el error o simplemente dejo que el programa finalice con un error de segmentación cuando intenta eliminar la referencia del puntero nulo".

Este argumento pasa por alto tres consideraciones importantes:

- En función del tipo y el tamaño de la aplicación, puede que sea posible liberar la memoria que se está utilizando en otra ubicación para que la ejecución pueda continuar.

- Es imposible que el programa realice una salida de manera hábil si es necesario. Si el programa realiza una operación atómica, puede dejar el sistema en un estado inconsistente.

- El programador ha perdido la oportunidad de registrar la información de diagnóstico. ¿La llamada a malloc() presentó errores debido a que req_size era demasiado grande o a que se estaban administrando demasiadas solicitudes al mismo tiempo? ¿O el error lo provocó una pérdida de memoria que se acumuló a lo largo de un periodo? Si no se administra el error, es imposible saberlo.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[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 normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[19] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[41] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.missing_check_against_null
Abstract
Es posible que el programa elimine la referencia de un puntero nulo porque no comprueba el valor de devolución de una función que puede que devuelva un valor null.
Explanation
Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.

Ejemplo 1: El siguiente código no comprueba si la cadena devuelta por getParameter() es null antes de llamar a la función miembro compareTo(), lo que podría provocar una desreferencia de null.


String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
...
}
...
Ejemplo 2:. en el siguiente código se muestra una propiedad del sistema que se establece en un valor null y un programador elimina posteriormente su referencia al presuponer de forma incorrecta que siempre está definida.


System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
System.out.println("Not supported");


La defensa tradicional de este código de error es la siguiente:

"Sé que el valor solicitado siempre existirá porque... Si no existe, el programa no puede presentar el comportamiento deseado, por lo que no importa si gestiono el error o solo permito que el programa se anule mediante la eliminación de la referencia de un valor null".

Sin embargo, los usuarios malintencionados son expertos en buscar rutas inesperadas a través de programas, sobre todo, cuando se producen excepciones.
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[15] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[18] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[40] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.missing_check_against_null
Abstract
El programa puede eliminar potencialmente la referencia de un puntero nulo, generando una NullException.
Explanation
Los punteros nulos suelen producirse debido a que se ha infringido alguna presuposición del programador.

La mayoría de los problemas con el puntero nulo provocan problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la eliminación de la referencia del puntero nulo, es posible que también pueda usar la excepción resultante para omitir la lógica de seguridad o para hacer que la aplicación revele información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo 1: en el siguiente código, el programador presupone que el sistema tiene siempre definida una propiedad denominada "cmd". Si un usuario malintencionado puede controlar el entorno del programa para que no se defina "cmd", el programa genera una excepción de puntero nulo al intentar llamar al método Trim().


string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.dotnet.null_dereference
Abstract
El programa podría desreferenciar un puntero nulo y, por lo tanto, ocasionar un error de segmentación.
Explanation
Las excepciones del puntero nulo normalmente se producen cuando una o varias de las hipótesis del programador se infringen. Hay al menos tres enfoques para este problema: comprobar después de desreferenciar, desreferenciar después de comprobar y desreferenciar después de almacenar. Se produce un error de desreferencia tras la comprobación cuando un programa desreferencia un puntero que puede ser null antes de comprobar si es null o no. Los errores de desreferencia tras la comprobación se producen cuando un programa realiza una comprobación explícita de null y procede a desreferenciar el puntero cuando se sabe que es null. Los errores de este tipo son normalmente el resultado de errores de escritura o descuidos del programador. Los errores de desreferencia tras el almacenamiento se producen cuando un programa establece de forma explícita un puntero en null y luego lo desreferencia. Con frecuencia, el error es el resultado de que un programador inicialice una variable en null cuando se declara.

La mayoría de los problemas del puntero nulo derivan en problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la desreferencia del puntero nulo, también puede ser capaz de usar la excepción resultante para eludir la lógica de seguridad y planear un ataque por denegación de servicio o hacer que la aplicación revele la información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo 1: en el código siguiente, el programador supone que la variable ptr no es NULL. Esta suposición se hace explícita cuando el programador desreferencia el puntero. Esta suposición luego queda contradicha cuando el programador contrasta ptr y NULL. Si ptr puede ser NULL al comprobarla en la instrucción if, entonces también puede ser NULL cuando se desreferencia y podría ocasionar un error de segmentación.


ptr->field = val;
...
if (ptr != NULL) {
...
}
Ejemplo 2: En el código siguiente, el programador confirma que la variable ptr es NULL y por eso lo desreferencia erróneamente. Si ptr es NULL cuando se comprueba en la instrucción if, entonces se produce una desreferencia de null que provocará un error de segmentación.


if (ptr == null) {
ptr->field = val;
...
}
Ejemplo 3: En el código siguiente, el programador olvida que la cadena '\0' es en realidad 0 o NULL; por lo tanto, puede desreferenciar un puntero nulo y provocar un fallo de segmentación.


if (ptr == '\0') {
*ptr = val;
...
}
Ejemplo 4: En el código siguiente, el programador establece explícitamente la variable ptr en NULL. A continuación, el programador desreferencia ptr antes de comprobar si en el objeto hay un valor null.


*ptr = NULL;
...
ptr->field = val;
...
}
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.null_dereference
Abstract
El programa puede eliminar potencialmente la referencia de un puntero nulo, generando una NullPointerException.
Explanation
Los punteros nulos suelen producirse debido a que se ha infringido alguna presuposición del programador.

La mayoría de los problemas con el puntero nulo provocan problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la eliminación de la referencia del puntero nulo, es posible que también pueda usar la excepción resultante para omitir la lógica de seguridad o para hacer que la aplicación revele información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo: en el siguiente código, el programador presupone que el sistema tiene siempre definida una propiedad denominada "cmd". Si un usuario malintencionado puede controlar el entorno del programa para que no se defina "cmd", el programa genera una excepción de puntero nulo al intentar llamar al método trim().


String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[16] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[17] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.null_dereference
Abstract
La deserialización de datos que no son de confianza permite la inyección de objetos PHP arbitrarios, lo cual puede provocar que el programa ejecute comandos malintencionados en nombre de un atacante.
Explanation
Las vulnerabilidades de inyección de objetos se producen cuando los datos que no son de confianza no se corrigen correctamente antes de transferirlos a la función unserialize(). Los usuarios malintencionados podrían transferir cadenas serializadas especialmente diseñadas a una llamada unserialize() vulnerable, dando como resultado la inyección de objetos PHP en el ámbito de la aplicación. La gravedad de esta vulnerabilidad depende de las clases disponibles en el ámbito de la aplicación. Las clases que implementan un método mágico PHP como __wakeup o __destruct serán interesantes para los atacantes dado que podrán ejecutar el código dentro de esos métodos.

Ejemplo 1: el siguiente código muestra una clase PHP que implementa el método mágico __destruct() y ejecuta un comando del sistema definido como una propiedad de clases. También hay una llamada no segura a unserialize() con datos proporcionados por el usuario.


...
class SomeAvailableClass {
public $command=null;
public function __destruct() {
system($this->command);
}
}
...
$user = unserialize($_GET['user']);
...


En el Example 1, la aplicación puede estar esperando un objeto de User serializado, pero un atacante podría proporcionar una versión serializada de SomeAvailableClass con un valor predefinido para su propiedad command:


GET REQUEST: http://server/page.php?user=O:18:"SomeAvailableClass":1:{s:7:"command";s:8:"uname -a";}


Se llamará al método destructor tan pronto como no haya otras referencias al objeto de $user y, a continuación, ejecutará el comando proporcionado por el atacante.

Los atacantes podrían encadenar diferentes clases declaradas cuando se llama al unserialize() vulnerable mediante una técnica conocida como "Programación orientada a las propiedades", que introdujo Stefan Esser durante la conferencia BlackHat de 2010. Esta técnica permite a un atacante volver a utilizar el código existente para diseñar su propia carga.
References
[1] Johannes Dahse, Nikolai Krein, and Thorsten Holz Code Reuse Attacks in PHP: Automated POP Chain Generation
[2] Stefan Esser Utilizing Code Reuse/ROP in PHP Application Exploits
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 502
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[24] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[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.5 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 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 Improper Input Handling (WASC-20)
desc.dataflow.php.object_injection
Abstract
La deserialización de datos que no son de confianza permite la inyección de objetos de Ruby arbitrarios, lo cual puede provocar que el programa ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de objetos se producen cuando los datos que no son de confianza no se corrigen correctamente antes de transferirlos a la función que deserializa los datos como YAML.load(). Los usuarios malintencionados podrían transferir cadenas serializadas especialmente diseñadas a una llamada YAML.load() vulnerable, dando como resultado la inyección de objetos de Ruby arbitrarios en el programa, siempre y cuando la clase se cargue en la aplicación en el momento de deserialización. Esto puede facilitar un montón de oportunidades de ataques diversos, como omitir la lógica de validación para buscar vulnerabilidades de Cross-Site Scripting, permitir la SQL Injection a través de lo que parecen ser valores codificados o incluso la ejecución de código completa.

Ejemplo 1: El siguiente código muestra una clase de Ruby que crea una consulta SQL con sus atributos que luego se utiliza para consultar en la base de datos. También hay una llamada no segura a YAML.load() con datos proporcionados por el usuario.


...
class Transaction
attr_accessor :id
def initialize(num=nil)
@id = num.is_a?(Numeric) ? num : nil
end

def print_details
unless @id.nil?
print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
end
end
end

...
user = YAML.load(params[:user]);
user.print_details
...


En el Example 1, la aplicación puede estar esperando a un objeto de User serializado, que también tiene una función llamada print_details, pero un atacante en realidad podría proporcionar una versión serializada de un objeto Transaction con un valor predefinido para su atributo @id. Por lo tanto, una solicitud como la siguiente puede permitir la omisión de la comprobación de validación que intenta asegurarse de que @id es un valor numérico.


GET REQUEST: http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A


Si observamos la versión decodificada de esto, vemos que el parámetro user tiene asignado !ruby/object:Transaction\nid:4 or 5=5\n.
Entonces, la deserialización del parámetro de usuario creará un objeto de tipo Transaction y @id se establecerá en "4 or 5=5". Cuando el desarrollador cree que se llamará a User#print_details(), ahora se llamará a Transaction#print_details() y la interpolación de cadena de Ruby significará que la consulta SQL se cambiará para ejecutar la consulta: SELECT * FROM transactions WHERE id=4 or 5=5. Dado que se agregó la cláusula adicional, la consulta se evalúa en true y devolverá todo dentro de la tabla transactions en lugar de la única fila prevista por el desarrollador.

Los atacantes podrían encadenar diferentes clases declaradas cuando se llama al YAML.load() vulnerable mediante una técnica conocida como "Programación orientada a las propiedades", que introdujo Stefan Esser durante la conferencia BlackHat de 2010. Esta técnica permite a un atacante volver a utilizar el código existente para diseñar su propia carga.
References
[1] HD Moore Serialization Mischief in Ruby Land (CVE-2013-0156)
[2] Ruby Ruby Security
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 502
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[24] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[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.5 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 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 Improper Input Handling (WASC-20)
desc.dataflow.ruby.object_injection
Abstract
Un método clone() debe llamar super.clone() para obtener el nuevo objeto.
Explanation
Todas las implementaciones de clone() deben obtener el nuevo objeto llamando super.clone(). Si una clase no puede seguir esta convención, un método clone() de subclase devolverá un objeto del tipo incorrecto.


Ejemplo 1: las dos clases siguientes demuestran un error introducido por no llamar super.clone(). Dada la forma en que Kibitzer implementa clone(), el método de clonación de FancyKibitzer devolverá un objeto de tipo Kibitzer en lugar de FancyKibitzer.


public class Kibitzer implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = new Kibitzer();
...
}
}

public class FancyKibitzer extends Kibitzer
implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = super.clone();
...
}
}
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 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 580
desc.structural.java.object_model_violation_erroneous_clone_method