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.

Mass Assignment: Request Parameters Bound into Persisted Objects

Abstract
Cuando se permite rellenar automáticamente entidades de base de datos persistentes mediante parámetros de solicitud, se permite a un atacante crear registros no intencionados en entidades de asociación o actualizar campos no intencionados en el objeto de la entidad.
Explanation
Los objetos modelo son una representación orientada a objetos de entidades de base de datos. Proporcionan los métodos adecuados para cargar, almacenar, actualizar y eliminar entidades de base de datos asociadas.
Hibernate, Microsoft .NET Entity Framework y LINQ son ejemplos de marcos de trabajo de asignación relacional de objetos (ORM) que le ayudan a crear objetos modelo respaldados por bases de datos.

Many web frameworks strive to make life easier for developers by Muchos marcos de trabajo web tratan de facilitarles la vida a los desarrolladores proporcionando un mecanismo de enlace para los parámetros de solicitudes en objetos enlazados con solicitudes basado en la asociación de nombres de parámetros de solicitud con nombres de atributos de objeto modelo (basado en métodos públicos de asociación de getter y setter).

Si una aplicación utiliza clases ORM como objetos enlazados con solicitudes, es probable que un parámetro de solicitud pueda modificar cualquier campo en los objetos modelo correspondientes y cualquier campo anidado de un atributo de objeto.

Ejemplo 1: el Order, Customer y Profile son clases persistentes de Microsoft .NET Entity.

public class Order {
public string ordered { get; set; }
public List<LineItem> LineItems { get; set; }
pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
public int CustomerId { get; set; }
...
public virtual Profile Profile { get; set; }
...
}
public class Profile {
public int profileId { get; set; }
public string username { get; set; }
public string password { get; set; }
...
}
OrderController es la clase controlador MVC de ASP.NET que trata la solicitud:


public class OrderController : Controller{
StoreEntities db = new StoreEntities();
...

public String updateOrder(Order order) {
...
db.Orders.Add(order);
db.SaveChanges();
}
}

Dado que las clases de entidades modelo se enlazan de forma automática a las solicitudes, un atacante podría valerse de esta vulnerabilidad para actualizar la contraseña de otro usuario agregando los siguientes parámetros a la solicitud: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 915
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[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 A08 Software and Data Integrity Failures
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.dotnet.mass_assignment_request_parameters_bound_into_persisted_objects
Abstract
Cuando se permite rellenar automáticamente entidades de base de datos persistentes mediante parámetros de solicitud, se permite a un usuario malintencionado crear registros no intencionados en entidades de asociación o actualizar campos no intencionados en el objeto de la entidad.
Explanation
Los objetos persistentes están enlazados a la base de datos subyacente y se actualizan automáticamente mediante la estructura de persistencia como, por ejemplo, Hibernate o JPA. Al permitir que estos objetos se enlacen dinámicamente a la solicitud por medio de Spring MVC, un usuario podría insertar valores inesperados en la base de datos proporcionando parámetros de solicitud adicionales.
Ejemplo 1: el Order, Customer y Profile son clases Hibernate persistentes.

public class Order {
String ordered;
List lineItems;
Customer cust;
...
}
public class Customer {
String customerId;
...
Profile p;
...
}
public class Profile {
String profileId;
String username;
String password;
...
}
OrderController es la clase de controlador que administra la solicitud:

@Controller
public class OrderController {
...
@RequestMapping("/updateOrder")
public String updateOrder(Order order) {
...
session.save(order);
}
}

Como las clases de comandos se enlazan automáticamente a la solicitud, un atacante puede aprovechar esta vulnerabilidad para actualizar la contraseña de otro usuario agregando los siguientes parámetros a la solicitud: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[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 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 915
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[18] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[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 - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.java.mass_assignment_request_parameters_bound_into_persisted_objects