Reino: API Abuse

Un API es un contrato entre un autor de llamada y un receptor de llamada. Las formas de abuso de API más comunes los produce el autor de llamada cuando no consigue atender su fin de este contrato. Por ejemplo, si un programa no consigue llamar chdir() después de llamar chroot(), se viola el contrato que especifica cómo cambiar el directorio de origen activo de una forma segura. Otro buen ejemplo de un abuso de manual es esperar que el receptor devuelva una información de DNS de confianza al autor de llamada. En este caso, el autor de llamada abusa el API del receptor haciendo determinadas suposiciones sobre su comportamiento (que el valor de retorno se puede usar con fines de autenticación). También se puede violar el contrato entre el autor de llamada y el receptor desde el otro lado. Por ejemplo, si un codificador envía SecureRandom y devuelve un valor no aleatorio, se viola el contrato.

81 elementos encontrados
Debilidades
Abstract
Los atacantes pueden reemplazar las entradas DNS. Por motivos de seguridad, no confíe en nombres DNS.
Explanation
Muchos servidores DNS son susceptibles de sufrir ataques, por eso debe suponer que su software se ejecutará alguna vez en un entorno con un servidor DNS afectado. Si los atacantes están autorizados a hacer actualizaciones de DNS (a veces denominado envenenamiento de la caché del DNS), pueden redirigir su tráfico de red a través de sus equipos o hacer que parezca que sus direcciones IP forman parte de su dominio. No base la seguridad de su sistema en nombres DNS.
Ejemplo: el siguiente ejemplo de código utiliza una búsqueda DNS para determinar si una solicitud entrante es de un host de confianza o no. Si un atacante es capaz de dañar la caché DNS, puede obtener un estatus de confianza.


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


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


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


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


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

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

...
String isValid = "true";
if ( Boolean.getBoolean(isValid) ) {
System.out.println("TRUE");
}
else {
System.out.println("FALSE");
}
...
References
[1] Class Boolean Oracle
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.semantic.java.often_misused_boolean_getboolean
Abstract
El reemplazo incorrecto de las clases de .NET Framework puede provocar que se ejecute código arbitrario en el servidor, que se abuse de la lógica de la aplicación o que se deniegue el servicio.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los ataques más devastadores normalmente incluyen la ejecución remota de código, con la cual un atacante consigue ejecutar código malintencionado en el contexto del programa. El método GetChars en las clases Decoder y Encoding, y el método GetBytes en las clases Encoder y Encoding de .NET Framework llevan a cabo aritmética de puntero de forma interna en las matrices de caracteres y bytes para convertir un intervalo de caracteres en un intervalo de bytes y viceversa.
Cuando se realizan operaciones de aritmética de puntero, los desarrolladores suelen sustituir los métodos anteriores incorrectamente e introducen vulnerabilidades como la ejecución de código arbitrario, el abuso de la lógica de la aplicación y la denegación del servicio.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 176
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.dotnet.often_misused_encoding
Abstract
Este método es difícil de usar correctamente.
Explanation
Es fácil creer que este método de codificación le protegerá contra ataques de inserción; sin embargo, si el método no se usa exactamente en el contexto adecuado, puede ofrecer mucha menos protección de la que merece.

Ejemplo 1: la siguiente llamada de codificación permite a un atacante tener un poco de libertad para insertar JavaScript malintencionado:

out.println("x = " + encoder.encodeForJavaScript(input) + ";");
References
[1] OWASP ESAPI Secure Coding Guideline
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 176
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.structural.java.often_misused_encoding
Abstract
Es posible que la llamada ajuste perfectamente los caracteres. Los caracteres no admitidos que se transfieren a los métodos de la API de forma predeterminada se pueden asignar con ajuste perfecto a caracteres peligrosos.
Explanation
Cuando los juegos de caracteres entre el sistema operativo y las aplicaciones que se ejecutan en este no coinciden, los caracteres no admitidos que se pasan a los métodos de la API de forma predeterminada pueden asignarse con ajuste perfecto a caracteres peligrosos.

Ejemplo 1:en Objective-C, el ejemplo siguiente convierte un objeto NSString que contiene un carácter UTF-8 a datos ASCII de nuevo:


...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...


