209 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
El programa define una directiva entre dominios demasiado permisiva.
Explanation
De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, es necesario tener cuidado al cambiar la configuración porque una directiva entre dominios demasiado permisiva permitirá que una aplicación malintencionada se comunique con la aplicación víctima de manera inadecuada, lo que provocará suplantación de identidad, robo de datos, retransmisión y otros ataques.

Ejemplo 1: El código siguiente es un ejemplo del uso de un carácter comodín para especificar mediante programación los dominios con los que la aplicación se puede comunicar.


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


El uso de * como el argumento de allowDomain() indica que otras aplicaciones SWF pueden tener acceso a los datos desde cualquier dominio.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 942
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
El programa define una directiva de encabezados personalizados demasiado permisiva.
Explanation
De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. A partir de Flash Player 9,0,124,0, Adobe también introdujo la capacidad de definir qué encabezados personalizados Flash Player puede enviar a través de dominios. Sin embargo, se debe tener precaución al definir esta configuración porque una directiva de encabezados personalizados demasiado permisiva, cuando se aplica junto con la directiva entre dominios demasiado permisiva, permitirá que una aplicación malintencionada envíe encabezados de su elección a la aplicación de destino, lo que podría conducir a diversos ataques o provocar errores en la ejecución de la aplicación que no sabe cómo manejar los encabezados recibidos.

Ejemplo 1: La configuración siguiente muestra el uso de un carácter comodín para especificar los encabezados que puede enviar Flash Player entre dominios.


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


Utilizar el* como el valor del atributo headers indica que cualquier encabezado se enviará a través de dominios.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
El programa utiliza la entrada del usuario no validada para eludir las restricciones de directiva entre dominios.
Explanation
De forma predeterminada, las aplicaciones Flash están sujetas a la misma directiva de origen, lo que garantiza que dos aplicaciones SWF pueden tener acceso a los datos respectivos solo si proceden del mismo dominio. Adobe Flash permite a los desarrolladores modificar la directiva mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, es necesario tener cuidado al decidir quién puede influir en la configuración porque una directiva entre dominios demasiado permisiva permitirá que una aplicación malintencionada se comunique con la aplicación víctima de manera inadecuada, lo que provocará suplantación de identidad, robo de datos, retransmisión y otros ataques. Las vulnerabilidades de omisión de las restricciones de directivas se producen cuando:

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

2. Los datos se utilizan para cargar o modificar la configuración de directivas entre dominios.
Ejemplo 1: El siguiente código utiliza el valor de uno de los parámetros para el archivo SWF cargado como la dirección URL desde donde cargar el archivo de directivas entre dominios.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
Ejemplo 2: El siguiente código utiliza el valor de uno de los parámetros para el archivo SWF cargado con el fin de definir la lista de dominios de confianza.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
El programa permite que las aplicaciones SWF de HTTP y HTTPS se comuniquen.
Explanation
A partir de Flash Player 7, no se permite que las aplicaciones SWF cargadas a través de HTTP tengan acceso a los datos de las aplicaciones SWF cargadas a través de HTTPS de forma predeterminada. Adobe Flash permite a los desarrolladores modificar esta restricción mediante programación o a través de la configuración adecuada en el archivo de configuración crossdomain.xml. Sin embargo, se deben tomar precauciones al definir esta configuración porque las aplicaciones SWF cargadas a través de HTTP son objeto de ataques Man-In-The-Middle (MITM) y, por tanto, no son de confianza.

Ejemplo: El siguiente código llama a allowInsecureDomain(), que desactiva la restricción que impide que las aplicaciones SWF cargadas a través de HTTP tengan acceso a los datos de las aplicaciones SWF cargadas a través de HTTPS.


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[25] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
El programa permite a un usuario malintencionado controlar los componentes centrales del clúster de Hadoop en los que se ejecuta la aplicación cliente.
Explanation
Los errores de control del clúster de Hadoop se producen cuando:

- Los datos entran en un programa desde un origen que no es de confianza.

- Los componentes centrales del clúster de Hadoop como, por ejemplo, NameNode, DataNode o JobTraker consumen los datos para cambiar el estado del clúster.

