diff --git a/2019/es/src/0x00-header.md b/2019/es/src/0x00-header.md new file mode 100644 index 000000000..07f6e712f --- /dev/null +++ b/2019/es/src/0x00-header.md @@ -0,0 +1,17 @@ +![OWASP LOGO](images/owasp-logo.png) + +## Seguridad API OWASP Top 10 2019 + +Los Diez Riesgos de Seguridad API Más Críticos + +29 de Mayo de 2019 + +![WASP Logo URL TBA](images/front-wasp.png) + +| | | | +| - | - | - | +| https://owasp.org | Este trabajo está licenciado bajo la [Licencia Internacional 4.0 de Creative Commons Attribution-ShareAlike][1] | ![Creative Commons License Logo](images/front-cc.png) | + +[1]: http://creativecommons.org/licenses/by-sa/4.0/ + + diff --git a/2019/es/src/0x00-notice.md b/2019/es/src/0x00-notice.md new file mode 100644 index 000000000..2aa47f41b --- /dev/null +++ b/2019/es/src/0x00-notice.md @@ -0,0 +1,14 @@ +Aviso +===== + +Esta es la versión de texto de Seguridad API OWASP Top 10 2019, usado como fuente para +la versión oficial distribuída como Portable Document Format (PDF). + +Las contribuciones al proyecto como comentarios, correcciones o traducciones +deben realizarse aquí. Por detalles sobre [Cómo contribuir][1], por favor referirse +al documento [CONTRIBUTING.md][1]. + +* Erez Yallon +* Inon Shkedy + +[1]: ../../CONTRIBUTING.md diff --git a/2019/es/src/0x00-toc.md b/2019/es/src/0x00-toc.md new file mode 100644 index 000000000..6fd93ced1 --- /dev/null +++ b/2019/es/src/0x00-toc.md @@ -0,0 +1,24 @@ +Índice de contenidos +==================== + +* [Índice de contenidos](0x00-toc.md) +* [Sobre OWASP](0x01-about-owasp.md) +* [Prefacio](0x02-foreword.md) +* [Introducción](0x03-introduction.md) +* [Notas de la versión](0x04-release-notes.md) +* [Riesgos de Seguridad API](0x10-api-security-risks.md) +* [Seguridad API OWASP Top 10 – 2019](0x11-t10.md) +* [API1:2019 Autorización a Nivel de Objeto Rota](0xa1-broken-object-level-authorization.md) +* [API2:2019 Autenticación de Usuario Rota](0xa2-broken-user-authentication.md) +* [API3:2019 Exposición de Datos Excesiva](0xa3-excessive-data-exposure.md) +* [API4:2019 Falta de Recursos & Límite de Velocidad](0xa4-lack-of-resources-and-rate-limiting.md) +* [API5:2019 Autorización a Nivel de Función Rota](0xa5-broken-function-level-authorization.md) +* [API6:2019 Asignación Masiva](0xa6-mass-assignment.md) +* [API7:2019 Configuración de Seguridad Incorrecta](0xa7-security-misconfiguration.md) +* [API8:2019 Inyección](0xa8-injection.md) +* [API9:2019 Administración de Activos Incorrecta](0xa9-improper-assets-management.md) +* [API10:2019 Registros y Monitoreo Insuficientes](0xaa-insufficient-logging-monitoring.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) +* [Agradecimientos](0xd1-acknowledgments.md) diff --git a/2019/es/src/0x01-about-owasp.md b/2019/es/src/0x01-about-owasp.md new file mode 100644 index 000000000..8594d6b2b --- /dev/null +++ b/2019/es/src/0x01-about-owasp.md @@ -0,0 +1,46 @@ +Sobre OWASP +=========== + +El Proyecto Abierto de Seguridad en Aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta dedicada a permitir a que las organizaciones desarrollen, adquieran y mantengan aplicaciones y APIs en las que se puedan confiar. + +En OWASP, encontrará de forma abierta y gratuita: + +* Herramientas y estándares de seguridad en aplicaciones. +* Libros completos de revisiones de seguridad en aplicaciones, desarrollo de código fuente seguro y revisiones de seguridad en código fuente +* Presentaciones y [videos][1]. +* [Hojas de trucos][2] en varios temas comunes. +* Controles de seguridad estándar y bibliotecas. +* [Capítulos locales en todo el mundo][3]. +* Investigaciones de vanguardia. +* Numerosas [conferencias alrededor del mundo][4]. +* [Listas de correo][5]. + +Conozca más en: [https://www.owasp.org][6]. + +Todas las herramientas de OWASP, documentos, videos, presentaciones y capítulos son gratuitos y abiertos a cualquier interesado en mejorar la seguridad en aplicaciones. + +Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras en todas estas áreas. + +OWASP es un nuevo tipo de organización. Nuestra libertad de presiones comerciales nos permite proveer información sobre seguridad en aplicaciones sin sesgos, práctica y rentable. + +OWASP no está afiliada con ninguna compañía de tecnología, aunque apoyamos el uso instruido de tecnologías de seguridad comercial. OWASP produce muchos tipos de materiales en una manera abierta y colaborativa. + +La Fundación OWASP es una entidad sin fines de lucro para asegurar el éxito a largo plazo del proyecto. Casi todos los asociados con OWASP son voluntarios, incluyendo la junta directiva de OWASP, comités globales, líderes de capítulos, los líderes y miembros de proyectos. Apoyamos la investigación innovadora sobre seguridad a través de becas e infraestructura. + +¡Únase a nosotros! + +## Copyright y Licencia + +![license](images/license.png) + +Copyright © 2003-2017 The OWASP Foundation. + +Este trabajo está licenciado bajo la [Licencia Internacional 4.0 de Creative Commons Attribution-ShareAlike][7]. Para cualquier caso de reuso o de distribución, debe dejar claro los términos de la licencia de esta obra. + +[1]: https://www.youtube.com/user/OWASPGLOBAL +[2]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[3]: https://www.owasp.org/index.php/OWASP_Chapter +[4]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[5]: https://lists.owasp.org/mailman/listinfo +[6]: https://www.owasp.org +[7]: http://creativecommons.org/licenses/by-sa/4.0/ diff --git a/2019/es/src/0x02-foreword.md b/2019/es/src/0x02-foreword.md new file mode 100644 index 000000000..29bd0acb6 --- /dev/null +++ b/2019/es/src/0x02-foreword.md @@ -0,0 +1,44 @@ +Prefacio +======== + +Un elemento fundamental de la innovación en el mundo actual basado en aplicaciones es la +Interfaz de programación de aplicaciones (API por sus siglas en inglés). Desde bancos, +minoristas y transporte hasta IoT, vehículos autónomos y ciudades inteligentes, las API +son una parte fundamental de aplicaciones móviles, SaaS y web modernas y se pueden +encontrar en las orientadas al cliente, internas y orientadas a socios. + +Por naturaleza, las API exponen la lógica de la aplicación y datos confidenciales como +Información Personalmente Identificable (PII por sus siglas en inglés) y debido a esto, +las API cada vez más se convierten en un objetivo para los atacantes. +Sin API seguras, la innovación rápida sería imposible. + +Aunque un Top 10 más amplio de los riesgos de seguridad de una aplicación web todavía +es relevante, debido a su naturaleza particular, se requiere una lista de riesgos de seguridad +específicos de la API. La seguridad de API se centra en estrategias y soluciones para +comprender y mitigar las vulnerabilidades únicas y riesgos de seguridad asociados con las API. + +Si está familiarizado con el [Proyecto Top 10 de OWASP][1], notará las +similitudes entre ambos documentos: están destinados a la legibilidad y +adopción. Si eres nuevo en la serie OWASP Top 10, quizás sea mejor que leas +las secciones [Riesgos de seguridad API][2] y [Metodología y datos][3] +antes de saltar a la lista del Top 10. + +Puede contribuir al OWASP API Security Top 10 con sus preguntas, comentarios, +e ideas en nuestro repositorio de proyectos GitHub: + +* https://github.com/OWASP/API-Security/issues +* https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.md + +Puede encontrar el Top 10 de seguridad de API OWASP aquí: + +* https://www.owasp.org/index.php/OWASP_API_Security_Project +* https://github.com/OWASP/API-Security + +Queremos agradecer a todos los colaboradores que hicieron posible este proyecto con su +esfuerzo y contribuciones. Todos están listados en la [Sección de Agradecimientos][4]. +¡Gracias! + +[1]: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project +[2]: ./0x10-api-security-risks.md +[3]: ./0xd0-about-data.md +[4]: ./0xd1-acknowledgments.md diff --git a/2019/es/src/0x03-introduction.md b/2019/es/src/0x03-introduction.md new file mode 100644 index 000000000..347e0b74a --- /dev/null +++ b/2019/es/src/0x03-introduction.md @@ -0,0 +1,30 @@ +Introducción +============ + +## ¡Bienvenido a OWASP API Security Top 10 - 2019! + +Bienvenido a la primera edición de OWASP API Security Top 10. Si estás +familiarizado con la serie OWASP Top 10, notarás algunas similitudes: +La intención es la legibilidad y la adopción. De lo contrario, considera visitar +[La página wiki de OWASP API Security Project][1], antes de profundizar en +los riesgos más críticos de seguridad de APIs. + +Las APIs juegan un papel muy importante en la arquitectura de las aplicaciones +modernas. Debido a que la creación de conciencia en el aspecto de seguridad y la +innovación avanzan a diferentes ritmos, es importante enfocarse en las +debilidades de seguridad que comúnmente se encuentran en las APIs. + +El objetivo principal de OWASP API Security Top 10 es educar a los involucrados +en el desarrollo y mantenimiento de APIs, por ejemplo, desarrolladores, +diseñadores, arquitectos, gerentes u organizaciones. + +En la sección [Metodología y datos][2], puedes leer más acerca de cómo esta +primera edición se creó. En futuras versiones, queremos involucrar a la +industria de seguridad, por medio de una convocatoria pública para recolectar +datos. Por ahora, alentamos a todos a contribuir con preguntas, comentarios e +ideas en nuestro [repositorio de GitHub][3] o mediante la [Lista de correo][4]. + +[1]: https://www.owasp.org/index.php/OWASP_API_Security_Project +[2]: ./0xd0-about-data.md +[3]: https://github.com/OWASP/API-Security +[4]: https://groups.google.com/a/owasp.org/forum/#!forum/api-security-project diff --git a/2019/es/src/0x04-release-notes.md b/2019/es/src/0x04-release-notes.md new file mode 100644 index 000000000..40abab3d2 --- /dev/null +++ b/2019/es/src/0x04-release-notes.md @@ -0,0 +1,25 @@ +Notas de la versión +=================== + +Esta es la primera edición de OWASP API Security Top 10, que planeamos actualizar +periódicamente, cada tres o cuatro años. + +A diferencia de esta versión, en versiones futuras, queremos hacer una +llamada pública para obtener datos, involucrando a la industria de la seguridad +en este esfuerzo. En la sección [Metodología y datos][1], encontrará más detalles +sobre cómo se creó esta versión. Para más detalles sobre los riesgos de seguridad, +consulte la sección [Riesgos de seguridad de la API][2]. + +Es importante darse cuenta de que en los últimos años, la arquitectura de +las aplicaciones han cambiado significativamente. Actualmente, las API juegan +un papel muy importante en esta nueva arquitectura de microservicios, +aplicaciones de página única (SPA), aplicaciones móviles, IoT, etc. + +El OWASP API Security Top 10 fue un esfuerzo necesario para crear conciencia sobre +problemas de seguridad API modernos. Solo fue posible debido a un gran esfuerzo de +varios voluntarios, todos ellos enumerados en la sección [Agradecimientos][3]. +¡Gracias! + +[1]: ./0xd0-about-data.md +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/2019/es/src/0x10-api-security-risks.md b/2019/es/src/0x10-api-security-risks.md new file mode 100644 index 000000000..6428592dc --- /dev/null +++ b/2019/es/src/0x10-api-security-risks.md @@ -0,0 +1,40 @@ +Riesgos de seguridad en APIs +================== + +La [Metodología de calificación de riesgo de OWASP][1] se utilizó para hacer el análisis de riesgo. + +La siguiente tabla resume la terminología asociada con la puntuación de riesgo. + +| Agente/Vector de Ataque | Explotabilidad | Prevalencia de Debilidad | Debilidad de Detectabilidad | Impacto Técnico | Impactos de Negocio | +| :-: | :-: | :-: | :-: | :-: | :-: | +| Específico de API | Fácil: **3** | Extendido **3** | Fácil **3** | Grave **3** | Específico de negocio | +| Específico de API | Promedio: **2** | Común **2** | Promedio **2** | Moderado **2** | Específico de negocio | +| Específico de API | Difícil: **1** | Difícil **1** | Difícil **1** | Menor **1** | Específico de negocio | + +**Nota**: Esta forma de hacerlo no toma en cuenta la probabilidad del agente de amenaza. Tampoco toma en cuenta ninguno de los diversos detalles técnicos asociados +con una aplicación en particular. Cualquiera de estos factores podría afectar significativamente la probabilidad general de que un atacante encuentre y explote a una vulnerabilidad en particular. Esta calificación no toma en cuenta el impacto real en su negocio. Su organización tendrá que decidir cuánto riesgo de aplicaciones y APIs está dispuesta a aceptar dependiendo de su cultura, industria y entorno regulatorio. El propósito de OWASP API Security Top 10 no es hacer este análisis de riesgo por usted. + +## Referencias + +### OWASP + +* [Metodología de calificación de riesgo de OWASP][1] +* [Artículo sobre amenazas / Modelación de riesgos][2] + +### Externos + +* [ISO 31000: Estándar de gestión de riesgos][3] +* [ISO 27001: SGSI][4] +* [NIST Cyber ​​Framework (EE. UU.)][5] +* [Mitigaciones estratégicas de ASD (AU)][6] +* [NIST CVSS 3.0][7] +* [Herramienta de modelado de amenazas de Microsoft][8] + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: https://www.owasp.org/index.php/Threat_Risk_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/2019/es/src/0x11-t10.md b/2019/es/src/0x11-t10.md new file mode 100644 index 000000000..10a7a8e37 --- /dev/null +++ b/2019/es/src/0x11-t10.md @@ -0,0 +1,15 @@ +OWASP Top 10 Riesgos de Seguridad en APIs - 2019 +====================================== + +| Riesgo | Descripción | +| ---- | ----------- | +| API1: 2019 - Autorización a Nivel de Objeto Rota | Las APIs tienden a exponer métodos que manejan identificadores de objetos, creando así un problema con una superficie de ataque muy amplia en el control de acceso de nivel. Las comprobaciones de autorización a nivel de objeto deben considerarse en todas las funciones que acceden a una fuente de datos utilizando la entrada del usuario. | +| API2: 2019 - Autenticación de Usuario Rota | Los mecanismos de autenticación a menudo se implementan incorrectamente, lo que permite a los atacantes comprometer los tokens de autenticación o explotar fallas de implementación para asumir las identidades de otros usuarios de manera temporal o permanente. Comprometer la capacidad del sistema para identificar al cliente / usuario también compromete la seguridad de la API en general. | +| API3: 2019 - Exposición Excesiva de Datos | Al esperar implementaciones genéricas, los desarrolladores tienden a exponer todas las propiedades de los objetos sin considerar su sensibilidad individual, confiando en que los clientes realicen un filtro de datos antes de mostrarlo al usuario. | +| API4: 2019 - Falta de recursos y Límite de Velocidad | Muy a menudo, las APIs no imponen ninguna restricción sobre el tamaño o la cantidad de recursos que puede solicitar el cliente / usuario. Esto no solo afecta el rendimiento del servidor de la API, lo que puede llevar a la denegación de servicio (DoS), sino que también deja la puerta abierta a fallas de autenticación como ataques de fuerza bruta. | +| API5: 2019 - Autorización rota a nivel de función | Políticas complejas de control de acceso con diferentes jerarquías, grupos y roles, y una separación poco clara entre las funciones administrativas y regulares, tienden a llevar a fallas de autorización. Al explotar estos problemas, los atacantes obtienen acceso a los recursos y / o funciones de otros usuarios o a funciones administrativas. | +| API6: 2019 - Asignación Masiva | La vinculación de datos proporcionados por el cliente (por ejemplo, JSON) a modelos de datos, sin un filtrado de propiedades adecuado basado en una lista blanca, generalmente conduce a la asignación masiva. Adivinar propiedades de objetos, explorar otros métodos expuestos de la API, leer la documentación o proporcionar propiedades de objetos adicionales en el cuerpo de las solicitudes, permite a los atacantes modificar las propiedades de objetos que no deberían ser alterados. | +| API7: 2019 - Configuración Incorrecta de Seguridad | La configuración incorrecta de seguridad suele ser el resultado de usar configuraciones predeterminadas no seguras, configuraciones incompletas o ad-hoc, almacenamiento abierto en la nube, encabezados HTTP mal configurados, métodos HTTP innecesarios, uso compartido de recursos de origen cruzado permisivo (CORS) y mensajes de error detallados que contienen información sensible. | +| API8: 2019 - Inyección | Los defectos de inyección, como SQL, NoSQL, Inyección de comandos, etc., ocurren cuando se envían datos no confiables a un intérprete como parte de un comando o consulta. Los datos maliciosos del atacante pueden engañar al intérprete para que ejecute comandos no deseados o que acceda a los datos sin autorización adecuada. | +| API9: 2019 - Control de Acceso Inadecuado | Las APIs tienden a exponer más métodos que las aplicaciones web tradicionales, lo que hace que la documentación adecuada y actualizada sea muy importante. Los hosts adecuados y el inventario de versiones de las APIs implementadas también juegan un rol importante para mitigar problemas como utilizar versiones de APIs que ya no reciben mantenimiento y exponer métodos que solo deben de ser usados de manera interna y en el ambiente de desarrollo. | +| API10: 2019 - Registro y Monitoreo Insuficiente | El registro y monitoreo insuficiente, junto con la falta o ineficiencia de una integración a una estrategia de respuesta a incidentes, permite a los atacantes atacar aún más los sistemas, mantener persistencia, pasar a otros sistemas para manipular, extraer o destruir datos. La mayoría de los estudios demuestran que el tiempo para detectar una filtración de datos es superior a 200 días. Generalmente es detectada por externos en lugar de que sea por medio de procesos internos o monitoreo. diff --git a/2019/es/src/0xa1-broken-object-level-authorization.md b/2019/es/src/0xa1-broken-object-level-authorization.md new file mode 100644 index 000000000..0ec5ff09c --- /dev/null +++ b/2019/es/src/0xa1-broken-object-level-authorization.md @@ -0,0 +1,68 @@ +API1:2019 Autorización a Nivel de Objeto Rota +============================================= + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **3** | Frecuencia **3** : Detectabilidad **2** | Técnico **3** : Específico del Negocio | +| Atacantes pueden explotar recursos de una API que son vulnerables a una autorización a nivel de objeto rota, al manipular el ID de un objeto que es enviado en una petición. Esto puede derivar en acceso no autorizado a datos sensibles. Este problema es extremadamente común en aplicaciones basadas en API ya que el componente del servidor usualmente no realiza un seguimiento completo del estado del cliente y, en cambio, hace más uso de parámetros como el ID de objeto, que es enviado desde el cliente, para decidir a qué objeto acceder. | Éste ha sido el ataque más común y de mayor impacto en APIs. Los mecanismos de autorización y control de acceso en aplicaciones modernas son complejos y extendidos. Incluso si la aplicación implementa una correcta infraestructura para controles de autorizacion, los desarrolladores podrían olvidarse de usar esos controles antes de permitir el acceso a un objeto sensible. La detección del control de acceso usualmente no es amigable con los tests automáticos o estáticos. | El acceso no autorizado puede resultar en revelación de información a partes no autorizadas, pérdida de datos o manipulación de los mismos. El acceso no autorizado a objetos también puede derivar en la apropiación completa de cuentas. | + + +## ¿Es vulnerable la API? + +La autorización a nivel de objeto es un mecanismo de control de acceso que usualmente +es implementado a nivel de código para validar que un usuario puede acceder sólo a los objetos +a los que debería acceder. + +Todo recurso de API que recibe un ID de objeto, y realiza cualquier tipo de +acción en el objeto, debe implementar controles de autorización a nivel de objeto. +Los controles deben validar que el usuario que ha iniciado sesión tiene acceso a realizar +la acción requerida en el objeto indicado. + +Las fallas en estos mecanismos típicamente resultan en revelación de información no autorizada, +modificación o destrucción de todos los datos. + + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +Una plataforma de e-commerce para tiendas online (shops) provee una página con una +lista de gráficos de ganancia de sus tiendas alojadas. Inspeccionando las peticiones del navegador, +un atacante puede identificar los recursos de API que son usados como fuente de datos para esos gráficos +y sus patrones `/shops/{shopName}/revenue_data.json`. Usando otro recurso API, +el atacante puede obtener la lista de nombres de todas las tiendas alojadas. Con un script +simple para manipular los nombres en la lista, reemplazando `{shopName}` en la URL, +el atacante puede ganar acceso a la información de ventas de miles de tiendas e-commerce. + + +### Escenario #2 + +Monitoreando el tráfico de red de un dispositivo wearable, la siguiente petición +HTTP `PATCH` gana la atención de un atacante debido a la presencia de un encabezado +HTTP personalizado `X-User-Id: 54796`. Reemplazando el valor de `X-User-Id` con `54795`, +el atacante recibe una respuesta HTTP exitosa y es posible modificar datos de +cuentas de otros usuarios. + + +## Cómo prevenir + +* Implementar mecanismos de autorización apropiados que se basen en las políticas + del usuario y su jerarquía. +* Utilizar un mecanismo de autorización para controlar si el usuario que ha iniciado sesión + tiene acceso para realizar la acción solicitada en el registro, en toda función que usa un + dato ingresado por el cliente para acceder a un registro de la base de datos. +* Es preferible usar valores aleatorios e impredecibles como GUIDs para los IDs de los registros. +* Escriba tests para evaluar los mecanismos de autorización. No despliegue cambios vulnerables que rompan los tests. + + +## Referencias + +### Externas + +* [CWE-284: Improper Access Control][1] +* [CWE-285: Improper Authorization][2] +* [CWE-639: Authorization Bypass Through User-Controlled Key][3] + +[1]: https://cwe.mitre.org/data/definitions/284.html +[2]: https://cwe.mitre.org/data/definitions/285.html +[3]: https://cwe.mitre.org/data/definitions/639.html diff --git a/2019/es/src/0xa2-broken-user-authentication.md b/2019/es/src/0xa2-broken-user-authentication.md new file mode 100644 index 000000000..e750b0acc --- /dev/null +++ b/2019/es/src/0xa2-broken-user-authentication.md @@ -0,0 +1,76 @@ +API2:2019 Autenticación de Usuario Rota +======================================= + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **3** | Frecuencia **2** : Detectabilidad **2** | Técnico **3** : Específico del Negocio | +| La autenticación en APIs es un mecanismo complejo y confuso. Ingenieros de software y seguridad pueden tener ideas equivocadas sobre cuáles son los límites de autenticación y cómo implementarla correctamente. Agregado a esto, el mecanismo de autenticación es un objetivo fácil para los atacantes, ya que está expuesto a todo el mundo. Estos dos puntos hacen al componente de autenticación potencialmente vulnerable a muchos exploits. | Existen 2 subproblemas: 1. Falta de mecanismos de protección: Los recursos de APIs que son responsables de la autenticación deben ser tratados de forma diferente a los recursos regulares e implementar capas extra de protección 2. Implementación incorrecta del mecanismo: El mecanismo es usado / implementado sin considerar los vectores de ataque, o es el caso de uso equivocado (p.e., un mecanismo de autenticación diseñado para clientes IoT puede no ser la elección correcta para aplicaciones web). | Atacantes pueden obtener control a cuentas de otros usuarios en el sistema, leer sus datos personales y realizar acciones sensibles en su nombre, como transacciones monetarias y enviar mensajes personales. | + +## ¿Es vulnerable la API? + +Los recursos y flujos de autenticación son activos que deben ser protegidos. "Olvidé mi contraseña / recuperar contraseña" debe ser tratado de la misma forma que los mecanismos de autenticación. + +Una API es vulnerable si: +* Permite el [relleno de credenciales][1] donde el atacante tiene una lista de usuarios y contraseñas válidos. +* Permite a los atacantes realizar ataques de fuerza bruta sobre la misma cuenta de usuario, sin presentar mecanismos de bloqueo de captcha/cuenta. +* Permite contraseñas débiles. +* Envía detalles de autenticación sensibles, como tokens de authenticación y contraseñas en la URL. +* No valida la autenticidad de los tokens. +* Acepta tokens JWT no/débilmente firmados (`"alg":"none"`)/no valida su fecha de expiración. +* Usa contraseñas en texto plano, encriptadas o codificadas con algoritmos de hash débiles. +* Usa claves de encriptación débiles. + +## Escenarios de Ataque de Ejemplo + +## Escenario #1 + +[Relleno de credenciales][1] (usando [listas de usuarios/contraseñas conocidas][2]), es un ataque común. +Si una aplicación no implementa protecciones de ataque automático o de relleno de credenciales, +la aplicación puede ser usada como un oráculo de contraseñas (probador) para determinar si las credenciales son válidas. + +## Escenario #2 + +Un atacante comienza el flujo de recuperación de contraseña realizando una petición POST a `/api/system/verification-codes` +e incluyendo el nombre de usuario en el cuerpo de la petición. +A continuación un token SMS con 6 dígitos es enviado al teléfono de la víctima. +Como la API no implementa una política de límite de peticiones, el atacante puede probar todas las combinaciones posibles usando +un script multi-hilo contra el recurso `/api/system/verification-codes/{smsToken}` para descubrir el token correcto en unos minutos. + +## Cómo prevenir + +* Asegurarse que conoce todos los flujos de autenticación posibles a la API (móviles/ + web/links profundos que implementan autenticación en 1 click/etc.) +* Pregúntele a sus ingenieros qué flujos ha olvidado. +* Lea acerca de sus mecanismos de autenticación. Asegúrese que entiende qué y cómo son usados. + OAuth no es autenticación, tampoco lo son las claves de API. +* No invente la rueda en autenticación, generación de tokens, almacenamiento de contraseñas. Use los estándars. +* Los recursos de recuperación de credenciales/olvido de contraseñas deben ser tratados como recursos de + inicio de sesión en términos de protecciones de fuerza bruta, límite de peticiones y de bloqueo. +* Use la [Guía OWASP de Autenticación][3]. +* Cuando sea posible, implemente autenticación multi factor. +* Implemente mecanismos anti fuerza bruta para mitigar el relleno de credenciales, ataques de diccionario y + ataques de fuerza bruta en sus recursos de autenticación. + Este mecanismo debe ser más estricto que los mecanismos de límite de peticiones regulares de su API. +* Implemente mecanismos de [bloqueo de cuenta][4] / captcha para prevenir fuerza bruta contra usuarios específicos. + Implemente controles de contraseñas débiles. +* Las claves de API no deberían ser usadas para autenticar usuarios, sino para [aplicaciones cliente/autenticación de proyecto][5]. + +## Referencias + +### OWASP + +* [Guía OWASP de Administración de Claves][6] +* [Guía OWASP de Autenticación][3] +* [Relleno de Credenciales][1] + +### Externas + +* [CWE-798: Use of Hard-coded Credentials][7] + +[1]: https://www.owasp.org/index.php/Credential_stuffing +[2]: https://github.com/danielmiessler/SecLists +[3]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html +[4]: https://www.owasp.org/index.php/Testing_for_Weak_lock_out_mechanism_(OTG-AUTHN-003) +[5]: https://cloud.google.com/endpoints/docs/openapi/when-why-api-key +[6]: https://www.owasp.org/index.php/Key_Management_Cheat_Sheet +[7]: https://cwe.mitre.org/data/definitions/798.html diff --git a/2019/es/src/0xa3-excessive-data-exposure.md b/2019/es/src/0xa3-excessive-data-exposure.md new file mode 100644 index 000000000..8f758d7e8 --- /dev/null +++ b/2019/es/src/0xa3-excessive-data-exposure.md @@ -0,0 +1,56 @@ +API3:2019 Exposición de Datos Excesiva +====================================== + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **3** | Frecuencia **2** : Detectabilidad **2** | Técnico **2** : Específico del Negocio | +| La explotación de la Exposición de Datos Excesiva es simple, y usualmente es realizada inspeccionando el tráfico para analizar las respuestas de la API, buscando exposiciones de datos sensibles que no deberían ser devueltos al usuario. | Las APIs delegan en los clientes la realización de filtrado de datos. Como las APIs son usadas como fuentes de datos, a veces los desarrolladores intentan implementarlas de una manera genérica sin pensar sobre la sensibilidad de los datos expuestos. Las herramientas automáticas usualmente no pueden detectar este tipo de vulnerabilidad, ya que es difícil diferenciar entre datos legítimos devueltos por la API y datos sensibles que no deberían ser devueltos, sin un profundo conocimiento de la aplicación. | La Exposición de Datos Excesiva comúnmente deriva en la exposición de datos sensibles. | + +## ¿Es vulnerable la API? + +La API devuelve datos sensibles al cliente por ser diseñada de esta manera. +Estos datos son usualmente filtrados del lado del cliente antes de ser presentados al usuario. +Un atacante puede inspeccionar el tráfico fácilmente y ver los datos sensibles. + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +El equipo móvil usa el recurso `/api/articles/{articleId}/comments/{commentId}` +en la vista de artículos para mostrar metadatos de comentarios. +Inspeccionando el tráfico de la aplicación móvil, un atacante descubre que otros datos sensibles +relacionados al autor del comentario también son devueltos. La implementación del recurso utiliza un método +`toJSON()` en el modelo `User`, que contiene PII, al serializar el objeto. + +### Escenario #2 + +Un sistema de vigilancia basado en IoT permite a los administradores crear usuarios con diferentes permisos. +Un administrador creó una cuenta de usuario para un nuevo guardia de seguridad que debería tener acceso +solo a edificios específicos del lugar. Una vez que el guardia de seguridad utiliza su aplicación móvil, +una llamada a API es disparada a: `/api/sites/111/cameras` para recibir información sobre las cámaras disponibles +y mostrarlas en el panel de control. La respuesta contiene una lista con detalles sobre las cámaras en el +siguiente formato: `{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}`. +Mientras la GUI del cliente solo muestra las cámaras a las que el guardia de seguridad debería tener acceso, +la respuesta de la API contiene una lista completa de todas las cámaras en el lugar. + +## Cómo prevenir + +* Nunca delegue en el cliente el filtrado de datos sensibles. +* Revise las respuestas de la API para asegurarse que contienen solo datos legítimos. +* Los ingenieros de backend deberían preguntarse siempre: "Quién es el consumidor de esta información" antes de exponer un nuevo recurso de API +* Evitar el uso de métodos genéricos como `to_json()` y `to_string()`. + En cambio, seleccione una a una las propiedades específicas que realmente quiere devolver. +* Clasifique la información sensible y personalmente identificable + (PII por las siglas en inglés de Personally Identifable Information) + que su aplicación almacena y utiliza, revisando todas las llamadas API que devuelvan dicha información + para ver si esas respuestas pueden convertirse en un problema de seguridad. +* Implemente un mecanismo de validación de respuesta basado en esquemas como una capa de seguridad adicional. Ya que parte de este mecanismo define y asegura los datos devueltos por todos los métodos API, incluyendo los errores. + + +## Referencias + +### Externas + +* [CWE-213: Intentional Information Exposure][1] + +[1]: https://cwe.mitre.org/data/definitions/213.html diff --git a/2019/es/src/0xa4-lack-of-resources-and-rate-limiting.md b/2019/es/src/0xa4-lack-of-resources-and-rate-limiting.md new file mode 100644 index 000000000..c04459f7e --- /dev/null +++ b/2019/es/src/0xa4-lack-of-resources-and-rate-limiting.md @@ -0,0 +1,85 @@ +API4:2019 Falta de Recursos & Límite de Velocidad +================================================= + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **2** | Frecuencia **3** : Detectabilidad **3** | Técnico **2** : Específico del Negocio | +| La explotación requiere peticiones API simples. La autenticación no es requerida. Múltiples peticiones concurrentes pueden ser realizadas desde una sola computadora local o usando recursos computacionales en la nube. | Es común encontrar APIs que no implementan límites de velocidad o APIs donde los límites no están configurados correctamente. | La explotación puede derivar en Denegación de Servicio, haciendo que la API no responda o que se inhabilite. | + +## ¿Es vulnerable la API? + +Las peticiones API consumen recursos como red, CPU, memoria y almacenamiento. La +cantidad de recursos requeridos para satisfacer una petición depende en mayor medida +en los datos del usuario y la lógica de negocios del recurso. También, considere el hecho +de que las peticiones desde múltiples clientes API compiten por los recursos disponibles. +Una API es vulnerable si al menos uno de los siguientes límites es ignorado +o configurado inapropiadamente (p.e. muy bajo/alto): + +* Tiempo de espera de ejecución +* Memoria máxima asignable +* Número de descriptores de archivo +* Número de procesos +* Tamaño de carga de la petición (p.e. cargas de archivos) +* Número de peticiones por cliente/recurso +* Número de registros por página a devolver en una sóla respuesta + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +Un atacante carga una imagen grande realizando una petición POST a `/api/v1/images`. +Cuando la carga se completa, la API crea múltiples muestras con tamaños diferentes. +Debido al tamaño de la imagen cargada, la memoria disponible se agota durante +la creación de las muestras y la API no responde otras peticiones. + +### Escenario #2 + +Tenemos una aplicación que contiene la lista de usuarios en una interfaz con un límite +de `200` usuarios por página. La lista de usuarios se obtiene del servidor usando +la siguiente consulta: `/api/users?page=1&size=100`. Un atacante cambia el parámetro +`size` a `200 000`, causando problemas de performance en la base de datos. Mientras +tanto, la API no responde y no es capaz que atender las peticiones clientes de éste +ni de otros clientes (o sea, Denegación de Servicio). + +El mismo escenario puede usarse para provocar errores de desbordamiento de enteros +o de desbordamiento de búfer. + +## Cómo Prevenir + +* Docker hace fácil el límite de [memoria][1], [CPU][2], [número de reinicios][3], + [descriptores de archivo, y procesos][4]. +* Implementar un límite de cuán seguido un cliente puede llamar a la API en un marco de tiempo definido. +* Notificar al cliente cuando el límite es excedido al proveer el número límite y el tiempo + en el que el límite será reiniciado. +* Agregar una correcta validación del lado del servidor para parámetros de consulta y del cuerpo de la petición, + específicamente aquellos que controlan el número de registros a ser devueltos en la respuesta. +* Defina y aplique un tamaño máximo de datos en todos los parámetros entrantes y cargas, como + un largo máximo para cadenas y un máximo número de elementos en listas. + + +## Referencias + +### OWASP + +* [Blocking Brute Force Attacks][5] +* [Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, + processes, restarts)][6] +* [REST Assessment Cheat Sheet][7] + +### Externas + +* [CWE-307: Improper Restriction of Excessive Authentication Attempts][8] +* [CWE-770: Allocation of Resources Without Limits or Throttling][9] +* “_Rate Limiting (Throttling)_” - [Security Strategies for Microservices-based + Application Systems][10], 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-policies---restart +[4]: https://docs.docker.com/engine/reference/commandline/run/#set-ulimits-in-container---ulimit +[5]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks +[6]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/Docker_Security_Cheat_Sheet.md#rule-7---limit-resources-memory-cpu-file-descriptors-processes-restarts +[7]: https://github.com/OWASP/CheatSheetSeries/blob/3a8134d792528a775142471b1cb14433b4fda3fb/cheatsheets/REST_Assessment_Cheat_Sheet.md +[8]: https://cwe.mitre.org/data/definitions/307.html +[9]: https://cwe.mitre.org/data/definitions/770.html +[10]: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204-draft.pdf diff --git a/2019/es/src/0xa5-broken-function-level-authorization.md b/2019/es/src/0xa5-broken-function-level-authorization.md new file mode 100644 index 000000000..9ef7fab96 --- /dev/null +++ b/2019/es/src/0xa5-broken-function-level-authorization.md @@ -0,0 +1,105 @@ +API5:2019 Autorización a nivel de función rota +============================================== + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **3** | Frecuencia **2** : Detectabilidad **1** | Técnico **2** : Específico del Negocio | +| La explotación requiere que el atacante envíe solicitudes API legítimas un recurso API al que no debería tener acceso. Esos recursos +pueden quedar expuestos a usuarios anónimos o usuarios regulares sin privilegios. Es más fácil descubrir esas falencias en APIs, ya que +las APIs son más estructuradas, y la forma de acceder a ciertas funciones es más predecible (p.e. reemplazando el método HTTP +de GET a PUT, o cambiando la cadena "users" en la URL a "admins"). | Los controles de autorización para una función o recurso son +usualmente administrados vía la configuración, y a veces a nivel de código. Implementando controles propicios puede ser una tarea confusa, +ya que aplicaciones modernas pueden contener muchos tipos de roles o grupos y jerarquías de usuario complejas(p.e. sub-usuarios, +usuarios con más de un rol). | Estas falencias permiten a los atacantes acceder a funcionalidad no autorizada. Las +funciones Administrativas son objetivos clave para este tipo de ataque. | + +## ¿Es vulnerable la API? + +La mejor manera de encontrar problemas de autorización a nivel de función rota +es realizar un análisis profundo del mecanismo de autorización, teniendo en +cuenta la jerarquía de usuarios, los diferentes roles o grupos en la aplicación +y realizando las siguientes preguntas: + +* ¿Puede un usuario regular acceder a recursos administrativos? +* ¿Puede un usuario realizar acciones sensibles (p.e. creación, modificación, + o borrado) a las que no debería tener acceso, simplemente cambiando el + método HTTP (p.e. de `GET` a `DELETE`)? +* ¿Puede un usuario del grupo X acceder a una función que debería estar expuesta + sólo a usuarios del grupo Y, simplemente adivinando la URL del recurso y sus + parámetros (p.e. `/api/v1/users/export_all`)? + +No asuma que un recurso API es regular o administrativo sólo basándose en la +ruta de la URL. + +Mientras los desarrolladores pueden elegir exponer la mayoría de los recursos +administrativos dentro de una ruta específica, como `api/admins`, es muy común +encontrar esos recursos administrativos dentro de otras rutas relativas junto +con recursos regulares, como `api/users`. + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +Durante el proceso de registración a una aplicación que permite sólo usuarios +invitados a unirse, la aplicación móvil dispara una solicitud API a +`GET /api/invites/{invite_guid}`. La respuesta contiene un JSON con detalles +sobre la invitación, incluyendo el rol del usuario y su email. + +Un atacante duplica la solicitud y manipula el método HTTP y el recurso a +`POST /api/invites/new`. Este recurso sólo debería ser accedido por +administradores usando la consola de administración, que no implementa +controles de autorización a nivel de función. + +El atacante explota el error y se envía una invitación a sí mismo para crear +una cuenta de administrador: + +``` +POST /api/invites/new + +{“email”:”hugo@malicious.com”,”role”:”admin”} +``` + +### Escenario #2 + +Una API contiene un recurso que debería estar expuesto sólo a administradores - +`GET /api/admin/v1/users/all`. Este recurso devuelve los detalles de todos los +usuarios de la aplicación y no implementa controles de autorización a nivel de +función. Un atacante que se aprendió la estructura de la API realiza una +suposición educada y se las arregla para acceder a este recurso, que expone +datos sensibles de los usuarios de la aplicación. + +## Cómo Prevenir + +Su aplicación debería tener una forma consistente y fácil de analizar el módulo +de autorización que es invocado desde todas sus funciones de negocios. +Frecuentemente, dicha protección es provista por uno o más componentes externos +al código de la aplicación. + +* Los mecanismos de protección deberían denegar todo acceso por defecto, + requiriendo autorizaciones explícitas para roles específicos en todas las + funciones. +* Revise sus recursos API contra fallas de autorización a nivel de función, + teniendo en cuenta la lógica de negocios de la aplicación y la jerarquía de + grupos. +* Asegúrese que todos sus controladores administrativos heredan de un + controlador administrativo abstracto que implementa controles de autorización + basados en el grupo/rol del usuario. +* Asegúrese que las funciones administrativas dentro de controladores regulares + implementan controles de autorización basados en el grupo y rol del usuario. + +## Referencias + +### OWASP + +* [OWASP Article on Forced Browsing][1] +* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2] +* [OWASP Development Guide: Chapter on Authorization][3] + +### Externas + +* [CWE-285: Improper Authorization][4] + +[1]: https://www.owasp.org/index.php/Forced_browsing +[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control +[3]: https://www.owasp.org/index.php/Category:Access_Control +[4]: https://cwe.mitre.org/data/definitions/285.html diff --git a/2019/es/src/0xa6-mass-assignment.md b/2019/es/src/0xa6-mass-assignment.md new file mode 100644 index 000000000..9a56e70fc --- /dev/null +++ b/2019/es/src/0xa6-mass-assignment.md @@ -0,0 +1,91 @@ +API6:2019 - Asignación Masiva +============================= + +| Amenazas/Vectores de ataque | Debilidades de seguridad | Impactos | +| - | - | - | +| Específico de la API : Explotabilidad **2** | Frecuencia **2** : Detectabilidad **2** | Técnico **2** : Específico del Negocio | +| La explotación usualmente requiere un conocimiento de la lógica de negocio, relaciones de objetos y la estructura de la API. +La explotación de la asignación masiva es más fácil en las API, ya que por diseño exponen la implementación subyacente de la aplicación +junto con los nombres de las propiedades. | Los marcos modernos alientan a los desarrolladores a usar funciones que enlazan +automáticamente la entrada del cliente en variables de código y objetos internos. Los atacantes pueden usar esta metodología para +actualizar o sobrescribir las propiedades de objetos sensibles que los desarrolladores nunca tuvieron la intención de exponer. | +La explotación puede conducir a la escalada de privilegios, la manipulación de datos, eludir los mecanismos de seguridad y más. | + +## ¿Es vulnerable la API? + +Los objetos en aplicaciones modernas pueden contener muchas propiedades. +Algunas de estas propiedades deben ser actualizadas directamente por el cliente +(ej. `user.first_name` or `user.address`) y algunas no (ej. la bandera `user.is_vip`). + +Un recurso de API es vulnerable si convierte automáticamente los parámetros del cliente +en propiedades de objeto interno, sin considerar la sensibilidad y el nivel de +exposición de estas propiedades. Esto podría permitir que un atacante actualice +propiedades de objeto a las que no deberían tener acceso. + +Ejemplos de propiedades sensibles: + +* **Propiedades relacionadas a permisos**: `user.is_admin`, `user.is_vip` deberían + ser escritas sólo por administradores. +* **Propiedades dependientes del proceso**: `user.cash` debería ser escrita sólo + internamente luego de la verificación del pago. +* **Propiedades internas**: `article.created_time` debería ser escrita sólo + internamente por la aplicación. + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +Una aplicación de viaje compartido le brinda al usuario la opción de editar +información básica de su perfil. Durante este proceso, se envía una llamada API +a `PUT /api/v1/users/me` con el siguiente objeto JSON legítimo: + +```json +{"user_name":"inons","age":24} +``` + +La petición `GET /api/v1/users/me` incluye una propiedad adicional +credit_balance: + +```json +{"user_name":"inons","age":24,"credit_balance":10}. +``` + +El atacante replica el primer request con el siguiente contenido: + +```json +{"user_name":"attacker","age":60,"credit_balance":99999} +``` + +Como el recurso es vulnerable a asignación masiva, el atacante recibe +crédito sin pagar. + +### Escenario #2 + +Un portal para compartir videos permite a los usuarios cargar y descargar contenido en +diferentes formatos. Un atacante que explora la API descubrió que el recurso +`GET /api/v1/videos/{video_id}/meta_data` devuelve un objeto JSON con las propiedades +del video. Una de las propiedades es `"mp4_conversion_params":"-vcodec h264"`, +que indica que la aplicación usa un comando de shell para convertir el video. + +El atacante también descubrió que el recurso `POST /api/v1/videos/new` es vulnerable a +asignación masiva y permite al cliente establecer cualquier propiedad del objeto de video. +El atacante establece un valor malicioso de la siguiente manera: +`"mp4_conversion_params":"-vcódec h264 && format C:/"`. Este valor causará un +inyección de comandos de shell una vez que el atacante descargue el video como MP4. + +## Cómo prevenir + +* Cuando sea posible, evite usar funciones que enlazan automáticamente una entrada de cliente + con variables de código u objetos internos. +* Incluya en una lista blanca solo las propiedades que el cliente debe actualizar. +* Utilice las funciones integradas para incluir en la lista negra las propiedades a las que + no deben acceder los clientes. +* Cuando corresponda, defina explícitamente y haga cumplir esquemas para los datos de entrada. + +## Referencias + +### Extrernas + +* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][1] + +[1]: https://cwe.mitre.org/data/definitions/915.html diff --git a/2019/es/src/0xa7-security-misconfiguration.md b/2019/es/src/0xa7-security-misconfiguration.md new file mode 100644 index 000000000..947e0c522 --- /dev/null +++ b/2019/es/src/0xa7-security-misconfiguration.md @@ -0,0 +1,93 @@ +API7:2019 Configuración incorrecta de seguridad +=================== + +|Agente/Vector de Ataque | Debilidades de Seguridad | Impacto | +| - | - | - | +| API Específica : Explotabilidad **3** | Prevalencia **3** : Detectabilidad **3** | Técnico **2** : ¿Negocio? | +| Los atacantes a menudo intentarán encontrar fallas que no han sido actualizadas, métodos comunes que estén expuestos o archivos y directorios desprotegidos para obtener acceso no autorizado o conocimiento del sistema. | La configuración incorrecta de seguridad puede ocurrir en cualquier nivel de la pila de API, desde el nivel de red hasta el nivel de aplicación. Hay herramientas automatizadas que están disponibles para detectar y explotar configuraciones incorrectas, como servicios innecesarios u opciones obsoletas. | Las configuraciones incorrectas de seguridad no solo pueden exponer datos confidenciales del usuario, sino también detalles del sistema que pueden llevar a un compromiso total del servidor. | + + +## ¿La API es Vulnerable? + +La API puede ser vulnerable si: + +* Falta fortificación apropiada de seguridad en cualquier parte de la pila de la aplicación, o si tiene permisos incorrectamente configurados en los servicios en la nube. +* Faltan los últimos parches de seguridad o los sistemas están desactualizados. +* Se habilitan funciones innecesarias (por ejemplo, verbos HTTP). +* Falta la seguridad de la capa de transporte (TLS). +* Las directivas de seguridad no se envían a los clientes (por ejemplo, [Encabezados de seguridad][1]). +* Falta una política de intercambio de recursos de origen cruzado (CORS) o está configurada incorrectamente. +* Los mensajes de error incluyen rastros de la pila u otra información confidencial está expuesta. + + +## Ejemplos de escenarios de ataque + +### Escenario #1 + +Un atacante encuentra el archivo `.bash_history` en el directorio raíz del +servidor, que contiene comandos utilizados por el equipo de DevOps para acceder a la API: + +``` +$ curl -X GET 'https: //api.server/endpoint/' -H 'autorización: Basic Zm9vOmJhcg==' +``` + +Un atacante también podría encontrar nuevos métodos expuestos por la API que solo son utilizados por el equipo de DevOps y no están documentados. + +### Escenario #2 + +Para atacar a un servicio en específico, un atacante utiliza un motor de búsqueda popular para buscar computadoras que son directamente accesibles desde Internet. El atacante encontró un host ejecutando un sistema de gestión de base de datos popular, escuchando por el puerto predeterminado. El host estaba usando la configuración predeterminada, la cual tiene la autenticación deshabilitada por defecto, y el atacante obtuvo acceso a millones de registros con Información Personal Identificable (PII), preferencias personales y datos de autenticación. + +### Escenario #3 +Al inspeccionar el tráfico de una aplicación móvil, un atacante descubre que no todo +el tráfico HTTP se realiza utilizando un protocolo seguro (por ejemplo, TLS). El atacante encuentra que esto es cierto, específicamente para la descarga de imágenes de perfil. Debido a que la interacción con el usuario es binaria, a pesar del hecho de que el tráfico de la API se realiza por medio de un protocolo seguro, el atacante encuentra un patrón en el tamaño de las respuestas de la API, las cuales utiliza para rastrear las preferencias del usuario sobre el contenido que se representa (por ejemplo, imágenes de perfil). + +## Cómo se previene +El ciclo de vida de la API debe de incluir: +* Un proceso de fortificación repetible que lleve hacia una implementación +rápida y fácil en un ambiente debidamente aislado. +* Una tarea para revisar y actualizar configuraciones en toda la pila de la API. +La revisión debe incluir: archivos de orquestación, componentes de la API y +servicios en la nube (por ejemplo, permisos en una cubeta S3). +* Un canal de comunicación seguro para todas las interacciones de la API + cuando ésta accede a los activos estáticos (por ejemplo, imágenes). +* Un proceso automatizado para evaluar continuamente la efectividad de la + configuración y ajustes en todos los ambientes. + +Además: + +* Para evitar que los rastros de excepción y otro tipo de información valiosa +sea enviada a los atacantes, solo si aplica, defina y aplique un estándar a todas las respuestas de la API, incluyendo las respuestas de errores. +* Asegúrese de que solo los verbos HTTP especificados puedan acceder a la API. +Todos los demás verbos HTTP deben de deshabilitarse (por ejemplo, HEAD). +* Las APIs que esperan ser accedidas desde clientes basados en navegador +(por ejemplo, front-end de una aplicación web) deben implementar una política +adecuada de intercambio de recursos de origen cruzado (CORS). + + +## Referencias + +### OWASP + +* [OWASP Secure Headers Project][1] +* [OWASP Testing Guide: Configuration Management][2] +* [OWASP Testing Guide: Testing for Error Codes][3] +* [OWASP Testing Guide: Test Cross Origin Resource Sharing][9] + + +### Externos + +* [CWE-2: Environmental Security Flaws][4] +* [CWE-16: Configuration][5] +* [CWE-388: Error Handling][6] +* [Guide to General Server Security][7], NIST +* [Let’s Encrypt: a free, automated, and open Certificate Authority][8] + +[1]: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project +[2]: https://www.owasp.org/index.php/Testing_for_configuration_management +[3]: https://www.owasp.org/index.php/Testing_for_Error_Code_(OTG-ERR-001) +[4]: https://cwe.mitre.org/data/definitions/2.html +[5]: https://cwe.mitre.org/data/definitions/16.html +[6]: https://cwe.mitre.org/data/definitions/388.html +[7]: https://csrc.nist.gov/publications/detail/sp/800-123/final +[8]: https://letsencrypt.org/ +[9]: https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007) diff --git a/2019/es/src/0xa8-injection.md b/2019/es/src/0xa8-injection.md new file mode 100644 index 000000000..2ae0504a2 --- /dev/null +++ b/2019/es/src/0xa8-injection.md @@ -0,0 +1,92 @@ +API8:2019 Inyección +=================== + +|Agente/Vector de Ataque | Debilidades de Seguridad | Impacto | +| - | - | - | +| API Específica : Explotabilidad **3** | Prevalencia **2** : Detectabilidad **3** | Técnico **3** : ¿Negocio? | +| Los atacantes alimentarán la API con datos maliciosos a través de los vectores de inyección disponibles (por ejemplo, entrada directa, parámetros, servicios integrados, etc.), esperando que se envíen a un intérprete. | Los defectos de inyección son muy comunes y a menudo se encuentran en consultas SQL, LDAP o NoSQL, comandos del sistema operativo, analizadores XML y ORM. Estos defectos son fáciles de descubrir cuando se revisa el código fuente. Los atacantes pueden usar escáneres y fuzzers. | La inyección puede conducir a la divulgación de información y pérdida de datos. También puede llevar a un DoS o apoderarse completamente del host. | + +## ¿La API es Vulnerable? + +La API es vulnerable a inyección si: + +* Información suministrada por el cliente no es validada, filtrada, o sanitizada por la API. +* Información suministrada por el cliente es directamente usada o concatenada a consultas SQL/NoSQL/LDAP, comandos de SO, Analizadores de XML, y Mapeo Relacional de Objetos (ORM) / Mapeador de Documentos de Objetos (ODM). +* Datos que vienen de sistemas externos (ej. sistemas integrados) no son validados, filtrados, o sanitizados por la API. + +## Ejemplos de escenarios de ataque + +### Escenario #1 + +El firmware de un dispositivo de control parental expone el método `/api/CONFIG/restore` el cual espera un appId para que se +envíe como un parámetro multiparte. Usando un descompilador, un atacante descubre que un appId pasa directamente a una llamada al +sistema sin ningún tipo de sanitización: + +```c +snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d", + "/mnt/shares/usr/bin/scripts/", appid, 66); +system(cmd); +``` + +El siguiente comando permite al atacante apagar cualquier dispositivo con el mismo firmware vulnerable: +``` +$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)' +``` + +### Escenario #2 + +Tenemos una aplicación con funcionalidad CRUD básica para operaciones con +reservaciones. Un atacante logró identificar que la inyección NoSQL podría ser posible +a través del parámetro de `bookingId`, un parámetro de tipo string en la petición para borrar una reservación. Así es como se ve dicha solicitud: `DELETE /api/bookings?bookingId=678`. + +El servidor de la API usa la siguiente función para manejar las solicitudes de eliminación: + +```javascript +router.delete('/bookings', async function (req, res, next) { + try { + const deletedBooking = await Bookings.findOneAndRemove({'_id' : req.query.bookingId}); + res.status(200); + } catch (err) { + res.status(400).json({error: 'Unexpected error occured while processing a request'}); + } +}); +``` + +El atacante intercepta la petición y cambia el parámetro de tipo string `bookingId` como se muestra a continuación. En este caso, el atacante logró eliminar la reservación de otro usuario. + +``` +DELETE /api/bookings?bookingId[$ne]=678 +``` + +## Cómo se previene + +Para prevenir ataques de inyección se requiere que los datos se mantengan separados de los comandos y las consultas. + +* Realice la validación de datos utilizando una biblioteca única, confiable y actualizada. +* Valide, filtre y desinfecte todos los datos proporcionados por el cliente u otros datos provenientes de sistemas integrados. +* Los caracteres especiales se deben escapar utilizando la sintaxis específica para el intérprete de destino. +* Opte por una API segura que proporcione una interfaz parametrizada. +* Siempre limite el número de registros devueltos para evitar la divulgación masiva en caso de un ataque de inyección. +* Valide los datos entrantes utilizando filtros suficientes para permitir solo valores válidos para cada parámetro de entrada. +* Defina tipos de datos y patrones estrictos para todos los parámetros de tipo string. + +## Referencias + +### OWASP + +* [OWASP Injection Flaws][1] +* [SQL Injection][2] +* [NoSQL Injection Fun with Objects and Arrays][3] +* [Command Injection][4] + +### Externos + +* [CWE-77: Command Injection][5] +* [CWE-89: SQL Injection][6] + +[1]: https://www.owasp.org/index.php/Injection_Flaws +[2]: https://www.owasp.org/index.php/SQL_Injection +[3]: https://www.owasp.org/images/e/ed/GOD16-NOSQL.pdf +[4]: https://www.owasp.org/index.php/Command_Injection +[5]: https://cwe.mitre.org/data/definitions/77.html +[6]: https://cwe.mitre.org/data/definitions/89.html diff --git a/2019/es/src/0xa9-improper-assets-management.md b/2019/es/src/0xa9-improper-assets-management.md new file mode 100644 index 000000000..b6ac4098a --- /dev/null +++ b/2019/es/src/0xa9-improper-assets-management.md @@ -0,0 +1,80 @@ +API9:2019 Control de Acceso Inadecuado +==================================== + +|Agente/Vector de Ataque | Debilidades de Seguridad | Impacto | +| - | - | - | +| API Específica : Explotabilidad **3** | Prevalencia **3** : Detectabilidad **2** | Técnico **2** : Negocio | +| Las versiones antiguas de API generalmente no tienen las últimas actualizaciones de seguridad y son una manera fácil de comprometer sistemas sin tener que luchar contra los mecanismos de seguridad más modernos, los cuales podrían estar configurados para solo proteger las versiones de las APIs más recientes. | La documentación obsoleta hace que sea más difícil encontrar y / o arreglar vulnerabilidades. La falta de inventario de activos y de estrategias de retiro de los mismos resulta que sistemas estén funcionando aunque no cuenten con las últimas actualizaciones de seguridad, lo que pudiese resultar en la fuga de datos sensibles. Es común encontrar hosts de APIs innecesariamente expuestos debido a conceptos modernos como microservicios, que hacen que las aplicaciones sean independientes y fáciles de desplegar (p.e., computación en la nube, k8s). | Los atacantes pueden obtener acceso a datos sensibles, o incluso tomar el control de un servidor a través del uso de una versión antigua y desactualizada de alguna API conectada a la misma base de datos. | + +## ¿La API es Vulnerable? + +La API es vulnerable si: + +* El propósito de una API no está claro y no hay respuestas explícitas a las siguientes preguntas: + + * ¿En qué entorno se está ejecutando la API (p.e., producción, pre-producción, pruebas, desarrollo)? + * ¿Quién debería tener acceso de red a la API (público, interno, socios)? + * ¿Qué versión de la API se está ejecutando? + * ¿Qué datos son recolectados y procesados por la API (p.e., PII)? + * ¿Cuál es el flujo de datos? + * No hay documentación, o la documentación existente no está actualizada. + * No hay plan de retiro para cada versión de API. + * Falta el inventario de hosts o está desactualizado. + * Falta el inventario de servicios integrados, ya sea de primeras o terceras partes, o está desactualizado. + * Versiones antiguas o previas de la API están ejecutándose sin parches. + + +## Escenarios de Ataque de Ejemplo + +### Escenario #1 + +Después de rediseñar sus aplicaciones, un servicio de búsqueda dejó una versión antigua de la API (`api.someservice.com/v1`) en ejecución, sin protección y con acceso a la base de datos. Mientras se dirigía a una de las últimas aplicaciones lanzadas, un +atacante encontró la dirección de la API (`api.someservice.com/v2`). Reemplazando `v2` con +`v1` en la URL, el atacante obtuvo acceso a la antigua API desprotegida, +exponiendo la información personal identificable (PII) de más de 100 millones de usuarios. + +### Escenario #2 + +Una red social implementó un mecanismo de limitación de velocidad que bloquea a los atacantes de usar un ataque de fuerza bruta para adivinar tokens de restablecimiento de contraseña. Este mecanismo no fue implementado como parte del código de la API, sino en otro componente entre el cliente y la API oficial (`www.socialnetwork.com`). Un investigador encontró un dominio de una API beta (`www.mbasic.beta.socialnetwork.com`) que corre la misma API, incluyendo el mecanismo de restablecimiento de contraseñas, pero el mecanismo de limitación de velocidad no estaba en su lugar. El investigador fue capaz de restablecer la contraseña de cualquier usuario por medio de la utilización de un simple ataque de fuerza bruta para adivinar un token de 6 dígitos. + +## Cómo Prevenir + +* Haga un inventario de todos los hosts de sus APIs y documente aspectos +importantes de cada un de ellas, centrándose en el entorno de la API +(por ejemplo, producción, pre-producción, pruebas, desarrollo), quién debe +tener acceso de red al host (por ejemplo, pública, interna, socios) y la versión +de la API. +* Haga un inventario de servicios integrados y documente aspectos importantes +como su propósito en el sistema, qué datos se manejan (flujo de datos) y su +nivel de sensibilidad. +* Documente todos los aspectos de su API, como autenticación, errores, +redireccionamientos, política de límite de velocidad, intercambio de recursos de +origen cruzado (CORS) y métodos expuestos, incluidos sus parámetros, +solicitudes y respuestas. +* Genere la documentación automáticamente por medio de la adopción de estándares +abiertos. Incluya la documentación de compilación en su proceso de +Integración Continua / Despliegue continuo. +* Ponga la documentación de la API a disposición de aquellos autorizados para +usar la API. +* Use medidas de protección externa, como firewalls de seguridad para todas las +versiones expuestas de sus APIs, es decir, no solo para la versión de producción +más actual. +* Evite usar datos de producción con implementaciones de APIs que no sean de +producción. Si esto es inevitable, estos métodos expuestos deben de recibir el +mismo cuidado de seguridad que las que se encuentran en producción. +* Cuando las versiones más recientes de las APIs incluyan mejoras de seguridad, +realice un análisis de riesgo para tomar la decisión de las acciones de +mitigación requeridas para las versiones anteriores: por ejemplo, ver si es +posible hacer esas mejoras de seguridad sin romper la compatibilidad de las APIs +anteriores o ver si necesita remover la versión anterior rápidamente y obligar a +todos los clientes a que solo puedan usar la última versión. + +## Referencias + +### Externos + +* [CWE-1059: Incomplete Documentation][1] +* [OpenAPI Initiative][2] + +[1]: https://cwe.mitre.org/data/definitions/1059.html +[2]: https://www.openapis.org/ diff --git a/2019/es/src/0xaa-insufficient-logging-monitoring.md b/2019/es/src/0xaa-insufficient-logging-monitoring.md new file mode 100644 index 000000000..81ddbc535 --- /dev/null +++ b/2019/es/src/0xaa-insufficient-logging-monitoring.md @@ -0,0 +1,74 @@ +API10:2019 Registro y Monitoreo Insuficiente +============================================ + +|Agente/Vector de Ataque | Debilidades de Seguridad | Impacto | +| - | - | - | +| API Específica : Explotabilidad **2** | Prevalencia **3** : Detectabilidad **1** | Técnico **2** : Negocio | +| Los atacantes se pueden aprovechar de la falta de registro y monitoreo para abusar sistemas sin ser detectados. | Sin registro y monitoreo, o sin suficiente registro y monitoreo, es casi imposible detectar actividades sospechosas y responder a ellas a tiempo. | Sin la visibilidad sobre constantes actividades maliciosas, los atacantes tienen tiempo suficiente para comprometer sistemas.| + +## ¿Es vulnerable la API? + +La API es vulnerable si: + +* No produce ningún tipo de registro, el nivel del registro no es el correcto, o + los mensajes de registro no incluyen detalles suficientes. +* La integridad del registro no está garantizada +(e.g., [Inyección de Registro][1]). +* Los registros no son continuamente monitoreados. +* La infraestructura de la API no es continuamente monitoreada. + +## Ejemplos de escenarios de ataque + +### Escenario #1 +Las llaves de acceso de una API administrativa fueron comprometidas en un +repositorio público. El dueño del repositorio fue notificado vía correo +electrónico sobre la posible fuga, pero tomó más de 48 horas para actuar de +acuerdo al incidente y dicha fuga pudo haber causado acceso a datos sensibles. +Debido a la falta de registros, la compañía no es capaz de verificar qué datos +fueron accedidos por los atacantes. + +### Escenario #2 +Una plataforma para compartir vídeos fue afectada a “gran escala” por un ataque +de relleno automático de credenciales. A pesar de que intentos fallidos de +inicio de sesión se estaban registrando, ninguna alerta se activó durante el +periodo del ataque. Como reacción a las quejas de los usuarios, los registros +de la API fueron analizados y el ataque fue detectado. La compañía tuvo que +realizar un anuncio público pidiendo a los usuarios que restablezcan sus +contraseñas y reportó el incidente a las autoridades regulatorias. + +## Cómo Prevenir +* Registrar todos los fallos de intentos de autenticación, acceso denegado y +errores de validación de entrada. +* Los registros deben de ser escritos usando un formato adecuado para el consumo +de una solución de gestión de registros y debe incluir detalle suficiente para +identificar al actor malicioso. +* Los registros deben de manejarse como datos sensibles y su integridad debe de +ser garantizada durante reposo y tránsito. +* Configurar un sistema de monitoreo para continuamente monitorear la +infraestructura, red y la API funcionando. +* Usar un sistema de gestión de información y eventos de seguridad (SIEM) para +agregar y administrar registros de todos los componentes de la pila API y los +hosts. +* Configurar paneles personalizados y alertas, permitiendo que actividades +sospechosas sean detectadas y respondidas más temprano. + + +## Referencias + +### OWASP + +* [OWASP Logging Cheat Sheet][2] +* [OWASP Proactive Controls: Implement Logging and Intrusion Detection][3] +* [OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification Requirements][4] + +### Externos + +* [CWE-223: Omission of Security-relevant Information][5] +* [CWE-778: Insufficient Logging][6] + +[1]: https://www.owasp.org/index.php/Log_Injection +[2]: https://www.owasp.org/index.php/Logging_Cheat_Sheet +[3]: https://www.owasp.org/index.php/OWASP_Proactive_Controls +[4]: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x15-V7-Error-Logging.md +[5]: https://cwe.mitre.org/data/definitions/223.html +[6]: https://cwe.mitre.org/data/definitions/778.html diff --git a/2019/es/src/0xb0-next-devs.md b/2019/es/src/0xb0-next-devs.md new file mode 100644 index 000000000..114fad4aa --- /dev/null +++ b/2019/es/src/0xb0-next-devs.md @@ -0,0 +1,38 @@ +¿Qué sigue para los desarrolladores? +========================== + +La tarea de crear y mantener software seguro, o reparar el software actual, +puede ser difícil. Las APIs no son diferentes. + +Creemos que la educación y la conciencia son factores clave para desarrollar +software seguro. Todo lo demás que es requerido para lograr el objetivo +depende de **establecer y usar procesos de seguridad repetibles y controles +estándares de seguridad**. + +OWASP tiene numerosos recursos gratuitos y abiertos para abordar el tema de la +seguridad desde que inicia un proyecto. Visite la +[página de proyectos de OWASP][1] para obtener una lista completa de los +proyectos disponibles. + +| | | +|-|-| +| **Educación** | Puede comenzar a leer [Materiales del proyecto educativo de OWASP][2] de acuerdo con su profesión e interés. Para el aprendizaje práctico, agregamos **crAPI** - **API** **C**ompletamente **R**ídicula en [nuestro plan de trabajo][3]. Mientras tanto, puede practicar WebAppSec utilizando el [Módulo OWASP DevSlop Pixi][4], un servicio vulnerable de WebApp y API con el fin de enseñar a los usuarios cómo probar aplicaciones web modernas y APIs para identificar problemas de seguridad y para aprender a desarrollar APIs más seguras. También puede asistir a las sesiones de capacitación [Conferencia de AppSec de OWASP][5] o [unirse al capítulo local][6]. | +| **Requisitos de seguridad** | La seguridad debe ser parte de cada proyecto desde el principio. Al obtener los requerimientos, es importante definir qué significa "seguro" para ese proyecto en particular. OWASP recomienda utilizar el [Estándar de verificación de seguridad de aplicaciones (ASVS) de OWASP][7] como guía para definir los requerimientos de seguridad. Si usted está subcontratando, considere el [Anexo del contrato de software seguro de OWASP][8], el cual debería ser adaptado a las leyes y regulaciones locales. | +| **Arquitectura de seguridad** | La seguridad debe de tomarse en cuenta durante todas las etapas del proyecto. Las [Hojas de trucos de prevención de OWASP][9] son un buen punto de partida para obtener orientación sobre cómo diseñar la seguridad durante la fase de arquitectura. Entre muchas otras, usted encontrará la [Hoja de referencia de seguridad REST][10] y la [Hoja de referencia de evaluación REST][11]. | +| **Controles estándares de seguridad** | La adopción de controles estándares de seguridad reduce el riesgo de introducir debilidades de seguridad al escribir su propia lógica. A pesar del hecho de que muchos frameworks modernos ahora vienen con controles estándares incorporados de una manera efectiva, [Controles proactivos OWASP][12] le brinda una buena visión general de los controles de seguridad que debería incluir en su proyecto. OWASP también proporciona algunas librerías y herramientas que le pueden servir, como la de controles de validación. | +| **Ciclo de vida del desarrollo seguro de software** | Puede usar el [Modelo de madurez de garantía de software de OWASP (SAMM)][13] para mejorar el proceso al momento de crear APIs. Además, otros proyectos de OWASP están disponibles para ayudarle durante las diferentes fases de desarrollo de APIs, por ejemplo, el [Proyecto de revisión de código de OWASP][14]. | + +[1]: https://www.owasp.org/index.php/Category:OWASP_Project +[2]: https://www.owasp.org/index.php/OWASP_Education_Material_Categorized +[3]: https://www.owasp.org/index.php/OWASP_API_Security_Project#tab=Road_Map +[4]: https://devslop.co/Home/Pixi +[5]: https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference +[6]: https://www.owasp.org/index.php/OWASP_Chapter +[7]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[8]: https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex +[9]: https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series +[10]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md +[11]: https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Assessment_Cheat_Sheet.md +[12]: https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=OWASP_Proactive_Controls_2018 +[13]: https://www.owasp.org/index.php/OWASP_SAMM_Project +[14]: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project diff --git a/2019/es/src/0xb1-next-devsecops.md b/2019/es/src/0xb1-next-devsecops.md new file mode 100644 index 000000000..c0bf8efe1 --- /dev/null +++ b/2019/es/src/0xb1-next-devsecops.md @@ -0,0 +1,32 @@ +¿Qué sigue para DevSecOps? +========================= + +Debido a su importancia en las arquitecturas de aplicaciones modernas, +desarrollar APIs seguras es fundamental. La seguridad no puede ser descuidada, +y debería ser parte de todo el ciclo de vida del desarrollo de software. +Hacer escaneos y pruebas de penetración anualmente ya no es suficiente. + +DevSecOps debería unirse al esfuerzo de desarrollo, facilitando pruebas +continuas de seguridad a lo largo de todo el ciclo de vida del desarrollo de +software. Su meta es mejorar dicho proceso por medio de la automatización sin +sacrificar velocidad de desarrollo. + +Ante la duda, manténgase informado y revise el [Manifiesto DevSecOps][1] con +frecuencia. + +| | | +|-|-| +| **Comprender el Modelo de Amenazas** | Las pruebas con mayor prioridad provienen de un modelo de amenaza. Si no tiene uno, considere usar [OWASP Application Security Verification Standard (ASVS)][2] y la [Guía de pruebas de OWASP][3] como referencia. Involucrar al equipo de desarrollo puede ayudar a que éste sea más consciente de la seguridad. | +| **Comprender el SDLC** | Únase al equipo de desarrollo para entender mejor el ciclo de vida del desarrollo del software. Su contribución en las pruebas continuas de seguridad debe ser compatible con las personas, los procesos y las herramientas. Todos deberían estar de acuerdo con el proceso para que no haya fricciones o resistencia innecesaria. | +| **Estrategia de pruebas** | Debido a que su trabajo no debe afectar la velocidad de desarrollo, se debe elegir la mejor técnica (simple, rápida y precisa) para verificar los requisitos de seguridad. El [Marco de conocimientos de seguridad de OWASP][4] y el [Estándar de verificación de seguridad de aplicaciones de OWASP][5] pueden ser excelentes fuentes de requisitos funcionales y no funcionales de seguridad. También, existen otras fuentes para [proyectos][6] y [herramientas][7] similares a las que ofrece la [comunidad DevSecOps][8]. | +| **Lograr cobertura y precisión** | Usted es el puente entre los desarrolladores y los equipos de operaciones. Para lograr cobertura, no solo debe concentrarse en la funcionalidad, sino también en la orquestación. Desde el principio, trabaje cerca de los equipos de desarrollo y operaciones para que pueda optimizar su tiempo y esfuerzo. Su meta debe ser llegar a un estado en donde la seguridad esencial se verifique continuamente. | +| **Comunicar claramente los hallazgos** | Aporte valor con la menor fricción posible. Entregue los hallazgos de manera oportuna y dentro de las herramientas que utilizan los equipos de desarrollo (no archivos PDF). Únase al equipo de desarrollo para abordar los hallazgos. Aproveche la oportunidad para educarlos, describiendo claramente la debilidad y cómo se puede abusar de ella, de ser posible incluya un escenario de ataque real. | + +[1]: https://www.devsecops.org/ +[2]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[3]: https://www.owasp.org/index.php/OWASP_Testing_Project +[4]: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework +[5]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project +[6]: http://devsecops.github.io/ +[7]: https://github.com/devsecops/awesome-devsecops +[8]: http://devsecops.org diff --git a/2019/es/src/0xd0-about-data.md b/2019/es/src/0xd0-about-data.md new file mode 100644 index 000000000..76322b381 --- /dev/null +++ b/2019/es/src/0xd0-about-data.md @@ -0,0 +1,47 @@ +Metodología y Datos +==================== + +## Visión de conjunto + +Debido a que la industria no se ha enfocado específicamente en la arquitectura +de aplicaciones más reciente, en donde las APIs juegan un papel fundamental, +compilando una lista de los diez riesgos de seguridad de APIs más críticos, +basada en una llamada pública para recopilar datos, habría sido una tarea +difícil. A pesar de no haber hecho una llamada al público, la lista resultante +de los 10 riesgos más críticos todavía se basa en datos disponibles +públicamente, contribuciones hechas por expertos en seguridad y discusión +abierta con la comunidad de seguridad. + +## Metodología + +En la primera fase, datos públicos acerca de incidentes de seguridad acerca de +APIs fueron recopilados, revisados y categorizados por un grupo de expertos de +seguridad. Dichos datos fueron recopilados de plataformas de _bug bounty_ y de +bases de datos de vulnerabilidades con no más de un año de antigüedad. +Fueron utilizados con fines estadísticos. + +En la siguiente fase, se le pidió a profesionales de seguridad con experiencia +en pruebas de penetración que hicieran su propia lista de los 10 riesgos más +críticos. + +La [Metodología de calificación de riesgo del OWASP][1] fue usada para realizar +un análisis. Los puntajes fueron discutidos y revisados entre los profesionales +de seguridad. Para consideraciones sobre estos asuntos, consulte los +[Riesgos de seguridad de las APIs][2] ubicados en la sección número. + +El primer borrador del OWASP API Security Top 10 2019 fue el resultado de un +consenso entre los resultados estadísticos de la fase uno y la lista de los +profesionales de seguridad. Este borrador fue presentado para su apreciación y +revisión por otro grupo de profesionales de seguridad, con experiencia relevante +en el campo de seguridad de APIs. + +El OWASP API Security Top 10 2019 se presentó por primera vez en el OWASP Global +AppSec Tel Aviv event (mayo de 2019). Desde entonces, ha estado disponible en +GitHub con el fin de discusión pública y contribuciones. + +La lista de contribuyentes está disponible en la sección de +[Agradecimientos][3]. + +[1]: https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology +[2]: ./0x10-api-security-risks.md +[3]: ./0xd1-acknowledgments.md diff --git a/2019/es/src/0xd1-acknowledgments.md b/2019/es/src/0xd1-acknowledgments.md new file mode 100644 index 000000000..9b914f190 --- /dev/null +++ b/2019/es/src/0xd1-acknowledgments.md @@ -0,0 +1,43 @@ +Agradecimientos a contribuyentes particulares +=============== + +## Agradecimientos a los contribuyentes + +Quisiéramos agradecer a los siguientes contribuyentes que contribuyeron +públicamente en GitHub o por otros medios: + +* 007divyachawla +* Abid Khan +* Adam Fisher +* anotherik +* bkimminich +* caseysoftware +* Chris Westphal +* dsopas +* DSotnikov +* emilva +* ErezYalon +* flascelles +* Guillaume Benats +* IgorSasovets +* Inonshk +* JonnySchnittger +* jmanico +* jmdx +* Keith Casey +* kozmic +* LauraRosePorter +* leonelquinteros +* Matthieu Estrade +* nathanawmk +* PauloASilva +* pentagramz +* philippederyck +* pleothaud +* r00ter +* Raj kumar +* Sagar Popat +* shekodn +* Stephen Gates +* thomaskonrad +* xycloops123 diff --git a/2019/es/src/images/cover.jpg b/2019/es/src/images/cover.jpg new file mode 100644 index 000000000..771f35a93 Binary files /dev/null and b/2019/es/src/images/cover.jpg differ diff --git a/2019/es/src/images/front-cc.png b/2019/es/src/images/front-cc.png new file mode 100644 index 000000000..45f139804 Binary files /dev/null and b/2019/es/src/images/front-cc.png differ diff --git a/2019/es/src/images/front-wasp.png b/2019/es/src/images/front-wasp.png new file mode 100644 index 000000000..5a163dd4b Binary files /dev/null and b/2019/es/src/images/front-wasp.png differ diff --git a/2019/es/src/images/license.png b/2019/es/src/images/license.png new file mode 100644 index 000000000..124d3ba4d Binary files /dev/null and b/2019/es/src/images/license.png differ diff --git a/2019/es/src/images/owasp-logo.png b/2019/es/src/images/owasp-logo.png new file mode 100644 index 000000000..caeb47bdf Binary files /dev/null and b/2019/es/src/images/owasp-logo.png differ