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
Nunca deben usarse las funciones que no se pueden utilizar con seguridad.
Explanation
Determinadas funciones se comportan de forma peligrosa independientemente de cómo se utilicen. Las funciones de esta categoría se implementaron a menudo sin tener en cuenta las cuestiones relativas a la seguridad.

desc.semantic.cpp.dangerous_function.master
Abstract
Nunca deben usarse las funciones que no se pueden utilizar con seguridad.
Explanation
Determinadas funciones se comportan de forma peligrosa independientemente de cómo se utilicen. Las funciones de esta categoría se implementaron a menudo sin tener en cuenta las cuestiones relativas a la seguridad.

desc.semantic.php.dangerous_function.master
Abstract
Nunca deben usarse las funciones que no se pueden utilizar con seguridad.
Explanation
DBMS_UTILITY.EXEC_DDL_STATEMENT solo ejecutará instrucciones clasificadas como parte del lenguaje de definición de datos. El resto de instrucciones que no sean compatibles con SQL incrustado se omitirá sin notificación alguna. Este comportamiento dificulta la detección de errores cuando se utiliza el procedimiento.
References
[1] How to write SQL injection proof PL/SQL
desc.semantic.sql.dangerous_function_exec_ddl
Abstract
Las funciones que no pueden utilizarse de forma segura, o en las que hacerlo resulta muy complicado, no deberían utilizarse.
Explanation
Algunas funciones se comportan de forma peligrosa o inesperada. Las funciones de esta categoría se implementaron a menudo sin tener en cuenta las cuestiones relativas a la seguridad.

desc.structural.ruby.dangerous_function
Abstract
Nunca deben usarse las funciones que no se pueden utilizar con seguridad.
Explanation
Determinadas funciones se comportan de forma peligrosa independientemente de cómo se utilicen. Las funciones de esta categoría se implementaron a menudo sin tener en cuenta las cuestiones relativas a la seguridad.

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 4
[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 676
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-0-5
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[12] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.semantic.cpp.dangerous_function_strcpy
Abstract
Las funciones que no se pueden usar de forma segura nunca deben usarse.
Explanation
Ciertas funciones tienen un comportamiento peligroso, independientemente de cómo se utilicen. Las funciones de esta categoría a menudo se implementaron sin tener en cuenta la seguridad.

Ejemplo 1: dada la URL http://www.example.com/index.php?param=..., el siguiente fragmento de código de php dentro de index.php imprimirá el valor del parámetro de URL param (transferido en lugar de "...") en la pantalla si coincide con la expresión regular de POSIX '^[[:alnum:]]*$' que representa a "cero o más caracteres alfanuméricos":

<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>


Mientras que el Example 1 funciona como se esperaba con la entrada alfanumérica, debido a que se utiliza la función ereg() no segura para validar la entrada contaminada, es posible llevar a cabo un ataque de scripts de sitios (XSS) mediante la inyección de un byte null. Al pasar un valor para param que contiene una cadena alfanumérica válida seguida de un byte null y, a continuación, una etiqueta <script>(por ejemplo, "Hello123%00<script>alert("XSS")</script>"), ereg($pattern, $string) seguirá siendo true, dado que la función ereg() ignora todo lo que sigue a un carácter de byte null al leer la cadena de entrada (de izquierda a derecha). En este ejemplo, esto significa que la etiqueta <script> inyectada seguida del byte null se mostrará al usuario y se evaluará.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[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 676
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[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
[16] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
desc.semantic.php.dangerous_function_unsafe_regular_expression
Abstract
La función xp_cmdshell no se puede utilizar con seguridad, por lo que no debe usarse.
Explanation
Determinadas funciones se comportan de forma peligrosa independientemente de cómo se utilicen. La función xp_cmdshell inicia un shell de comandos de Windows para ejecutar la cadena de comandos proporcionada. El comando se ejecuta en el sistema predeterminado o en un contexto de proxy proporcionado. Sin embargo, no hay ninguna forma de limitar un usuario al conjunto especificado previamente de operaciones con privilegios y cualquier concesión de privilegio anima al usuario a ejecutar la cadena de comandos que desee.
References
[1] xp_cmdshell
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 242
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[19] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[20] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.semantic.sql.dangerous_function_xp_cmdshell
Abstract
El método tiene la anotación de peligroso. Todos los usos de este método se marcarán como problemas.
Explanation
La anotación FortifyDangerous ha sido aplicada a este método. Se utiliza para indicar que es peligroso y, por motivos de seguridad, todos los usos deben examinarse.
desc.structural.java.dangerous_method
Abstract
La variable es de un tipo que se ha anotado como peligroso.
Explanation
La anotación FortifyDangerous ha sido aplicada a este tipo. Se utiliza para indicar que es peligroso y, por motivos de seguridad, todos los usos deben examinarse.

desc.structural.java.dangerous_class_variable
Abstract
El uso inadecuado del sistema chroot() podría permitir a los usuarios malintencionados escapar de un aprisionamiento chroot.
Explanation
La llamada al sistema chroot() permite a un proceso cambiar su percepción del directorio raíz del sistema de procesamiento de archivos. Después de llamar correctamente a chroot(), un proceso no puede acceder a ningún archivo que se encuentre fuera del árbol de directorios definido por el nuevo directorio raíz. Un entorno de este tipo recibe el nombre de aprisionamiento chroot y se utiliza normalmente para impedir la posibilidad de que los procesos puedan subvertirse y usarse para obtener acceso a archivos no autorizados. Por ejemplo, muchos servidores FTP se ejecutan en aprisionamientos chroot para impedir que un usuario malintencionado que descubra una nueva vulnerabilidad en el servidor descargue el archivo de contraseñas u otros archivos confidenciales del sistema.

El uso inadecuado de chroot() puede permitir a los usuarios malintencionados escaparse del aprisionamiento chroot. La función chroot() no cambia el directorio de trabajo actual del proceso, por lo que las rutas relativas aún pueden hacer referencia a los recursos del sistema de archivos que se encuentran fuera del aprisionamiento chroot una vez que se haya llamado a chroot().

Ejemplo 1: tenga en cuenta el siguiente código de origen de un (hipotético) servidor FTP:


chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);


Este código se encarga de leer un nombre de archivo de la red, abriendo el archivo correspondiente en el equipo local y enviando el contenido a través de la red. Este código se puede utilizar para implementar el comando GET de FTP. El servidor FTP llama a chroot() en sus rutinas de inicialización en un intento de impedir el acceso a los archivos ubicados fuera de /var/ftproot. Sin embargo, como el servidor no cambia el directorio de trabajo actual llamando a chdir("/"), un usuario malintencionado podría solicitar el archivo "../../../../../etc/passwd" y obtener una copia del archivo de contraseña del sistema.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] A. Chuvakin Using Chroot Securely
desc.semantic.cpp.directory_restriction