Los clústeres de Hadoop son un entorno hostil. Si no se establecen correctamente las configuraciones de seguridad que protegen frente al acceso no autorizado a los nodos del clúster, es posible que se produzca un ataque. Esto conlleva la posibilidad de que se manipule cualquier dato proporcionado por el clúster de Hadoop.

Ejemplo 1: el siguiente código muestra un envío de Job en una aplicación de cliente típica que obtiene entradas de la línea de comandos en un equipo maestro de clúster de Hadoop:


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

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

/* This sets the ownership of a file pointed by the path to a user identified
* by command line arguments.
*/
nNode.setOwner(path, args[2], args[3]);
...
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.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 - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[21] 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
[22] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.hadoop_cluster_manipulation
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
No utilice realloc() para cambiar el tamaño de los búferes que almacenan información confidencial. Es posible que la función deje una copia de la información confidencial en la memoria, donde no se puede sobrescribir.
Explanation
Las vulnerabilidades de inspección de montón se producen cuando los datos confidenciales como, por ejemplo, una contraseña o una clave de cifrado, se pueden mostrar a un usuario malintencionado porque no se han eliminado de la memoria.

La función realloc() se utiliza normalmente para aumentar el tamaño de un bloque de memoria asignada. Esta operación requiere a menudo la copia de contenido del bloque de memoria antiguo a uno nuevo más grande. Esta operación deja intacto el contenido del bloque original, pero inaccesible para el programa, lo que impide que este pueda limpiar datos confidenciales de la memoria. Si un usuario malintencionado consigue examinar posteriormente el contenido del volcado de la memoria, los datos confidenciales podrían mostrarse.

Ejemplo: el siguiente código llama a realloc() en un búfer que contiene datos confidenciales:


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


Se intentan limpiar los datos confidenciales de la memoria, pero se utiliza realloc(), por lo que una copia de los mismos aún puede estar visible en la memoria asignada originalmente para plaintext_buffer.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.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 244
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 8.3.6 Sensitive Private Data (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[23] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection
Abstract
No utilice VirtualLock para bloquear páginas que contengan datos confidenciales. No siempre se implementa la función.
Explanation
Las vulnerabilidades de inspección de montón se producen cuando los datos confidenciales como, por ejemplo, una contraseña o una clave de cifrado, se pueden mostrar a un usuario malintencionado porque no se han eliminado de la memoria.

La función VirtualLock está diseñada para bloquear páginas en la memoria a fin de impedir que se transmitan a un disco. Sin embargo, en Windows 95/98/ME, la función solo se implementa como código stub y no tiene ningún efecto.

References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.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 591
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[19] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection_swappable_memory
Abstract
El programa crea un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo:

HtmlInputHidden hidden = new HtmlInputHidden();


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 472
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[10] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[13] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[35] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[36] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.hidden_field
Abstract
El programa crea un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo:

Hidden hidden = new Hidden(element);


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] IDS14-J. Do not trust the contents of hidden form fields CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 472
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[14] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[36] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[37] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.java.hidden_field
Abstract
Se utiliza un campo de formulario oculto.
Explanation
A menudo, los programadores confían en el contenido de los campos ocultos, suponiendo que los usuarios no podrán verlos ni manipular su contenido. Los atacantes pueden burlar estas suposiciones. Examinan los valores escritos en los campos ocultos y los alteran o reemplazan si contenido por datos de ataque.

Ejemplo: Una etiqueta <input> del tipo hidden indica el uso de un campo oculto.

<input type="hidden">


