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.
File Disclosure: Spring
Abstract
Construir una ruta de acceso direccionada en el servidor con entrada de usuarios podría permitir a un atacante descargar binarios de aplicaciones (incluyendo clases de aplicaciones o archivos jar) o ver archivos arbitrarios dentro de directorios protegidos.
Explanation
Un archivo queda al descubierto cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear de forma dinámica una ruta.
Ejemplo 1: el siguiente código obtiene datos que no son de confianza y los utiliza para crear una ruta que se utiliza en un reenvío del servidor.
Si un usuario malintencionado ha proporcionado una URL con un parámetro de solicitud que coincide con una ubicación de archivo confidencial, este podrá ver ese archivo. Por ejemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" le permitiría ver el archivo applicationContext.xml de la aplicación.
Una vez que el usuario malintencionado dispone de applicationContext.xml, podría localizar y descargar otros archivos de configuración a los que se hace referencia en este archivo, o incluso archivos class o jar. Esto permitiría a un usuario malintencionado obtener información confidencial acerca de una aplicación y usarla para otros tipos de ataques.
1. Los datos entran en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear de forma dinámica una ruta.
Ejemplo 1: el siguiente código obtiene datos que no son de confianza y los utiliza para crear una ruta que se utiliza en un reenvío del servidor.
...
String returnURL = request.getParameter("returnURL");
return new ModelAndView(returnURL);
...
Si un usuario malintencionado ha proporcionado una URL con un parámetro de solicitud que coincide con una ubicación de archivo confidencial, este podrá ver ese archivo. Por ejemplo, "http://www.yourcorp.com/webApp/logic?returnURL=WEB-INF/applicationContext.xml" le permitiría ver el archivo applicationContext.xml de la aplicación.
Una vez que el usuario malintencionado dispone de applicationContext.xml, podría localizar y descargar otros archivos de configuración a los que se hace referencia en este archivo, o incluso archivos class o jar. Esto permitiría a un usuario malintencionado obtener información confidencial acerca de una aplicación y usarla para otros tipos de ataques.
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.1
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 552
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[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 A01 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download 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.1
[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 2009 Risky Resource Management - CWE ID 073
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.dataflow.java.file_disclosure_spring