Reino: Input Validation and Representation
Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.
Process Control
Abstract
La transferencia del control del programa a un programa o una transacción no confiables, o a un entorno que no es de confianza puede hacer que una aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre del programa o el código de la transacción que se invoca: el usuario malintencionado controla explícitamente el código de transacción o el nombre del programa.
- Un atacante puede cambiar el entorno en el que se invoca al programa o a la transacción: el usuario malintencionado controla implícitamente un área de comunicación que se pone a disposición de la transacción o el programa invocados.
En este caso, nos ocupamos principalmente del primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre del programa o el código de la transacción que se invoca. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena o como parte de una cadena que representa un nombre de programa o código de transacción que se invoca.
3. Mediante la ejecución de código desde la transacción o el programa invocados, la aplicación otorga al usuario malintencionado un privilegio o una capacidad que no tendría de otro modo.
Ejemplo 1: El siguiente fragmento de código de una utilidad del sistema con privilegios lee un valor de una solicitud HTTP para determinar el código de la transacción al que llamar.
Este fragmento de código permite a un usuario malintencionado llamar a cualquier transacción y ejecutar potencialmente código arbitrario con los privilegios elevados de la aplicación. Dado que el programa no valida el valor leído desde la solicitud HTTP, si un usuario malintencionado puede controlar este valor, podrá engañar a la aplicación para que ejecute código malintencionado y tome el control del sistema.
- Un usuario malintencionado puede cambiar el nombre del programa o el código de la transacción que se invoca: el usuario malintencionado controla explícitamente el código de transacción o el nombre del programa.
- Un atacante puede cambiar el entorno en el que se invoca al programa o a la transacción: el usuario malintencionado controla implícitamente un área de comunicación que se pone a disposición de la transacción o el programa invocados.
En este caso, nos ocupamos principalmente del primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre del programa o el código de la transacción que se invoca. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena o como parte de una cadena que representa un nombre de programa o código de transacción que se invoca.
3. Mediante la ejecución de código desde la transacción o el programa invocados, la aplicación otorga al usuario malintencionado un privilegio o una capacidad que no tendría de otro modo.
Ejemplo 1: El siguiente fragmento de código de una utilidad del sistema con privilegios lee un valor de una solicitud HTTP para determinar el código de la transacción al que llamar.
...
tid = request->get_form_field( 'tid' ).
CALL TRANSACTION tid USING bdcdata MODE 'N'
MESSAGES INTO messtab.
...
Este fragmento de código permite a un usuario malintencionado llamar a cualquier transacción y ejecutar potencialmente código arbitrario con los privilegios elevados de la aplicación. Dado que el programa no valida el valor leído desde la solicitud HTTP, si un usuario malintencionado puede controlar este valor, podrá engañar a la aplicación para que ejecute código malintencionado y tome el control del sistema.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[22] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[23] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[24] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[26] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.abap.process_control
Abstract
La carga de bibliotecas o de ejecutables desde un origen o un entorno que no son de confianza puede ocasionar que una aplicación ejecute comandos malintencionados en nombre de un atacante.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un atacante podría cambiar el nombre de la biblioteca o del ejecutable que carga el programa: el atacante controla de manera explícita cuál es el nombre de la biblioteca o del ejecutable.
- Un atacante podría cambiar el entorno en el que se carga la biblioteca o el ejecutable: el atacante controla de manera implícita lo que significa el nombre de la biblioteca o el ejecutable.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena o como parte de una cadena, la cual representa una biblioteca o un ejecutable que la aplicación carga.
3. Al ejecutar el código desde la biblioteca o el ejecutable, la aplicación concede al atacante un privilegio o una capacidad que no tendría de otro modo.
Ejemplo 1: el siguiente código de una utilidad de sistema con privilegios utiliza la propiedad de configuración de aplicación
Este código permite a un atacante cargar una biblioteca o un ejecutable y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
- Un atacante podría cambiar el nombre de la biblioteca o del ejecutable que carga el programa: el atacante controla de manera explícita cuál es el nombre de la biblioteca o del ejecutable.
- Un atacante podría cambiar el entorno en el que se carga la biblioteca o el ejecutable: el atacante controla de manera implícita lo que significa el nombre de la biblioteca o el ejecutable.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena o como parte de una cadena, la cual representa una biblioteca o un ejecutable que la aplicación carga.
3. Al ejecutar el código desde la biblioteca o el ejecutable, la aplicación concede al atacante un privilegio o una capacidad que no tendría de otro modo.
Ejemplo 1: el siguiente código de una utilidad de sistema con privilegios utiliza la propiedad de configuración de aplicación
APPHOME
y, a continuación, carga una biblioteca nativa en función de una ruta de acceso relativa desde el directorio especificado.
...
string lib = ConfigurationManager.AppSettings["APPHOME"];
Environment.ExitCode = AppDomain.CurrentDomain.ExecuteAssembly(lib);
...
Este código permite a un atacante cargar una biblioteca o un ejecutable y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
APPHOME
de la aplicación, con el objetivo de que apunte a una ruta diferente que contenga una versión malintencionada de LIBNAME
. Como el programa no valida el valor leído en el entorno, si el atacante puede controlar el valor de la propiedad del sistema APPHOME
, puede engañar a la aplicación para que ejecute código malintencionado y asumir el control del sistema.References
[1] Dotnet 4.6 API Documentation Microsoft
[2] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[23] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[24] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[27] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.dotnet.process_control
Abstract
La carga de bibliotecas desde una fuente que no es de confianza o un entorno no confiable puede provocar que una aplicación ejecute código malicioso en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un atacante puede cambiar la biblioteca que el programa ejecuta: el atacante controla explícitamente cuál es la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como parte de una cadena que representa un nombre de biblioteca cargada por la aplicación.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza una entrada del Registro para determinar el directorio en el que se ha instalado y carga un archivo de biblioteca en función de una ruta relativa desde el directorio especificado.
El código de este ejemplo permite a un usuario malintencionado cargar una biblioteca arbitraria desde la que se ejecutará el código con el privilegio elevado de la aplicación, modificando una clave del Registro para especificar una ruta diferente que contenga una versión maliciosa de
Ejemplo 2: el siguiente código procede de una utilidad de administración basada en la Web que concede acceso a los usuarios a una interfaz mediante la que pueden actualizar su perfil en el sistema. La utilidad usa una biblioteca con el nombre
Sin embargo, el programa no especifica una ruta absoluta para
Este tipo de ataque es posible debido al orden de búsqueda usado por
La clave no está definida en los sistemas Windows 2000/NT ni Windows Me/98/95.
En los sistemas en los que existe la clave,
Si
(Configuración predeterminada para Windows XP-SP1 y versiones posteriores, así como para Windows Server 2003.)
1. El directorio desde el que se cargó la aplicación.
2. El directorio del sistema.
3. El directorio del sistema de 16 bits, si existe.
4. El directorio de Windows.
5. El directorio actual.
6. Los directorios enumerados en la variable de entorno
Si
1. El directorio desde el que se cargó la aplicación.
2. El directorio actual.
3. El directorio del sistema.
4. El directorio del sistema de 16 bits, si existe.
5. El directorio de Windows.
6. Los directorios enumerados en la variable de entorno
- Un atacante puede cambiar la biblioteca que el programa ejecuta: el atacante controla explícitamente cuál es la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como parte de una cadena que representa un nombre de biblioteca cargada por la aplicación.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza una entrada del Registro para determinar el directorio en el que se ha instalado y carga un archivo de biblioteca en función de una ruta relativa desde el directorio especificado.
...
RegQueryValueEx(hkey, "APPHOME",
0, 0, (BYTE*)home, &size);
char* lib=(char*)malloc(strlen(home)+strlen(INITLIB));
if (lib) {
strcpy(lib,home);
strcat(lib,INITCMD);
LoadLibrary(lib);
}
...
El código de este ejemplo permite a un usuario malintencionado cargar una biblioteca arbitraria desde la que se ejecutará el código con el privilegio elevado de la aplicación, modificando una clave del Registro para especificar una ruta diferente que contenga una versión maliciosa de
INITLIB
. Como el programa no valida el valor leído del entorno, si un usuario malintencionado puede controlar el valor de APPHOME
, este puede engañar a la aplicación para que ejecute código malicioso.Ejemplo 2: el siguiente código procede de una utilidad de administración basada en la Web que concede acceso a los usuarios a una interfaz mediante la que pueden actualizar su perfil en el sistema. La utilidad usa una biblioteca con el nombre
liberty.dll
, que se supone que se encuentra en un directorio del sistema estándar.
LoadLibrary("liberty.dll");
Sin embargo, el programa no especifica una ruta absoluta para
liberty.dll
. Si un usuario malintencionado traslada en el orden de búsqueda una biblioteca maliciosa con el nombre liberty.dll
a una posición superior que el archivo previsto y consigue ejecutar el programa en su entorno en lugar de en el entorno del servidor web, la aplicación cargará la biblioteca maliciosa en lugar de la de confianza. Como este tipo de aplicación se ejecuta con privilegios elevados, el contenido del archivo liberty.dll
del usuario malintencionado se ejecutará ahora también con este nivel de privilegios, lo que podría darle el control completo del sistema.Este tipo de ataque es posible debido al orden de búsqueda usado por
LoadLibrary()
cuando no se especifica una ruta absoluta. Si se realiza una búsqueda en el directorio actual antes que en los directorios del sistema, como era el caso hasta las versiones más recientes de Windows, este tipo de ataque pasa a ser trivial si el atacante puede ejecutar de forma local el programa. El orden de búsqueda depende de la versión del sistema operativo y, en los sistemas operativos más recientes, se controla mediante el valor de esta clave del Registro:
HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode
La clave no está definida en los sistemas Windows 2000/NT ni Windows Me/98/95.
En los sistemas en los que existe la clave,
LoadLibrary()
presenta el siguiente comportamiento:Si
SafeDllSearchMode
es 1, se utiliza el siguiente orden de búsqueda:(Configuración predeterminada para Windows XP-SP1 y versiones posteriores, así como para Windows Server 2003.)
1. El directorio desde el que se cargó la aplicación.
2. El directorio del sistema.
3. El directorio del sistema de 16 bits, si existe.
4. El directorio de Windows.
5. El directorio actual.
6. Los directorios enumerados en la variable de entorno
PATH
.Si
SafeDllSearchMode
es 0, se utiliza el siguiente orden de búsqueda:1. El directorio desde el que se cargó la aplicación.
2. El directorio actual.
3. El directorio del sistema.
4. El directorio del sistema de 16 bits, si existe.
5. El directorio de Windows.
6. Los directorios enumerados en la variable de entorno
PATH
.References
[1] LoadLibraryW function Microsoft
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[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 - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[16] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[23] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[24] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[25] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[27] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[28] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.cpp.process_control
Abstract
La transferencia del control del programa a un programa de aplicación o a un entorno que no es de confianza puede provocar que la aplicación ejecute comandos malintencionados en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre del programa que se invoca: el usuario malintencionado controla explícitamente el nombre del programa de aplicación.
- Un usuario malintencionado puede cambiar el entorno en el que se invoca el programa: el usuario malintencionado controla implícitamente un área de comunicación que pasa a estar disponible para el programa invocado.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el nombre del programa que se invoca. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como parte o totalidad de una cadena que representa un programa que se invoca, o determina el grado de control sobre el entorno en el que se invoca el programa.
3. Mediante la ejecución de código desde el programa invocado, la aplicación brinda al usuario malintencionado un privilegio o capacidad que dicho usuario no tendría en caso contrario.
Ejemplo 1: El siguiente código de una utilidad de sistema con privilegios lee un valor desde el terminal para determinar el nombre del programa al que se transfiere el control.
Este código permite a un usuario malintencionado transferir el control a un programa y potencialmente ejecutar el código arbitrario con el privilegio elevado de la aplicación. Dado que el programa no valida el valor leído del terminal, si un usuario malintencionado controla este valor, entonces puede engañar a la aplicación para que ejecute código malintencionado y tomar el control del sistema.
- Un usuario malintencionado puede cambiar el nombre del programa que se invoca: el usuario malintencionado controla explícitamente el nombre del programa de aplicación.
- Un usuario malintencionado puede cambiar el entorno en el que se invoca el programa: el usuario malintencionado controla implícitamente un área de comunicación que pasa a estar disponible para el programa invocado.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el nombre del programa que se invoca. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como parte o totalidad de una cadena que representa un programa que se invoca, o determina el grado de control sobre el entorno en el que se invoca el programa.
3. Mediante la ejecución de código desde el programa invocado, la aplicación brinda al usuario malintencionado un privilegio o capacidad que dicho usuario no tendría en caso contrario.
Ejemplo 1: El siguiente código de una utilidad de sistema con privilegios lee un valor desde el terminal para determinar el nombre del programa al que se transfiere el control.
...
ACCEPT PROGNAME.
EXEC CICS
LINK PROGRAM(PROGNAME)
COMMAREA(COMA)
LENGTH(LENA)
DATALENGTH(LENI)
SYSID('CONX')
END-EXEC.
...
Este código permite a un usuario malintencionado transferir el control a un programa y potencialmente ejecutar el código arbitrario con el privilegio elevado de la aplicación. Dado que el programa no valida el valor leído del terminal, si un usuario malintencionado controla este valor, entonces puede engañar a la aplicación para que ejecute código malintencionado y tomar el control del sistema.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[22] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[23] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[24] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[26] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.cobol.process_control
Abstract
La carga de bibliotecas desde una fuente que no es de confianza o un entorno no confiable puede provocar que una aplicación ejecute comandos maliciosos en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza la propiedad del sistema
Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
Ejemplo 2: el siguiente código utiliza
El problema aquí es que
Un archivo que contiene código nativo se carga desde el sistema de archivos local, desde una ubicación en la que se suelen obtener los archivos de biblioteca. Los detalles de este proceso dependen de la implementación. La asignación de un nombre de biblioteca a un nombre de archivo concreto se realiza de forma específica al sistema.
Si un usuario malintencionado es capaz de incluir en el orden de búsqueda una copia maliciosa de
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza la propiedad del sistema
APPHOME
para determinar el directorio en el que se ha instalado y, a continuación, carga una biblioteca nativa en función de una ruta relativa desde el directorio especificado.
...
String home = System.getProperty("APPHOME");
String lib = home + LIBNAME;
java.lang.Runtime.getRuntime().load(lib);
...
Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
APPHOME
para que señale a una ruta diferente que contiene una versión maliciosa de LIBNAME
. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME
, pueden engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema. Ejemplo 2: el siguiente código utiliza
System.loadLibrary()
para cargar código de una biblioteca nativa denominada library.dll
, que normalmente se encuentra en un directorio del sistema estándar.
...
System.loadLibrary("library.dll");
...
El problema aquí es que
System.loadLibrary()
acepta un nombre de biblioteca y no una ruta para que se cargue la biblioteca. Según la documentación de la API de Java 1.4.2 API, esta función se comporta de la siguiente forma [1]:Un archivo que contiene código nativo se carga desde el sistema de archivos local, desde una ubicación en la que se suelen obtener los archivos de biblioteca. Los detalles de este proceso dependen de la implementación. La asignación de un nombre de biblioteca a un nombre de archivo concreto se realiza de forma específica al sistema.
Si un usuario malintencionado es capaz de incluir en el orden de búsqueda una copia maliciosa de
library.dll
en una posición superior a la del archivo que pretende cargar la aplicación, esta cargará la copia malintencionada en lugar del archivo previsto. Dada la naturaleza de la aplicación, esta se ejecuta con privilegios elevados. Es decir, que el contenido de library.dll
del usuario malintencionado se ejecutará con privilegios elevados, dándole la posibilidad de tener un control completo del sistema.References
[1] Java 1.4.2 API Documentation Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[23] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[24] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[27] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.java.process_control
Abstract
La carga de bibliotecas desde una fuente que no es de confianza o un entorno no confiable puede provocar que una aplicación ejecute comandos maliciosos en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el código siguiente utiliza una "función" no documentada actualmente de
En
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el código siguiente utiliza una "función" no documentada actualmente de
Express
para cargar un archivo de biblioteca de forma dinámica. Node.js
seguirá buscando en la ruta de carga de biblioteca habitual un archivo o un directorio que contenga dicha biblioteca[1].
var express = require('express');
var app = express();
app.get('/', function(req, res, next) {
res.render('tutorial/' + req.params.page);
});
En
Express
, la página que se transfiere a Response.render()
cargará una biblioteca de la extensión cuando no se conozca de antemano. Esto suele estar bien para las entradas como "foo.pug", ya que implica la carga de la biblioteca pug
, un motor de creación de plantillas muy conocido. Sin embargo, si un atacante controlase la página, y por lo tanto la extensión, podría cargar cualquier biblioteca de las rutas de carga de módulos Node.js
. Dado que el programa no valida la información recibida del parámetro de URL, un atacante podría engañar a la aplicación para que ejecutara código malintencionado y tomara el control del sistema.References
[1] Node.js Modules Documentation Node.js
[2] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[23] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[24] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[27] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.javascript.process_control
Abstract
La carga de bibliotecas desde una fuente que no es de confianza o un entorno no confiable puede provocar que una aplicación ejecute comandos maliciosos en nombre de un usuario malintencionado.
Explanation
Las vulnerabilidades de control del proceso presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza la propiedad del sistema
Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
Ejemplo 2: el siguiente código utiliza
El problema aquí es que
Si un usuario malintencionado es capaz de incluir en el orden de búsqueda una copia maliciosa de
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el nombre de la biblioteca que se ha cargado. Las vulnerabilidades de control del proceso de este tipo se producen cuando:
1. Los datos entran en la aplicación desde una fuente no confiable.
2. Los datos se utilizan como una cadena que representa una biblioteca cargada por la aplicación o como parte de esta.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Ejemplo 1: el siguiente código de una aplicación con privilegios utiliza la propiedad del sistema
APPHOME
para determinar el directorio en el que se ha instalado y, a continuación, carga una biblioteca nativa en función de una ruta relativa desde el directorio especificado.
...
$home = getenv("APPHOME");
$lib = $home + $LIBNAME;
dl($lib);
...
Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de la propiedad
APPHOME
para que señale a una ruta diferente que contiene una versión maliciosa de LIBNAME
. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME
, pueden engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.Ejemplo 2: el siguiente código utiliza
dl()
para cargar código de una biblioteca denominada sockets.dll
, que puede cargarse desde varios ubicaciones, según la instalación y configuración.
...
dl("sockets");
...
El problema aquí es que
dl()
acepta un nombre de biblioteca y no una ruta para que se cargue la biblioteca.Si un usuario malintencionado es capaz de incluir en el orden de búsqueda una copia maliciosa de
sockets.dll
en una posición superior a la del archivo que pretende cargar la aplicación, esta cargará la copia malintencionada en lugar del archivo previsto. Dada la naturaleza de la aplicación, esta se ejecuta con privilegios elevados. Es decir, que el contenido de sockets.dll
del usuario malintencionado se ejecutará con privilegios elevados, dándole la posibilidad de tener un control completo del sistema.References
[1] M. Achour et al. PHP Manual
[2] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[15] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[20] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[21] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[22] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[23] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[24] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[27] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.dataflow.php.process_control
Abstract
La carga de bibliotecas desde una fuente que no es de confianza o un entorno no confiable puede provocar que una aplicación ejecute comandos maliciosos en nombre de un usuario malintencionado. Dentro de Ruby hay lugares comunes donde pueden producirse tanto ataques de control de procesos como ataques de inyección de comandos.
Explanation
Dentro de Ruby, el control de procesos puede producirse habitualmente cuando se ejecuta un comando, lo que habilita dos ataques:
1. Control de procesos
Las vulnerabilidades de control de procesos presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos interesa principalmente el segundo escenario, la posibilidad de que un atacante pueda ser capaz de controlar el entorno de forma que el programa cargue una versión malintencionada de la biblioteca nombrada.
1. Un atacante proporciona una biblioteca malintencionada a una aplicación.
2. La aplicación carga la biblioteca malintencionada porque no consigue especificar una ruta de acceso absoluta o verificar el archivo que se está cargando.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Tenga en cuenta que el control de procesos puede ocurrir en plataformas Windows al ejecutar un programa externo, ya que el shell utilizado para ejecutar los comandos se elige mediante las variables de entorno RUBYSHELL o COMSPEC. Si un usuario malintencionado es capaz de modificar cualquiera de estas variables de entorno en el entorno actual, significa que el programa al que apuntan estas variables de entorno se ejecutará con el permiso o el programa de Ruby en ejecución.
2. Inyección de comandos
Las vulnerabilidades de inyección de comandos se presentan de dos formas:
- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.
- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.
En este caso, nos ocupamos principalmente del segundo escenario, la posibilidad de que un usuario malintencionado pueda cambiar el significado del comando cambiando una variable de entorno o colocando un ejecutable malintencionado al principio en la ruta de búsqueda. Las vulnerabilidades Command Injection de este tipo se producen cuando:
1. Un usuario malintencionado modifica el entorno de una aplicación.
2. La aplicación ejecuta un comando sin especificar una ruta de acceso absoluta o comprobar el archivo binario que se está ejecutando.
3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.
Ejemplo 1: El siguiente código ejecuta
Esto plantea un doble problema:
1. En las plataformas Windows,
2. En todas las plataformas de este escenario, el problema es que el programa no especifica una ruta absoluta y no puede limpiar su entorno antes de ejecutar la llamada a
1. Control de procesos
Las vulnerabilidades de control de procesos presentan dos formas:
- Un usuario malintencionado puede cambiar el nombre de la biblioteca que carga el programa: este controla de forma explícita cuál es el nombre de la biblioteca.
- Un usuario malintencionado puede modificar el entorno en el que se carga la biblioteca: este controla de forma implícita lo que significa el nombre de la biblioteca.
En este caso, nos interesa principalmente el segundo escenario, la posibilidad de que un atacante pueda ser capaz de controlar el entorno de forma que el programa cargue una versión malintencionada de la biblioteca nombrada.
1. Un atacante proporciona una biblioteca malintencionada a una aplicación.
2. La aplicación carga la biblioteca malintencionada porque no consigue especificar una ruta de acceso absoluta o verificar el archivo que se está cargando.
3. Al ejecutar el código desde la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.
Tenga en cuenta que el control de procesos puede ocurrir en plataformas Windows al ejecutar un programa externo, ya que el shell utilizado para ejecutar los comandos se elige mediante las variables de entorno RUBYSHELL o COMSPEC. Si un usuario malintencionado es capaz de modificar cualquiera de estas variables de entorno en el entorno actual, significa que el programa al que apuntan estas variables de entorno se ejecutará con el permiso o el programa de Ruby en ejecución.
2. Inyección de comandos
Las vulnerabilidades de inyección de comandos se presentan de dos formas:
- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.
- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.
En este caso, nos ocupamos principalmente del segundo escenario, la posibilidad de que un usuario malintencionado pueda cambiar el significado del comando cambiando una variable de entorno o colocando un ejecutable malintencionado al principio en la ruta de búsqueda. Las vulnerabilidades Command Injection de este tipo se producen cuando:
1. Un usuario malintencionado modifica el entorno de una aplicación.
2. La aplicación ejecuta un comando sin especificar una ruta de acceso absoluta o comprobar el archivo binario que se está ejecutando.
3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.
Ejemplo 1: El siguiente código ejecuta
Kernel.system()
para ejecutar un ejecutable llamado program.exe
, que normalmente se encuentra dentro de un directorio estándar del sistema.
...
system("program.exe")
...
Esto plantea un doble problema:
1. En las plataformas Windows,
Kernel.system()
ejecuta algo a través de un shell. Si un usuario malintencionado es capaz de manipular las variables de entorno RUBYSHELL
o COMSPEC
, es posible que apunten a un ejecutable malintencionado al que se llamará con el comando dado a Kernel.system()
. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando program.exe
del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionándole un control completo del sistema.2. En todas las plataformas de este escenario, el problema es que el programa no especifica una ruta absoluta y no puede limpiar su entorno antes de ejecutar la llamada a
Kernel.system()
. Si un usuario malintencionado puede modificar la variable $PATH
para que señale a un archivo binario malintencionado llamado program.exe
y, a continuación, ejecutar la aplicación en su entorno, el archivo malintencionado binario se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando program.exe
del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionándole un control completo del sistema.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 114, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[13] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[14] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[19] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[20] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[21] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[22] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[23] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[24] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[26] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20), Improper Filesystem Permissions (WASC-17)
desc.structural.ruby.process_control