Reino: Code Quality

Una mala calidad del código lleva a un comportamiento no predecible. Desde la perspectiva de un usuario, muchas veces también supone una usabilidad limitada. Pero para un atacante es una oportunidad para atacar al sistema de formas insospechadas.

93 elementos encontrados
Debilidades
Abstract
Se ha detectado un PendingIntent que tiene su valor de marca establecido en FLAG_MUTABLE. Los intents pendientes creados con el valor de marca FLAG_MUTABLE son susceptibles de tener campos Intent no especificados configurados en sentido descendente, que pueden modificar la capacidad del Intent y dejar el sistema expuesto a deficiencias.
Explanation
Permitir la modificación del Intent subyacente de un PendingIntent después de su creación puede dejar un sistema abierto a ataques. Esto depende principalmente de la capacidad general del Intent subyacente. En la mayoría de los casos, se recomienda evitar posibles problemas configurando la marca PendingIntent en FLAG_IMMUTABLE.

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


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

val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_mutable_pending_intent
Abstract
La memoria se asigna, pero nunca se libera.
Explanation
Las pérdidas de memoria presentan dos causas habituales, que a veces se superponen:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

Por lo general, la mayoría de las pérdidas de memoria provocan problemas de confiabilidad pero si un atacante puede desencadenar de forma intencionada una pérdida de memoria, este puede ser capaz de iniciar un ataque de denegación de servicio (bloqueando el programa) o aprovechar otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: la siguiente función de C pierde un bloque de memoria asignada si la llamada a read() no devuelve el número esperado de bytes:


char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cpp.memory_leak
Abstract
La memoria está asignada, pero nunca se libera.
Explanation
Las pérdidas de memoria tienen dos causas comunes que a menudo se solapan:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

La mayoría de pérdidas de memoria derivan en problemas generales de confiabilidad de software, pero si un atacante puede desencadenar intencionadamente una pérdida de memoria, también puede ser capaz de lanzar un ataque de denegación de servicio (bloqueando el programa) o aprovecharse de otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: El siguiente programa de Micro Focus COBOL genera fugas de un bloque de memoria asignada si se produce un error:


CALL "CBL_ALLOC_MEM"
USING mem-pointer
BY VALUE mem-size
BY VALUE flags
RETURNING status-code
END-CALL

IF status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
SET ADDRESS OF mem TO mem-pointer
END-IF

PERFORM write-data
IF ws-status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
DISPLAY "Success!"
END-IF

CALL "CBL_FREE_MEM"
USING BY VALUE mem-pointer
RETURNING status-code
END-CALL

GOBACK
.
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cobol.memory_leak
Abstract
Un objeto asigna memoria a una variable miembro y no consigue liberarla en su método dealloc().
Explanation
Las pérdidas de memoria presentan dos causas habituales, que a veces se superponen:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

Por lo general, la mayoría de las pérdidas de memoria provocan problemas de confiabilidad pero si un atacante puede desencadenar de forma intencionada una pérdida de memoria, este puede ser capaz de iniciar un ataque de denegación de servicio (bloqueando el programa) o aprovechar otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: El objeto de Objective-C asigna memoria al método init() pero no consigue liberarla en el método deallocate(), por lo que se produce una falta de memoria:


- (void)init
{
myVar = [NSString alloc] init];
...
}

