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
Esta función infringe el contrato que debe comparar su parámetro con null.
Explanation
El estándar de Java exige que las implementaciones de Object.equals(), Comparable.compareTo() y Comparator.compare() devuelvan un valor especificado si sus parámetros son null. De no cumplir el contrato se daría lugar a un comportamiento inesperado.

Ejemplo 1: La implementación siguiente del método equals() no compara su parámetro con null.


public boolean equals(Object object)
{
return (toString().equals(object.toString()));
}
References
[1] MET10-J. Follow the general contract when implementing the compareTo() method CERT
[2] MET08-J. Preserve the equality contract when overriding the equals() method CERT
desc.controlflow.java.missing_check_for_null_parameter
Abstract
Un método clone() debe llamar super.clone() para obtener el nuevo objeto.
Explanation
Todas las implementaciones de clone() deben obtener el nuevo objeto llamando super.clone(). Si una clase no puede seguir esta convención, un método clone() de subclase devolverá un objeto del tipo incorrecto.


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


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

public class FancyKibitzer extends Kibitzer
implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = super.clone();
...
}
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[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 580
desc.structural.java.object_model_violation_erroneous_clone_method
Abstract
Esta clase ignora solo uno de Equals() y GetHashCode().
Explanation
Se espera que los objetos .NET obedezcan a un número de invariables relacionadas con la igualdad. Una de estas invariables es que los objetos iguales deben tener códigos hash iguales. En otras palabras, si a.Equals(b) == true, entonces a.GetHashCode() == b.GetHashCode().

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

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


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

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

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


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

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

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

En otras palabras, una aplicación malintencionada sin los permisos correspondientes puede omitir la comprobación de permisos mediante la adopción del permiso de la aplicación para obtener acceso a recursos a los que, de lo contrario, no podría acceder. Esto provoca lo que se conoce como ataque de tipo "confused deputy".
References
[1] Designing for Security Android
[2] Context: Android Developers Android
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[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 Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 275
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[10] Standards Mapping - FIPS200 AC
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[14] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[15] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[16] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[20] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[23] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.java.often_misused_android_permission_check
Abstract
A continuación, el código confirma a los autores de la llamada que se ha concedido un determinado permiso, lo que permitirá a un usuario malintencionado omitir los controles de seguridad.
Explanation
Los permisos de .NET Framework funcionan avanzando por el árbol de pila (donde el árbol crece hacia abajo), para comprobar si los permisos establecidos son suficientes para acceder a un recurso. Cuando un desarrollador usa Assert() con un permiso concreto, es una forma de decir que el flujo de control actual tiene el permiso especificado. Esto provoca que .NET Framework detenga cualquier comprobación de permisos adicional, siempre y cuando se hayan satisfecho los permisos necesarios, por lo que el código que llama al código que realiza la llamada a Assert() podría no tener el permiso requerido. Usar Assert() es útil en ciertos casos, pero puede dar lugar a vulnerabilidades cuando permite que un usuario malintencionado tome el control de un recurso que no tendría derecho a controlar de otro modo.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 275
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[8] Standards Mapping - FIPS200 AC
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[13] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[14] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[17] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[21] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.semantic.dotnet.often_misused_asserting_permissions