Si examina cuidadosamente el resultado, el carácter "..." se tradujo por tres puntos consecutivos. Si ha medido el búfer de salida basándose en el búfer de entrada, la aplicación podría ser vulnerable al buffer overflow. Se pueden asignar otros caracteres de un carácter a dos. El carácter griego "fi" se asignará a una "f" seguida de una letra "i". Al cargar el búfer con estos caracteres de carga frontal, un usuario malintencionado obtiene un control completo sobre el número de caracteres que se utilizan para provocar el buffer overflow.
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 176
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.objc.method_may_best_fit_map_characters
Abstract
Es posible que la llamada ajuste perfectamente los caracteres. Los caracteres no admitidos que se transfieren a los métodos de la API de forma predeterminada se pueden asignar con ajuste perfecto a caracteres peligrosos.
Explanation
Cuando los juegos de caracteres entre el sistema operativo y las aplicaciones que se ejecutan en este no coinciden, los caracteres no admitidos que se pasan a los métodos de la API de forma predeterminada pueden asignarse con ajuste perfecto a caracteres peligrosos.

Ejemplo 1: En Swift, el ejemplo siguiente convierte un objeto NSString que contiene un carácter UTF-8 a datos ASCII de nuevo:


...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...


Si examina cuidadosamente el resultado, el carácter "..." se tradujo por tres puntos consecutivos. Si ha medido el búfer de salida basándose en el búfer de entrada, la aplicación podría ser vulnerable al buffer overflow. Se pueden asignar otros caracteres de un carácter a dos. El carácter griego "fi" se asignará a una "f" seguida de una letra "i". Al cargar el búfer con estos caracteres de carga frontal, un usuario malintencionado obtiene un control completo sobre el número de caracteres que se utilizan para provocar el buffer overflow.
References
[1] Apple Secure Coding Guide Apple
[2] String Programming Guide Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 176
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.2 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
desc.semantic.swift.method_may_best_fit_map_characters
Abstract
La función _alloca() puede lanzar una excepción de desbordamiento de pila, que podría ocasionar el bloqueo del programa.
Explanation
La función _alloca() asigna memoria en la pila. Si una solicitud de asignación es demasiado grande para el espacio de pila disponible, _alloca() lanza una excepción. Si la excepción no se detecta, el programa se bloquea, con la posibilidad de que se habilite un ataque por denegación de servicio.
_alloca() está en desuso desde Microsoft Visual Studio 2005(R). Se ha sustituido por _alloca_s(), más seguro.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 248
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation
[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
desc.semantic.cpp.often_misused_exception_handling._alloca
Abstract
Transferir un búfer de salida de un tamaño inadecuado a una función de manipulación de rutas de acceso puede ocasionar un desbordamiento de búfer.
Explanation
Windows proporciona una gran cantidad de funciones de utilidad que manipulan los búferes que contienen nombres de archivos. En la mayoría de los casos, el resultado es devuelto en un búfer que se transfiere como entrada. (Normalmente el nombre de archivo se modifica en su sitio). La mayoría de las funciones requieren que el búfer tenga una longitud mínima de MAX_PATH bytes, aunque debe consultar la documentación de cada función individualmente. Si el búfer no tiene la longitud suficiente como para almacenar el resultado de la manipulación, podría producirse un desbordamiento de búfer.

Ejemplo:

char *createOutputDirectory(char *name) {
char outputDirectoryName[128];
if (getCurrentDirectory(128, outputDirectoryName) == 0) {
return null;
}
if (!PathAppend(outputDirectoryName, "output")) {
return null;
}
if (!PathAppend(outputDirectoryName, name)) {
return null;
}
if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
!= ERROR_SUCCESS) {
return null;
}
return StrDup(outputDirectoryName);
}


En este ejemplo, la función crea un directorio llamado "output\<name>" en el directorio actual y devuelve una copia de su nombre asignada por montón. Para la mayoría de los valores del directorio actual y el parámetro de nombre, esta función funcionará correctamente. Sin embargo, si el parámetro name es especialmente largo, entonces la segunda llamada a PathAppend() podría provocar el buffer overflow outputDirectoryName, que tiene menos de MAX_PATH bytes.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.cpp.often_misused_file_system.windows
Abstract
La máscara especificada por el argumento umask() se confunde habitualmente con el argumento para chmod().
Explanation
La página man de umask() comienza por la instrucción falsa:

"umask sets the umask to mask & 0777"

Aunque este comportamiento se ajustaría más al uso de chmod(), cuando el argumento proporcionado por el usuario especifica los bits para habilitar el archivo concreto, el comportamiento de umask() es precisamente el contrario: umask() establece umask en ~mask & 0777.

La página man de umask() continúa para describir el uso correcto de umask():

"open() utiliza umask para establecer los permisos de archivo iniciales de un archivo recién creado. De forma específica, los permisos de umask se desactivan desde el argumento de modo para open(2) (de esta forma, por ejemplo, el valor predeterminado umask normal de 022 resultados en los archivos que se están creando con permisos 0666 &amp; ~022 = 0644 = rw-r--r-- en el caso habitual donde se encuentra el modo se especifica como 0666)".
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.java.often_misused_file_system
Abstract
La llamada identificada utiliza métodos que siguen vínculos simbólicos.
Explanation
Se sabe que determinadas funciones siguen ciegamente los vínculos simbólicos. Cuando esto suceda, la aplicación se abrirá, leerá o escribirá datos en el archivo al que señala el vínculo simbólico en lugar de en la representación del vínculo simbólico. Un atacante puede engañar a la aplicación al escribir en archivos de sistema alternativos o críticos o proporcionar datos expuestos a la aplicación.