Si los campos ocultos contienen información confidencial, esta se incluirá en la caché al igual que el resto de la página. Esto provoca que la información confidencial se almacene en la caché del explorador sin que el usuario lo sepa.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 472
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002420
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[10] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[11] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[13] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 642
[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3610 CAT I
[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3610 CAT I
[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3610 CAT I
[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3610 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3610 CAT I
[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3610 CAT I
[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3610 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002485 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002485 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002485 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002485 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002485 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002485 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002485 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002485 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002485 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002485 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002485 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002485 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002485 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002485 CAT I
[35] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[36] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.content.html.hidden_field
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
Algunas funciones pueden devolver un puntero a la memoria fuera de los límites del búfer que se va a buscar. Las operaciones posteriores en el puntero podrían tener consecuencias no deseadas.
Explanation
Las funciones que buscan caracteres dentro de un búfer pueden devolver un puntero fuera de los límites del búfer proporcionado en cualquiera de las siguientes circunstancias:

- Un usuario controla el contenido del búfer que se va a buscar.

- Un usuario controla el valor que se va a buscar.

Ejemplo 1: El siguiente programa breve utiliza un argumento de línea de comandos que no es de confianza como búfer de búsqueda en una llamada a rawmemchr().


int main(int argc, char** argv) {
char* ret = rawmemchr(argv[0], 'x');
printf("%s\n", ret);
}


El programa está diseñado para imprimir una subcadena de argv[0], aunque es posible que acabe imprimiendo una parte de la memoria anterior a argv[0].

Este problema es similar a un error de finalización de cadena, en el que el programador utiliza una matriz de caracteres para incluir un terminador null.
References
[1] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[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 Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 466
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[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 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[17] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[18] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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 2009 Risky Resource Management - CWE ID 119
[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, 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
desc.semantic.cpp.illegal_pointer_value.master
Abstract
La clase está anotada como inmutable, pero un campo está mutado.
Explanation
A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Sin embargo, uno de los campos mutables de la clase presenta un método de mutación al que se llama desde fuera del constructor y el destructor.

Ejemplo 1: el siguiente código para una clase final inmutable declara un Set como private y final y, a continuación, crea erróneamente un método que modifica el Set.


@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...

public void addStooge(String name) {
stooges.add(name);
}
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[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 normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 471
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation
Abstract
La clase se ha anotado como inmutable, pero un campo no es final.
Explanation
A esta clase se le ha dado la anotación de Immutable, desde el paquete de anotaciones de JCIP. Un campo no final infringe la inmutabilidad de la clase al permitir la modificación del valor.

Ejemplo 1: el siguiente código de una clase inmutable declara de forma incorrecta un campo public y no final.


@Immutable
public class ImmutableInteger {
public int value;

}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] OBJ58-J. Limit the extensibility of classes and methods with invariants CERT
[4] MUTABLE-1: Prefer immutability for value types Oracle
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[9] Standards Mapping - Common Weakness Enumeration CWE ID 471
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[21] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_non_final_fields
Abstract
La clase se ha anotado como inmutable, pero un campo se ha modificado.
Explanation
A esta clase se le ha dado la anotación de Inmutable, desde el paquete de anotaciones de JCIP. Un campo público de tipo mutable permite que el código externo a la clase modifique el contenido e infrinja la inmutabilidad de la clase.

Ejemplo 1: el código siguiente para una clase final inmutable declara erróneamente un Set como public y final.


@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.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 471
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_public_mutable_fields
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
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


FORM GenerateReceiptURL CHANGING baseUrl TYPE string.
DATA: r TYPE REF TO cl_abap_random,
var1 TYPE i,
var2 TYPE i,
var3 TYPE n.


GET TIME.
var1 = sy-uzeit.
r = cl_abap_random=>create( seed = var1 ).
r->int31( RECEIVING value = var2 ).
var3 = var2.
CONCATENATE baseUrl var3 ".html" INTO baseUrl.
ENDFORM.


Este código utiliza la función CL_ABAP_RANDOM->INT31 para generar identificadores "únicos" para las páginas de recibos que crea. Como CL_ABAP_RANDOM es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
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 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 338
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[19] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.abap.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


string GenerateReceiptURL(string baseUrl) {
Random Gen = new Random();
return (baseUrl + Gen.Next().toString() + ".html");
}


Este código utiliza la función Random.Next() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.Next() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] RandomNumberGenerator Class Microsoft
[2] System.Security.Cryptography Namespace Microsoft
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 338
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.dotnet.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


char* CreateReceiptURL() {
int num;
time_t t1;
char *URL = (char*) malloc(MAX_URL);
if (URL) {
(void) time(&t1);
srand48((long) t1); /* use time to set seed */
sprintf(URL, "%s%d%s", "http://test.com/", lrand48(), ".html");
}
return URL;
}


Este código utiliza la función lrand48() para generar identificadores "únicos" para las páginas de recibos que crea. Como lrand48() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.
References
[1] B. Schneier Yarrow: A secure pseudorandom number generator
[2] CryptLib
[3] Crypto++
[4] BeeCrypt
[5] OpenSSL
[6] CryptoAPI: CryptGenRandom() Microsoft
[7] RtlGenRandom() Microsoft
[8] .NET System.Security.Cryptography: Random Number Generation Microsoft
[9] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[10] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[11] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[12] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[13] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[14] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[15] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[16] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[17] Standards Mapping - CIS Kubernetes Benchmark partial
[18] Standards Mapping - Common Weakness Enumeration CWE ID 338
[19] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[20] Standards Mapping - FIPS200 MP
[21] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[22] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[23] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[24] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[25] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[26] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[27] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[28] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[29] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[30] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[31] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[43] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cpp.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.


Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


<cfoutput>
Receipt: #baseUrl##Rand()#.cfm
</cfoutput>


Este código utiliza la función Rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] ColdFusion Java CFX Reference Adobe
[2] Java Cryptography Architecture Oracle
[3] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 338
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.cfml.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles. Sin embargo, su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: El siguiente código utiliza un PRNG estadístico para crear una clave RSA.


import "math/rand"
...
var mathRand = rand.New(rand.NewSource(1))
rsa.GenerateKey(mathRand, 2048)


Este código utiliza la función rand.New() a fin de generar aleatoridad para una clave RSA. Como rand.New() es un PRNG estadístico, es fácil que un atacante adivine los valores que genera.
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 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 338
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[19] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.golang.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (baseUrl + ranGen.nextInt(400000000) + ".html");
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.nextInt() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 338
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.java.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


function genReceiptURL (baseURL){
var randNum = Math.random();
var receiptURL = baseURL + randNum + ".html";
return receiptURL;
}


Este código utiliza la función Math.random() para generar identificadores "únicos" para las páginas de recibos que crea. Como Math.random() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Crypto | Node.js documentation The OpenJS Foundation and Node.js contributors
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 338
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[19] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[20] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.javascript.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


fun GenerateReceiptURL(baseUrl: String): String {
val ranGen = Random(Date().getTime())
return baseUrl + ranGen.nextInt(400000000).toString() + ".html"
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que cree. Como Random.nextInt() es un PRNG estadístico, es fácil que un atacante adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 338
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.kotlin.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


function genReceiptURL($baseURL) {
$randNum = rand();
$receiptURL = $baseURL . $randNum . ".html";
return $receiptURL;
}


Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
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 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 338
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[19] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.php.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


CREATE or REPLACE FUNCTION CREATE_RECEIPT_URL
RETURN VARCHAR2
AS
rnum VARCHAR2(48);
time TIMESTAMP;
url VARCHAR2(MAX_URL)
BEGIN
time := SYSTIMESTAMP;
DBMS_RANDOM.SEED(time);
rnum := DBMS_RANDOM.STRING('x', 48);
url := 'http://test.com/' || rnum || '.html';
RETURN url;
END


Este código utiliza la función DBMS_RANDOM.SEED() para generar identificadores "únicos" para las páginas de recibos que crea. Como DBMS_RANDOM.SEED() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también presenta errores, sería más seguro si utilizase un generador de números aleatorios que no crease identificadores de recepción predecibles.
References
[1] Oracle Database Security Guide
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 338
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[19] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[20] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.sql.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def genReceiptURL(self,baseURL):
randNum = random.random()
receiptURL = baseURL + randNum + ".html"
return receiptURL


Este código utiliza la función rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
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 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 338
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[9] Standards Mapping - FIPS200 MP
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[18] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[19] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.python.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def generateReceiptURL(baseUrl) {
randNum = rand(400000000)
return ("#{baseUrl}#{randNum}.html");
}


Este código utiliza la función Kernel.rand() para generar identificadores "únicos" para las páginas de recibos que crea. Como Kernel.rand() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 338
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[8] Standards Mapping - FIPS200 MP
[9] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[12] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[13] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[17] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[18] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[19] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.structural.ruby.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: El siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


def GenerateReceiptURL(baseUrl : String) : String {
val ranGen = new scala.util.Random()
ranGen.setSeed((new Date()).getTime())
return (baseUrl + ranGen.nextInt(400000000) + ".html")
}


Este código utiliza la función Random.nextInt() para generar identificadores "únicos" para las páginas de recibos que crea. Como Random.nextInt() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] Java Cryptography Architecture Oracle
[2] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[3] MSC02-J. Generate strong random numbers CERT
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 338
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[20] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[21] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.scala.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y, como tales, no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: El código siguiente usa un PRNG estadístico para crear un valor aleatorio que se usa como token de restablecimiento de contraseñas.


sqlite3_randomness(10, &reset_token)
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Elaine Barker and John Kelsey NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators NIST
[3] Elaine Barker and John Kelsey NIST DRAFT Special Publication 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation NIST
[4] Elaine Barker and John Kelsey DRAFT NIST Special Publication 800-90C: Recommendation for Random Bit Generator (RBG) Constructions NIST
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 338
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[18] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[21] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[22] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.3 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.swift.insecure_randomness
Abstract
Los generadores de números pseudoaleatorios estándar no pueden soportar ataques criptográficos.
Explanation
Cuando se utiliza una función que puede producir valores predecibles como un origen de aleatoriedad en un contexto de seguridad, se producen errores de aleatoriedad no segura.

Los equipos son máquinas deterministas y como tales no pueden producir una aleatoriedad auténtica. Los generadores de números pseudoaleatorios (PRNG, Pseudorandom Number Generator) aproximan la aleatoriedad de forma algorítmica, a partir de un valor de inicialización desde el que se calculan los valores siguientes.

Existen dos tipos de PRNG: estadísticos y criptográficos. Los PRNG estadísticos proporcionan propiedades estadísticas útiles, pero su resultado es altamente predecible y crea una secuencia numérica fácil de reproducir que no es adecuada para aquellos casos en los que la seguridad dependa de que los valores generados sean impredecibles. Los PRNG criptográficos resuelven este problema mediante la generación de resultados que sean más difíciles de predecir. Para que un valor sea criptográficamente seguro, debe ser imposible o altamente improbable para un usuario malintencionado distinguir entre el valor aleatorio generado y un valor verdaderamente aleatorio. Por lo general, si un algoritmo PRNG no se anuncia como criptográficamente seguro, es probable que se trate de un PRNG estadístico y no debería usarse en contextos relativos a la seguridad en los que su uso podría provocar vulnerabilidades graves, como contraseñas temporales fáciles de adivinar, claves criptográficas predecibles, secuestro de sesiones y suplantación de identidad DNS.

Ejemplo: el siguiente código utiliza un PRNG estadístico para crear una dirección URL de un recibo que permanece activo durante un período de tiempo después de una compra.


...
Function genReceiptURL(baseURL)
dim randNum
randNum = Rnd()
genReceiptURL = baseURL & randNum & ".html"
End Function
...


Este código utiliza la función Rnd() para generar identificadores "únicos" para las páginas de recibos que crea. Como Rnd() es un PRNG estadístico, es fácil que un usuario malintencionado adivine las cadenas que genera. Aunque el diseño subyacente del sistema de recepción también es defectuoso, sería más seguro si utilizara un generador de números aleatorios que no generase identificadores de recibos predecibles, como un PRNG criptográfico.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] CryptoAPI: CryptGenRandom() Microsoft
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 338
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[10] Standards Mapping - FIPS200 MP
[11] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-13 Cryptographic Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-13 Cryptographic Protection
[14] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[15] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 3.2.2 Session Binding Requirements (L1 L2 L3), 3.2.4 Session Binding Requirements (L2 L3), 6.3.1 Random Values (L2 L3), 6.3.2 Random Values (L2 L3), 6.3.3 Random Values (L3)
[19] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[20] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[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 7.3 - Use of Cryptography
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.3 - Use of Cryptography, Control Objective B.2.4 - Terminal Software Design
[33] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 330
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.2 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.2 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.2 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.2 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.2 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.2 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-002050 CAT II
desc.semantic.vb.insecure_randomness