- (void)dealloc
{
[otherVar release];
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.structural.objc.memory_leak
Abstract
El programa cambia el tamaño de un bloque de memoria asignada. Si el cambio de tamaño falla, el bloque original se perderá.
Explanation
Las pérdidas de memoria presentan dos causas habituales, que a veces se superponen:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

Por lo general, la mayoría de las pérdidas de memoria provocan problemas de confiabilidad pero si un atacante puede desencadenar de forma intencionada una pérdida de memoria, este puede ser capaz de iniciar un ataque de denegación de servicio (bloqueando el programa) o aprovechar otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: la siguiente función C pierde un bloque de memoria asignada si la llamada para realloc() no logra cambiar el tamaño de la asignación original.


char* getBlocks(int fd) {
int amt;
int request = BLOCK_SIZE;
char* buf = (char*) malloc(BLOCK_SIZE + 1);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
while ((amt % BLOCK_SIZE) != 0) {
if (amt < request) {
goto ERR;
}
request = request + BLOCK_SIZE;
buf = realloc(buf, request);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
}

return buf;

ERR:
if (buf) {
free(buf);
}
return NULL;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[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 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.memory_leak_reallocation
Abstract
El programa cambia el tamaño de un bloque de memoria asignada. Si no se puede cambiar el tamaño, se generarán fugas del bloque original.
Explanation
Las pérdidas de memoria tienen dos causas comunes que a menudo se solapan:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar la memoria.

La mayoría de pérdidas de memoria derivan en problemas generales de confiabilidad de software, pero si un atacante puede desencadenar intencionadamente una pérdida de memoria, también puede ser capaz de lanzar un ataque de denegación de servicio (bloqueando el programa) o aprovecharse de otro comportamiento inesperado del programa derivado de una situación de bajo nivel de memoria [1].

Ejemplo 1: El siguiente programa de Micro Focus COBOL genera fugas de un bloque de memoria asignada si la llamada a realloc() no puede cambiar el tamaño de la asignación original.


CALL "malloc" USING
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

ADD 1000 TO mem-size

CALL "realloc" USING
BY VALUE mem-pointer
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

IF mem-pointer <> null
CALL "free" USING
BY VALUE mem-pointer
END-CALL
END-IF
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[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 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cobol.memory_leak_reallocation
Abstract
El programa puede eliminar potencialmente la referencia de un puntero nulo, generando una NullException.
Explanation
Los punteros nulos suelen producirse debido a que se ha infringido alguna presuposición del programador.

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

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


string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
desc.controlflow.dotnet.null_dereference
Abstract
El programa podría desreferenciar un puntero nulo y, por lo tanto, ocasionar un error de segmentación.
Explanation
Las excepciones del puntero nulo normalmente se producen cuando una o varias de las hipótesis del programador se infringen. Hay al menos tres enfoques para este problema: comprobar después de desreferenciar, desreferenciar después de comprobar y desreferenciar después de almacenar. Se produce un error de desreferencia tras la comprobación cuando un programa desreferencia un puntero que puede ser null antes de comprobar si es null o no. Los errores de desreferencia tras la comprobación se producen cuando un programa realiza una comprobación explícita de null y procede a desreferenciar el puntero cuando se sabe que es null. Los errores de este tipo son normalmente el resultado de errores de escritura o descuidos del programador. Los errores de desreferencia tras el almacenamiento se producen cuando un programa establece de forma explícita un puntero en null y luego lo desreferencia. Con frecuencia, el error es el resultado de que un programador inicialice una variable en null cuando se declara.

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

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


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


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


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


*ptr = NULL;
...
ptr->field = val;
...
}
desc.controlflow.cpp.null_dereference
Abstract
El programa puede eliminar potencialmente la referencia de un puntero nulo, generando una NullPointerException.
Explanation
Los punteros nulos suelen producirse debido a que se ha infringido alguna presuposición del programador.

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

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


String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
desc.controlflow.java.null_dereference
Abstract
El uso de funciones en desuso u obsoletas podría indicar código sin atender.
Explanation
En general, a medida que evolucionan los lenguajes de programación, los métodos se quedan obsoletos de vez en cuando debido a:

- Los avances en el lenguaje
- El conocimiento mejorado del modo seguro y eficaz en que deben realizarse las
operaciones
- Los cambios en las convenciones que rigen determinadas operaciones

Las instrucciones que se quitan de un lenguaje normalmente se reemplazan por homólogos más recientes que realizan la misma tarea de alguna manera diferente y, con suerte, mejor.

En concreto, SAP ABAP ha evolucionado para incluir objetos ABAP, la extensión orientada a objetos de ABAP y para operar en un entorno Unicode compatible. Como resultado, se exige una sintaxis más estricta en las clases o los programas Unicode. Las construccionesobsoletas todavía están disponibles por razones de compatibilidad con versiones anteriores únicamente y solo se puede acceder a ellos fuera de las clases o en programas que no sean Unicode. Hay construcciones de reemplazo para todos los elementos de lenguaje obsoletos, que mejoran la eficiencia y legibilidad de los programas. Muchas especificaciones de memoria, longitud y tipo implícitas y ambiguas de la sintaxis obsoleta deben especificarse de un modo más preciso y explícito en la nueva sintaxis. Se recomienda que adopte la nueva sintaxis para que los programas se entiendan mejor, sean más robustos y más fáciles de mantener.


No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
desc.semantic.abap.obsolete
Abstract
El uso de funciones en desuso u obsoletas podría indicar código sin atender.
Explanation
A medida que evolucionan los lenguajes de programación, las funciones se vuelven a veces obsoletas debido a los siguientes motivos:

- Los avances en el lenguaje
- El conocimiento mejorado del modo seguro y eficaz en que deben realizarse las
operaciones
- Los cambios en las convenciones que rigen determinadas operaciones


Las funciones eliminadas de un lenguaje suelen reemplazarse por equivalentes más recientes que realizan la misma tarea de forma ligeramente diferente y es de esperar que también de forma más eficaz.
Ejemplo: el siguiente código crea un nuevo objeto SqlClientPermission, que controla el modo en que los usuarios pueden conectarse a una base de datos. En este ejemplo, el programa transfiere false como segundo parámetro al constructor, que controla si los usuarios tienen permiso para establecer conexión con contraseñas en blanco. Al transferir el valor "false" a este parámetro, se indica que no deben permitirse contraseñas en blanco.


...
SCP = new SqlClientPermission(pstate, false);
...


Sin embargo, como el objeto PermissionState transferido como primer parámetro reemplaza cualquier valor transferido al segundo parámetro, el constructor permite el uso de contraseñas en blanco para las conexiones de base de datos, lo que contradice el segundo argumento. Para rechazar las contraseñas en blanco, el programa debe transferir PermissionState.None al primer parámetro del constructor. Debido a la ambigüedad en su funcionalidad, la versión de dos parámetros del constructor SqlClientPermission se ha dejado de utilizar en favor de la versión de un único parámetro, que transmite el mismo grado de información sin el riesgo de interpretaciones erróneas.

No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
desc.semantic.dotnet.obsolete
Abstract
El uso de funciones en desuso u obsoletas podría indicar código sin atender.
Explanation
A medida que evolucionan los lenguajes de programación, las funciones se vuelven a veces obsoletas debido a los siguientes motivos:

- Los avances en el lenguaje.
- Conocimiento mejorado de cómo las operaciones deben realizarse de forma eficaz y segura.
- Los cambios en las convenciones que rigen determinadas operaciones.

Las funciones que se eliminan suelen reemplazarse por equivalentes más recientes que realizan la misma tarea de forma ligeramente diferente y es de esperar que también de forma más eficaz.
Ejemplo: el siguiente código usa la función en desuso getpw() para comprobar que una contraseña de texto sin formato coincide con una contraseña cifrada del usuario. Si la contraseña es válida, la función establece result en 1; de lo contrario, se establece en 0.


...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...


Aunque el código suele tener un comportamiento correcto, el uso de la función getpw() puede provocar problemas desde el punto de vista de la seguridad, ya que puede desbordar el búfer que pasa a su segundo parámetro. Debido a esta vulnerabilidad, getpw() se ha sustituido por getpwuid(), que realiza la misma búsqueda que getpw(), pero que devuelve un puntero a una estructura asignada estadísticamente para mitigar el riesgo.

No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
desc.semantic.cpp.obsolete
Abstract
El uso de funciones desusadas u obsoletas podría indicar código desatendido o el uso de una versión anticuada de ColdFusion.
Explanation
A medida que evolucionan los lenguajes de programación, los métodos se vuelven obsoletos de vez en cuando debido a:

- Los avances en el lenguaje
- El conocimiento mejorado del modo seguro y eficaz en que deben realizarse las
operaciones
- Los cambios en las convenciones que rigen determinadas operaciones

Los métodos que se quitan de un lenguaje normalmente se reemplazan por homólogos más recientes que realizan la misma tarea de alguna manera diferente y, con suerte, mejor.


No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
desc.semantic.cfml.obsolete
Abstract
El uso de funciones en desuso u obsoletas podría indicar código sin atender.
Explanation
A medida que evolucionan los lenguajes de programación, los métodos se vuelven obsoletos de vez en cuando debido a:

- Los avances en el lenguaje
- El conocimiento mejorado del modo seguro y eficaz en que deben realizarse las
operaciones
- Los cambios en las convenciones que rigen determinadas operaciones

Los métodos que se quitan de un lenguaje normalmente se reemplazan por homólogos más recientes que realizan la misma tarea de alguna manera diferente y, con suerte, mejor.
Ejemplo: el siguiente código crea un objeto de cadena a partir de una matriz de bytes y un valor que especifica los 8 bits principales de cada carácter Unicode de 16 bits.


...
String name = new String(nameBytes, highByte);
...


En este ejemplo, es posible que el constructor no pueda convertir correctamente bytes en caracteres según el juego de caracteres que se utilice para codificar la cadena representada por nameBytes. Debido a la evolución de los juegos de caracteres utilizados para codificar cadenas, este constructor quedó obsoleto y reemplazado por un constructor que acepta como uno de sus parámetros el nombre del charset que se utiliza para codificar los bytes para la conversión.

No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
References
[1] MET02-J. Do not use deprecated or obsolete classes or methods CERT
desc.semantic.java.obsolete
Abstract
El uso de funciones en desuso u obsoletas podría indicar código sin atender.
Explanation
A medida que evolucionan los lenguajes de programación, los métodos se vuelven obsoletos de vez en cuando debido a:

- Los avances en el lenguaje
- El conocimiento mejorado del modo seguro y eficaz en que deben realizarse las
operaciones
- Los cambios en las convenciones que rigen determinadas operaciones.

Los métodos que se quitan de un lenguaje normalmente se reemplazan por homólogos más recientes que realizan la misma tarea de alguna manera diferente y, con suerte, mejor.
Ejemplo: el siguiente código utiliza la stdlib Digest::HMAC, cuyo uso está explícitamente contraindicado en la documentación debido a su implicación accidental dentro de una versión.


require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...


En este ejemplo, la clase Digest::HMAC dejó de utilizarse de forma inmediata al estar implicada en una inclusión accidental dentro de una versión. Debido a la posibilidad de que no funcione según lo previsto a causa del código experimental o no probado adecuadamente, su uso está fuertemente contraindicado, especialmente si consideramos la relación que tienen los códigos HMAC con la funcionalidad criptográfica.

No todas las funciones están en desuso o se sustituyen porque supongan un riesgo de seguridad. Sin embargo, la presencia de una función obsoleta a menudo indica que el código que lo rodea se ha quedado sin atender y que puede estar en mal estado. La seguridad del software no ha sido una prioridad, o incluso una consideración, durante mucho tiempo. Si el programa utiliza las funciones en desuso u obsoletas, aumentará la probabilidad de que haya problemas de seguridad al acecho.
desc.structural.ruby.obsolete
Abstract
Se utiliza una función obsoleta.
Explanation
Debido a la naturaleza acelerada de los contratos inteligentes, las funciones y los operadores pueden quedar obsoletos con las versiones más nuevas del compilador y su uso puede generar código de baja calidad, efectos secundarios no deseados y/o errores de compilación.

Ejemplo 1: El siguiente código obtiene el hash del bloque actual usando block.blockhash(), que ha quedado obsoleto desde la versión 0.5.0 del compilador Solidity.


bytes32 blockhash = block.blockhash(0);
desc.structural.solidity.swc111
Abstract
La función está obsoleta y no garantiza que un puntero sea válido o que sea seguro utilizar la memoria referenciada.
Explanation
Hay varias razones para no utilizar las funciones de clase IsBadXXXPtr(). Estas funciones:
1) No son seguras para subprocesos.
2) Con frecuencia están implicadas en bloqueos causados por su sondeo de direcciones de memoria no válidas.
3) Se cree de forma errónea que realizan una administración de errores correcta durante las condiciones de excepción.