Ejemplo 1: el código siguiente utiliza las funciones que siguen los vínculos simbólicos:


...
struct stat output;
int ret = stat(aFilePath, &output);
// error handling omitted for this example
struct timespec accessTime = output.st_atime;
...
References
[1] Apple Secure Coding Guide Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.objc.methods_follow_sym_links
Abstract
La máscara especificada por el argumento umask() se confunde habitualmente con el argumento para chmod().
Explanation
La página man de umask() comienza por la instrucción falsa:

"umask establece umask para enmascarar & 0777"

Aunque este comportamiento se ajustaría más al uso de chmod(), cuando el argumento proporcionado por el usuario especifica los bits para habilitar el archivo concreto, el comportamiento de umask() es precisamente el contrario: umask() establece umask en ~mask & 0777.

La página man de umask() continúa para describir el uso correcto de umask():

"Se utiliza umask para establecer los permisos de archivo iniciales de un archivo recién creado. De forma específica, los permisos umask se desactivan desde el argumento de modo (de esta forma, por ejemplo, el valor predeterminado umask normal de 022 da como resultado nuevos archivos que se crean con permisos 0666 & ~022 = 0644 = rw-r--r-- en el caso habitual donde el modo se especifica como 0666)."
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[18] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[21] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[22] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.python.often_misused_file_system.umask
Abstract
La llamada utiliza los métodos que escriben en los archivos temporales antes de escribir en el archivo de destino.
Explanation
Muchas API reducirán el riesgo de pérdida de datos al escribir completamente en un archivo temporal y, a continuación, copiar el archivo completo en la ubicación de destino. Asegúrese de que el método identificado no funciona en archivos o rutas de acceso de directorios públicos o temporales ya que un atacante puede reemplazar el archivo temporal de la instantánea antes de escribirlo en el archivo de destino. Esto permite al atacante controlar el contenido de los archivos que la aplicación utiliza en directorios públicos.

Ejemplo 1: el código siguiente escribe el transactionId activo en un archivo temporal del directorio Documentos de la aplicación empleando un método vulnerable:


...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...
References
[1] Apple Secure Coding Guide Apple
[2] Apple NSString Class Reference Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 249, CWE ID 560
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[22] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3590.1 CAT I
[23] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3590.1 CAT I
[24] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3590.1 CAT I
[25] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3590.1 CAT I
[26] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3590.1 CAT I
[27] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3590.1 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3590.1 CAT I
desc.semantic.swift.methods_unsafe_on_public_or_tmp_directories
Abstract
Autorizar a los usuarios a que carguen archivos puede permitir a los atacantes introducir contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los usuarios malintencionados más devastadores normalmente incluyen la ejecución remota de código, con la cual un usuario malintencionado consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los atacantes que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen a un intérprete de código (por ejemplo, JSP/ASPX/PHP), los atacantes pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.

El código siguiente recibe un archivo cargado que asigna al objeto posted. FileUpload es del tipo System.Web.UI.HtmlControls.HtmlInputFile.
Ejemplo:

HttpPostedFile posted = FileUpload.PostedFile;

Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o inclusión peligrosa de archivos, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.dotnet.often_misused_file_upload
Abstract
El hecho de permitir que los usuarios carguen archivos puede provocar que los atacantes inyecten contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los ataques más devastadores normalmente incluyen la ejecución remota de código, con la cual un atacante consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los atacantes que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen a un intérprete de código (por ejemplo, JSP/ASPX/PHP), los atacantes pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.

Ejemplo: la siguiente clase de controlador Spring MVC presenta un parámetro que permite administrar los archivos cargados.

@Controller
public class MyFormController {
...
@RequestMapping("/test")
public String uploadFile (org.springframework.web.multipart.MultipartFile file) {
...
} ...
}


Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o inclusión peligrosa de archivos, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.java.often_misused_file_upload_spring
Abstract
Autorizar a los usuarios a que carguen archivos puede permitir a los atacantes introducir contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los usuarios malintencionados más devastadores normalmente incluyen la ejecución remota de código, con la cual un usuario malintencionado consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los atacantes que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen al intérprete de PHP, los atacantes pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.

Ejemplo 1: el siguiente código procesa los archivos cargados y los mueve a un directorio de la raíz web. Los atacantes pueden cargar archivos de origen de PHP malintencionados a este programa y, a continuación, solicitarlos del servidor, lo que hará que el intérprete de PHP los ejecute.


