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.
Struts 2 Bad Practices: Request Map Tampering
Abstract
Una acción de Struts 2.x implementa una clase que permite a un usuario malintencionado modificar la lógica de negocio de la aplicación vinculando datos arbitrarios a los objetos del servidor de la sesión, la aplicación o la solicitud.
Explanation
Apache Struts 2.x incluía las nuevas interfaces de Aware para que los desarrolladores pudiesen introducir fácilmente en su código de Actions mapas con información de tiempo de ejecución importante. Estas interfaces incluyen:
Por otro lado, Struts 2.x enlaza automáticamente los datos de la solicitud del usuario con las propiedad de la acción a través de descriptores de acceso definidos en la acción. Dado que las interfaces de Aware requieren que se implemente el setter público definido en la interfaz de Aware, este setter se enlazará también de forma automática con cualquier parámetro de solicitud que sea coincidente con el nombre de la interfaz de Aware que pueda permitir a los usuarios malintencionados remotos modificar los valores del tiempo de ejecución a través de un parámetro proporcionado a una aplicación que implemente una interfaz afectada, como demuestran las interfaces
La siguiente URL permitirá a un usuario malintencionado sobrescribir el atributo de "roles" en el mapa de la sesión, lo que potencialmente puede permitirle convertirse en administrador.
Mientras que estas interfaces sólo requieren la implementación de los descriptores de acceso del setter, si el correspondiente getter también está implementado, los cambios en estas colecciones de mapas se almacenarán en la sesión en lugar de afectar únicamente a la solicitud actual.
org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware y org.apache.struts2.interceptor.RequestAware. Con el fin de incorporar cualquiera de estos mapas de datos en el código de Actions, los desarrolladores deben implementar el marco que se especifica en la interfaz (por ejemplo: setSession para la interfaz SessionAware):
public class VulnerableAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
@Override
public void setSession(Map<String, Object> session) {
this.session = session;
}
Por otro lado, Struts 2.x enlaza automáticamente los datos de la solicitud del usuario con las propiedad de la acción a través de descriptores de acceso definidos en la acción. Dado que las interfaces de Aware requieren que se implemente el setter público definido en la interfaz de Aware, este setter se enlazará también de forma automática con cualquier parámetro de solicitud que sea coincidente con el nombre de la interfaz de Aware que pueda permitir a los usuarios malintencionados remotos modificar los valores del tiempo de ejecución a través de un parámetro proporcionado a una aplicación que implemente una interfaz afectada, como demuestran las interfaces
SessionAware, RequestAware, ApplicationAware.La siguiente URL permitirá a un usuario malintencionado sobrescribir el atributo de "roles" en el mapa de la sesión, lo que potencialmente puede permitirle convertirse en administrador.
http://server/VulnerableAction?session.roles=admin
Mientras que estas interfaces sólo requieren la implementación de los descriptores de acceso del setter, si el correspondiente getter también está implementado, los cambios en estas colecciones de mapas se almacenarán en la sesión en lugar de afectar únicamente a la solicitud actual.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 20
[2] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[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 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] 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
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.structural.java.struts2_bad_practices_request_map_tampering