Ejemplo: el código siguiente utiliza IsBadWritePtr() en un intento de impedir malas escrituras de memoria.

if (IsBadWritePtr(ptr, length))
{
[handle error]
}


Con frecuencia los programadores utilizan estas funciones con la intención de que detecten casos de excepción, pero las funciones normalmente causan más problemas de los que solucionan.
References
[1] Raymond Chen IsBadXxxPtr should really be called CrashProgramRandomly
[2] IsBadWritePtr Function Microsoft
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 730
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[11] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[13] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[34] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[35] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.cpp.obsolete_inadequate_pointer_validation
Abstract
La clase contiene un campo y un método con el mismo nombre.
Explanation
Resulta confuso tener un campo miembro y un método con el mismo nombre. Facilita que el programador llame accidentalmente el método cuando intenta acceder al campo o viceversa.

Ejemplo 1:

public class Totaller {
private int total;
public int total() {
...
}
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[6] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.java.poor_style_confusing_naming.member_and_method
Abstract
El contrato utiliza una variable oculta que es ambigua y propensa a ser mal utilizada.
Explanation
Solidity permite a los desarrolladores declarar ambiguamente variables de estado. Esto significa que aunque dos variables diferentes en dos contextos diferentes puedan declararse con el mismo nombre, su uso puede generar confusión y usos inadecuados.

Esto puede suceder tanto a nivel de función como a nivel de herencia. Por ejemplo, si Contrato1 declara var1 y hereda de Contrato2, que también declara una variable denominada var1, entonces las variables son ambiguas y se pueden confundir fácilmente entre sí más adelante en la ejecución del contrato inteligente.

Ejemplo 1: El siguiente código utiliza herencia y declara una variable de estado con el mismo nombre en ambos contratos inteligentes. Puede resultar difícil determinar cuál es el hardcap real de la venta del token.


contract Tokensale {
uint hardcap = 10000 ether;

function Tokensale() { }

function fetchCap() public constant returns(uint) {
return hardcap;
}
}

contract Presale is Tokensale {
uint hardcap = 1000 ether;

function Presale() Tokensale() { }
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[6] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.solidity.swc119