<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
echo "Valid upload received\n";
} else {
echo "Invalid upload rejected\n";
} ?>


Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o introducción remota, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.
References
[1] M. Achour et al. PHP Manual
[2] PHP Security Consortium PhpSecInfo Test Information
[3] Alla Bezroutchko Secure file upload in PHP web applications
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[20] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[22] Standards Mapping - OWASP Top 10 2010 A1 Injection
[23] Standards Mapping - OWASP Top 10 2013 A1 Injection
[24] Standards Mapping - OWASP Top 10 2017 A1 Injection
[25] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.php.often_misused_file_upload
Abstract
Autorizar a los usuarios a que carguen archivos puede permitir a los atacantes introducir contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los usuarios malintencionados más devastadores normalmente incluyen la ejecución remota de código, con la cual un usuario malintencionado consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los usuarios malintencionados que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen al intérprete de Python, los usuarios malintencionados pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.

Ejemplo 1: el siguiente código procesa los archivos cargados y los mueve a un directorio de la raíz web. Los atacantes podrían cargar archivos malintencionados a este programa y posteriormente solicitarlos desde el servidor.


from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
files = request.FILES
for f in files.values():
path = default_storage.save('upload/', File(f))
...


Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o introducción remota, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.
References
[1] Django Foundation File Uploads
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.python.often_misused_file_upload
Abstract
Autorizar a los usuarios a que carguen archivos puede permitir a los atacantes introducir contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los usuarios malintencionados más devastadores normalmente incluyen la ejecución remota de código, con la cual un usuario malintencionado consigue ejecutar código malintencionado en el contexto del programa. Si los atacantes pueden cargar archivos en un directorio ejecutable públicamente, entonces pueden hacer que el código malintencionado que contienen estos archivos se ejecute en el servidor.

Incluso aunque un programa almacene archivos cargados en un directorio que no sea de acceso público, los atacantes podrían seguir siendo capaces de aprovechar la capacidad de introducir contenido malintencionado en el entorno del servidor para elaborar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o introducción remota, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.ruby.often_misused_file_upload
Abstract
Autorizar a los usuarios a que carguen archivos puede permitir a los atacantes introducir contenido peligroso o código malintencionado para que se ejecute en el servidor.
Explanation
Independientemente del lenguaje en el que esté escrito un programa, los usuarios malintencionados más devastadores normalmente incluyen la ejecución remota de código, con la cual un usuario malintencionado consigue ejecutar código malintencionado en el contexto del programa. Si se permite a los atacantes que carguen archivos a un directorio accesible desde la Web que hace que estos archivos se pasen a un intérprete de código (por ejemplo, JSP/ASPX/PHP), los atacantes pueden provocar que el código malintencionado contenido en los archivos se ejecute en el servidor.
Incluso en el caso de un programa que almacene los archivos cargados en un directorio que no sea accesible desde la Web, los atacantes pueden conseguir introducir contenido malintencionado en el entorno del servidor para preparar otros ataques. Si el programa es susceptible a las vulnerabilidades de manipulación de rutas, inserción de comandos o inclusión peligrosa de archivos, un atacante puede cargar un archivo con contenido malintencionado y provocar que el programa lo lea o ejecute aprovechando otra vulnerabilidad.

Una etiqueta <input> del tipo file indica que el programa acepta la carga de archivos.
Ejemplo:

<input type="file">
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 434
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.content.html.often_misused_file_upload
Abstract
Los idiomas de las plantillas no se deben mezclar para evitar las protecciones de secuencias de comandos en sitios cruzados.
Explanation
Cuando se combinan motores de plantillas, las protecciones que se implementaron anteriormente para una plantilla dejan de funcionar o de ser válidas. En el mejor de los casos, esto puede hacer que la funcionalidad no funcione según lo esperado, pero también puede permitir a los usuarios malintencionados evitar las protecciones en el motor y acabar en vulnerabilidades de scripts entre sitios.

Ejemplo 1: en el siguiente código, se configura un módulo AngularJS para utilizar "[[" y "]]" como delimitadores de expresión en lugar de los valores predeterminados.


myModule.config(function($interpolateProvider){
$interpolateProvider.startSymbol("[[");
$interpolateProvider.endSymbol("]]");
});


Esto puede provocar que el otro motor de plantilla que realiza la validación escape las expresiones, que pueden no ser compatibles con las expresiones AngularJS, lo que podría llevar a que los usuarios omitan la validación regular y ejecuten su propio código dentro del explorador.
References
[1] AngularJS $interpolateProvider documentation Google
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
desc.structural.javascript.often_misused_mixing_template_languages