diff --git a/2025/docs/es/0x00_2025-Introduction.md b/2025/docs/es/0x00_2025-Introduction.md new file mode 100644 index 000000000..b8995cf03 --- /dev/null +++ b/2025/docs/es/0x00_2025-Introduction.md @@ -0,0 +1,113 @@ +![Logotipo de OWASP](../assets/TOP_10_logo_Final_Logo_Colour.png) + +# Los Diez Riesgos de Seguridad de Aplicaciones Web Más Críticos + +# Introducción + +¡Bienvenidos a la octava edición del OWASP Top Ten! + +Un enorme agradecimiento a todos los que contribuyeron con datos y perspectivas en la encuesta. Sin ustedes, esta edición no habría sido posible. **¡GRACIAS!** + + +## Presentación del OWASP Top 10:2025 + + + +* [A01:2025 - Pérdida de Control de Acceso](A01_2025-Broken_Access_Control.md) +* [A02:2025 - Configuración de Seguridad Incorrecta](A02_2025-Security_Misconfiguration.md) +* [A03:2025 - Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md) +* [A04:2025 - Fallas Criptográficas](A04_2025-Cryptographic_Failures.md) +* [A05:2025 - Inyección](A05_2025-Injection.md) +* [A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md) +* [A07:2025 - Fallas de Autenticación](A07_2025-Authentication_Failures.md) +* [A08:2025 - Fallas en la Integridad del Software o de los Datos](A08_2025-Software_or_Data_Integrity_Failures.md) +* [A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad](A09_2025-Security_Logging_and_Alerting_Failures.md) +* [A10:2025 - Manejo Inadecuado de Condiciones Excepcionales](A10_2025-Mishandling_of_Exceptional_Conditions.md) + + +## Qué ha cambiado en el Top 10 para 2025 + +Hay dos categorías nuevas y una consolidación en el Top Ten para 2025. Hemos trabajado para mantener nuestro enfoque en la causa raíz por encima de los síntomas tanto como ha sido posible. Debido a la complejidad de la ingeniería de software y la seguridad del software, es básicamente imposible crear diez categorías sin algún nivel de solapamiento. + +![Mapeo](../assets/2025-mappings.png) + +* **[A01:2025 - Pérdida de Control de Acceso](A01_2025-Broken_Access_Control.md)** mantiene su posición en el #1 como el riesgo de seguridad de aplicaciones más grave; los datos aportados indican que, de media, el 3,73% de las aplicaciones analizadas presentaban una o más de las 40 Enumeraciones de Debilidades Comunes (CWE, por sus siglas en inglés: *Common Weakness Enumerations*) en esta categoría. Como indica la línea discontinua en la figura anterior, la Falsificación de Solicitudes del Lado del Servidor (SSRF, *Server-Side Request Forgery*) se ha integrado en esta categoría. +* **[A02:2025 - Configuración de Seguridad Incorrecta](A02_2025-Security_Misconfiguration.md)** subió del #5 en 2021 al #2 en 2025. Las configuraciones incorrectas son más prevalentes en los datos de este ciclo. El 3,00% de las aplicaciones analizadas tenían una o más de las 16 CWE en esta categoría. Esto no es sorprendente, ya que la ingeniería de software sigue aumentando la cantidad de comportamiento de una aplicación que se basa en configuraciones. +* **[A03:2025 - Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md)** es una expansión de [A06:2021 - Componentes Vulnerables y Desactualizados](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) para incluir un alcance más amplio de compromisos que ocurren dentro o a través de todo el ecosistema de dependencias de software, sistemas de construcción (*build systems*) e infraestructura de distribución. Esta categoría fue votada mayoritariamente como una de las principales preocupaciones en la encuesta de la comunidad. Esta categoría cuenta con 5 CWE y una presencia limitada en los datos recopilados, pero creemos que esto se debe a los desafíos en las pruebas y esperamos que las pruebas se pongan al día en esta área. Esta categoría tiene el menor número de ocurrencias en los datos, pero también las puntuaciones medias más altas de explotación e impacto de CVE (*Common Vulnerabilities and Exposures*). +* **[A04:2025 - Fallas Criptográficas](A04_2025-Cryptographic_Failures.md)** baja dos puestos del #2 al #4 en la clasificación. Los datos aportados indican que, de media, el 3,80% de las aplicaciones tienen una o más de las 32 CWE en esta categoría. Esta categoría a menudo conduce a la exposición de datos sensibles o al compromiso del sistema. +* **[A05:2025 - Inyección](A05_2025-Injection.md)** baja dos puestos del #3 al #5 en la clasificación, manteniendo su posición relativa respecto a Fallas Criptográficas y Diseño Inseguro. La inyección es una de las categorías más probadas, con el mayor número de CVE asociados a las 38 CWE de esta categoría. La inyección incluye una gama de problemas que van desde el Secuencia de Comandos en Sitios Cruzados (XSS, alta frecuencia/bajo impacto) hasta vulnerabilidades de Inyección SQL (baja frecuencia/alto impacto). +* **[A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md)** desciende dos puestos del #4 al #6 en el ranking, al ser superada por Configuración de Seguridad Incorrecta y Fallas en la Cadena de Suministro de Software. Esta categoría se introdujo en 2021, y hemos visto mejoras notables en la industria relacionadas con el modelado de amenazas y un mayor énfasis en el diseño seguro. +* **[A07:2025 - Fallas de Autenticación](A07_2025-Authentication_Failures.md)** mantiene su posición en el #7 con un ligero cambio de nombre (anteriormente era "[Fallas de Identificación y Autenticación](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)") para reflejar con mayor precisión las 36 CWE de esta categoría. Esta categoría sigue siendo importante, pero el mayor uso de marcos de trabajo estandarizados para la autenticación parece estar teniendo efectos beneficiosos en la incidencia de las fallas de autenticación. +* **[A08:2025 - Fallas en la Integridad del Software o de los Datos](A08_2025-Software_or_Data_Integrity_Failures.md)** continúa en el #8 de la lista. Esta categoría se centra en la falla al mantener los límites de confianza y verificar la integridad del software, el código y los artefactos de datos a un nivel inferior al de las fallas en la Cadena de Suministro de Software. +* **[A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad](A09_2025-Security_Logging_and_Alerting_Failures.md)** conserva su posición en el #9. Esta categoría tiene un ligero cambio de nombre (anteriormente "[Fallas de Registro y Monitorización de Seguridad](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/)") para enfatizar la importancia de la funcionalidad de alerta necesaria para inducir una acción apropiada ante eventos de registro relevantes. Un excelente registro sin alertas tiene un valor mínimo para identificar incidentes de seguridad. Esta categoría siempre estará infrarrepresentada en los datos, y fue votada de nuevo para una posición en la lista por los participantes de la encuesta de la comunidad. +* **[A10:2025 - Manejo Inadecuado de Condiciones Excepcionales](A10_2025-Mishandling_of_Exceptional_Conditions.md)** es una nueva categoría para 2025. Esta categoría contiene 24 CWE que se centran en el manejo inadecuado de errores, errores lógicos, fallas en modo abierto (*failing open*) y otros escenarios relacionados derivados de condiciones anormales que los sistemas pueden encontrar. + + +## Metodología + +Esta entrega del Top Ten sigue estando informada por los datos, pero no impulsada ciegamente por ellos. Clasificamos 12 categorías basándonos en los datos aportados, y permitimos que dos fueran promovidas o destacadas por las respuestas de la encuesta de la comunidad. Hacemos esto por una razón fundamental: examinar los datos aportados es, esencialmente, mirar al pasado. Los investigadores de seguridad de aplicaciones dedican tiempo a identificar nuevas vulnerabilidades y a desarrollar nuevos métodos de prueba. Se necesitan de semanas a años para integrar estas pruebas en herramientas y procesos. Para cuando podemos probar una debilidad de forma fiable a escala, pueden haber pasado años. También existen riesgos importantes que quizá nunca podamos probar de forma fiable y que no estén presentes en los datos. Para equilibrar esa visión, utilizamos una encuesta comunitaria para preguntar a los profesionales de la seguridad y el desarrollo de aplicaciones que están en primera línea qué ven como riesgos esenciales que pueden estar infrarrepresentados en los datos de las pruebas. + + +## Cómo se estructuran las categorías + +Algunas categorías han cambiado con respecto a la entrega anterior del OWASP Top Ten. He aquí un resumen de alto nivel de los cambios en las categorías. + +En esta iteración, solicitamos datos sin restricciones sobre las CWE, a diferencia de lo que hicimos para la edición de 2021. Preguntamos por el número de aplicaciones probadas en un año determinado (empezando en 2021) y el número de aplicaciones con al menos una instancia de una CWE encontrada en las pruebas. Este formato nos permite seguir la prevalencia de cada CWE dentro de la población de aplicaciones. Ignoramos la frecuencia para nuestros propósitos; aunque puede ser necesaria para otras situaciones, solo oculta la prevalencia real en la población de aplicaciones. Que una aplicación tenga cuatro instancias de una CWE o 4.000 instancias no forma parte del cálculo para el Top Ten. Especialmente porque los evaluadores manuales tienden a listar una vulnerabilidad solo una vez, sin importar cuántas veces se repita en una aplicación, mientras que los marcos de pruebas automatizadas listan cada instancia de una vulnerabilidad como única. Pasamos de aproximadamente 30 CWE en 2017, a casi 400 CWE en 2021, a 589 CWE en esta edición para analizar en el conjunto de datos. Planeamos realizar análisis de datos adicionales como suplemento en el futuro. Este aumento significativo en el número de CWE hace necesarios cambios en la estructura de las categorías. + +Pasamos varios meses agrupando y categorizando CWE y podríamos haber continuado durante meses adicionales. Tuvimos que parar en algún momento. Existen CWE de tipo causa raíz y de tipo síntoma, donde los tipos de causa raíz son como "Falla Criptográfica" y "Configuración Incorrecta", en contraste con los tipos de síntoma como "Exposición de Datos Sensibles" y "Denegación de Servicio". Decidimos centrarnos en la causa raíz siempre que fuera posible, ya que es más lógico para proporcionar orientación de identificación y remediación. Centrarse en la causa raíz por encima del síntoma no es un concepto nuevo; el Top Ten ha sido una mezcla de síntoma y causa raíz. Las CWE también son una mezcla de síntoma y causa raíz; simplemente estamos siendo más deliberados al señalarlo. Hay un promedio de 25 CWE por categoría en esta entrega, con los límites inferiores en 5 CWE para A03:2025 - Fallas en la Cadena de Suministro de Software y A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad, hasta 40 CWE en A01:2025 - Pérdida de Control de Acceso. Tomamos la decisión de limitar el número de CWE en una categoría a 40. Esta estructura de categorías actualizada ofrece beneficios adicionales de formación, ya que las empresas pueden centrarse en las CWE que tengan sentido para un lenguaje o marco de trabajo (*framework*). + +Se nos ha preguntado por qué no cambiar a una lista de 10 CWE como un Top 10, similar a las 25 debilidades de software más peligrosas de MITRE (MITRE Top 25). Hay dos razones principales por las que utilizamos múltiples CWE en las categorías. En primer lugar, no todas las CWE existen en todos los lenguajes de programación o marcos de trabajo. Esto causa problemas para las herramientas y los programas de formación/concienciación, ya que parte del Top Ten puede no ser aplicable. La segunda razón es que existen múltiples CWE para vulnerabilidades comunes. Por ejemplo, hay múltiples CWE para Inyección general, Inyección de Comandos, Secuencia de Comandos en Sitios Cruzados, Contraseñas Codificadas (*Hardcoded Passwords*), Falta de Validación, Desbordamientos de Búfer (*Buffer Overflows*), Almacenamiento de Información Sensible en Texto Claro y muchas otras. Dependiendo de la organización o del evaluador, se pueden utilizar diferentes CWE. Al utilizar una categoría con múltiples CWE, podemos ayudar a elevar el nivel base y la concienciación sobre los diferentes tipos de debilidades que pueden ocurrir bajo un nombre de categoría común. En esta edición del Top Ten 2025, hay 248 CWE dentro de las 10 categorías. Hay un total de 968 CWE en el [diccionario descargable de MITRE](https://cwe.mitre.org) en el momento de este lanzamiento. + + +## Cómo se utilizan los datos para seleccionar las categorías + +Al igual que hicimos para la edición de 2021, aprovechamos los datos de CVE para la *Explotabilidad* y el *Impacto (Técnico)*. Descargamos OWASP Dependency Check y extrajimos las puntuaciones de Explotación e Impacto de CVSS (*Common Vulnerability Scoring System*), agrupándolas por las CWE relevantes listadas con los CVE. Requirió bastante investigación y esfuerzo, ya que todos los CVE tienen puntuaciones de CVSSv2, pero existen fallas en CVSSv2 que CVSSv3 debería abordar. A partir de cierto momento, a todos los CVE se les asigna también una puntuación CVSSv3. Además, los rangos de puntuación y las fórmulas se actualizaron entre CVSSv2 y CVSSv3. + +En CVSSv2, tanto la Explotación como el Impacto (Técnico) podían ser de hasta 10.0, pero la fórmula los reducía al 60% para Explotación y al 40% para Impacto. En CVSSv3, el máximo teórico se limitó a 6,0 para Explotación y 4,0 para Impacto. Teniendo en cuenta la ponderación, la puntuación de Impacto se desplazó hacia arriba, casi un punto y medio de media en CVSSv3, y la explotabilidad se desplazó casi medio punto hacia abajo de media. + +Existen aproximadamente 175.000 registros (frente a los 125.000 de 2021) de CVE mapeados a CWE en la Base de Datos Nacional de Vulnerabilidades (NVD, *National Vulnerability Database*), extraídos de OWASP Dependency Check. Además, hay 643 CWE únicas mapeadas a CVE (frente a las 241 de 2021). Dentro de los casi 220.000 CVE que se extrajeron, 160.000 tenían puntuaciones CVSS v2, 156.000 tenían puntuaciones CVSS v3 y 6.000 tenían puntuaciones CVSS v4. Muchos CVE tienen múltiples puntuaciones, razón por la cual el total es superior a 220.000. + +Para el Top Ten 2025, calculamos las puntuaciones medias de explotación e impacto de la siguiente manera. Agrupamos todos los CVE con puntuaciones CVSS por CWE y ponderamos tanto las puntuaciones de explotación como las de impacto por el porcentaje de la población que tenía CVSSv3, así como la población restante con puntuaciones CVSSv2, para obtener una media global. Mapeamos estos promedios a las CWE en el conjunto de datos para utilizarlos como puntuación de Explotación e Impacto (Técnico) para la otra mitad de la ecuación de riesgo. + +¿Por qué no utilizar CVSS v4.0?, se preguntarán. Esto se debe a que el algoritmo de puntuación cambió fundamentalmente y ya no proporciona fácilmente las puntuaciones de *Explotación* o *Impacto* como lo hacen CVSS v2 y CVSSv3. Intentaremos encontrar una manera de utilizar la puntuación CVSS v4.0 para futuras versiones del Top Ten, pero no pudimos determinar una manera oportuna de hacerlo para la edición de 2025. + + +## Por qué utilizamos una encuesta comunitaria + +Los resultados en los datos se limitan en gran medida a lo que la industria puede probar de forma automatizada. Hable con un profesional veterano de AppSec y le hablará de cosas que encuentra y tendencias que ve que aún no están en los datos. Se necesita tiempo para que la gente desarrolle metodologías de prueba para ciertos tipos de vulnerabilidades y luego más tiempo para que esas pruebas se automaticen y se ejecuten contra una gran población de aplicaciones. Todo lo que encontramos es mirar hacia el pasado y podría estar omitiendo tendencias del último año que no están presentes en los datos. + +Por lo tanto, solo seleccionamos ocho de las diez categorías a partir de los datos porque están incompletos. Las otras dos categorías provienen de la encuesta comunitaria del Top 10. Permite a los profesionales que están en primera línea votar por lo que consideran los riesgos más altos que podrían no estar en los datos (y que quizá nunca se expresen en datos). + + +## Gracias a nuestros colaboradores de datos + +Las siguientes organizaciones (junto con varios donantes anónimos) donaron amablemente datos de más de 2,8 millones de aplicaciones para hacer de este el conjunto de datos de seguridad de aplicaciones más grande y completo. Sin ustedes, esto no sería posible. + +* Accenture (Praga) +* Anónimo (múltiples) +* Bugcrowd +* Contrast Security +* CryptoNet Labs +* Intuitor SoftTech Services +* Orca Security +* Probely +* Semgrep +* Sonar +* usd AG +* Veracode +* Wallarm + +## Autores Principales +* Andrew van der Stock - X: [@vanderaj](https://x.com/vanderaj) +* Brian Glas - X: [@infosecdad](https://x.com/infosecdad) +* Neil Smithline - X: [@appsecneil](https://x.com/appsecneil) +* Tanya Janca - X: [@shehackspurple](https://x.com/shehackspurple) +* Torsten Gigler - Mastodon: [@torsten_gigler@infosec.exchange](https://infosec.exchange/@torsten_gigler) + +## Registro de problemas y solicitudes de incorporación de cambios (*pull requests*) + +Por favor, registre cualquier corrección o problema: + +### Enlaces del proyecto: +* [Página principal](https://owasp.org/www-project-top-ten/) +* [Repositorio de GitHub](https://github.com/OWASP/Top10) diff --git a/2025/docs/es/0x01_2025-About_OWASP.md b/2025/docs/es/0x01_2025-About_OWASP.md new file mode 100644 index 000000000..e0b2a71c7 --- /dev/null +++ b/2025/docs/es/0x01_2025-About_OWASP.md @@ -0,0 +1,35 @@ +# Acerca de OWASP + +El Proyecto Abierto Global de Seguridad de Aplicaciones (OWASP, por sus siglas en inglés: *Open Worldwide Application Security Project*) es una comunidad abierta dedicada a permitir que las organizaciones desarrollen, adquieran y mantengan aplicaciones y API en las que se pueda confiar. + +En OWASP, encontrará recursos gratuitos y abiertos: + +- Herramientas y estándares de seguridad de aplicaciones. +- Investigación de vanguardia. +- Controles de seguridad y bibliotecas estándar. +- Libros completos sobre pruebas de seguridad de aplicaciones, desarrollo de código seguro y revisión de código seguro. +- Presentaciones y [vídeos](https://www.youtube.com/user/OWASPGLOBAL). +- [Guías de referencia rápida](https://cheatsheetseries.owasp.org/) sobre varios temas comunes. +- [Reuniones de capítulos](https://owasp.org/chapters/) celebradas en todo el mundo y en línea. +- [Eventos, formación y conferencias](https://owasp.org/events/). +- [Google Groups](https://groups.google.com/g/owasp). + +Obtenga más información en: [https://owasp.org](https://owasp.org). + +Todas las herramientas, documentos, vídeos, presentaciones y capítulos de OWASP son gratuitos y están abiertos a cualquier persona interesada en mejorar la seguridad de las aplicaciones. + +Abogamos por abordar la seguridad de las aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más eficaces para la seguridad de las aplicaciones requieren mejoras en todas estas áreas. + +OWASP es un tipo de organización diferente. Nuestra libertad de presiones comerciales nos permite proporcionar información imparcial, práctica y rentable sobre la seguridad de las aplicaciones. + +OWASP no está afiliada a ninguna empresa tecnológica, aunque apoyamos el uso informado de la tecnología de seguridad comercial. OWASP produce muchos tipos de materiales de forma colaborativa, transparente y abierta. + +La Fundación OWASP es la entidad sin ánimo de lucro que garantiza el éxito del proyecto a largo plazo. Casi todas las personas asociadas con OWASP son voluntarias, incluidos la junta directiva de OWASP, los líderes de capítulos, los líderes de proyectos y los miembros de proyectos. Apoyamos la investigación innovadora en seguridad con becas e infraestructura. + +¡Únase a nosotros! + +## Derechos de autor y licencia + +![Licencia](../assets/license.png) + +Copyright © 2003-2025 The OWASP® Foundation, Inc. Este documento se publica bajo la licencia Creative Commons Attribution Share-Alike 4.0. Para cualquier reutilización o distribución, debe dejar claros a los demás los términos de la licencia de este trabajo. diff --git a/2025/docs/es/0x02_2025-What_are_Application_Security_Risks.md b/2025/docs/es/0x02_2025-What_are_Application_Security_Risks.md new file mode 100644 index 000000000..e53fcff6f --- /dev/null +++ b/2025/docs/es/0x02_2025-What_are_Application_Security_Risks.md @@ -0,0 +1,103 @@ +# ¿Qué son los Riesgos de Seguridad de Aplicaciones? +Los atacantes pueden utilizar potencialmente muchos caminos diferentes a través de su aplicación para dañar a su empresa u organización. Cada una de estas vías plantea un riesgo potencial que debe ser investigado. + +![Diagrama de cálculo](../assets/2025-algorithm-diagram.png) + + + + + + + + + + + + + + + + + + +
+ Agentes de Amenaza + + Vectores de Ataque + + Explotabilidad + + Probabilidad de Ausencia de Controles +

+ + de Seguridad +

+ Impactos Técnicos + + Impactos de Negocio +
+ Por entorno, dinámicos según el panorama de la situación + + Por exposición de la Aplicación (por entorno) + + Promedio Ponderado de Explotación + + Controles Ausentes por tasa media de Incidencia Ponderada por cobertura + + Promedio Ponderado de Impacto + + Por Negocio +
+ + +En nuestra Calificación de Riesgo hemos tenido en cuenta los parámetros universales de explotabilidad, la probabilidad media de ausencia de controles de seguridad para una debilidad y sus impactos técnicos. + +Cada organización es única, al igual que los actores de amenazas para esa organización, sus objetivos y el impacto de cualquier brecha de seguridad. Si una organización de interés público utiliza un sistema de gestión de contenidos (CMS) para información pública y un sistema de salud utiliza exactamente el mismo CMS para registros médicos sensibles, los actores de amenazas y los impactos de negocio pueden ser muy diferentes para el mismo software. Es fundamental comprender el riesgo para su organización basándose en la exposición de la aplicación, los agentes de amenaza aplicables según el panorama de la situación (para ataques dirigidos y no dirigidos por negocio y ubicación) y los impactos de negocio individuales. + + +## Cómo se utilizan los datos para seleccionar y clasificar las categorías + +En 2017, seleccionamos las categorías por tasa de incidencia para determinar la probabilidad, y luego las clasificamos mediante una discusión del equipo basada en décadas de experiencia para Explotabilidad, Detectabilidad (también probabilidad) e Impacto Técnico. Para 2021, utilizamos datos de Explotabilidad e Impacto (Técnico) de las puntuaciones CVSSv2 y CVSSv3 en la Base de Datos Nacional de Vulnerabilidades (NVD). Para 2025, continuamos con la misma metodología que creamos en 2021. + +Descargamos OWASP Dependency Check y extrajimos las puntuaciones de Explotación e Impacto de CVSS agrupadas por CWE relacionadas. Requirió bastante investigación y esfuerzo, ya que todos los CVE tienen puntuaciones CVSSv2, pero existen fallas en CVSSv2 que CVSSv3 debería abordar. A partir de cierto momento, a todos los CVE se les asigna también una puntuación CVSSv3. Además, los rangos de puntuación y las fórmulas se actualizaron entre CVSSv2 y CVSSv3. + +En CVSSv2, tanto la Explotación como el Impacto (Técnico) podían ser de hasta 10.0, pero la fórmula los reducía al 60% para Explotación y al 40% para Impacto. En CVSSv3, el máximo teórico se limitó a 6,0 para Explotación y 4,0 para Impacto. Teniendo en cuenta la ponderación, la puntuación de Impacto se desplazó hacia arriba, casi un punto y medio de media en CVSSv3, y la explotabilidad se desplazó casi medio punto hacia abajo de media cuando realizamos el análisis para el Top Ten de 2021. + +Existen aproximadamente 175.000 registros (frente a los 125.000 de 2021) de CVE mapeados a CWE en la Base de Datos Nacional de Vulnerabilidades (NVD), extraídos de OWASP Dependency Check. Además, hay 643 CWE únicas mapeadas a CVE (frente a las 241 de 2021). Dentro de los casi 220.000 CVE que se extrajeron, 160.000 tenían puntuaciones CVSS v2, 156.000 tenían puntuaciones CVSS v3 y 6.000 tenían puntuaciones CVSS v4. Muchos CVE tienen múltiples puntuaciones, razón por la cual el total es superior a 220.000. + +Para el Top Ten 2025, calculamos las puntuaciones medias de explotación e impacto de la siguiente manera. Agrupamos todos los CVE con puntuaciones CVSS por CWE y ponderamos tanto las puntuaciones de explotación como las de impacto por el porcentaje de la población que tenía CVSSv3, así como la población restante con puntuaciones CVSSv2, para obtener una media global. Mapeamos estos promedios a las CWE en el conjunto de datos para utilizarlos como puntuación de Explotación e Impacto (Técnico) para la otra mitad de la ecuación de riesgo. + +¿Por qué no utilizar CVSS v4.0?, se preguntarán. Esto se debe a que el algoritmo de puntuación cambió fundamentalmente y ya no proporciona fácilmente las puntuaciones de *Explotación* o *Impacto* como lo hacen CVSSv2 y CVSSv3. Intentaremos encontrar una manera de utilizar la puntuación CVSS v4.0 para futuras versiones del Top Ten, pero no pudimos determinar una manera oportuna de hacerlo para la edición de 2025. + +Para la tasa de incidencia, calculamos el porcentaje de aplicaciones vulnerables a cada CWE a partir de la población analizada por una organización durante un periodo de tiempo. Como recordatorio, no estamos utilizando la frecuencia (o cuántas veces aparece un problema en una aplicación), nos interesa qué porcentaje de la población de aplicaciones se encontró que tenía cada CWE. + +Para la cobertura, observamos el porcentaje de aplicaciones probadas por todas las organizaciones para una CWE determinada. Cuanto mayor sea la cobertura calculada, mayor será la seguridad de que la tasa de incidencia es precisa, ya que el tamaño de la muestra es más representativo de la población. + +La fórmula que utilizamos para esta iteración es similar a la de 2021, con algunos cambios en la ponderación: +(Tasa de Incidencia Máxima % * 1000) + (Cobertura Máxima % * 100) + (Promedio de Explotación * 10) + (Promedio de Impacto * 20) + (Suma de Ocurrencias / 10000) = Puntuación de Riesgo + +Las puntuaciones calculadas oscilaron entre 621,60 para la categoría de Pérdida de Control de Acceso y 271,08 para Errores de Gestión de Memoria. + +Este no es un sistema perfecto, pero es valioso para clasificar las categorías de riesgo. + +Un desafío adicional que está creciendo es la definición de una "aplicación". A medida que la industria se desplaza hacia diferentes arquitecturas compuestas por microservicios y otras implementaciones que son más pequeñas que una aplicación tradicional, los cálculos son más difíciles. Por ejemplo, si una organización está probando repositorios de código, ¿qué considera una aplicación? Al igual que el crecimiento de CVSSv4, la próxima edición del Top Ten podría necesitar ajustar el análisis y la puntuación para tener en cuenta una industria en constante cambio. + +## Factores de Datos + +Existen factores de datos que se enumeran para cada una de las categorías del Top Ten; esto es lo que significan: + +**CWE Mapeadas:** El número de CWE mapeadas a una categoría por el equipo del Top Ten. + +**Tasa de Incidencia:** La tasa de incidencia es el porcentaje de aplicaciones vulnerables a esa CWE de la población analizada por esa organización para ese año. + +**Explotación Ponderada:** La subpuntuación de Explotación de las puntuaciones CVSSv2 y CVSSv3 asignadas a los CVE mapeados a las CWE, normalizada y colocada en una escala de 10 puntos. + +**Impacto Ponderado:** La subpuntuación de Impacto de las puntuaciones CVSSv2 y CVSSv3 asignadas a los CVE mapeados a las CWE, normalizada y colocada en una escala de 10 puntos. + +**Cobertura (de Pruebas):** El porcentaje de aplicaciones probadas por todas las organizaciones para una CWE determinada. + +**Ocurrencias Totales:** Número total de aplicaciones que se encontró que tenían las CWE mapeadas a una categoría. + +**CVE Totales:** Número total de CVE en la base de datos NVD que fueron mapeados a las CWE mapeadas a una categoría. + +**Fórmula:** (Tasa de Incidencia Máxima % * 1000) + (Cobertura Máxima % * 100) + (Promedio de Explotación * 10) + (Promedio de Impacto * 20) + (Suma de Ocurrencias / 10000) = Puntuación de Riesgo diff --git a/2025/docs/es/0x03_2025-Establishing_a_Modern_Application_Security_Program.md b/2025/docs/es/0x03_2025-Establishing_a_Modern_Application_Security_Program.md new file mode 100644 index 000000000..d2a717ca3 --- /dev/null +++ b/2025/docs/es/0x03_2025-Establishing_a_Modern_Application_Security_Program.md @@ -0,0 +1,303 @@ +# Establecimiento de un Programa Moderno de Seguridad de Aplicaciones + +Las listas del OWASP Top Ten son documentos de concienciación, destinados a llamar la atención sobre los riesgos más críticos de cualquier tema que cubran. No pretenden ser una lista completa, sino solo un punto de partida. En versiones anteriores de esta lista, hemos prescrito el inicio de un programa de seguridad de aplicaciones como la mejor manera de evitar estos riesgos, y más. En esta sección cubriremos cómo iniciar y construir un programa moderno de seguridad de aplicaciones. + +Si ya dispone de un programa de seguridad de aplicaciones, considere realizar una evaluación de madurez del mismo utilizando [OWASP SAMM (Software Assurance Maturity Model)](https://owasp.org/www-project-samm/) o DSOMM (DevSecOps Maturity Model). Estos modelos de madurez son integrales y exhaustivos, y pueden utilizarse para ayudarle a determinar dónde debe centrar mejor sus esfuerzos para ampliar y madurar su programa. Tenga en cuenta que no es necesario hacer todo lo que figura en OWASP SAMM o DSOMM para realizar un buen trabajo; su propósito es guiarle y ofrecerle muchas opciones. No pretenden ofrecer estándares inalcanzables ni describir programas inasumibles. Son amplios para ofrecerle muchas ideas y opciones. + +Si está iniciando un programa desde cero, o si considera que OWASP SAMM o DSOMM son "demasiado" para su equipo en este momento, por favor revise los siguientes consejos. + + +### 1. Establecer un enfoque de cartera basado en el riesgo: + +* Identifique las necesidades de protección de su cartera de aplicaciones desde una perspectiva de negocio. Esto debe estar impulsado, en parte, por las leyes de privacidad y otras regulaciones relevantes para el activo de datos que se protege. + +* Establezca un [modelo común de calificación de riesgos](https://owasp.org/www-community/OWASP_Risk_Rating_Methodology) con un conjunto consistente de factores de probabilidad e impacto que reflejen la tolerancia al riesgo de su organización. + + +* Mida y priorice en consecuencia todas sus aplicaciones y API. Añada los resultados a su [Base de Datos de Gestión de Configuración (CMDB, *Configuration Management Database*)](https://es.wikipedia.org/wiki/Base_de_datos_de_gesti%C3%B3n_de_configuraci%C3%B3n). + +* Establezca pautas de aseguramiento para definir adecuadamente la cobertura y el nivel de rigor requeridos. + + +### 2. Habilitar con una base sólida: + +* Establezca un conjunto de políticas y estándares enfocados que proporcionen una línea base de seguridad de aplicaciones a la que deban adherirse todos los equipos de desarrollo. + +* Defina un conjunto común de controles de seguridad reutilizables que complementen estas políticas y estándares, y proporcione orientación de diseño y desarrollo sobre su uso. + +* Establezca un plan de estudios de formación en seguridad de aplicaciones que sea obligatorio y esté dirigido a diferentes roles y temas de desarrollo. + + +### 3. Integrar la seguridad en los procesos existentes: + +* Defina e integre actividades de implementación y verificación seguras en los procesos de desarrollo y operativos existentes. + +* Las actividades incluyen el modelado de amenazas, el diseño seguro y la revisión del diseño, la codificación segura y la revisión de código, las pruebas de penetración (*penetration testing*) y la remediación. + +* Proporcione expertos en la materia y servicios de apoyo para que los equipos de desarrollo y de proyectos tengan éxito. + +* Revise su ciclo de vida de desarrollo de sistemas (SDLC, *System Development Life Cycle*) actual y todas las actividades, herramientas, políticas y procesos de seguridad del software, y documéntelos. + +* Para el nuevo software, añada una o más actividades de seguridad a cada fase del ciclo de vida de desarrollo de sistemas. A continuación ofrecemos muchas sugerencias de lo que puede hacer. Asegúrese de realizar estas nuevas actividades en cada nuevo proyecto o iniciativa de software; de esta manera, sabrá que cada nueva pieza de software se entregará con una postura de seguridad aceptable para su organización. + +* Seleccione sus actividades para garantizar que su producto final cumpla con un nivel de riesgo aceptable para su organización. + +* Para el software existente (a veces llamado *legacy*), querrá tener un plan de mantenimiento formal; por favor, busque ideas sobre cómo mantener aplicaciones seguras en la sección llamada "Operaciones y Gestión de Cambios". + + +### 4. Educación en Seguridad de Aplicaciones: + +* Considere iniciar un programa de "campeones de seguridad" (*security champions*), o un programa general de educación en seguridad para sus desarrolladores (a veces llamado programa de promoción o de concienciación sobre seguridad), para enseñarles todo lo que desearía que supieran. Esto los mantendrá actualizados, les ayudará a saber cómo realizar su trabajo de forma segura y hará que la cultura de seguridad en su lugar de trabajo sea más positiva. A menudo, también mejora la confianza entre los equipos y facilita una relación de trabajo más satisfactoria. OWASP le apoya en esto con la [Guía de Campeones de Seguridad de OWASP](https://securitychampions.owasp.org/), que se está ampliando paso a paso. + +* El Proyecto de Educación de OWASP proporciona materiales de formación para ayudar a educar a los desarrolladores en la seguridad de las aplicaciones web. Para un aprendizaje práctico sobre vulnerabilidades, pruebe el [Proyecto OWASP Juice Shop](https://owasp.org/www-project-juice-shop/) o [OWASP WebGoat](https://owasp.org/www-project-webgoat/). Para mantenerse al día, asista a una [Conferencia OWASP AppSec](https://owasp.org/events/), a una [Formación en Conferencias OWASP](https://owasp.org/events/) o a las reuniones de su [Capítulo OWASP](https://owasp.org/chapters/) local. + + +### 5. Proporcionar visibilidad a la dirección: + +* Gestione con métricas. Impulse la mejora y las decisiones de financiación basándose en las métricas y los datos de análisis capturados. Las métricas incluyen la adherencia a las prácticas y actividades de seguridad, las vulnerabilidades introducidas, las vulnerabilidades mitigadas, la cobertura de aplicaciones, la densidad de defectos por tipo y recuento de instancias, etc. + +* Analice los datos de las actividades de implementación y verificación para buscar la causa raíz y patrones de vulnerabilidad para impulsar mejoras estratégicas y sistémicas en toda la empresa. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras. + + + +## Establecer y utilizar procesos de seguridad repetibles y controles de seguridad estándar + +### Fase de Gestión de Recursos y Requisitos: + +* Recopile y negocie los requisitos de negocio para una aplicación con el área de negocio, incluidos los requisitos de protección con respecto a la confidencialidad, autenticidad, integridad y disponibilidad de todos los activos de datos, y la lógica de negocio esperada. + +* Recopile los requisitos técnicos, incluidos los requisitos de seguridad funcionales y no funcionales. OWASP recomienda utilizar el [Estándar de Verificación de Seguridad de Aplicaciones (ASVS, *Application Security Verification Standard*) de OWASP](https://owasp.org/www-project-application-security-verification-standard/) como guía para establecer los requisitos de seguridad de su(s) aplicación(es). + +* Planifique y negocie el presupuesto que cubra todos los aspectos de diseño, construcción, pruebas y operación, incluidas las actividades de seguridad. + +* Añada actividades de seguridad al cronograma de su proyecto. + +* Preséntese como el representante de seguridad en el inicio del proyecto (*kick off*), para que sepan con quién hablar. + + +### Solicitud de Propuestas (RFP) y Contratación: + +* Negocie los requisitos con desarrolladores internos o externos, incluyendo directrices y requisitos de seguridad con respecto a su programa de seguridad, por ejemplo, SDLC, mejores prácticas. + +* Evalúe el cumplimiento de todos los requisitos técnicos, incluyendo una fase de planificación y diseño. + +* Negocie todos los requisitos técnicos, incluyendo el diseño, la seguridad y los acuerdos de nivel de servicio (SLA). + +* Adopte plantillas y listas de verificación (*checklists*), como el [Anexo de Contrato de Software Seguro de OWASP](https://owasp.org/www-community/OWASP_Secure_Software_Contract_Annex).
**Nota:** *El anexo es para el derecho contractual de EE. UU., por lo que le rogamos que consulte con un asesor legal cualificado antes de utilizar el anexo de muestra.* + + +### Fase de Planificación y Diseño: + +* Negocie la planificación y el diseño con los desarrolladores y las partes interesadas internas, por ejemplo, especialistas en seguridad. + +* Defina la arquitectura de seguridad, los controles, las contramedidas y las revisiones de diseño apropiadas para las necesidades de protección y el nivel de amenaza esperado. Esto debe contar con el apoyo de especialistas en seguridad. + +* En lugar de adaptar la seguridad a sus aplicaciones y API a posteriori, es mucho más rentable diseñar la seguridad desde el principio. OWASP recomienda las [Guías de referencia rápida de OWASP (*Cheat Sheets*)](https://cheatsheetseries.owasp.org/index.html) y los [Controles Proactivos de OWASP](https://top10proactive.owasp.org/) como un buen punto de partida para orientarse sobre cómo diseñar la seguridad incluida desde el inicio. + +* Realice el modelado de amenazas, consulte la [Guía de referencia rápida de OWASP: Modelado de Amenazas](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). + +* Enseñe a sus arquitectos de software conceptos y patrones de diseño seguro y pídales que los añadan a sus diseños siempre que sea posible. + +* Examine los flujos de datos con sus desarrolladores. + +* Añada historias de usuario de seguridad junto con todas sus otras historias de usuario. + + +### Ciclo de Vida de Desarrollo Seguro: + + +* Para mejorar el proceso que sigue su organización al construir aplicaciones y API, OWASP recomienda el [Modelo de Madurez de Aseguramiento de Software (SAMM, *Software Assurance Maturity Model*) de OWASP](https://owasp.org/www-project-samm/). Este modelo ayuda a las organizaciones a formular e implementar una estrategia de seguridad de software adaptada a los riesgos específicos a los que se enfrenta su organización. + +* Proporcione formación en codificación segura a sus desarrolladores de software, y cualquier otra formación que considere que les ayudará a crear aplicaciones más robustas y seguras. + +* Revisión de código, consulte la [Guía de referencia rápida de OWASP: Revisión de Código Seguro](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). + +* Entregue a sus desarrolladores herramientas de seguridad y enséñeles a utilizarlas, especialmente los escáneres de análisis estático (SAST), análisis de composición de software (SCA), secretos e [Infraestructura como Código (IaC, *Infrastructure-as-Code*)](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html). + +* Cree "barreras de protección" (*guardrails*) para sus desarrolladores, si es posible (salvaguardas técnicas para orientarlos hacia opciones más seguras). + +* Construir controles de seguridad fuertes y usables es difícil. Ofrezca valores predeterminados seguros siempre que sea posible, y cree "caminos pavimentados" (*paved roads* — hacer que la forma más fácil sea también la más segura de hacer algo, la opción preferida obvia) siempre que sea posible. Las [Guías de referencia rápida de OWASP (*Cheat Sheets*)](https://cheatsheetseries.owasp.org/index.html) son un buen punto de partida para los desarrolladores, y muchos marcos de trabajo modernos vienen ahora con controles de seguridad estándar y efectivos para la autorización, validación, prevención de CSRF, etc. + +* Entregue a sus desarrolladores complementos (*plugins*) de IDE relacionados con la seguridad y anímelos a usarlos. + +* Proporcióneles una herramienta de gestión de secretos, licencias y documentación sobre cómo utilizarla. + +* Proporcióneles una IA privada para su uso, idealmente configurada con un servidor RAG lleno de documentación de seguridad útil, *prompts* que su equipo haya escrito para obtener mejores resultados y un servidor MCP que llame a las herramientas de seguridad preferidas de su organización. Enséñeles a utilizar la IA de forma segura, porque lo van a hacer tanto si le gusta como si no. + + +### Establecer Pruebas Continuas de Seguridad de Aplicaciones: + +* Pruebe las funciones técnicas y la integración con la arquitectura de TI y coordine las pruebas de negocio. + +* Cree casos de prueba de "uso" y "abuso" desde las perspectivas técnica y de negocio. + +* Gestione las pruebas de seguridad de acuerdo con los procesos internos, las necesidades de protección y el nivel de amenaza asumido por la aplicación. + +* Proporcione herramientas de pruebas de seguridad (*fuzzers*, DAST, etc.), un lugar seguro para realizar las pruebas y formación sobre cómo usarlas, O realice las pruebas por ellos, O contrate a un evaluador. + +* Si requiere un alto nivel de aseguramiento, considere una prueba de penetración formal, así como pruebas de estrés y de rendimiento. + +* Trabaje con sus desarrolladores para ayudarles a decidir qué deben corregir de los informes de errores, y asegúrese de que sus gerentes les den tiempo para hacerlo. + + +### Despliegue: + +* Ponga la aplicación en funcionamiento y migre desde aplicaciones utilizadas anteriormente si es necesario. + +* Finalice toda la documentación, incluida la base de datos de gestión de cambios (CMDB) y la arquitectura de seguridad. + + +### Operaciones y Gestión de Cambios: + +* Las operaciones deben incluir directrices para la gestión de la seguridad de la aplicación (por ejemplo, gestión de parches). + +* Aumente la concienciación sobre seguridad de los usuarios y gestione los conflictos entre usabilidad y seguridad. + +* Planifique y gestione los cambios, por ejemplo, la migración a nuevas versiones de la aplicación u otros componentes como el sistema operativo, el *middleware* y las bibliotecas. + +* Asegúrese de que todas las aplicaciones estén en su inventario, con todos los detalles importantes documentados. Actualice toda la documentación, incluyendo la de la CMDB y la arquitectura de seguridad, los controles y las contramedidas, así como cualquier manual de procedimientos (*runbook*) o documentación del proyecto. + +* Realice el registro, el monitoreo y las alertas para todas las aplicaciones. Añádalo si falta. + +* Cree procesos para una actualización y aplicación de parches eficaces y eficientes. + +* Establezca programas de escaneo regulares (idealmente dinámico, estático, de secretos, IaC y de análisis de composición de software). + +* Acuerdos de Nivel de Servicio (SLA) para la corrección de errores de seguridad. + +* Proporcione una forma para que los empleados (e idealmente también sus clientes) informen sobre errores. + +* Establezca un equipo de respuesta a incidentes capacitado que comprenda cómo son los ataques de software y que cuente con herramientas de observabilidad. + +* Ejecute herramientas de bloqueo o protección para detener ataques automatizados. + +* Refuerzo de configuraciones (*hardening*) anual (o más frecuente). + +* Pruebas de penetración al menos anuales (dependiendo del nivel de aseguramiento requerido para su aplicación). + +* Establezca procesos y herramientas para reforzar y proteger su cadena de suministro de software. + +* Establezca y actualice la planificación de la continuidad del negocio y la recuperación ante desastres que incluya sus aplicaciones más importantes y las herramientas que utiliza para mantenerlas. + + +### Retirada de Sistemas: + +* Cualquier dato requerido debe ser archivado. Todos los demás datos deben ser borrados de forma segura. + +* Retire la aplicación de forma segura, incluyendo la eliminación de cuentas, roles y permisos no utilizados. + +* Establezca el estado de su aplicación como retirado en la CMDB. + + +## Uso del OWASP Top 10 como estándar + +El OWASP Top 10 es principalmente un documento de concienciación. Sin embargo, esto no ha impedido que las organizaciones lo utilicen como un estándar de AppSec de facto en la industria desde su creación en 2003. Si desea utilizar el OWASP Top 10 como un estándar de codificación o de pruebas, sepa que es el mínimo indispensable y solo un punto de partida. + +Una de las dificultades de utilizar el OWASP Top 10 como estándar es que documentamos riesgos de AppSec, y no necesariamente problemas fácilmente comprobables. Por ejemplo, [A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md) está fuera del alcance de la mayoría de las formas de prueba. Otro ejemplo es comprobar si se han implementado registros y monitoreo eficaces en el lugar de uso, lo cual solo puede hacerse mediante entrevistas y solicitando un muestreo de respuestas a incidentes efectivas. Una herramienta de análisis de código estático puede buscar la ausencia de registros, pero puede ser imposible determinar si la lógica de negocio o el control de acceso están registrando brechas de seguridad críticas. Los evaluadores de penetración solo pueden determinar que han invocado la respuesta a incidentes en un entorno de prueba, que rara vez se monitorea de la misma manera que el de producción. + +He aquí nuestras recomendaciones sobre cuándo es apropiado utilizar el OWASP Top 10: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Caso de Uso + OWASP Top 10 2025 + Estándar de Verificación de Seguridad de Aplicaciones de OWASP (ASVS) +
Concienciación + Sí + +
Formación + Nivel de entrada + Integral +
Diseño y arquitectura + Ocasionalmente + Sí +
Estándar de codificación + Mínimo indispensable + Sí +
Revisión de Código Seguro + Mínimo indispensable + Sí +
Lista de comprobación de revisión por pares + Mínimo indispensable + Sí +
Pruebas unitarias + Ocasionalmente + Sí +
Pruebas de integración + Ocasionalmente + Sí +
Pruebas de penetración + Mínimo indispensable + Sí +
Soporte de herramientas + Mínimo indispensable + Sí +
Cadena de Suministro Segura + Ocasionalmente + Sí +
+ + +Alentamos a cualquiera que desee adoptar un estándar de seguridad de aplicaciones a utilizar el [Estándar de Verificación de Seguridad de Aplicaciones (ASVS) de OWASP](https://owasp.org/www-project-application-security-verification-standard/), ya que está diseñado para ser verificable y probado, y puede utilizarse en todas las partes de un ciclo de vida de desarrollo seguro. + +El ASVS es la única opción aceptable para los proveedores de herramientas. Las herramientas no pueden detectar, probar o proteger de forma integral contra el OWASP Top 10 debido a la naturaleza de varios de sus riesgos, con referencia a [A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md). OWASP desaconseja cualquier afirmación de cobertura total del OWASP Top 10, porque es sencillamente falsa. diff --git a/2025/docs/es/A01_2025-Broken_Access_Control.md b/2025/docs/es/A01_2025-Broken_Access_Control.md new file mode 100644 index 000000000..2ed5344c4 --- /dev/null +++ b/2025/docs/es/A01_2025-Broken_Access_Control.md @@ -0,0 +1,224 @@ +# A01:2025 Pérdida de Control de Acceso (Broken Access Control) ![icon](../assets/TOP_10_Icons_Final_Broken_Access_Control.png){: style="height:80px;width:80px" align="right"} + + + +## Antecedentes + +Manteniendo su posición en el #1 del Top Ten, se encontró que el 100% de las aplicaciones probadas tenían alguna forma de pérdida de control de acceso. Los CWE notables incluidos son *CWE-200: Exposición de Información Sensible a un Actor no Autorizado*, *CWE-201: Exposición de Información Sensible a Través de Datos Enviados*, *CWE-918: Falsificación de Solicitud del Lado del Servidor (SSRF)*, y *CWE-352: Falsificación de Solicitud en Sitios Cruzados (CSRF)*. Esta categoría tiene el mayor número de ocurrencias en los datos aportados y el segundo número más alto de CVE relacionados. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWE Mapeados + Tasa de Incidencia Máx. + Tasa de Incidencia Prom. + Cobertura Máx. + Cobertura Prom. + Explotación Ponderada Prom. + Impacto Ponderado Prom. + Ocurrencias Totales + CVE Totales +
40 + 20.15% + 3.74% + 100.00% + 42.93% + 7.04 + 3.84 + 1,839,701 + 32,654 +
+ + + +## Descripción + +El control de acceso aplica políticas de tal manera que los usuarios no puedan actuar fuera de sus permisos previstos. Las fallas suelen conducir a la divulgación no autorizada de información, la modificación o destrucción de todos los datos, o la ejecución de una función de negocio fuera de los límites del usuario. Las vulnerabilidades comunes de control de acceso incluyen: + + + +* Violación del principio de mínimo privilegio, comúnmente conocido como denegar por defecto, donde el acceso solo debe otorgarse para capacidades, roles o usuarios específicos, pero está disponible para cualquier persona. +* Elusión de los controles de acceso mediante la modificación de la URL (manipulación de parámetros o navegación forzada), el estado interno de la aplicación o la página HTML, o mediante el uso de una herramienta de ataque que modifique las solicitudes a la API. +* Permitir ver o editar la cuenta de otra persona proporcionando su identificador único (referencias directas inseguras a objetos o Insecure Direct Object References, IDOR). +* Una API accesible con falta de controles de acceso para POST, PUT y DELETE. +* Elevación de privilegio. Actuar como un usuario sin haber iniciado sesión o ganar privilegios más allá de los esperados para el usuario autenticado (por ejemplo, acceso de administrador). +* Manipulación de metadatos, como la repetición o manipulación de un token de control de acceso JSON Web Token (JWT), una cookie o un campo oculto manipulado para elevar privilegios, o el abuso de la invalidación de JWT. +* La desconfiguración de CORS permite el acceso a la API desde orígenes no autorizados o no confiables. +* Navegación forzada (adivinar URLs) hacia páginas autenticadas como un usuario no autenticado o hacia páginas privilegiadas como un usuario estándar. + + +## Cómo prevenir + +El control de acceso solo es efectivo cuando se implementa en código del lado del servidor de confianza o en APIs sin servidor (serverless), donde el atacante no puede modificar la comprobación del control de acceso o los metadatos. + + + +* Excepto para recursos públicos, denegar por defecto. +* Implementar mecanismos de control de acceso una sola vez y reutilizarlos en toda la aplicación, incluyendo la minimización del uso del Intercambio de Recursos de Origen Cruzado (Cross-Origin Resource Sharing, CORS). +* Los controles de acceso del modelo deben imponer la propiedad de los registros en lugar de permitir que los usuarios creen, lean, actualicen o eliminen cualquier registro. +* Los requisitos únicos de límites de negocio de la aplicación deben ser aplicados por los modelos de dominio. +* Desactivar el listado de directorios del servidor web y asegurarse de que los metadatos de los archivos (por ejemplo, .git) y los archivos de respaldo no estén presentes dentro de las raíces web. +* Registrar las fallas de control de acceso, alertar a los administradores cuando sea apropiado (por ejemplo: fallas repetidas). +* Implementar límites de tasa (límites de velocidad - rate limits) en el acceso a la API y a los controladores para minimizar el daño de las herramientas de ataque automatizadas. +* Los identificadores de sesión con estado deben invalidarse en el servidor tras el cierre de sesión. Los tokens JWT sin estado deben ser de corta duración para minimizar la ventana de oportunidad de un atacante. Para JWT de mayor duración, considere el uso de tokens de actualización (refresh tokens) y siga los estándares de OAuth para revocar el acceso. +* Utilizar kits de herramientas o patrones bien establecidos que proporcionen controles de acceso sencillos y declarativos. + +Los desarrolladores y el personal de control de calidad (QA) deben incluir el control de acceso funcional en sus pruebas unitarias y de integración. + + +## Escenarios de ejemplo de ataque + +**Escenario #1:** La aplicación utiliza datos no verificados en una llamada SQL que accede a la información de la cuenta: + + +``` +pstmt.setString(1, request.getParameter("acct")); +ResultSet results = pstmt.executeQuery( ); +``` + + +Un atacante puede simplemente modificar el parámetro 'acct' del navegador para enviar cualquier número de cuenta deseado. Si no se verifica correctamente, el atacante puede acceder a la cuenta de cualquier usuario. + + +``` +https://example.com/app/accountInfo?acct=notmyacct +``` + + +**Escenario #2:** Un atacante simplemente fuerza a los navegadores a dirigirse a URLs específicas. Se requieren derechos de administrador para acceder a la página de administración. + + +``` +https://example.com/app/getappInfo +https://example.com/app/admin_getappInfo +``` + + +Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si un usuario que no es administrador puede acceder a la página de administración, esto es una falla. + +**Escenario #3:** Una aplicación pone todo su control de acceso en su front-end. Aunque el atacante no puede llegar a `https://example.com/app/admin_getappInfo` debido al código JavaScript que se ejecuta en el navegador, simplemente puede ejecutar: + + +``` +$ curl https://example.com/app/admin_getappInfo +``` + + +desde la línea de comandos. + + +## Referencias + +* [Controles Proactivos de OWASP: C1: Implementar Control de Acceso](https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/) +* [Estándar de Verificación de Seguridad en Aplicaciones de OWASP: V8 Autorización](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md) +* [Guía de Pruebas de OWASP: Pruebas de Autorización](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/README) +* [Guía de referencia rápida de OWASP: Autorización](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) +* [PortSwigger: Explotación de la desconfiguración de CORS](https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties) +* [OAuth: Revocación de Acceso](https://www.oauth.com/oauth2-servers/listing-authorizations/revoking-access/) + + +## Lista de CWE Mapeados + +* [CWE-22 Limitación Inadecuada de un Nombre de Ruta a un Directorio Restringido ('Salto de Directorio' / 'Path Traversal')](https://cwe.mitre.org/data/definitions/22.html) + +* [CWE-23 Salto de Directorio Relativo (Relative Path Traversal)](https://cwe.mitre.org/data/definitions/23.html) + +* [CWE-36 Salto de Directorio Absoluto (Absolute Path Traversal)](https://cwe.mitre.org/data/definitions/36.html) + +* [CWE-59 Resolución de Enlace Inadecuada Antes del Acceso al Archivo ('Seguimiento de Enlaces') (Improper Link Resolution Before File Access ('Link Following'))](https://cwe.mitre.org/data/definitions/59.html) + +* [CWE-61 Seguimiento de Enlaces Simbólicos (Symlink) en UNIX (UNIX Symbolic Link (Symlink) Following)](https://cwe.mitre.org/data/definitions/61.html) + +* [CWE-65 Enlace Rígido en Windows (Windows Hard Link)](https://cwe.mitre.org/data/definitions/65.html) + +* [CWE-200 Exposición de Información Sensible a un Actor no Autorizado (Exposure of Sensitive Information to an Unauthorized Actor)](https://cwe.mitre.org/data/definitions/200.html) + +* [CWE-201 Exposición de Información Sensible a Través de Datos Enviados (Insertion of Sensitive Information Into Sent Data)](https://cwe.mitre.org/data/definitions/201.html) + +* [CWE-219 Almacenamiento de Archivo con Datos Sensibles Bajo la Raíz Web (Storage of File with Sensitive Data Under Web Root)](https://cwe.mitre.org/data/definitions/219.html) + +* [CWE-276 Permisos por Defecto Incorrectos (Incorrect Default Permissions)](https://cwe.mitre.org/data/definitions/276.html) + +* [CWE-281 Preservación Inadecuada de Permisos (Improper Preservation of Permissions)](https://cwe.mitre.org/data/definitions/281.html) + +* [CWE-282 Gestión Inadecuada de la Propiedad (Improper Ownership Management)](https://cwe.mitre.org/data/definitions/282.html) + +* [CWE-283 Propiedad no Verificada (Unverified Ownership)](https://cwe.mitre.org/data/definitions/283.html) + +* [CWE-284 Control de Acceso Inadecuado (Improper Access Control)](https://cwe.mitre.org/data/definitions/284.html) + +* [CWE-285 Autorización Inadecuada (Improper Authorization)](https://cwe.mitre.org/data/definitions/285.html) + +* [CWE-352 Falsificación de Solicitud en Sitios Cruzados (Cross-Site Request Forgery (CSRF))](https://cwe.mitre.org/data/definitions/352.html) + +* [CWE-359 Exposición de Información Personal Privada a un Actor no Autorizado (Exposure of Private Personal Information to an Unauthorized Actor)](https://cwe.mitre.org/data/definitions/359.html) + +* [CWE-377 Archivo Temporal Inseguro (Insecure Temporary File)](https://cwe.mitre.org/data/definitions/377.html) + +* [CWE-379 Creación de Archivo Temporal en Directorio con Permisos Inseguros (Creation of Temporary File in Directory with Insecure Permissions)](https://cwe.mitre.org/data/definitions/379.html) + +* [CWE-402 Transmisión de Recursos Privados a una Nueva Esfera ('Fuga de Recursos') (Transmission of Private Resources into a New Sphere ('Resource Leak'))](https://cwe.mitre.org/data/definitions/402.html) + +* [CWE-424 Protección Inadecuada de Ruta Alternativa (Improper Protection of Alternate Path)](https://cwe.mitre.org/data/definitions/424.html) + +* [CWE-425 Solicitud Directa ('Navegación Forzada' o 'Forced Browsing') (Direct Request ('Forced Browsing'))](https://cwe.mitre.org/data/definitions/425.html) + +* [CWE-441 Proxy o Intermediario no Intencionado ('Confused Deputy') (Unintended Proxy or Intermediary ('Confused Deputy'))](https://cwe.mitre.org/data/definitions/441.html) + +* [CWE-497 Exposición de Información Sensible del Sistema a una Esfera de Control no Autorizada (Exposure of Sensitive System Information to an Unauthorized Control Sphere)](https://cwe.mitre.org/data/definitions/497.html) + +* [CWE-538 Inserción de Información Sensible en un Archivo o Directorio Accesible Externamente (Insertion of Sensitive Information into Externally-Accessible File or Directory)](https://cwe.mitre.org/data/definitions/538.html) + +* [CWE-540 Inclusión de Información Sensible en el Código Fuente (Inclusion of Sensitive Information in Source Code)](https://cwe.mitre.org/data/definitions/540.html) + +* [CWE-548 Exposición de Información a Través del Listado de Directorios (Exposure of Information Through Directory Listing)](https://cwe.mitre.org/data/definitions/548.html) + +* [CWE-552 Archivos o Directorios Accesibles a Partes Externas (Files or Directories Accessible to External Parties)](https://cwe.mitre.org/data/definitions/552.html) + +* [CWE-566 Elusión de Autorización a Través de una Clave Primaria SQL Controlada por el Usuario (Authorization Bypass Through User-Controlled SQL Primary Key)](https://cwe.mitre.org/data/definitions/566.html) + +* [CWE-601 Redirección de URL a un Sitio no Confiable ('Redirección Abierta' u 'Open Redirect') (URL Redirection to Untrusted Site ('Open Redirect'))](https://cwe.mitre.org/data/definitions/601.html) + +* [CWE-615 Inclusión de Información Sensible en los Comentarios del Código Fuente (Inclusion of Sensitive Information in Source Code Comments)](https://cwe.mitre.org/data/definitions/615.html) + +* [CWE-639 Elusión de Autorización a Través de una Clave Controlada por el Usuario (Authorization Bypass Through User-Controlled Key)](https://cwe.mitre.org/data/definitions/639.html) + +* [CWE-668 Exposición de un Recurso a la Esfera Equivocada (Exposure of Resource to Wrong Sphere)](https://cwe.mitre.org/data/definitions/668.html) + +* [CWE-732 Asignación Incorrecta de Permisos para un Recurso Crítico (Incorrect Permission Assignment for Critical Resource)](https://cwe.mitre.org/data/definitions/732.html) + +* [CWE-749 Método o Función Peligrosa Expuesta (Exposed Dangerous Method or Function)](https://cwe.mitre.org/data/definitions/749.html) + +* [CWE-862 Falta de Autorización (Missing Authorization)](https://cwe.mitre.org/data/definitions/862.html) + +* [CWE-863 Autorización Incorrecta (Incorrect Authorization)](https://cwe.mitre.org/data/definitions/863.html) + +* [CWE-918 Falsificación de Solicitud del Lado del Servidor (Server-Side Request Forgery (SSRF))](https://cwe.mitre.org/data/definitions/918.html) + +* [CWE-922 Almacenamiento Inseguro de Información Sensible (Insecure Storage of Sensitive Information)](https://cwe.mitre.org/data/definitions/922.html) + +* [CWE-1275 Cookie Sensible con Atributo SameSite Incorrecto (Sensitive Cookie with Improper SameSite Attribute)](https://cwe.mitre.org/data/definitions/1275.html) diff --git a/2025/docs/es/A02_2025-Security_Misconfiguration.md b/2025/docs/es/A02_2025-Security_Misconfiguration.md new file mode 100644 index 000000000..c79366793 --- /dev/null +++ b/2025/docs/es/A02_2025-Security_Misconfiguration.md @@ -0,0 +1,148 @@ +# A02:2025 Configuración de Seguridad Incorrecta (Security Misconfiguration) ![icon](../assets/TOP_10_Icons_Final_Security_Misconfiguration.png){: style="height:80px;width:80px" align="right"} + + +## Antecedentes + +Subiendo desde el #5 en la edición anterior, se encontró que el 100% de las aplicaciones probadas tenían alguna forma de desconfiguración, con una tasa de incidencia promedio del 3.00% y más de 719k ocurrencias de CWE (Common Weakness Enumeration) (enumeración de Debilidades Comunes) en esta categoría de riesgo. Con el aumento del software altamente configurable, no es sorprendente ver que esta categoría ascienda. Los CWE notables incluidos son *CWE-16: Configuración* y *CWE-611: Restricción Inadecuada de Referencias a Entidades Externas XML (XML External Entity, XXE)*. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWE Mapeados + Tasa de Incidencia Máx. + Tasa de Incidencia Prom. + Cobertura Máx. + Cobertura Prom. + Explotación Ponderada Prom. + Impacto Ponderado Prom. + Ocurrencias Totales + CVE Totales +
16 + 27.70% + 3.00% + 100.00% + 52.35% + 7.96 + 3.97 + 719,084 + 1,375 +
+ + + +## Descripción + +La configuración de seguridad incorrecta ocurre cuando un sistema, aplicación o servicio en la nube se configura incorrectamente desde una perspectiva de seguridad, creando vulnerabilidades. + +La aplicación podría ser vulnerable si: + + + +* Carece de un bastionado (hardening) de seguridad adecuado en cualquier parte de la pila de la aplicación o tiene permisos configurados incorrectamente en los servicios en la nube. +* Hay funciones innecesarias habilitadas o instaladas (por ejemplo, puertos, servicios, páginas, cuentas, marcos de prueba o privilegios innecesarios). +* Las cuentas predeterminadas y sus contraseñas siguen habilitadas y sin cambios. +* Falta una configuración central para interceptar mensajes de error excesivos. El manejo de errores revela trazas de la pila (stack traces) u otros mensajes de error demasiado informativos a los usuarios. +* Para los sistemas actualizados, las últimas funciones de seguridad están desactivadas o no están configuradas de forma segura. +* Existe una priorización excesiva de la compatibilidad hacia atrás que conduce a una configuración insegura. +* Los ajustes de seguridad en los servidores de aplicaciones, frameworks de aplicaciones (por ejemplo, Struts, Spring, ASP.NET), bibliotecas, bases de datos, etc., no están establecidos en valores seguros. +* El servidor no envía cabeceras o directivas de seguridad, o estas no están establecidas en valores seguros. + +Sin un proceso de bastionado (hardening) de la configuración de seguridad de las aplicaciones que sea concertado y repetible, los sistemas corren un mayor riesgo. + + +## Cómo prevenir + +Deben implementarse procesos de instalación seguros, que incluyan: + + + +* Un proceso de bastionado (hardening) repetible que permita el despliegue rápido y sencillo de otro entorno que esté bloqueado adecuadamente. Los entornos de desarrollo, QA y producción deben estar configurados de forma idéntica, con credenciales diferentes en cada uno. Este proceso debe estar automatizado para minimizar el esfuerzo requerido para configurar un nuevo entorno seguro. +* Una plataforma mínima sin funciones, componentes, documentación o ejemplos innecesarios. Elimine o no instale funciones y frameworks que no utilice. +* Una tarea para revisar y actualizar las configuraciones de acuerdo con todas las notas de seguridad, actualizaciones y parches como parte del proceso de gestión de parches (consulte [A03 Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md)(Software Supply Chain Failures)). Revise los permisos de almacenamiento en la nube (por ejemplo, los permisos de los cubos S3). +* Una arquitectura de aplicación segmentada que proporcione una separación efectiva y segura entre componentes o inquilinos (tenants), con segmentación, contenedorización o grupos de seguridad en la nube (ACLs). +* Envío de directivas de seguridad a los clientes, por ejemplo, Cabeceras de Seguridad (Security Headers). +* Un proceso automatizado para verificar la eficacia de las configuraciones y ajustes en todos los entornos. +* Añadir proactivamente una configuración central para interceptar mensajes de error excesivos como medida de respaldo. +* Si estas verificaciones no están automatizadas, deben verificarse manualmente al menos una vez al año. +* Utilizar federación de identidades, credenciales de corta duración o mecanismos de acceso basados en roles proporcionados por la plataforma subyacente en lugar de incrustar claves estáticas o secretos en el código, los archivos de configuración o los flujos de trabajo (pipelines). + + +## Escenarios de ejemplo de ataque + +**Escenario #1:** El servidor de aplicaciones viene con aplicaciones de ejemplo que no se eliminaron del servidor de producción. Estas aplicaciones de ejemplo tienen fallas de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y las cuentas predeterminadas no se cambiaron. En ese caso, el atacante inicia sesión con la contraseña predeterminada y toma el control. + +**Escenario #2:** El listado de directorios no está desactivado en el servidor. Un atacante descubre que puede simplemente listar los directorios. El atacante encuentra y descarga las clases Java compiladas, las cuales descompila y les aplica ingeniería inversa para ver el código. El atacante encuentra entonces una falla grave de control de acceso en la aplicación. + +**Escenario #3:** La configuración del servidor de aplicaciones permite que se devuelvan mensajes de error detallados, como trazas de la pila, a los usuarios. Esto expone potencialmente información sensible o fallas subyacentes, como versiones de componentes que se sabe que son vulnerables. + +**Escenario #4:** Un proveedor de servicios en la nube (CSP) tiene por defecto permisos de compartición abiertos a Internet. Esto permite el acceso a datos sensibles almacenados en el almacenamiento en la nube. + + +## Referencias + +* [Guía de Pruebas de OWASP: Gestión de la Configuración](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README) +* [Guía de Pruebas de OWASP: Pruebas de Códigos de Error](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) +* [Estándar de Verificación de Seguridad en Aplicaciones V13 Configuración] (OWASP Application Security Verification Standard (ASVS)) (https://github.com/OWASP/ASVS/blob/master/5.0/en/0x22-V13-Configuration.md) +* [Guía de NIST para el Bastionado General de Servidores](Guide to General Server Security)(https://csrc.nist.gov/publications/detail/sp/800-123/final) +* [Guías/Benchmarks de Configuración de Seguridad de CIS] (CIS Benchmarks List)(https://www.cisecurity.org/cis-benchmarks/) +* [Descubrimiento y Enumeración de Cubos Amazon S3](AWS S3 Bucket Discovery)(https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) +* ScienceDirect: Security Misconfiguration + +## Lista de CWE Mapeados + +* [CWE-5 Configuración Incorrecta de J2EE: Transmisión de Datos Sin Cifrado (J2EE Misconfiguration: Data Transmission Without Encryption)](https://cwe.mitre.org/data/definitions/5.html) + +* [CWE-11 Configuración Incorrecta de ASP.NET: Creación de Binario de Depuración (ASP.NET Misconfiguration: Creating Debug Binary)](https://cwe.mitre.org/data/definitions/11.html) + +* [CWE-13 Configuración Incorrecta de ASP.NET: Contraseña en Archivo de Configuración (ASP.NET Misconfiguration: Password in Configuration File)](https://cwe.mitre.org/data/definitions/13.html) + +* [CWE-15 Control Externo del Sistema o del Ajuste de la Configuración (External Control of System or Configuration Setting)](https://cwe.mitre.org/data/definitions/15.html) + +* [CWE-16 Configuración (Configuration)](https://cwe.mitre.org/data/definitions/16.html) + +* [CWE-260 Contraseña en Archivo de Configuración (Password in Configuration File)](https://cwe.mitre.org/data/definitions/260.html) + +* [CWE-315 Almacenamiento en Texto Plano de Información Sensible en una Cookie (Cleartext Storage of Sensitive Information in a Cookie)](https://cwe.mitre.org/data/definitions/315.html) + +* [CWE-489 Código de Depuración Activo (Active Debug Code)](https://cwe.mitre.org/data/definitions/489.html) + +* [CWE-526 Exposición de Información Sensible a Través de Variables de Entorno (Exposure of Sensitive Information Through Environmental Variables)](https://cwe.mitre.org/data/definitions/526.html) + +* [CWE-547 Uso de Constantes Relevantes para la Seguridad quemadas en el código (harcodeadas) + (Use of Hard-coded, Security-relevant Constants)](https://cwe.mitre.org/data/definitions/547.html) + +* [CWE-611 Restricción Inadecuada de Referencias a Entidades Externas XML (Improper Restriction of XML External Entity Reference)](https://cwe.mitre.org/data/definitions/611.html) + +* [CWE-614 Cookie Sensible en Sesión HTTPS sin el Atributo 'Secure' (Sensitive Cookie in HTTPS Session Without 'Secure' Attribute)](https://cwe.mitre.org/data/definitions/614.html) + +* [CWE-776 Restricción Inadecuada de Referencias a Entidades Recursivas en DTDs ('Expansión de Entidades XML') (Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion'))](https://cwe.mitre.org/data/definitions/776.html) + +* [CWE-942 Política de Seguridad entre Dominios Permisiva con Dominios No Confiables (Permissive Cross-domain Policy with Untrusted Domains)](https://cwe.mitre.org/data/definitions/942.html) + +* [CWE-1004 Cookie Confidencial sin el Indicador 'HttpOnly' (Sensitive Cookie Without 'HttpOnly' Flag)](https://cwe.mitre.org/data/definitions/1004.html) + +* [CWE-1174 Configuración Incorrecta de ASP.NET: Validación de Modelo Inadecuada (ASP.NET Misconfiguration: Improper Model Validation)](https://cwe.mitre.org/data/definitions/1174.html) diff --git a/2025/docs/es/A03_2025-Software_Supply_Chain_Failures.md b/2025/docs/es/A03_2025-Software_Supply_Chain_Failures.md new file mode 100644 index 000000000..76fcda6aa --- /dev/null +++ b/2025/docs/es/A03_2025-Software_Supply_Chain_Failures.md @@ -0,0 +1,175 @@ +# A03:2025 Fallas en la Cadena de Suministro de Software (Software Supply Chain Failures) ![icon](../assets/TOP_10_Icons_Final_Vulnerable_Outdated_Components.png){: style="height:80px;width:80px" align="right"} + + +## Antecedentes + +Este fue el primer clasificado en la encuesta comunitaria del Top 10, con exactamente el 50% de los encuestados situándolo en el #1. Desde su aparición inicial en el Top 10 de 2013 como "A9 – Uso de Componentes con Vulnerabilidades Conocidas", el riesgo ha crecido en alcance para incluir todas las fallas de la cadena de suministro, no solo los que involucran vulnerabilidades conocidas. A pesar de este mayor alcance, las fallas en la cadena de suministro siguen siendo un reto de identificar, con solo 11 CVE (Common Vulnerability and Exposures)(Vulnerabilidades y Exposiciones Comunes) que tienen los CWE (Common Weakness Enumeration) relacionados. Sin embargo, cuando se prueban y se informan en los datos aportados, esta categoría tiene la tasa de incidencia promedio más alta, con un 5.19%. Los CWE relevantes son *CWE-477: Uso de Función Obsoleta*, *CWE-1104: Uso de Componentes de Terceros no Mantenidos*, *CWE-1329: Dependencia en un Componente que no es Actualizable*, y *CWE-1395: Dependencia en un Componente de Terceros Vulnerable*. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWE Mapeados + Tasa de Incidencia Máx. + Tasa de Incidencia Prom. + Cobertura Máx. + Cobertura Prom. + Explotación Ponderada Prom. + Impacto Ponderado Prom. + Ocurrencias Totales + CVE Totales +
6 + 9.56% + 5.72% + 65.42% + 27.47% + 8.17 + 5.23 + 215,248 + 11 +
+ + + +## Descripción + +Las fallas en la cadena de suministro de software son rupturas u otros compromisos en el proceso de construcción, distribución o actualización del software. A menudo son causados por vulnerabilidades o cambios maliciosos en el código de terceros, herramientas u otras dependencias en las que confía el sistema. + +Es probable que sea vulnerable si: + +* no realiza un seguimiento cuidadoso de las versiones de todos los componentes que utiliza (tanto en el lado del cliente como en el del servidor). Esto incluye los componentes que utiliza directamente, así como las dependencias anidadas (transitivas). +* el software es vulnerable, no tiene soporte o está desactualizado. Esto incluye el sistema operativo (SO), el servidor web/de aplicaciones, el sistema de gestión de bases de datos (DBMS), las aplicaciones, las API y todos los componentes, entornos de ejecución y bibliotecas. +* no escanea regularmente en busca de vulnerabilidades y no se suscribe a boletines de seguridad relacionados con los componentes que utiliza. +* no dispone de un proceso de gestión de cambios o de un seguimiento de los mismos dentro de su cadena de suministro, incluyendo el seguimiento de los IDE, las extensiones y actualizaciones de los IDE, los cambios en el repositorio de código de su organización, los entornos aislados (sandboxes), los repositorios de imágenes y bibliotecas, la forma en que se crean y almacenan los artefactos, etc. Cada parte de su cadena de suministro debe estar documentada, especialmente los cambios. +* no ha bastionado (hardenizado) cada parte de su cadena de suministro, con especial atención al control de acceso y la aplicación del mínimo privilegio. +* sus sistemas de cadena de suministro no tienen ninguna separación de funciones (separation of duty). Ninguna persona debería poder escribir código y desplegarlo a producción sin la supervisión de otro ser humano. +* se utilizan en entornos de producción, o pueden impactar en ellos, componentes de fuentes no confiables en cualquier parte de la pila (stack)tecnológica. +* no corrige ni actualiza la plataforma subyacente, los frameworks y las dependencias de forma oportuna y basada en el riesgo. Esto suele ocurrir en entornos donde el parcheado es una tarea mensual o trimestral bajo control de cambios, dejando a las organizaciones abiertas a días o meses de exposición innecesaria antes de corregir las vulnerabilidades. +* los desarrolladores de software no prueban la compatibilidad de las bibliotecas actualizadas o parcheadas. +* no asegura las configuraciones de cada parte de su sistema (consulte [A02:2025-Configuración de Seguridad Incorrecta](https://owasp.org/Top10/2025/A02_2025-Security_Misconfiguration/)). +* su flujo de CI/CD (CI/CD pipeline) tiene una seguridad más débil que los sistemas que construye y despliega, especialmente si es complejo. + + +## Cómo prevenir + +Debe existir un proceso de gestión de parches para: + + + +* Generar y gestionar de forma centralizada la Lista de Materiales de Software (Software Bill of Materials, SBOM) (inventario de componentes de software) de todo su software. +* Realizar un seguimiento no solo de sus dependencias directas, sino también de sus dependencias (transitivas), y así sucesivamente. +* Reducir la superficie de ataque eliminando las dependencias no utilizadas, las funciones innecesarias, los componentes, los archivos y la documentación. +* Inventariar continuamente las versiones de los componentes tanto del lado del cliente como del servidor (por ejemplo, frameworks, bibliotecas) y sus dependencias utilizando herramientas como OWASP Dependency Track, OWASP Dependency Check, retire.js, etc. +* Supervisar continuamente fuentes como Common Vulnerability and Exposures (CVE), National Vulnerability Database (NVD) y [Open Source Vulnerabilities (OSV)](https://osv.dev/) en busca de vulnerabilidades en los componentes que utiliza. Utilice herramientas de análisis de composición de software (Software Composition Analysis, SCA), de cadena de suministro de software o herramientas de SBOM centradas en la seguridad para automatizar el proceso. Suscríbase a alertas de vulnerabilidades de seguridad relacionadas con los componentes que utiliza. +* Obtener únicamente componentes de fuentes oficiales (confiables) a través de enlaces seguros. Prefiera los paquetes firmados para reducir la posibilidad de incluir un componente modificado y malicioso (consulte [A08:2025-Fallas en la Integridad del Software o de los Datos](https://owasp.org/Top10/2025/A08_2025-Software_or_Data_Integrity_Failures/)). +* Elegir deliberadamente qué versión de una dependencia utiliza y actualizarla solo cuando sea necesario. +* Vigilar las bibliotecas y componentes que no reciben mantenimiento o que no crean parches de seguridad para versiones antiguas. Si no es posible parchear, considere la posibilidad de migrar a una alternativa. Si eso no es posible, considere el despliegue de un parche virtual para monitorizar, detectar o proteger contra el problema descubierto. +* Actualizar regularmente su CI/CD, IDE y cualquier otra herramienta de desarrollo. +* Evitar el despliegue de actualizaciones en todos los sistemas simultáneamente. Utilice despliegues escalonados o despliegues canario (canary deployments) para limitar la exposición en caso de que un proveedor de confianza se vea comprometido. + + +Debe existir un proceso de gestión de cambios o un sistema de seguimiento para rastrear los cambios en: + +* Ajustes de CI/CD (continuous integration / continuous delivery-deployment) (todas las herramientas y flujos de construcción) +* Repositorios de código +* Áreas de pruebas (sandboxes) +* IDE de los desarrolladores +* Herramientas de SBOM y artefactos creados +* Sistemas de registro (logging) y registros (logs) +* Integraciones con terceros, como SaaS +* Repositorios de artefactos +* Registros de contenedores + + +Bastione (hardening) los siguientes sistemas, lo que incluye habilitar MFA (Multi-Factor Authentication) (Autenticación multifactor) y restringir el IAM (Identity and Access Management) (Gestión de Identidades y Accesos): + +* Su repositorio de código (lo que incluye no subir secretos, proteger ramas, copias de seguridad) +* Estaciones de trabajo de los desarrolladores (parcheado regular, MFA, monitoreo y más) +* Tu servidor de compilación y CI/CD (separación de funciones, control de acceso, compilaciones firmadas, secretos con alcance de entorno, registros a prueba de manipulaciones, más) +* Sus artefactos (garantizar la integridad mediante la procedencia, la firma y la marca de tiempo (time stamp), promocionar artefactos en lugar de reconstruirlos para cada entorno, garantizar que las compilaciones sean inalterables) +* Infraestructura como código (gestionada como todo el código, incluyendo el uso de PRs (Pull Requests) y control de versiones) + +Cada organización debe garantizar un plan continuo para monitorear, triar y aplicar actualizaciones o cambios de configuración durante toda la vida útil de la aplicación o portafolio. + + + +## Escenarios de ejemplo de ataque + +**Escenario #1:** Un proveedor de confianza es comprometido con malware, lo que provoca que sus sistemas informáticos sean comprometidos al actualizar. El ejemplo más famoso de esto es probablemente: + + + +* El compromiso de SolarWinds en 2019 que llevó a que unas 18,000 organizaciones se vieran comprometidas. [https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) + +**Escenario #2:** Un proveedor de confianza es comprometido de tal manera que se comporta de forma maliciosa solo bajo una condición específica. + + + +* El robo de 1,500 millones de dólares a Bybit en 2025 fue causado por [un ataque a la cadena de suministro en el software de la billetera (wallet)](https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/) que solo se ejecutaba cuando se utilizaba la billetera objetivo. + +**Escenario #3:** El ataque a la cadena de suministro [`Shai-Hulud`](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem) en 2025 fue el primer gusano npm autopropagable con éxito. Los ataques sembraron versiones maliciosas de paquetes populares, que utilizaban un script de post-instalación para recolectar y exfiltrar datos sensibles a repositorios públicos de GitHub. El malware también detectaba tokens de npm en el entorno de la víctima y los utilizaba automáticamente para subir versiones maliciosas de cualquier paquete accesible. El gusano alcanzó más de 500 versiones de paquetes antes de ser interrumpido por npm. Este ataque a la cadena de suministro fue avanzado, de rápida propagación y dañino, y al dirigirse a las máquinas de los desarrolladores demostró que los propios desarrolladores son ahora objetivos principales para los ataques a la cadena de suministro. + +**Escenario #4:** Los componentes suelen ejecutarse con los mismos privilegios que la propia aplicación, por lo que las fallas en cualquier componente pueden tener un impacto grave. Tales fallas pueden ser accidentales (por ejemplo, un error de progrmación) o intencionados (por ejemplo, una puerta trasera (backdoor) en un componente). Algunos ejemplos de vulnerabilidades de componentes explotables descubiertas son: + +* CVE-2017-5638, una vulnerabilidad de ejecución remota de código en Struts 2 que permite la ejecución de código arbitrario en el servidor, ha sido señalada como la causa de brechas significativas. +* CVE-2021-44228 ("Log4Shell"), una vulnerabilidad de día cero de ejecución remota de código en Apache Log4j, ha sido señalada como la causa de campañas de ransomware, criptominería y otros ataques. + + +## Referencias + +* [Estándar de Verificación de Seguridad en Aplicaciones de OWASP: V15 Arquitectura y Codificación Segura] (OWASP Application Security Verification Standard (ASVS)) (https://owasp.org/www-project-application-security-verification-standard/) +* [Serie de guías rápidas de OWASP: SBOM de Gráfico de Dependencias](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html) +* [Serie de guías rápidas de OWASP: Gestión de Dependencias Vulnerables](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) +* [OWASP Dependency-Track](https://owasp.org/www-project-dependency-track/) +* [OWASP CycloneDX](https://owasp.org/www-project-cyclonedx/) +* [Estándar de Verificación de Seguridad en Aplicaciones de OWASP: V1 Arquitectura, diseño y modelado de amenazas](https://owasp-aasvs.readthedocs.io/en/latest/v1.html) +* [OWASP Dependency Check (para bibliotecas Java y .NET)](https://owasp.org/www-project-dependency-check/) +* Guía de Pruebas de OWASP - Map Application Architecture (OTG-INFO-010) +* [Mejores Prácticas de Parcheado Virtual de OWASP](https://owasp.org/www-community/Virtual_Patching_Best_Practices) +* [La desafortunada realidad de las bibliotecas inseguras](https://www.scribd.com/document/105692739/JeffWilliamsPreso-Sm) +* [Búsqueda de Vulnerabilidades y Exposiciones Comunes (CVE) de MITRE](https://www.cve.org) +* [Base de Datos Nacional de Vulnerabilidades (NVD)](https://nvd.nist.gov) +* [Retire.js para detectar bibliotecas JavaScript vulnerables conocidas](https://retirejs.github.io/retire.js/) +* [Base de datos de alertas de seguridad de GitHub](https://github.com/advisories) +* Base de datos de avisos de seguridad y herramientas para bibliotecas Ruby +* [Controles de Integridad de Software de SAFECode (PDF)](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [Ataque a la cadena de suministro Glassworm](https://thehackernews.com/2025/10/self-spreading-glassworm-infects-vs.html) +* [Campaña de ataque a la cadena de suministro PhantomRaven](https://thehackernews.com/2025/10/phantomraven-malware-found-in-126-npm.html) + + +## Lista de CWE Mapeados + +* [CWE-447 Uso de Función Obsoleta (Use of Obsolete Function)](https://cwe.mitre.org/data/definitions/447.html) + +* [CWE-1035 Top 10 2017 A9: Uso de Componentes con Vulnerabilidades Conocidas (2017 Top 10 A9: Using Components with Known Vulnerabilities)](https://cwe.mitre.org/data/definitions/1035.html) + +* [CWE-1104 Uso de Componentes de Terceros no Mantenidos (Use of Unmaintained Third Party Components)](https://cwe.mitre.org/data/definitions/1104.html) + +* [CWE-1329 Dependencia en un Componente que no es Actualizable (Reliance on Component That is Not Updatable)](https://cwe.mitre.org/data/definitions/1329.html) + +* [CWE-1357 Dependencia en un Componente Insuficientemente Confiable (Reliance on Insufficiently Trustworthy Component)](https://cwe.mitre.org/data/definitions/1357.html) + +* [CWE-1395 Dependencia en un Componente de Terceros Vulnerable (Dependency on Vulnerable Third-Party Component)](https://cwe.mitre.org/data/definitions/1395.html) diff --git a/2025/docs/es/A04_2025-Cryptographic_Failures.md b/2025/docs/es/A04_2025-Cryptographic_Failures.md new file mode 100644 index 000000000..7fbc1d752 --- /dev/null +++ b/2025/docs/es/A04_2025-Cryptographic_Failures.md @@ -0,0 +1,195 @@ +# A04:2025 Fallas Criptográficas ![icon](../assets/TOP_10_Icons_Final_Crypto_Failures.png){: style="height:80px;width:80px" align="right"} + + + +## Antecedentes. + +Bajando dos posiciones hasta el #4, esta debilidad se centra en fallas relacionadas con la ausencia de criptografía, criptografía insuficientemente robusta, filtración de claves criptográficas y errores relacionados. Tres de los CWEs más comunes en este riesgo involucran el uso de un generador de números pseudoaleatorios débil: *CWE-327 Algoritmo Criptográfico Vulnerado o Inseguro, CWE-331: Entropía Insuficiente*, *CWE-1241: Uso de Algoritmo Predecible en Generador de Números Aleatorios*, y *CWE-338 Uso de un Generador de Números Pseudoaleatorios (PRNG Pseudo-random Number Generator) Criptográficamente Débil*. + + + +## Factores. + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeados + Tasa Máx. de Incidencia + Tasa Prom. de Incidencia + Cobertura Máx. + Cobertura Prom. + Explotabilidad Ponderada Prom. + Impacto Ponderado Prom. + Total de Ocurrencias + Total de CVEs +
32 + 13.77% + 3.80% + 100.00% + 47.74% + 7.23 + 3.90 + 1,665,348 + 2,185 +
+ + + +## Descripción. + +En términos generales, todos los datos en tránsito deben cifrarse en la [capa de transporte](https://en.wikipedia.org/wiki/Transport_layer) (capa 4 del [modelo OSI](https://en.wikipedia.org/wiki/OSI_model)). Obstáculos anteriores como el rendimiento de la CPU y la gestión de claves privadas/certificados ahora son manejados por CPUs con instrucciones diseñadas para acelerar el cifrado (p. ej., [soporte AES](https://en.wikipedia.org/wiki/AES_instruction_set)), y la gestión de claves privadas y certificados se ha simplificado mediante servicios como [LetsEncrypt.org](https://LetsEncrypt.org), con los principales proveedores de nube ofreciendo servicios de gestión de certificados aún más integrados para sus plataformas específicas. + +Más allá de asegurar la capa de transporte, es importante determinar qué datos necesitan cifrado en reposo y qué datos requieren cifrado adicional en tránsito (en la [capa de aplicación](https://en.wikipedia.org/wiki/Application_layer), capa 7 del OSI). Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos, información personal y secretos comerciales requieren protección adicional, especialmente si esos datos están sujetos a leyes de privacidad como el Reglamento General de Protección de Datos (RGPD Règlement Général sur la Protection des Données (General Data Protection Regulation)) de la UE, o regulaciones como el Estándar de Seguridad de Datos PCI (PCI DSS). Para todos esos datos: + + + +* ¿Se usan algoritmos o protocolos criptográficos antiguos o débiles, ya sea por defecto o en código heredado? +* ¿Se usan claves criptográficas predeterminadas, se generan claves débiles, se reutilizan claves, o falta una gestión y rotación adecuada de claves? +* ¿Se incluyen claves criptográficas en repositorios de código fuente? +* ¿No se aplica el cifrado? Por ejemplo, ¿faltan directivas o cabeceras de seguridad HTTP (del navegador)? +* ¿Se valida correctamente el certificado del servidor recibido y la cadena de confianza? +* ¿Se ignoran, reutilizan o generan de forma insegura los vectores de inicialización para el modo de operación criptográfico? ¿Se usa un modo de operación inseguro como ECB? ¿Se usa cifrado cuando el cifrado autenticado sería más apropiado? +* ¿Se usan contraseñas como claves criptográficas sin una función de derivación de claves basada en contraseña? +* ¿Se usa aleatoriedad no diseñada para cumplir requisitos criptográficos? Aunque se elija la función correcta, ¿necesita ser inicializada (seed) por el desarrollador y, de ser así, ha sobrescrito la funcionalidad de semilla fuerte incorporada con una semilla con entropía/imprevisibilidad insuficiente? +* ¿Se usan funciones hash obsoletas como MD5 o SHA1, o se usan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas? +* ¿Son explotables los mensajes de error criptográficos o la información de canal lateral, por ejemplo en forma de ataques de relleno de oracle (padding oracle)? +* ¿Puede el algoritmo criptográfico ser degradado o eludido? + +Consultar referencias ASVS: Criptografía (V11), Comunicación Segura (V12) y Protección de Datos (V14). + + +## Cómo se previene. + +Como mínimo, hacer lo siguiente y consultar las referencias: + + + +* Clasificar y etiquetar los datos procesados, almacenados o transmitidos por una aplicación. Identificar qué datos son sensibles según las leyes de privacidad, los requisitos regulatorios o las necesidades del negocio. +* Almacenar las claves más sensibles en un HSM físico o basado en la nube. +* Usar implementaciones bien reconocidas de algoritmos criptográficos siempre que sea posible. +* No almacenar datos sensibles innecesariamente. Descartarlos lo antes posible o usar tokenización conforme a PCI DSS (Payment Card Industry Data Security Standard) (Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago) o incluso truncamiento. Los datos que no se retienen no pueden ser robados. +* Asegurarse de cifrar todos los datos sensibles en reposo. +* Garantizar que estén en uso algoritmos, protocolos y claves estándar actualizados y robustos; usar una gestión de claves adecuada. +* Cifrar todos los datos en tránsito con protocolos >= TLS 1.2 únicamente, con cifradores de secreto hacia adelante (forward secrecy, FS), eliminar soporte para cifrados en modo CBC, soportar algoritmos de intercambio de claves cuánticos. Para HTTPS, aplicar cifrado mediante HTTP Strict Transport Security (HSTS). Verificar todo con una herramienta. +* Deshabilitar el caché para respuestas que contengan datos sensibles. Esto incluye el caché en el CDN, el servidor web y cualquier caché de aplicación (p. ej., Redis). +* Aplicar los controles de seguridad requeridos según la clasificación de datos. +* No usar protocolos sin cifrado como FTP y STARTTLS. Evitar usar SMTP para transmitir datos confidenciales. +* Almacenar contraseñas usando funciones de hashing robustas, adaptativas y con sal (salt), con un factor de trabajo (factor de retardo), como Argon2, yescrypt, scrypt o PBKDF2-HMAC-SHA-512. Para sistemas heredados que usan bcrypt, consultar la [Guía de referencia rápida de OWASP: Almacenamiento de Contraseñas](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* Los vectores de inicialización deben elegirse apropiadamente para el modo de operación. Esto puede significar usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe usarse dos veces para una clave fija. +* Usar siempre cifrado autenticado en lugar de solo cifrado. +* Las claves deben generarse criptográficamente de forma aleatoria y almacenarse en memoria como arreglos de bytes. Si se usa una contraseña, debe convertirse en clave mediante una función de derivación de clave basada en contraseña apropiada. +* Asegurarse de que se use aleatoriedad criptográfica donde corresponda y que no haya sido inicializada (seeded) de forma predecible o con baja entropía. La mayoría de las APIs modernas no requieren que el desarrollador inicialice el CSPRNG para que sea seguro. +* Evitar funciones criptográficas obsoletas, métodos de construcción de bloques y esquemas de relleno (padding), como MD5, SHA1, Modo de Encadenamiento de Bloques (CBC), PKCS número 1 v1.5. +* Asegurarse de que las configuraciones y ajustes cumplan los requisitos de seguridad mediante revisión por especialistas en seguridad, herramientas diseñadas para este propósito, o ambos. +* Es necesario prepararse ahora para la criptografía poscuántica (PQC), ver referencia (ENISA), para que los sistemas de alto riesgo estén protegidos a más tardar a finales de 2030. + + +## Ejemplos de escenarios de ataque. + +**Escenario #1**: Un sitio no usa ni exige TLS en todas las páginas, o admite cifrado débil. Un atacante monitorea el tráfico de red (p. ej., en una red inalámbrica insegura), degrada las conexiones de HTTPS a HTTP, intercepta solicitudes y roba la cookie de sesión del usuario. El atacante luego reproduce esta cookie y secuestra la sesión (autenticada) del usuario, accediendo o modificando los datos privados del usuario. Alternativamente, podría alterar todos los datos transportados, por ejemplo, el destinatario de una transferencia de dinero. + +**Escenario #2**: La base de datos de contraseñas usa hashes sin sal (salt) o hashes simples para almacenar todas las contraseñas. Un fallo de carga de archivos permite a un atacante recuperar la base de datos de contraseñas. Todos los hashes sin salt pueden quedar expuestos con una tabla arcoiris (rainbow table) de hashes precalculados. Los hashes generados por funciones hash simples o rápidas pueden ser descifrados por GPUs, incluso si tenían sal. + + +## Referencias. + + + +* [OWASP Controles Proactivos: C2: Usar Criptografía para Proteger Datos](https://top10proactive.owasp.org/archive/2024/the-top-10/c2-crypto/) +* [Estándar de Verificación de Seguridad de Aplicaciones OWASP (ASVS): ](https://owasp.org/www-project-application-security-verification-standard) [V11,](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x20-V11-Cryptography.md) [12, ](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x21-V12-Secure-Communication.md) [14](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x23-V14-Data-Protection.md) +* [Guía de referencia rápida de OWASP: Protección de la Capa de Transporte](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html) +* [Guía de referencia rápida de OWASP: Protección de Privacidad del Usuario](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html) +* [Guía de referencia rápida de OWASP: Almacenamiento de Contraseñas](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) +* [Guía de referencia rápida de OWASP: Almacenamiento Criptográfico](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html) +* [Guía de referencia rápida de OWASP: HSTS (Seguridad de Transporte Estricta HTTP)](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) +* [Guía de Pruebas OWASP: Pruebas de Criptografía Débil](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/README) +* [ENISA: Hoja de Ruta de Implementación Coordinada para la Transición a la Criptografía Poscuántica](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography) +* [NIST publica los primeros 3 Estándares de Cifrado Poscuántico finalizados](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) + + +## Lista de CWEs Mapeados + +* [CWE-261 Codificación Débil para Contraseñas (Weak Encoding for Password)](https://cwe.mitre.org/data/definitions/261.html) + +* [CWE-296 Seguimiento Inadecuado de la Cadena de Confianza de un Certificado (Improper Following of a Certificate's Chain of Trust)](https://cwe.mitre.org/data/definitions/296.html) + +* [CWE-319 Transmisión en Texto Plano de Información Sensible (Cleartext Transmission of Sensitive Information)](https://cwe.mitre.org/data/definitions/319.html) + +* [CWE-320 Errores en la Gestión de Claves (Key Management Errors) (Prohibido)](https://cwe.mitre.org/data/definitions/320.html) + +* [CWE-321 Uso de Clave Criptográfica Embebida (quemada) en el Código (Use of Hard-coded Cryptographic Key)](https://cwe.mitre.org/data/definitions/321.html) + +* [CWE-322 Intercambio de Claves sin Autenticación de Entidad (Key Exchange without Entity Authentication)](https://cwe.mitre.org/data/definitions/322.html) + +* [CWE-323 Reutilización de un Nonce o Par de Claves en el Cifrado (Reusing a Nonce, Key Pair in Encryption)](https://cwe.mitre.org/data/definitions/323.html) + +* [CWE-324 Uso de una Clave Más Allá de su Fecha de Expiración (Use of a Key Past its Expiration Date)](https://cwe.mitre.org/data/definitions/324.html) + +* [CWE-325 Paso Criptográfico Requerido Faltante (Missing Required Cryptographic Step)](https://cwe.mitre.org/data/definitions/325.html) + +* [CWE-326 Fortaleza de Cifrado Inadecuada (Inadequate Encryption Strength)](https://cwe.mitre.org/data/definitions/326.html) + +* [CWE-327 Algoritmo Criptográfico Vulnerado o Riesgoso (Use of a Broken or Risky Cryptographic Algorithm)](https://cwe.mitre.org/data/definitions/327.html) + +* [CWE-328 Hash Unidireccional Reversible (Reversible One-Way Hash)](https://cwe.mitre.org/data/definitions/328.html) + +* [CWE-329 No Usar un IV Aleatorio con el Modo CBC (Not Using a Random IV with CBC Mode)](https://cwe.mitre.org/data/definitions/329.html) + +* [CWE-330 Uso de Valores Insuficientemente Aleatorios (Use of Insufficiently Random Values)](https://cwe.mitre.org/data/definitions/330.html) + +* [CWE-331 Entropía Insuficiente (Insufficient Entropy)](https://cwe.mitre.org/data/definitions/331.html) + +* [CWE-332 Entropía Insuficiente en el PRNG (Insufficient Entropy in PRNG)](https://cwe.mitre.org/data/definitions/332.html) + +* [CWE-334 Espacio Pequeño de Valores Aleatorios (Small Space of Random Values)](https://cwe.mitre.org/data/definitions/334.html) + +* [CWE-335 Uso Incorrecto de Semillas en el Generador de Números Pseudoaleatorios (Incorrect Usage of Seeds in Pseudo-Random Number Generator) (PRNG)](https://cwe.mitre.org/data/definitions/335.html) + +* [CWE-336 Misma Semilla en el Generador de Números Pseudoaleatorios (Same Seed in Pseudo-Random Number Generator) (PRNG)](https://cwe.mitre.org/data/definitions/336.html) + +* [CWE-337 Semilla Predecible en el Generador de Números Pseudoaleatorios (Predictable Seed in Pseudo-Random Number Generator) (PRNG)](https://cwe.mitre.org/data/definitions/337.html) + +* [CWE-338 Uso de un Generador de Números Pseudoaleatorios Criptográficamente Débil (Use of Cryptographically Weak Pseudo-Random Number Generator) (PRNG)](https://cwe.mitre.org/data/definitions/338.html) + +* [CWE-340 Generación de Números o Identificadores Predecibles (Generation of Predictable Numbers or Identifiers)](https://cwe.mitre.org/data/definitions/340.html) + +* [CWE-342 Valor Exacto Predecible a Partir de Valores Anteriores (Predictable Exact Value from Previous Values)](https://cwe.mitre.org/data/definitions/342.html) + +* [CWE-347 Verificación Inadecuada de Firma Criptográfica (Improper Verification of Cryptographic Signature)](https://cwe.mitre.org/data/definitions/347.html) + +* [CWE-523 Transporte Desprotegido de Credenciales (Unprotected Transport of Credentials)](https://cwe.mitre.org/data/definitions/523.html) + +* [CWE-757 Selección de Algoritmo Menos Seguro Durante la Negociación (Selection of Less-Secure Algorithm During Negotiation) ('Degradación de Algoritmo' / 'Algorithm Downgrade')](https://cwe.mitre.org/data/definitions/757.html) + +* [CWE-759 Uso de Hash Unidireccional sin Sal (Use of a One-Way Hash without a Salt)](https://cwe.mitre.org/data/definitions/759.html) + +* [CWE-760 Uso de Hash Unidireccional con Sal Predecible (Use of a One-Way Hash with a Predictable Salt)](https://cwe.mitre.org/data/definitions/760.html) + +* [CWE-780 Uso del Algoritmo RSA sin OAEP (Use of RSA Algorithm without OAEP)](https://cwe.mitre.org/data/definitions/780.html) + +* [CWE-916 Uso de Hash de Contraseña con Esfuerzo Computacional Insuficiente (Use of Password Hash With Insufficient Computational Effort)](https://cwe.mitre.org/data/definitions/916.html) + +* [CWE-1240 Uso de una Primitiva Criptográfica con una Implementación Riesgosa (Use of a Cryptographic Primitive with a Risky Implementation)](https://cwe.mitre.org/data/definitions/1240.html) + +* [CWE-1241 Uso de Algoritmo Predecible en Generador de Números Aleatorios (Use of Predictable Algorithm in Random Number Generator)](https://cwe.mitre.org/data/definitions/1241.html) \ No newline at end of file diff --git a/2025/docs/es/A05_2025-Injection.md b/2025/docs/es/A05_2025-Injection.md new file mode 100644 index 000000000..c56c48f1b --- /dev/null +++ b/2025/docs/es/A05_2025-Injection.md @@ -0,0 +1,187 @@ +# A05:2025 Inyección ![icon](../assets/TOP_10_Icons_Final_Injection.png){: style="height:80px;width:80px" align="right"} + +## Antecedentes. + +La Inyección cae dos posiciones del #3 al #5 en el ranking, manteniendo su posición relativa respecto a A04:2025-Fallos Criptográficos y A06:2025-Diseño Inseguro. La inyección es una de las categorías más probadas, con el 100% de las aplicaciones evaluadas para algún tipo de inyección. Tuvo el mayor número de CVEs de cualquier categoría, con 37 CWEs en esta categoría. La inyección incluye Cross-Site Scripting (XSS) (alta frecuencia/bajo impacto) con más de 30.000 CVEs e Inyección SQL (baja frecuencia/alto impacto) con más de 14.000 CVEs. La gran cantidad de CVEs reportados para CWE-79 Neutralización Inadecuada de Entradas Durante la Generación de Páginas Web ('Cross-site Scripting') reduce el impacto ponderado promedio de esta categoría. + + +## Tabla de puntuación. + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs MapeadosTasa Máx. de IncidenciaTasa Prom. de IncidenciaCobertura Máx.Cobertura Prom.Explotabilidad Ponderada Prom.Impacto Ponderado Prom.Total de OcurrenciasTotal de CVEs
3713.77%3.08%100.00%42.93%7.154.321,404,24962,445
+ + +## Descripción. + +Una vulnerabilidad de inyección es una falla en una aplicación que permite que entradas no confiables del usuario sean enviadas a un intérprete (p. ej., un navegador, una base de datos, la línea de comandos) y provoca que el intérprete ejecute partes de esa entrada como comandos. + +Una aplicación es vulnerable a estos tipos de ataque cuando: + +* Los datos proporcionados por el usuario no son validados, filtrados ni sanitizados por la aplicación. +* Se invocan consultas dinámicas o llamadas no parametrizadas, sin codificar los parámetros de forma acorde al contexto, directamente en el intérprete. +* Se utilizan datos no sanitizados dentro de los parámetros de búsqueda en consultas de Mapeo Relacional de Objetos (ORM — Object-Relational Mapping), para extraer registros sensibles adicionales. +* Se utilizan datos potencialmente dañinos directamente o se concatenan. El SQL o comando resultante contiene la estructura y los datos maliciosos en consultas dinámicas, comandos o procedimientos almacenados. + +Algunas de las inyecciones más comunes son SQL, NoSQL, comandos de sistema operativo (OS), Mapeo Relacional de Objetos (ORM), LDAP (Lightweight Directory Access Protocol) (Protocolo Ligero de Acceso a Directorios), y lenguaje de expresiones (EL) u Object Graph Navigation Library (OGNL). El concepto es idéntico para todos los intérpretes. La detección se logra mejor mediante una combinación de revisión de código fuente junto con pruebas automatizadas (incluyendo fuzzing) de todos los parámetros, encabezados, URL, cookies, datos JSON, SOAP y XML. La incorporación de herramientas de pruebas de seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en el pipeline de CI/CD también puede ser de utilidad para identificar fallas de inyección antes del despliegue en producción. + +Una clase relacionada de vulnerabilidades de inyección se ha vuelto común en los LLMs. Estas se tratan por separado en el [OWASP LLM Top 10](https://genai.owasp.org/llm-top-10/), específicamente en [LLM01:2025 Inyección de Prompts (Prompt Injection)](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). + + +## Cómo se previene. + +El mejor medio para prevenir inyecciones requiere mantener los datos separados de los comandos y las consultas: + +* La opción preferida es utilizar una API segura, que evite el uso del intérprete por completo, proporcione una interfaz parametrizada, o migre a herramientas de Object-Relational Mapping (ORMs). +**Nota:** Incluso cuando se parametrizan, los procedimientos almacenados pueden seguir introduciendo inyección SQL si PL/SQL o T-SQL concatena consultas y datos, o si se ejecutan datos dañinos con EXECUTE IMMEDIATE o exec(). + +Cuando no sea posible separar los datos de los comandos, se pueden reducir las amenazas utilizando las siguientes técnicas. + +* Implemente validaciones de entradas de datos del lado del servidor, utilizando "listas blancas" (allow-lists). De todos modos, esto no es una defensa completa, ya que muchas aplicaciones requieren el uso de caracteres especiales, como en campos de texto o APIs para aplicaciones móviles. +* Para cualquier consulta dinámica restante, escape los caracteres especiales utilizando la sintaxis de escape específica para el intérprete en cuestión. +**Nota:** Las estructuras SQL como nombres de tablas, nombres de columnas, etc. no pueden ser escapadas y, por lo tanto, los nombres de estructura suministrados por el usuario son peligrosos. Este es un problema común en el software de generación de informes. + +**Advertencia:** estas técnicas implican el análisis sintáctico (parsing) y el escape de cadenas complejas, lo que las hace propensas a errores y poco robustas ante cambios menores en el sistema subyacente. + +## Ejemplos de escenarios de ataque. + +**Escenario #1:** Una aplicación utiliza datos no confiables en la construcción de la siguiente consulta SQL vulnerable: + +``` +String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; +``` + +Un atacante modifica el valor del parámetro 'id' en su navegador para enviar: `' OR '1'='1`. Por ejemplo: + +``` +http://example.com/app/accountView?id=' OR '1'='1 +``` + +Esto modifica el significado de la consulta para retornar todos los registros de la tabla accounts. Ataques más peligrosos podrían modificar o eliminar datos, o incluso invocar procedimientos almacenados. + +**Escenario #2:** La confianza ciega de una aplicación en los frameworks puede dar lugar a consultas que siguen siendo vulnerables. Por ejemplo, Hibernate Query Language (HQL): + +``` +Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'"); +``` + +Un atacante suministra: `' OR custID IS NOT NULL OR custID='`. Esto elude el filtro y retorna todas las cuentas. Si bien HQL tiene menos funciones peligrosas que el SQL puro, sigue permitiendo el acceso no autorizado a datos cuando se concatenan entradas del usuario en las consultas. + +**Escenario #3:** Una aplicación pasa la entrada del usuario directamente a un comando del sistema operativo: + +``` +String cmd = "nslookup " + request.getParameter("domain"); +Runtime.getRuntime().exec(cmd); +``` + +Un atacante suministra `example.com; cat /etc/passwd` para ejecutar comandos arbitrarios en el servidor. + +## Referencias. + +* [OWASP Controles Proactivos: Acceso Seguro a Bases de Datos (Secure Database Access)](https://owasp.org/www-project-proactive-controls/v3/en/c3-secure-database) +* [OWASP ASVS: V5 Validación de Entradas y Codificación (Input Validation and Encoding)](https://owasp.org/www-project-application-security-verification-standard) +* [Guía de Pruebas OWASP: Inyección SQL (SQL Injection),](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05-Testing_for_SQL_Injection) [Inyección de Comandos (Command Injection)](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/12-Testing_for_Command_Injection), y [Inyección ORM (ORM Injection)](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/05.7-Testing_for_ORM_Injection) +* Guía de referencia rápida de OWASP: Prevención de Inyección (Injection Prevention)](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html) +* Guía de referencia rápida de OWASP: Prevención de Inyección SQL (SQL Injection Prevention)](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) +* Guía de referencia rápida de OWASP: Prevención de Inyección en Java (Injection Prevention in Java)](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet_in_Java.html) +* Guía de referencia rápida de OWASP: Parametrización de Consultas (Query Parameterization)](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) +* [Amenazas Automatizadas OWASP a Aplicaciones Web – OAT-014](https://owasp.org/www-project-automated-threats-to-web-applications/) +* [PortSwigger: Inyección de plantillas del lado del servidor (Server-side template injection)](https://portswigger.net/kb/issues/00101080_serversidetemplateinjection) +* [Awesome Fuzzing: lista de recursos de fuzzing](https://github.com/secfigo/Awesome-Fuzzing) + +## Lista de CWEs Mapeados + +* [CWE-20 Validación Inadecuada de Entradas (Improper Input Validation)](https://cwe.mitre.org/data/definitions/20.html) + +* [CWE-74 Neutralización Inadecuada de Elementos Especiales en la Salida Usada por un Componente Posterior ('Inyección') (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))](https://cwe.mitre.org/data/definitions/74.html) + +* [CWE-76 Neutralización Inadecuada de Elementos Especiales Equivalentes (Improper Neutralization of Equivalent Special Elements)](https://cwe.mitre.org/data/definitions/76.html) + +* [CWE-77 Neutralización Inadecuada de Elementos Especiales Usados en un Comando ('Inyección de Comandos') (Improper Neutralization of Special Elements used in a Command ('Command Injection'))](https://cwe.mitre.org/data/definitions/77.html) + +* [CWE-78 Neutralización Inadecuada de Elementos Especiales Usados en un Comando del Sistema Operativo ('Inyección de Comandos OS') (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))](https://cwe.mitre.org/data/definitions/78.html) + +* [CWE-79 Neutralización Inadecuada de Entradas Durante la Generación de Páginas Web ('Secuencia de Comandos en Sitios Cruzados') (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))](https://cwe.mitre.org/data/definitions/79.html) + +* [CWE-80 Neutralización Inadecuada de Etiquetas HTML Relacionadas con Scripts en una Página Web (XSS Básico) (Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS))](https://cwe.mitre.org/data/definitions/80.html) + +* [CWE-83 Neutralización Inadecuada de Scripts en Atributos en una Página Web (Improper Neutralization of Script in Attributes in a Web Page)](https://cwe.mitre.org/data/definitions/83.html) + +* [CWE-86 Neutralización Inadecuada de Caracteres Inválidos en Identificadores en Páginas Web (Improper Neutralization of Invalid Characters in Identifiers in Web Pages)](https://cwe.mitre.org/data/definitions/86.html) + +* [CWE-88 Neutralización Inadecuada de Delimitadores de Argumentos en un Comando ('Inyección de Argumentos') (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection'))](https://cwe.mitre.org/data/definitions/88.html) + +* [CWE-89 Neutralización Inadecuada de Elementos Especiales Usados en un Comando SQL ('Inyección SQL') (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))](https://cwe.mitre.org/data/definitions/89.html) + +* [CWE-90 Neutralización Inadecuada de Elementos Especiales Usados en una Consulta LDAP ('Inyección LDAP') (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))](https://cwe.mitre.org/data/definitions/90.html) + +* [CWE-91 Inyección XML (también conocida como Inyección XPath Ciega) (XML Injection (aka Blind XPath Injection))](https://cwe.mitre.org/data/definitions/91.html) + +* [CWE-93 Neutralización Inadecuada de Secuencias CRLF ('Inyección CRLF') (Improper Neutralization of CRLF Sequences ('CRLF Injection'))](https://cwe.mitre.org/data/definitions/93.html) + +* [CWE-94 Control Inadecuado de la Generación de Código ('Inyección de Código') (Improper Control of Generation of Code ('Code Injection'))](https://cwe.mitre.org/data/definitions/94.html) + +* [CWE-95 Neutralización Inadecuada de Directivas en Código Evaluado Dinámicamente ('Inyección Eval') (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))](https://cwe.mitre.org/data/definitions/95.html) + +* [CWE-96 Neutralización Inadecuada de Directivas en Código Guardado Estáticamente ('Inyección de Código Estático') (Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection'))](https://cwe.mitre.org/data/definitions/96.html) + +* [CWE-97 Neutralización Inadecuada de Inclusiones del Lado del Servidor (SSI) Dentro de una Página Web (Improper Neutralization of Server-Side Includes (SSI) Within a Web Page)](https://cwe.mitre.org/data/definitions/97.html) + +* [CWE-98 Control Inadecuado del Nombre de Archivo para Sentencia Include/Require en Programas PHP ('Inclusión Remota de Archivos PHP') (Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion'))](https://cwe.mitre.org/data/definitions/98.html) + +* [CWE-99 Control Inadecuado de Identificadores de Recursos ('Inyección de Recursos') (Improper Control of Resource Identifiers ('Resource Injection'))](https://cwe.mitre.org/data/definitions/99.html) + +* [CWE-103 Struts: Definición Incompleta del Método validate() (Struts: Incomplete validate() Method Definition)](https://cwe.mitre.org/data/definitions/103.html) + +* [CWE-104 Struts: Bean de Formulario No Extiende la Clase de Validación (Struts: Form Bean Does Not Extend Validation Class)](https://cwe.mitre.org/data/definitions/104.html) + +* [CWE-112 Validación XML Faltante (Missing XML Validation)](https://cwe.mitre.org/data/definitions/112.html) + +* [CWE-113 Neutralización Inadecuada de Secuencias CRLF en Cabeceras HTTP ('División de Respuesta HTTP') (Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting'))](https://cwe.mitre.org/data/definitions/113.html) + +* [CWE-114 Control de Procesos (Process Control)](https://cwe.mitre.org/data/definitions/114.html) + +* [CWE-115 Malinterpretación de la Salida (Misinterpretation of Output)](https://cwe.mitre.org/data/definitions/115.html) + +* [CWE-116 Codificación o Escape Inadecuado de la Salida (Improper Encoding or Escaping of Output)](https://cwe.mitre.org/data/definitions/116.html) + +* [CWE-129 Validación Inadecuada del Índice de Arreglo (Improper Validation of Array Index)](https://cwe.mitre.org/data/definitions/129.html) + +* [CWE-159 Manejo Inadecuado del Uso Inválido de Elementos Especiales (Improper Handling of Invalid Use of Special Elements)](https://cwe.mitre.org/data/definitions/159.html) + +* [CWE-470 Uso de Entrada Controlada Externamente para Seleccionar Clases o Código ('Reflexión Insegura') (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))](https://cwe.mitre.org/data/definitions/470.html) + +* [CWE-493 Variable Pública Crítica Sin Modificador Final (Critical Public Variable Without Final Modifier)](https://cwe.mitre.org/data/definitions/493.html) + +* [CWE-500 Campo Estático Público No Marcado como Final (Public Static Field Not Marked Final)](https://cwe.mitre.org/data/definitions/500.html) + +* [CWE-564 Inyección SQL: Hibernate (SQL Injection: Hibernate)](https://cwe.mitre.org/data/definitions/564.html) + +* [CWE-610 Referencia Controlada Externamente a un Recurso en Otra Esfera (Externally Controlled Reference to a Resource in Another Sphere)](https://cwe.mitre.org/data/definitions/610.html) + +* [CWE-643 Neutralización Inadecuada de Datos Dentro de Expresiones XPath ('Inyección XPath') (Improper Neutralization of Data within XPath Expressions ('XPath Injection'))](https://cwe.mitre.org/data/definitions/643.html) + +* [CWE-644 Neutralización Inadecuada de Cabeceras HTTP para Sintaxis de Scripting (Improper Neutralization of HTTP Headers for Scripting Syntax)](https://cwe.mitre.org/data/definitions/644.html) + +* [CWE-917 Neutralización Inadecuada de Elementos Especiales Usados en una Sentencia de Lenguaje de Expresiones ('Inyección de Lenguaje de Expresiones') (Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection'))](https://cwe.mitre.org/data/definitions/917.html) diff --git a/2025/docs/es/A06_2025-Insecure_Design.md b/2025/docs/es/A06_2025-Insecure_Design.md new file mode 100644 index 000000000..f786e1ec4 --- /dev/null +++ b/2025/docs/es/A06_2025-Insecure_Design.md @@ -0,0 +1,165 @@ +# A06:2025 – Diseño Inseguro ![icon](../assets/TOP_10_Icons_Final_Insecure_Design.png){: style="height:80px;width:80px" align="right"} + +## Antecedentes + +Diseño Inseguro baja dos posiciones del #4 al #6 en el ranking, ya que **[A02:2025-Configuración de Seguridad Incorrecta](A02_2025-Security_Misconfiguration.md)** y **[A03:2025-Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md)** la superan. Esta categoría fue introducida en 2021 y hemos observado mejoras notables en la industria relacionadas con el modelado de amenazas y un mayor énfasis en el diseño seguro. Esta categoría se enfoca en los riesgos relacionados con fallas de diseño y arquitectura, con un llamado a un mayor uso de modelado de amenazas, patrones de diseño seguros y arquitecturas de referencia. Esto incluye fallas en la lógica de negocio de una aplicación, por ejemplo, la falta de definición de cambios de estado no deseados o inesperados dentro de una aplicación. Como comunidad, necesitamos ir más allá del "desplazamiento a la izquierda" en el espacio de codificación, hacia actividades previas al código, como la redacción de requisitos y el diseño de aplicaciones, que son fundamentales para los principios de Seguridad por Diseño (ver **[Establecer un Programa Moderno de AppSec: Fase de Planificación y Diseño](0x03_2025-Establishing_a_Modern_Application_Security_Program.md)**). Las Enumeraciones de Debilidades Comunes (CWE) notables incluyen *CWE-256: Almacenamiento Desprotegido de Credenciales, CWE-269: Gestión Incorrecta de Privilegios, CWE-434: Subida sin Restricciones de Archivos de Tipo Peligroso, CWE-501: Violación de Límites de Confianza y CWE-522: Credenciales Insuficientemente Protegidas.* + +## Tabla de Puntuación + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs MapeadasTasa de Incidencia MáxTasa de Incidencia PromCobertura MáxCobertura PromExplotabilidad Ponderada PromImpacto Ponderado PromIncidencias TotalesTotal CVEs
3922.18%1.86%88.76%35.18%6.964.05729,8827,647
+ +## Descripción + +El diseño inseguro es una categoría amplia que representa diferentes debilidades, expresadas como "diseño de control faltante o ineficaz". El diseño inseguro no es la fuente de las otras 10 categorías. Existe una diferencia entre un diseño inseguro y una implementación insegura. Distinguimos entre fallas de diseño y defectos de implementación por un motivo, difieren en la causa raíz y remediaciones. Incluso un diseño seguro puede tener defectos de implementación que conduzcan a vulnerabilidades que pueden explotarse. Un diseño inseguro no se puede arreglar con una implementación perfecta, ya que, por definición, los controles de seguridad necesarios nunca se crearon para defenderse de ataques específicos. Uno de los factores que contribuye al diseño inseguro es la falta de perfiles de riesgo empresarial inherentes al software o sistema en desarrollo y, por lo tanto, la falta de determinación del nivel de diseño de seguridad que se requiere. + +Los tres componentes clave de un diseño seguro son: + +* Recopilación de Requisitos y Gestión de Recursos +* Creación de un Diseño Seguro +* Contar con un Ciclo de Vida de Desarrollo Seguro + +### Gestión de requerimientos y recursos + +Recopile y negocie los requisitos de negocio de la aplicación con las partes interesadas, incluidos los requisitos de protección relacionados con la confidencialidad, integridad, disponibilidad y autenticidad de todos los activos de datos y la lógica de negocio esperada. Tenga en cuenta qué tan expuesta estará su aplicación y si necesita segregación de funcionalidades (además del control de acceso). Recopile los requerimientos técnicos, incluidos los funcionales de seguridad y los no funcionales. Planifique y negocie que el presupuesto cubra el diseño, construcción, prueba y operación, incluyendo las actividades de seguridad. + +### Diseño seguro + +El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de manera sólida para prevenir métodos de ataque conocidos. El modelado de amenazas debe estar integrado en sesiones de refinamiento (o actividades similares); buscar cambios en los flujos de datos y el control de acceso u otros controles de seguridad. Durante la creación de las historias de usuario, determine el flujo correcto y los estados de falla. Asegúrese de que sean bien entendidos y acordados por las partes responsables e impactadas. Analice las suposiciones y las condiciones para los flujos esperados y de falla, asegúrese de que aún sean precisos y deseables. Determine cómo validar las suposiciones y hacer cumplir las condiciones necesarias para los comportamientos adecuados. Asegúrese de que los resultados estén documentados en las historias de usuario. Aprenda de los errores y ofrezca incentivos positivos para promover mejoras. El diseño seguro no es un complemento ni una herramienta que pueda agregar al software. + +### Ciclo de Desarrollo Seguro (S-SDLC) + +El software seguro requiere un ciclo de vide de desarrollo seguro, un patrón de diseño seguro, una metodología de carretera pavimentada ("paved road"), bibliotecas de componentes seguros, herramientas y modelado de amenazas. Comuníquese con sus especialistas en seguridad desde el comienzo y durante todo el proyecto, así como durante su fase de mantenimiento. Considere aprovechar el [Modelo de Madurez para el Aseguramiento del Software (SAMM)](https://owaspsamm.org) para ayudar a estructurar sus esfuerzos de desarrollo de software seguro. + +A menudo se subestima la autorresponsabilidad de los desarrolladores. Fomente una cultura de conciencia, responsabilidad y mitigación proactiva de riesgos. Los intercambios regulares sobre seguridad (por ejemplo, durante sesiones de modelado de amenazas) pueden generar una mentalidad para incluir la seguridad en todas las decisiones de diseño importantes. + +## Cómo se previene + +* Establezca y use un ciclo de vida de desarrollo seguro apoyado en Profesionales en Seguridad de Aplicaciones para ayudarlo a evaluar y diseñar la seguridad y controles relacionados con la privacidad +* Establezca y utilice un catálogo de patrones de diseño seguros o componentes de "camino pavimentado" listos para ser utilizados +* Utilice el modelado de amenazas para flujos críticos de autenticación, control de acceso, lógica de negocio y todo clave +* Use el modelado de amenazas como herramienta educativa para generar una mentalidad de seguridad +* Integre el lenguaje y los controles de seguridad en las historias de usuario +* Integre verificaciones de viabilidad en cada capa de su aplicación (desde el frontend al backend) +* Escriba pruebas unitarias y de integración para validar que todos los flujos críticos son resistentes al modelo de amenazas. Recopile casos de uso *y* casos de mal uso para cada capa de la aplicación. +* Separe las capas del sistema y las capas de red según las necesidades de exposición y protección +* Separe a los tenants de manera robusta por diseño en todos los niveles + +## Ejemplos de Escenarios de Ataque + +**Escenario #1:** Un flujo de trabajo de recuperación de credenciales podría incluir "preguntas y respuestas", lo cual está prohibido por NIST 800-63b, OWASP ASVS y OWASP Top 10. Las preguntas y respuestas no pueden considerarse como evidencia de identidad, ya que más de una persona puede conocer las respuestas. Dicha funcionalidad debe eliminarse y reemplazarse con un diseño más seguro. + +**Escenario #2:** Una cadena de cines permite descuentos en reservas grupales y tiene un máximo de quince asistentes antes de solicitar un depósito. Los atacantes podrían modelar este flujo y probar si pueden encontrar un vector de ataque en la lógica de negocio de la aplicación, por ejemplo, reservar seiscientos asientos en todos los cines a la vez en pocas solicitudes, causando una pérdida masiva de ingresos. + +**Escenario #3:** El sitio web de comercio electrónico de una cadena minorista no tiene protección contra bots administrados por revendedores que compran tarjetas de video de alta gama para revender en sitios de subastas. Esto genera una publicidad terrible para los fabricantes de tarjetas de video y los dueños de la cadena minorista, así como un resentimiento duradero entre los entusiastas que no pueden obtener estas tarjetas a ningún precio. El diseño cuidadoso de medidas anti-bot y reglas de lógica de dominio, como compras realizadas a los pocos segundos de la disponibilidad, pueden identificar compras no auténticas y rechazar dichas transacciones. + +## Referencias + +* [Guía de referencia rápida de OWASP: Principios de Diseño Seguro](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html) +* [OWASP SAMM: Diseño | Arquitectura Segura](https://owaspsamm.org/model/design/secure-architecture/) +* [OWASP SAMM: Diseño | Evaluación de Amenazas](https://owaspsamm.org/model/design/threat-assessment/) +* [NIST – Pautas sobre Estándares Mínimos para la Verificación de Software por Desarrolladores](https://www.nist.gov/publications/guidelines-minimum-standards-developer-verification-software) +* [El Manifiesto de Modelado de Amenazas](https://threatmodelingmanifesto.org/) +* [Asombroso Modelado de Amenazas](https://github.com/hysnsec/awesome-threat-modelling) + +## Lista de CWEs Mapeadas + +* [CWE-73 Control Externo del Nombre o Ruta de Archivo (External Control of File Name or Path)](https://cwe.mitre.org/data/definitions/73.html) + +* [CWE-183 Lista Permisiva de Entradas Permitidas (Permissive List of Allowed Inputs)](https://cwe.mitre.org/data/definitions/183.html) + +* [CWE-256 Almacenamiento Desprotegido de Credenciales (Unprotected Storage of Credentials)](https://cwe.mitre.org/data/definitions/256.html) + +* [CWE-266 Asignación Incorrecta de Privilegios (Incorrect Privilege Assignment)](https://cwe.mitre.org/data/definitions/266.html) + +* [CWE-269 Gestión Incorrecta de Privilegios (Improper Privilege Management)](https://cwe.mitre.org/data/definitions/269.html) + +* [CWE-286 Gestión Incorrecta de Usuarios (Incorrect User Management)](https://cwe.mitre.org/data/definitions/286.html) + +* [CWE-311 Falta de Cifrado de Datos Sensibles (Missing Encryption of Sensitive Data)](https://cwe.mitre.org/data/definitions/311.html) + +* [CWE-312 Almacenamiento en Texto Claro de Información Sensible (Cleartext Storage of Sensitive Information)](https://cwe.mitre.org/data/definitions/312.html) + +* [CWE-313 Almacenamiento en Texto Claro en un Archivo o en Disco (Cleartext Storage in a File or on Disk)](https://cwe.mitre.org/data/definitions/313.html) + +* [CWE-316 Almacenamiento en Texto Claro de Información Sensible en Memoria (Cleartext Storage of Sensitive Information in Memory)](https://cwe.mitre.org/data/definitions/316.html) + +* [CWE-362 Ejecución Concurrente Usando un Recurso Compartido con Sincronización Incorrecta ('Condición de Carrera') (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))](https://cwe.mitre.org/data/definitions/362.html) + +* [CWE-382 Malas Prácticas en J2EE: Uso de System.exit() (J2EE Bad Practices: Use of System.exit())](https://cwe.mitre.org/data/definitions/382.html) + +* [CWE-419 Canal Principal Desprotegido (Unprotected Primary Channel)](https://cwe.mitre.org/data/definitions/419.html) + +* [CWE-434 Subida sin Restricciones de Archivos de Tipo Peligroso (Unrestricted Upload of File with Dangerous Type)](https://cwe.mitre.org/data/definitions/434.html) + +* [CWE-436 Conflicto de Interpretación (Interpretation Conflict)](https://cwe.mitre.org/data/definitions/436.html) + +* [CWE-444 Interpretación Inconsistente de Solicitudes HTTP ('Contrabando de Solicitudes HTTP') (Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling'))](https://cwe.mitre.org/data/definitions/444.html) + +* [CWE-451 Representación Incorrecta de Información Crítica en la Interfaz de Usuario (UI) (User Interface (UI) Misrepresentation of Critical Information)](https://cwe.mitre.org/data/definitions/451.html) + +* [CWE-454 Inicialización Externa de Variables o Almacenes de Datos de Confianza (External Initialization of Trusted Variables or Data Stores)](https://cwe.mitre.org/data/definitions/454.html) + +* [CWE-472 Control Externo de Parámetros Web Asumidos como Inmutables (External Control of Assumed-Immutable Web Parameter)](https://cwe.mitre.org/data/definitions/472.html) + +* [CWE-501 Violación de Límites de Confianza (Trust Boundary Violation)](https://cwe.mitre.org/data/definitions/501.html) + +* [CWE-522 Credenciales Insuficientemente Protegidas (Insufficiently Protected Credentials)](https://cwe.mitre.org/data/definitions/522.html) + +* [CWE-525 Uso de Caché del Navegador Web que Contiene Información Sensible (Use of Web Browser Cache Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/525.html) + +* [CWE-539 Uso de Cookies Persistentes que Contienen Información Sensible (Use of Persistent Cookies Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/539.html) + +* [CWE-598 Uso del Método de Solicitud GET con Cadenas de Consulta Sensibles (Use of GET Request Method With Sensitive Query Strings)](https://cwe.mitre.org/data/definitions/598.html) + +* [CWE-602 Forzamiento en el Lado del Cliente la Seguridad del Lado del Servidor (Client-Side Enforcement of Server-Side Security)](https://cwe.mitre.org/data/definitions/602.html) + +* [CWE-628 Llamada a Función con Argumentos Especificados Incorrectamente (Function Call with Incorrectly Specified Arguments)](https://cwe.mitre.org/data/definitions/628.html) + +* [CWE-642 Control Externo de Datos de Estado Crítico (External Control of Critical State Data)](https://cwe.mitre.org/data/definitions/642.html) + +* [CWE-646 Confianza en el Nombre o Extensión de Archivo Suministrado Externamente (Reliance on File Name or Extension of Externally-Supplied File)](https://cwe.mitre.org/data/definitions/646.html) + +* [CWE-653 Aislamiento o Compartimentación Inadecuado (Improper Isolation or Compartmentalization)](https://cwe.mitre.org/data/definitions/653.html) + +* [CWE-656 Confianza en la Seguridad a través de la Oscuridad (Reliance on Security Through Obscurity)](https://cwe.mitre.org/data/definitions/656.html) + +* [CWE-657 Violación de los Principios de Diseño Seguro (Violation of Secure Design Principles)](https://cwe.mitre.org/data/definitions/657.html) + +* [CWE-676 Uso de Función Potencialmente Peligrosa (Use of Potentially Dangerous Function)](https://cwe.mitre.org/data/definitions/676.html) + +* [CWE-693 Fallo del Mecanismo de Protección (Protection Mechanism Failure)](https://cwe.mitre.org/data/definitions/693.html) + +* [CWE-799 Control Inadecuado de la Frecuencia de Interacción (Improper Control of Interaction Frequency)](https://cwe.mitre.org/data/definitions/799.html) + +* [CWE-807 Confianza en Entradas No Confiables en una Decisión de Seguridad (Reliance on Untrusted Inputs in a Security Decision)](https://cwe.mitre.org/data/definitions/807.html) + +* [CWE-841 Forzamiento Incorrecto del Flujo de Comportamiento (Improper Enforcement of Behavioral Workflow)](https://cwe.mitre.org/data/definitions/841.html) + +* [CWE-1021 Restricción Incorrecta de Capas o Marcos de UI Renderizados (Improper Restriction of Rendered UI Layers or Frames)](https://cwe.mitre.org/data/definitions/1021.html) + +* [CWE-1022 Uso de Enlace Web a un Destino No Confiable con Acceso window.opener (Use of Web Link to Untrusted Target with window.opener Access)](https://cwe.mitre.org/data/definitions/1022.html) + +* [CWE-1125 Superficie de Ataque Excesiva (Excessive Attack Surface)](https://cwe.mitre.org/data/definitions/1125.html) diff --git a/2025/docs/es/A07_2025-Authentication_Failures.md b/2025/docs/es/A07_2025-Authentication_Failures.md new file mode 100644 index 000000000..4837b9413 --- /dev/null +++ b/2025/docs/es/A07_2025-Authentication_Failures.md @@ -0,0 +1,201 @@ +# A07:2025 Fallas de Autenticación ![icon](../assets/TOP_10_Icons_Final_Identification_and_Authentication_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Antecedentes + +Las fallas de Autenticación mantienen su posición en el puesto #7 con un ligero cambio de nombre para reflejar con mayor precisión las 36 CWEs de esta categoría. A pesar de los beneficios de los marcos de trabajo estandarizados, esta categoría ha mantenido su rango #7 desde 2021. Las CWEs notables incluidas son *CWE-259: Uso de contraseñas codificadas, CWE-297: Validación incorrecta de certificado con discrepancia de host, CWE-287: Autenticación incorrecta, CWE-384: Fijación de sesión y CWE-798: Uso de credenciales codificadas*. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Tasa Máxima de Incidencia + Tasa Promedio de Incidencia + Cobertura Máxima + Cobertura Promedio + Promedio Ponderado de Explotación + Promedio Ponderado de Impacto + Ocurrencias Totales + CVEs Totales +
36 + 15.80% + 2.92% + 100.00% + 37.14% + 7.69 + 4.44 + 1,120,673 + 7,147 +
+ + + +## Descripción + +Esta vulnerabilidad está presente cuando un atacante es capaz de engañar a un sistema para que reconozca como legítimo a un usuario inválido o incorrecto. Puede haber debilidades de autenticación si la aplicación: + +* Permite ataques automatizados como el relleno de credenciales (credential stuffing), donde el atacante dispone de una lista filtrada de nombres de usuario y contraseñas válidos. Recientemente, este tipo de ataque se ha ampliado para incluir ataques de contraseñas híbridos (también conocidos como ataques de aspersión de contraseñas o password spray), en los que el atacante utiliza variaciones o incrementos de credenciales comprometidas para obtener acceso; por ejemplo, probando Password1!, Password2!, Password3!, y así sucesivamente. + +* Permite ataques de fuerza bruta u otros ataques automatizados y programados (scripts) que no se bloquean rápidamente. + +* Permite contraseñas predeterminadas, débiles o muy conocidas, como "Password1" o un nombre de usuario "admin" con una contraseña "admin". + +* Permite a los usuarios crear nuevas cuentas con credenciales que ya se sabe que han sido vulneradas. + +* Permite el uso de procesos de recuperación de credenciales y de olvido de contraseña débiles o ineficaces, como las "preguntas de seguridad basadas en el conocimiento", que no pueden hacerse seguras. + +* Utiliza almacenes de datos de contraseñas en texto claro, cifrados o con hash débil (ver [A04:2025-Fallas Criptográficas](https://owasp.org/Top10/2025/A04_2025-Cryptographic_Failures/)). + +* Carece de autenticación de múltiples factores (MFA) o esta es ineficaz. + +* Permite el uso de alternativas (fallbacks) débiles o ineficaces si la autenticación de múltiples factores no está disponible. + +* Expone el identificador de sesión en la URL, en un campo oculto o en otra ubicación insegura accesible para el cliente. + +* Reutiliza el mismo identificador de sesión después de un inicio de sesión exitoso. + +* No invalida correctamente las sesiones de usuario o los tokens de autenticación (principalmente los tokens de inicio de sesión único (SSO)) durante el cierre de sesión o tras un periodo de inactividad. + +* No valida correctamente el alcance (scope) y la audiencia prevista de las credenciales proporcionadas. + + +## Cómo prevenir + +* Siempre que sea posible, implementar y aplicar el uso de la autenticación de múltiples factores (MFA) para evitar ataques automatizados de relleno de credenciales, fuerza bruta y reutilización de credenciales robadas. + +* Siempre que sea posible, fomentar y habilitar el uso de gestores de contraseñas para ayudar a los usuarios a tomar mejores decisiones. + +* No distribuir ni desplegar aplicaciones con credenciales predeterminadas, especialmente para los usuarios administradores. + +* Implementar comprobaciones de contraseñas débiles, como probar las contraseñas nuevas o modificadas contra la lista de las 10,000 peores contraseñas. + +* Durante la creación de nuevas cuentas y los cambios de contraseña, validar contra listas de credenciales que se sabe han sido vulneradas (por ejemplo: utilizando [haveibeenpwned.com](https://haveibeenpwned.com)). + +* Alinear la longitud, la complejidad y las políticas de rotación de las contraseñas con las [directrices del Instituto Nacional de Estándares y Tecnología (NIST) 800-63b en la sección 5.1.1](https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=5.1.1%20Memorized%20Secrets) para Secretos Memorizados u otras políticas de contraseñas modernas y basadas en evidencias. + +* No obligar a los seres humanos a rotar las contraseñas a menos que se sospeche de una vulneración. Si se sospecha de una vulneración, forzar el restablecimiento de las contraseñas de inmediato. + +* Asegurarse de que las rutas de registro, recuperación de credenciales y API estén protegidas contra ataques de enumeración de cuentas utilizando los mismos mensajes para todos los resultados ("Nombre de usuario o contraseña inválidos"). + +* Limitar o retrasar de forma incremental los intentos fallidos de inicio de sesión, pero teniendo cuidado de no crear un escenario de denegación de servicio. Registrar todas las fallas y alertar a los administradores cuando se detecten o sospechen ataques de relleno de credenciales, fuerza bruta u otros. + +* Utilizar un gestor de sesiones integrado, seguro y del lado del servidor que genere un nuevo ID de sesión aleatorio con alta entropía después del inicio de sesión. Los identificadores de sesión no deben estar en la URL, deben almacenarse de forma segura en una cookie segura e invalidarse tras el cierre de sesión, por inactividad y tras tiempos de espera absolutos. + +* Idealmente, utilizar un sistema ya establecido y de confianza para gestionar la autenticación, la identidad y la gestión de sesiones. Transferir este riesgo siempre que sea posible adquiriendo y utilizando un sistema robusto y bien probado. + +* Verificar el uso previsto de las credenciales proporcionadas; por ejemplo, para los JWT, validar las afirmaciones (*claims*) `aud`, `iss` y los alcances (scopes). + + +## Ejemplos de escenarios de ataque + +**Escenario #1:** El relleno de credenciales (credential stuffing), es decir, el uso de listas de combinaciones conocidas de nombre de usuario y contraseña, es actualmente un ataque muy común. Recientemente, se ha descubierto que los atacantes "incrementan" o ajustan de otro modo las contraseñas, basándose en el comportamiento humano común. Por ejemplo, cambiando 'Invierno2025' por 'Invierno2026', o 'AmoAMiPerro6' por 'AmoAMiPerro7' o 'AmoAMiPerro5'. Este ajuste de los intentos de contraseña se denomina ataque de relleno de credenciales híbrido o ataque de aspersión de contraseñas (password spray), y pueden ser incluso más eficaces que la versión tradicional. Si una aplicación no implementa defensas contra amenazas automatizadas (fuerza bruta, scripts o bots) o relleno de credenciales, la aplicación puede utilizarse como un "oráculo de contraseñas" para determinar si las credenciales son válidas y obtener acceso no autorizado. + +**Escenario #2:** La mayoría de los ataques de autenticación con éxito se producen debido al uso continuado de las contraseñas como único factor de autenticación. Lo que antes se consideraba una buena práctica, como los requisitos de rotación y complejidad de las contraseñas, incita a los usuarios tanto a reutilizar contraseñas como a usar contraseñas débiles. Se recomienda a las organizaciones que dejen de aplicar estas prácticas, según la norma NIST 800-63, y que impongan el uso de la autenticación de múltiples factores en todos los sistemas importantes. + +**Escenario #3:** Los tiempos de espera de las sesiones de la aplicación no se han implementado correctamente. Un usuario utiliza un ordenador público para acceder a una aplicación y, en lugar de seleccionar "cerrar sesión", simplemente cierra la pestaña del navegador y se marcha. Otro ejemplo de esto es si una sesión de inicio de sesión único (SSO) no puede cerrarse mediante un cierre de sesión único (SLO). Es decir, un único inicio de sesión le permite acceder, por ejemplo, a su lector de correo, a su sistema de documentos y a su sistema de chat. Pero el cierre de sesión solo se produce en el sistema actual. Si un atacante utiliza el mismo navegador después de que la víctima crea que ha cerrado la sesión con éxito, pero con el usuario todavía autenticado en algunas de las aplicaciones, podrá acceder a la cuenta de la víctima. El mismo problema puede ocurrir en oficinas y empresas cuando no se ha salido correctamente de una aplicación sensible y un colega tiene acceso (temporal) al ordenador desbloqueado. + + +## Referencias + +* [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) + +* [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/01-introduction/05-introduction) + + +## Lista de CWEs Mapeadas + +* [CWE-258 Contraseña Vacía en Archivo de Configuración (Empty Password in Configuration File)](https://cwe.mitre.org/data/definitions/258.html) + +* [CWE-259 Uso de Contraseña Codificada de Forma Rígida (Use of Hard-coded Password)](https://cwe.mitre.org/data/definitions/259.html) + +* [CWE-287 Autenticación Incorrecta (Improper Authentication)](https://cwe.mitre.org/data/definitions/287.html) + +* [CWE-288 Elusión de Autenticación Mediante una Ruta o Canal Alternativo (Authentication Bypass Using an Alternate Path or Channel)](https://cwe.mitre.org/data/definitions/288.html) + +* [CWE-289 Elusión de Autenticación por Nombre Alternativo (Authentication Bypass by Alternate Name)](https://cwe.mitre.org/data/definitions/289.html) + +* [CWE-290 Elusión de Autenticación por Suplantación de Identidad (Authentication Bypass by Spoofing)](https://cwe.mitre.org/data/definitions/290.html) + +* [CWE-291 Dependencia de la Dirección IP para la Autenticación (Reliance on IP Address for Authentication)](https://cwe.mitre.org/data/definitions/291.html) + +* [CWE-293 Uso del Campo Referer para la Autenticación (Using Referer Field for Authentication)](https://cwe.mitre.org/data/definitions/293.html) + +* [CWE-294 Elusión de Autenticación por Captura y Repetición (Authentication Bypass by Capture-replay)](https://cwe.mitre.org/data/definitions/294.html) + +* [CWE-295 Validación Inadecuada del Certificado (Improper Certificate Validation)](https://cwe.mitre.org/data/definitions/295.html) + +* [CWE-297 Validación Inadecuada del Certificado con Discrepancia de Host (Improper Validation of Certificate with Host Mismatch)](https://cwe.mitre.org/data/definitions/297.html) + +* [CWE-298 Validación Inadecuada de la Caducidad del Certificado (Improper Validation of Certificate Expiration)](https://cwe.mitre.org/data/definitions/298.html) + +* [CWE-299 Validación Inadecuada de la Revocación del Certificado (Improper Check for Certificate Revocation)](https://cwe.mitre.org/data/definitions/299.html) + +* [CWE-300 Canal Accesible por un No-Punto Final (Channel Accessible by Non-Endpoint)](https://cwe.mitre.org/data/definitions/300.html) + +* [CWE-302 Elusión de Autenticación por Datos Supuestamente Inmutables (Authentication Bypass by Assumed-Immutable Data)](https://cwe.mitre.org/data/definitions/302.html) + +* [CWE-303 Implementación Incorrecta del Algoritmo de Autenticación (Incorrect Implementation of Authentication Algorithm)](https://cwe.mitre.org/data/definitions/303.html) + +* [CWE-304 Falta de un Paso Crítico en la Autenticación (Missing Critical Step in Authentication)](https://cwe.mitre.org/data/definitions/304.html) + +* [CWE-305 Elusión de Autenticación por Debilidad Primaria (Authentication Bypass by Primary Weakness)](https://cwe.mitre.org/data/definitions/305.html) + +* [CWE-306 Falta de Autenticación para una Función Crítica (Missing Authentication for Critical Function)](https://cwe.mitre.org/data/definitions/306.html) + +* [CWE-307 Restricción Inadecuada de Intentos Excesivos de Autenticación (Improper Restriction of Excessive Authentication Attempts)](https://cwe.mitre.org/data/definitions/307.html) + +* [CWE-308 Uso de Autenticación de Factor Único (Use of Single-factor Authentication)](https://cwe.mitre.org/data/definitions/308.html) + +* [CWE-309 Uso del Sistema de Contraseñas para la Autenticación Primaria (Use of Password System for Primary Authentication)](https://cwe.mitre.org/data/definitions/309.html) + +* [CWE-346 Error de Validación de Origen (Origin Validation Error)](https://cwe.mitre.org/data/definitions/346.html) + +* [CWE-350 Dependencia de la Resolución DNS Inversa para una Acción Crítica de Seguridad (Reliance on Reverse DNS Resolution for a Security-Critical Action)](https://cwe.mitre.org/data/definitions/350.html) + +* [CWE-384 Fijación de Sesión (Session Fixation)](https://cwe.mitre.org/data/definitions/384.html) + +* [CWE-521 Requisitos de Contraseña Débiles (Weak Password Requirements)](https://cwe.mitre.org/data/definitions/521.html) + +* [CWE-613 Expiración de Sesión Insuficiente (Insufficient Session Expiration)](https://cwe.mitre.org/data/definitions/613.html) + +* [CWE-620 Cambio de Contraseña no Verificado (Unverified Password Change)](https://cwe.mitre.org/data/definitions/620.html) + +* [CWE-640 Mecanismo de Recuperación de Contraseña Débil (Weak Password Recovery Mechanism for Forgotten Password)](https://cwe.mitre.org/data/definitions/640.html) + +* [CWE-798 Uso de Credenciales Codificadas de Forma Rígida (Use of Hard-coded Credentials)](https://cwe.mitre.org/data/definitions/798.html) + +* [CWE-940 Verificación Inadecuada del Origen de un Canal de Comunicación (Improper Verification of Source of a Communication Channel)](https://cwe.mitre.org/data/definitions/940.html) + +* [CWE-941 Destino Especificado Incorrectamente en un Canal de Comunicación (Incorrectly Specified Destination in a Communication Channel)](https://cwe.mitre.org/data/definitions/941.html) + +* [CWE-1390 Autenticación Débil (Weak Authentication)](https://cwe.mitre.org/data/definitions/1390.html) + +* [CWE-1391 Uso de Credenciales Débiles (Use of Weak Credentials)](https://cwe.mitre.org/data/definitions/1391.html) + +* [CWE-1392 Uso de Credenciales por Defecto (Use of Default Credentials)](https://cwe.mitre.org/data/definitions/1392.html) + +* [CWE-1393 Uso de Contraseña por Defecto (Use of Default Password)](https://cwe.mitre.org/data/definitions/1393.html) diff --git a/2025/docs/es/A08_2025-Software_or_Data_Integrity_Failures.md b/2025/docs/es/A08_2025-Software_or_Data_Integrity_Failures.md new file mode 100644 index 000000000..8175aa563 --- /dev/null +++ b/2025/docs/es/A08_2025-Software_or_Data_Integrity_Failures.md @@ -0,0 +1,121 @@ +# A08:2025 Fallas en la Integridad del Software o de los Datos ![icon](../assets/TOP_10_Icons_Final_Software_and_Data_Integrity_Failures.png){: style="height:80px;width:80px" align="right"} + +## Antecedentes + +Las fallas en la Integridad del Software o de los Datos continúan en el puesto #8, con un ligero cambio de nombre aclaratorio de "Fallas de Integridad de Software *o* Datos" (anteriormente "Fallas de Integridad de Software *y* Datos"). Esta categoría se centra en la falla de mantener los límites de confianza y verificar la integridad del software, el código y los artefactos de datos a un nivel inferior al de las fallas en la Cadena de Suministro de Software. Esta categoría se enfoca en hacer suposiciones relacionadas con las actualizaciones de software y los datos críticos, sin verificar su integridad. Las Enumeraciones de Debilidades Comunes (CWEs) notables incluyen *CWE-829: Inclusión de funcionalidad de una esfera de control no confiable, CWE-915: Modificación controlada incorrectamente de atributos de objetos determinados dinámicamente y CWE-502: Deserialización de datos no confiables*. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Tasa Máxima de Incidencia + Tasa Promedio de Incidencia + Cobertura Máxima + Cobertura Promedio + Promedio Ponderado de Explotación + Promedio Ponderado de Impacto + Ocurrencias Totales + CVEs Totales +
14 + 8.98% + 2.75% + 78.52% + 45.49% + 7.11 + 4.79 + 501,327 + 3,331 +
+ + + +## Descripción + +Las fallas de integridad de software y datos se relacionan con el código y la infraestructura que no protege contra el hecho de que el código o los datos inválidos o no confiables sean tratados como confiables y válidos. Un ejemplo de esto es cuando una aplicación confía en complementos (plugins), bibliotecas o módulos de fuentes, repositorios y redes de entrega de contenidos (CDN) no confiables. Una canalización (pipeline) CI/CD insegura, sin el uso y la provisión de comprobaciones de integridad del software, puede dar lugar a la posibilidad de acceso no autorizado, código inseguro o malicioso, o compromiso del sistema. Otro ejemplo de esto es un CI/CD que extrae código o artefactos de lugares no confiables y/o no los verifica antes de su uso (mediante la comprobación de la firma o un mecanismo similar). Por último, muchas aplicaciones incluyen ahora una funcionalidad de actualización automática, en la que las actualizaciones se descargan sin una verificación de integridad suficiente y se aplican a la aplicación previamente confiable. Los atacantes podrían subir sus propias actualizaciones para que se distribuyan y ejecuten en todas las instalaciones. Otro ejemplo es cuando los objetos o datos se codifican o serializan en una estructura que un atacante puede ver y modificar, lo cual es vulnerable a la deserialización insegura. + + +## Cómo prevenir + +* Utilizar firmas digitales o mecanismos similares para verificar que el software o los datos proceden de la fuente esperada y no han sido alterados. +* Asegurarse de que las bibliotecas y dependencias, como npm o Maven, solo consuman repositorios de confianza. Si se tiene un perfil de riesgo elevado, se debe considerar la posibilidad de alojar un repositorio interno con versiones de confianza que haya sido verificado. +* Garantizar que exista un proceso de revisión de los cambios de código y configuración para minimizar la posibilidad de que se introduzca código o configuración maliciosa en su flujo de software. +* Asegurarse de que su canalización CI/CD tenga la segregación, configuración y control de acceso adecuados para garantizar la integridad del código que fluye a través de los procesos de construcción y despliegue. +* Garantizar que no se reciban datos serializados sin firmar o sin cifrar de clientes no confiables y que se utilicen posteriormente sin algún tipo de comprobación de integridad o firma digital para detectar la manipulación o el reenvío (replay) de los datos serializados. + + +## Ejemplos de escenarios de ataque + +**Escenario #1: Inclusión de funcionalidad web de una fuente no confiable:** Una empresa utiliza un proveedor de servicios externo para proporcionar una funcionalidad de soporte. Por conveniencia, tiene un mapeo de DNS de `miEmpresa.ProveedorSoporte.com` a `soporte.miEmpresa.com`. Esto significa que todas las cookies, incluidas las de autenticación, establecidas en el dominio `miEmpresa.com` se enviarán ahora al proveedor de soporte. Cualquier persona con acceso a la infraestructura del proveedor de soporte puede robar las cookies de todos sus usuarios que hayan visitado `soporte.miEmpresa.com` y realizar un ataque de secuestro de sesión (session hijacking). + +**Escenario #2: Actualización sin firma:** Muchos routers domésticos, decodificadores, firmware de dispositivos y otros, no verifican las actualizaciones mediante firmware firmado. El firmware no firmado es un objetivo creciente para los atacantes y se espera que la situación empeore. Esto es una gran preocupación, ya que muchas veces no hay más mecanismo de remediación que corregirlo en una versión futura y esperar a que las versiones anteriores dejen de utilizarse. + +**Escenario #3: Uso de un paquete de una fuente no confiable:** Un desarrollador tiene problemas para encontrar la versión actualizada de un paquete que está buscando, por lo que lo descarga no del gestor de paquetes habitual y de confianza, sino de un sitio web en internet. El paquete no está firmado y, por lo tanto, no hay oportunidad de garantizar su integridad. El paquete incluye código malicioso. + +**Escenario #4: Deserialización insegura:** Una aplicación React llama a un conjunto de microservicios de Spring Boot. Al ser programadores funcionales, trataron de asegurar que su código fuera inmutable. La solución que se les ocurrió es serializar el estado del usuario y pasarlo de un lado a otro con cada solicitud. Un atacante observa la firma del objeto Java "rO0" (en base64) y utiliza el [Escáner de Deserialización de Java](https://github.com/federicodotta/Java-Deserialization-Scanner) para obtener la ejecución remota de código en el servidor de la aplicación. + + +## Referencias + +* [OWASP Cheat Sheet: Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Infrastructure as Code](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html) +* [OWASP Cheat Sheet: Deserialization](https://wiki.owasp.org/index.php/Deserialization_Cheat_Sheet) +* [SAFECode Software Integrity Controls](https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf) +* [A 'Worst Nightmare' Cyberattack: The Untold Story Of The SolarWinds Hack](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack) +* [CodeCov Bash Uploader Compromise](https://about.codecov.io/security-update) +* [Securing DevOps by Julien Vehent](https://www.manning.com/books/securing-devops) +* [Insecure Deserialization by Tenendo](https://tenendo.com/insecure-deserialization/) + + +## Lista de CWEs Mapeadas + +* [CWE-345 Verificación Insuficiente de la Autenticidad de los Datos (Insufficient Verification of Data Authenticity)](https://cwe.mitre.org/data/definitions/345.html) + +* [CWE-353 Falta de Soporte para la Verificación de Integridad (Missing Support for Integrity Check)](https://cwe.mitre.org/data/definitions/353.html) + +* [CWE-426 Ruta de Búsqueda No Confiable (Untrusted Search Path)](https://cwe.mitre.org/data/definitions/426.html) + +* [CWE-427 Elemento de Ruta de Búsqueda No Controlado (Uncontrolled Search Path Element)](https://cwe.mitre.org/data/definitions/427.html) + +* [CWE-494 Descarga de Código sin Verificación de Integridad (Download of Code Without Integrity Check)](https://cwe.mitre.org/data/definitions/494.html) + +* [CWE-502 Deserialización de Datos No Confiables (Deserialization of Untrusted Data)](https://cwe.mitre.org/data/definitions/502.html) + +* [CWE-506 Código Malicioso Incrustado (Embedded Malicious Code)](https://cwe.mitre.org/data/definitions/506.html) + +* [CWE-509 Código Malicioso que se Replica (Virus o Gusano) (Replicating Malicious Code (Virus or Worm))](https://cwe.mitre.org/data/definitions/509.html) + +* [CWE-565 Dependencia de Cookies sin Validación ni Verificación de Integridad (Reliance on Cookies without Validation and Integrity Checking)](https://cwe.mitre.org/data/definitions/565.html) + +* [CWE-784 Dependencia de Cookies sin Validación ni Verificación de Integridad en una Decisión de Seguridad (Reliance on Cookies without Validation and Integrity Checking in a Security Decision)](https://cwe.mitre.org/data/definitions/784.html) + +* [CWE-829 Inclusión de Funcionalidad desde una Esfera de Control No Confiable (Inclusion of Functionality from Untrusted Control Sphere)](https://cwe.mitre.org/data/definitions/829.html) + +* [CWE-830 Inclusión de Funcionalidad Web desde una Fuente No Confiable (Inclusion of Web Functionality from an Untrusted Source)](https://cwe.mitre.org/data/definitions/830.html) + +* [CWE-915 Modificación Controlada de Forma Inadecuada de Atributos de Objetos Determinados Dinámicamente (Improperly Controlled Modification of Dynamically-Determined Object Attributes)](https://cwe.mitre.org/data/definitions/915.html) + +* [CWE-926 Exportación Inadecuada de Componentes de Aplicaciones Android (Improper Export of Android Application Components)](https://cwe.mitre.org/data/definitions/926.html) diff --git a/2025/docs/es/A09_2025-Security_Logging_and_Alerting_Failures.md b/2025/docs/es/A09_2025-Security_Logging_and_Alerting_Failures.md new file mode 100644 index 000000000..c60a95b50 --- /dev/null +++ b/2025/docs/es/A09_2025-Security_Logging_and_Alerting_Failures.md @@ -0,0 +1,136 @@ +# A09:2025 Fallas en el Registro, Alerta y Monitoreo de Seguridad ![icon](../assets/TOP_10_Icons_Final_Security_Logging_and_Monitoring_Failures.png){: style="height:80px;width:80px" align="right"} + + +## Antecedentes + +Las fallas en el Registro, Alerta y Monitoreo de Seguridad mantienen su posición en el puesto #9. Esta categoría tiene un ligero cambio de nombre para enfatizar la función de alerta necesaria para inducir la acción ante eventos de registro relevantes. Esta categoría siempre estará infrarrepresentada en los datos y, por tercera vez, fue votada en una posición de la lista por los participantes de la encuesta de la comunidad. Esta categoría es increíblemente difícil de probar y tiene una representación mínima en los datos de CVE/CVSS (solo 723 CVE); pero puede tener un gran impacto en la visibilidad, las alertas de incidentes y la informática forense. Esta categoría incluye problemas con el *manejo adecuado de la codificación de salida hacia los archivos de registro (CWE-117), la inserción de datos sensibles en los archivos de registro (CWE-532) y el registro insuficiente (CWE-778).* + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Tasa Máxima de Incidencia + Tasa Promedio de Incidencia + Cobertura Máxima + Cobertura Promedio + Promedio Ponderado de Explotación + Promedio Ponderado de Impacto + Ocurrencias Totales + CVEs Totales +
5 + 11.33% + 3.91% + 85.96% + 46.48% + 7.19 + 2.65 + 260,288 + 723 +
+ + + +## Descripción + +Sin registro (logging) y monitoreo (monitoring), los ataques y las brechas de seguridad no pueden detectarse, y sin alertas (alerting) es muy difícil responder de forma rápida y eficaz durante un incidente de seguridad. Las fallas por registro, monitoreo continuo, detección y alertas insuficientes para iniciar respuestas activas se producen siempre que: + + +* No se registran eventos auditables, como los inicios de sesión, las fallas de inicio de sesión y las transacciones de alto valor, o se registran de forma incoherente (por ejemplo, registrando solo los inicios de sesión correctos, pero no los intentos fallidos). +* Las advertencias y los errores no generan mensajes de registro, o estos son inadecuados o poco claros. +* La integridad de los registros no está debidamente protegida contra la manipulación. +* Los registros de las aplicaciones y las API no se monitorean para detectar actividades sospechosas. +* Los registros solo se almacenan localmente y no se dispone de las copias de seguridad adecuadas. +* No existen o no son efectivos los umbrales de alerta y los procesos de escalado de respuesta adecuados. Las alertas no se reciben o no se revisan en un tiempo razonable. +* Las pruebas de penetración (pentesting) y los escaneos mediante herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST) (como Burp Suite o ZAP) no activan alertas. +* La aplicación no puede detectar, escalar o alertar sobre ataques activos en tiempo real o casi en tiempo real. +* Se es vulnerable a la filtración de información sensible al hacer visibles los eventos de registro y alerta para un usuario o un atacante (ver [A01:2025-Pérdida de Control de Acceso](A01_2025-Broken_Access_Control.md)), o al registrar información sensible que no debería registrarse (como PII o PHI). +* Se es vulnerable a inyecciones o ataques a los sistemas de registro o monitoreo si los datos de los registros no están correctamente codificados. +* La aplicación carece de errores u otras condiciones excepcionales, o los gestiona de forma inadecuada, de modo que el sistema no es consciente de que se ha producido un error y, por tanto, no puede registrar que ha habido un problema. +* Faltan "casos de uso" adecuados para la emisión de alertas o estos están desactualizados para reconocer una situación especial. +* Demasiadas alertas de falsos positivos hacen imposible distinguir las alertas importantes de las que no lo son, lo que provoca que se reconozcan demasiado tarde o no se reconozcan en absoluto (sobrecarga física del equipo del SOC). +* Las alertas detectadas no pueden procesarse correctamente porque el manual de procedimientos (playbook) para el caso de uso es incompleto, está desactualizado o no existe. + + +## Cómo prevenir + +Los desarrolladores deben implementar algunos o todos los controles siguientes, dependiendo del riesgo de la aplicación: + + +* Asegurarse de que todas las fallas de inicio de sesión, control de acceso y validación de entradas del lado del servidor puedan registrarse con suficiente contexto de usuario para identificar cuentas sospechosas o maliciosas, y conservarse durante el tiempo suficiente para permitir un análisis forense retardado. +* Asegurarse de que se registre cada parte de la aplicación que contenga un control de seguridad, tanto si tiene éxito como si falla. +* Asegurarse de que los registros se generen en un formato que las soluciones de gestión de registros puedan consumir fácilmente. +* Asegurarse de que los datos de registro estén codificados correctamente para evitar inyecciones o ataques a los sistemas de registro o monitoreo. +* Asegurarse de que todas las transacciones tengan un rastro de auditoría con controles de integridad para evitar su manipulación o eliminación, como tablas de bases de datos de solo adición (append-only) o similares. +* Asegurarse de que todas las transacciones que arrojen un error se reviertan (roll back) y se inicien de nuevo. Fallar siempre de forma segura (fail closed). +* Si su aplicación o sus usuarios se comportan de forma sospechosa, emita una alerta. Elabore directrices para sus desarrolladores sobre este tema para que puedan programar en consecuencia o adquiera un sistema para ello. +* Los equipos de DevSecOps y de seguridad deben establecer casos de uso de monitoreo y alerta eficaces, incluidos manuales de procedimientos (playbooks), de modo que las actividades sospechosas sean detectadas y respondidas rápidamente por el equipo del Centro de Operaciones de Seguridad (SOC). +* Añada 'honeytokens' (tokens trampa) como trampas para atacantes en su aplicación; por ejemplo, en la base de datos, en los datos, como identidades de usuario reales y/o técnicas. Al no utilizarse en la actividad normal del negocio, cualquier acceso genera datos de registro que pueden activar una alerta casi sin falsos positivos. +* El análisis del comportamiento y el apoyo de la IA podrían ser, opcionalmente, una técnica adicional para ayudar a conseguir bajas tasas de falsos positivos en las alertas. +* Establecer o adoptar un plan de respuesta y recuperación de incidentes, como el del Instituto Nacional de Estándares y Tecnología (NIST) 800-61r2 o posterior. Enseñe a sus desarrolladores de software cómo son los ataques e incidentes en las aplicaciones para que puedan informarlos. + +Existen productos comerciales y de código abierto para la protección de aplicaciones, como el OWASP ModSecurity Core Rule Set, y software de correlación de registros de código abierto, como el stack de Elasticsearch, Logstash, Kibana (ELK), que cuentan con cuadros de mando personalizados y alertas que pueden ayudarle a combatir estos problemas. También existen herramientas comerciales de observabilidad que pueden ayudarle a responder a los ataques o a bloquearlos casi en tiempo real. + + +## Ejemplos de escenarios de ataque + +**Escenario #1:** El operador del sitio web de un proveedor de planes de salud infantil no pudo detectar una brecha de seguridad debido a la falta de monitoreo y registro. Un tercero informó al proveedor del plan de salud que un atacante había accedido y modificado miles de registros sanitarios sensibles de más de 3.5 millones de niños. Una revisión posterior al incidente determinó que los desarrolladores del sitio web no habían subsanado vulnerabilidades importantes. Al no haber registro ni monitoreo del sistema, la brecha de datos podría haber estado en curso desde 2013, un periodo de más de siete años. + +**Escenario #2:** Una importante compañía aérea india sufrió una filtración de datos que afectó a más de diez años de datos personales de millones de pasajeros, incluidos datos de pasaportes y tarjetas de crédito. La filtración de datos se produjo en un proveedor externo de alojamiento en la nube, que notificó a la aerolínea la filtración después de algún tiempo. + +**Escenario #3:** Una importante aerolínea europea sufrió una brecha de seguridad notificable según el GDPR. Al parecer, la brecha fue causada por vulnerabilidades de seguridad en la aplicación de pagos explotadas por atacantes, que recolectaron más de 400,000 registros de pagos de clientes. Como consecuencia, el regulador de la privacidad multó a la aerolínea con 20 millones de libras. + + +## Referencias + +- [OWASP Proactive Controls: C9: Implement Logging and Monitoring](https://top10proactive.owasp.org/archive/2024/the-top-10/c9-security-logging-and-monitoring/) + +- [OWASP Application Security Verification Standard: V16 Security Logging and Error Handling](https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md) + +- [OWASP Cheat Sheet: Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Application_Logging_Vocabulary_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [Data Integrity: Recovering from Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-11/final) + +- [Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-25/final) + +- [Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/publications/detail/sp/1800-26/final) + +- [Real world example of such failures in Snowflake Breach](https://www.huntress.com/threat-library/data-breach/snowflake-data-breach) + + +## Lista de CWEs Mapeadas + +* [CWE-117 Neutralización Inadecuada de la Salida para Registros (Improper Output Neutralization for Logs)](https://cwe.mitre.org/data/definitions/117.html) + +* [CWE-221 Pérdida de Información por Omisión (Information Loss or Omission)](https://cwe.mitre.org/data/definitions/221.html) + +* [CWE-223 Omisión de Información Relevante para la Seguridad (Omission of Security-relevant Information)](https://cwe.mitre.org/data/definitions/223.html) + +* [CWE-532 Inserción de Información Sensible en un Archivo de Registro (Insertion of Sensitive Information into Log File)](https://cwe.mitre.org/data/definitions/532.html) + +* [CWE-778 Registro Insuficiente (Insufficient Logging)](https://cwe.mitre.org/data/definitions/778.html) diff --git a/2025/docs/es/A10_2025-Mishandling_of_Exceptional_Conditions.md b/2025/docs/es/A10_2025-Mishandling_of_Exceptional_Conditions.md new file mode 100644 index 000000000..c13330639 --- /dev/null +++ b/2025/docs/es/A10_2025-Mishandling_of_Exceptional_Conditions.md @@ -0,0 +1,147 @@ +# A10:2025 Manejo Inadecuado de Condiciones Excepcionales ![icon](../assets/TOP_10_Icons_Final_Mishandling_of_Exceptional_Conditions.png){: style="height:80px;width:80px" align="right"} + + +## Antecedentes + +El Manejo Inadecuado de Condiciones Excepcionales es una categoría nueva para 2025. Esta categoría contiene 24 CWE y se centra en el manejo inadecuado de errores, errores lógicos, fallas de forma abierta (failing open) y otros escenarios relacionados derivados de condiciones anormales que los sistemas pueden encontrar. Esta categoría incluye algunas CWE que anteriormente se asociaban con una mala calidad del código. Aquello era demasiado general para nosotros; en nuestra opinión, esta categoría más específica proporciona una mejor orientación. + +CWE notables incluidas en esta categoría: *CWE-209: Generación de mensajes de error que contienen información sensible, CWE-234: Omisión del manejo de parámetros faltantes, CWE-274: Manejo inadecuado de privilegios insuficientes, CWE-476: Desreferencia de puntero NULL,* y *CWE-636: No fallar de forma segura ('Fallar de forma abierta' / 'Failing Open')*. + + +## Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeadas + Tasa Máxima de Incidencia + Tasa Promedio de Incidencia + Cobertura Máxima + Cobertura Promedio + Promedio Ponderado de Explotación + Promedio Ponderado de Impacto + Ocurrencias Totales + CVEs Totales +
24 + 20.67% + 2.95% + 100.00% + 37.95% + 7.11 + 3.81 + 769,581 + 3,416 +
+ + + +## Descripción + +El manejo inadecuado de condiciones excepcionales en el software ocurre cuando los programas no logran prevenir, detectar y responder a situaciones inusuales e impredecibles, lo que provoca caídas (crashes), comportamientos inesperados y, a veces, vulnerabilidades. Esto puede implicar uno o más de los siguientes tres fallas: la aplicación no previene que ocurra una situación inusual, no identifica la situación mientras está ocurriendo y/o responde de forma deficiente o no responde en absoluto a la situación posteriormente. + + + +Las condiciones excepcionales pueden ser causadas por una validación de entradas ausente, deficiente o incompleta; por un manejo de errores de alto nivel tardío en lugar de realizarse en las funciones donde ocurren; por estados ambientales inesperados como problemas de memoria, privilegios o red; por un manejo de excepciones inconsistente o por excepciones que no se manejan en absoluto, permitiendo que el sistema caiga en un estado desconocido e impredecible. Cada vez que una aplicación no está segura de su siguiente instrucción, se ha manejado inadecuadamente una condición excepcional. Los errores y excepciones difíciles de encontrar pueden amenazar la seguridad de toda la aplicación durante mucho tiempo. + + + +Pueden ocurrir muchas vulnerabilidades de seguridad diferentes cuando manejamos inadecuadamente las condiciones excepcionales, como errores de lógica, desbordamientos (overflows), condiciones de carrera (race conditions), transacciones fraudulentas o problemas de memoria, estado, recursos, tiempos (timing), autenticación y autorización. Estos tipos de vulnerabilidades pueden afectar negativamente la confidencialidad, disponibilidad y/o integridad de un sistema o de sus datos. Los atacantes manipulan el manejo de errores defectuoso de una aplicación para atacar esta vulnerabilidad. + + +## Cómo prevenir + +Para manejar adecuadamente una condición excepcional, debemos planificar para tales situaciones (esperar lo peor). Debemos "capturar" (catch) cada posible error del sistema directamente en el lugar donde ocurre y luego manejarlo (lo que significa hacer algo significativo para resolver el problema y asegurar que nos recuperamos del mismo). Como parte del manejo, debemos incluir el lanzamiento de un error (para informar al usuario de forma comprensible), el registro (logging) del evento, así como la emisión de una alerta (alerting) si consideramos que está justificado. También deberíamos tener un manejador de excepciones global por si acaso algo se nos ha pasado por alto. Idealmente, también tendríamos herramientas o funcionalidades de monitoreo y/u observabilidad que vigilen errores repetidos o patrones que indiquen un ataque en curso, que pudieran emitir una respuesta, defensa o bloqueo de algún tipo. Esto puede ayudarnos a bloquear y responder a scripts y bots que se centran en nuestras debilidades de manejo de errores. + + + +Capturar y manejar las condiciones excepcionales garantiza que la infraestructura subyacente de nuestros programas no se deje a merced de situaciones impredecibles. Si se encuentra a mitad de una transacción de cualquier tipo, es extremadamente importante que revierta (roll back) cada parte de la transacción y comience de nuevo (lo que también se conoce como fallar de forma segura o "fail closed"). Intentar recuperar una transacción a medias es a menudo donde creamos errores irrecuperables. + + + +Siempre que sea posible, añada limitación de tasa (rate limiting), cuotas de recursos, regulación (throttling) y otros límites para prevenir las condiciones excepcionales en primer lugar. Nada en la tecnología de la información debería ser ilimitado, ya que esto conduce a una falta de resiliencia de la aplicación, denegación de servicio, ataques exitosos de fuerza bruta y facturas extraordinarias en la nube. + +Considere si errores idénticos repetidos, por encima de una cierta tasa, deberían mostrarse únicamente como estadísticas que indiquen con qué frecuencia han ocurrido y en qué intervalo de tiempo. Esta información debería añadirse al mensaje original para no interferir con el registro y monitoreo automatizados, consulte [A09:2025-Fallas en el Registro, Alerta y Monitoreo de Seguridad](A09_2025-Security_Logging_and_Alerting_Failures.md). + +Además de esto, querríamos incluir una validación de entradas estricta (con saneamiento o escape para los caracteres potencialmente peligrosos que debamos aceptar), un manejo de errores, registro, monitoreo y alertas *centralizados*, y un manejador de excepciones global. Una aplicación no debería tener múltiples funciones para manejar condiciones excepcionales; debería realizarse en un solo lugar, de la misma manera cada vez. También deberíamos crear requisitos de seguridad del proyecto para todos los consejos de esta sección, realizar actividades de modelado de amenazas y/o revisión de diseño seguro en la fase de diseño de nuestros proyectos, realizar revisiones de código o análisis estático, así como ejecutar pruebas de estrés, rendimiento y penetración del sistema final. + + + +Si es posible, toda su organización debería manejar las condiciones excepcionales de la misma manera, ya que esto facilita la revisión y auditoría del código en busca de errores en este importante control de seguridad. + + +## Ejemplos de escenarios de ataque + +**Escenario #1:** El agotamiento de recursos mediante el manejo inadecuado de condiciones excepcionales (Denegación de Servicio) podría producirse si la aplicación captura excepciones cuando se suben archivos, pero no libera adecuadamente los recursos después. Cada nueva excepción deja los recursos bloqueados o no disponibles de otro modo, hasta que se agotan todos los recursos. + +**Escenario #2:** Exposición de datos sensibles mediante un manejo inadecuado o errores de base de datos que revelan el error completo del sistema al usuario. El atacante continúa forzando errores para utilizar la información sensible del sistema para crear un mejor ataque de inyección SQL. Los datos sensibles en los mensajes de error del usuario sirven de reconocimiento (reconnaissance). + +**Escenario #3:** La corrupción de estado en transacciones financieras podría ser causada por un atacante que interrumpe una transacción de varios pasos mediante interrupciones de red. Imagine que el orden de la transacción fuera: debitar la cuenta del usuario, acreditar la cuenta de destino, registrar la transacción. Si el sistema no revierte adecuadamente toda la transacción (fallar de forma segura o "fail closed") cuando hay un error a mitad del proceso, el atacante podría potencialmente vaciar la cuenta del usuario, o posiblemente una condición de carrera podría permitir al atacante enviar dinero al destino varias veces. + + +## Referencias + +OWASP MASVS‑RESILIENCE + +- [OWASP Cheat Sheet: Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) + +- [OWASP Cheat Sheet: Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html) + +- [OWASP Application Security Verification Standard (ASVS): V16.5 Error Handling](https://github.com/OWASP/ASVS/blob/master/5.0/en/0x25-V16-Security-Logging-and-Error-Handling.md#v165-error-handling) + +- [OWASP Testing Guide: 4.8.1 Testing for Error Handling](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/01-Testing_For_Improper_Error_Handling) + +* [Best practices for exceptions (Microsoft, .Net)](https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions) + +* [Clean Code and the Art of Exception Handling (Toptal)](https://www.toptal.com/developers/abap/clean-code-and-the-art-of-exception-handling) + +* [General error handling rules (Google for Developers)](https://developers.google.com/tech-writing/error-messages/error-handling) + +* [Example of real-world mishandling of an exceptional condition](https://www.firstreference.com/blog/human-error-and-internal-control-failures-cause-us62m-fine/) + + +## Lista de CWEs Mapeadas +* [CWE-209 Generación de Mensajes de Error que Contienen Información Sensible (Generation of Error Message Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/209.html) +* [CWE-215 Inserción de Información Sensible en el Código de Depuración (Insertion of Sensitive Information Into Debugging Code)](https://cwe.mitre.org/data/definitions/215.html) +* [CWE-234 Omisión del Manejo de Parámetros Faltantes (Failure to Handle Missing Parameter)](https://cwe.mitre.org/data/definitions/234.html) +* [CWE-235 Manejo Inadecuado de Parámetros Extra (Improper Handling of Extra Parameters)](https://cwe.mitre.org/data/definitions/235.html) +* [CWE-248 Excepción No Capturada (Uncaught Exception)](https://cwe.mitre.org/data/definitions/248.html) +* [CWE-252 Valor de Retorno No Verificado (Unchecked Return Value)](https://cwe.mitre.org/data/definitions/252.html) +* [CWE-274 Manejo Inadecuado de Privilegios Insuficientes (Improper Handling of Insufficient Privileges)](https://cwe.mitre.org/data/definitions/274.html) +* [CWE-280 Manejo Inadecuado de Permisos o Privilegios Insuficientes (Improper Handling of Insufficient Permissions or Privileges)](https://cwe.mitre.org/data/definitions/280.html) +* [CWE-369 División por Cero (Divide By Zero)](https://cwe.mitre.org/data/definitions/369.html) +* [CWE-390 Detección de Condición de Error sin Acción (Detection of Error Condition Without Action)](https://cwe.mitre.org/data/definitions/390.html) +* [CWE-391 Condición de Error No Verificada (Unchecked Error Condition)](https://cwe.mitre.org/data/definitions/391.html) +* [CWE-394 Código de Estado o Valor de Retorno Inesperado (Unexpected Status Code or Return Value)](https://cwe.mitre.org/data/definitions/394.html) +* [CWE-396 Declaración de Catch para Excepción Genérica (Declaration of Catch for Generic Exception)](https://cwe.mitre.org/data/definitions/396.html) +* [CWE-397 Declaración de Throws para Excepción Genérica (Declaration of Throws for Generic Exception)](https://cwe.mitre.org/data/definitions/397.html) +* [CWE-460 Limpieza Inadecuada al Lanzar una Excepción (Improper Cleanup on Thrown Exception)](https://cwe.mitre.org/data/definitions/460.html) +* [CWE-476 Desreferencia de Puntero NULL (NULL Pointer Dereference)](https://cwe.mitre.org/data/definitions/476.html) +* [CWE-478 Falta de Caso por Defecto en una Expresión de Condición Múltiple (Missing Default Case in Multiple Condition Expression)](https://cwe.mitre.org/data/definitions/478.html) +* [CWE-484 Sentencia Break Omitida en un Switch (Omitted Break Statement in Switch)](https://cwe.mitre.org/data/definitions/484.html) +* [CWE-550 Mensaje de Error Generado por el Servidor que Contiene Información Sensible (Server-generated Error Message Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/550.html) +* [CWE-636 No Fallar de Forma Segura ('Fallar de Forma Abierta' / 'Failing Open')](https://cwe.mitre.org/data/definitions/636.html) +* [CWE-703 Verificación o Manejo Inadecuado de Condiciones Excepcionales (Improper Check or Handling of Exceptional Conditions)](https://cwe.mitre.org/data/definitions/703.html) +* [CWE-754 Verificación Inadecuada de Condiciones Inusuales o Excepcionales (Improper Check for Unusual or Exceptional Conditions)](https://cwe.mitre.org/data/definitions/754.html) +* [CWE-755 Manejo Inadecuado de Condiciones Excepcionales (Improper Handling of Exceptional Conditions)](https://cwe.mitre.org/data/definitions/755.html) +* [CWE-756 Falta de Página de Error Personalizada (Missing Custom Error Page)](https://cwe.mitre.org/data/definitions/756.html) diff --git a/2025/docs/es/X01_2025-Next_Steps.md b/2025/docs/es/X01_2025-Next_Steps.md new file mode 100644 index 000000000..d286964d4 --- /dev/null +++ b/2025/docs/es/X01_2025-Next_Steps.md @@ -0,0 +1,324 @@ +# Siguientes Pasos + +Por diseño, el OWASP Top 10 está intrínsecamente limitado a los diez riesgos más significativos. Cada OWASP Top 10 tiene riesgos "al límite" que se consideran detenidamente para su inclusión, pero que al final no pasaron el corte. Los otros riesgos fueron más prevalentes e impactantes. + +Vale la pena esforzarse en identificar y remediar los siguientes tres problemas, ya sea para organizaciones que trabajan hacia un programa de seguridad de aplicaciones (AppSec) maduro, consultorías de seguridad o proveedores de herramientas que deseen ampliar la cobertura de sus ofertas. + + +## X01:2025 Falta de Resiliencia de la Aplicación + +### Antecedentes + +Este es un cambio de nombre de la Denegación de Servicio (Denial of Service) de 2021. Se le cambió el nombre porque describía un síntoma más que una causa raíz. Esta categoría se centra en CWEs que describen debilidades relacionadas con problemas de resiliencia. La puntuación de esta categoría estuvo muy cerca de A10:2025 - Manejo Inadecuado de Condiciones Excepcionales. Los CWE relevantes incluyen: *CWE-400 Consumo de Recursos No Controlado (Uncontrolled Resource Consumption), CWE-409 Manejo Inadecuado de Datos Altamente Comprimidos (Amplificación de Datos) (Improper Handling of Highly Compressed Data (Data Amplification)), CWE-674 Recursión No Controlada (Uncontrolled Recursion)* y *CWE-835 Bucle con Condición de Salida Inalcanzable ('Bucle Infinito') (Loop with Unreachable Exit Condition ('Infinite Loop'))*. + + +### Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeados + Tasa de Incidencia Máxima + Tasa de Incidencia Promedio + Cobertura Máxima + Cobertura Promedio + Explotación Ponderada Promedio + Impacto Ponderado Promedio + Ocurrencias Totales + CVEs Totales +
16 + 20.05% + 4.55% + 86.01% + 41.47% + 7.92 + 3.49 + 865,066 + 4,423 +
+ + + +### Descripción + +Esta categoría representa una debilidad sistémica en la forma en que las aplicaciones responden al estrés, las fallas y los casos extremos de los que no pueden recuperarse. Cuando una aplicación no maneja, resiste o se recupera con elegancia de condiciones inesperadas, restricciones de recursos y otros eventos adversos, puede resultar fácilmente en problemas de disponibilidad (lo más común), pero también en corrupción de datos, divulgación de datos sensibles, fallas en cascada y/o elusión de controles de seguridad. + +Además, [X02:2025 Fallas en la Gestión de Memoria](#x022025-memory-management-failures) también pueden provocar la falla de la aplicación o incluso de todo el sistema. + +### Cómo prevenir + +Para prevenir este tipo de vulnerabilidad, debe diseñar sus sistemas para la falla y la recuperación. + +* Añada límites, cuotas y funcionalidad de conmutación por error (failover), prestando especial atención a las operaciones que más recursos consumen. +* Identifique las páginas que consumen muchos recursos y planifique con antelación: Reduzca la superficie de ataque, especialmente no exponiendo "gadgets" y funciones innecesarias que requieran muchos recursos (por ejemplo, CPU, memoria) a usuarios desconocidos o no confiables. +* Realice una validación de entradas estricta con listas de permitidos (allow-lists) y limitaciones de tamaño, luego realice pruebas exhaustivas. +* Limite los tamaños de las respuestas y nunca envíe respuestas sin procesar al cliente (procéselas en el lado del servidor). +* Establezca por defecto un estado seguro/cerrado (nunca abierto), deniegue por defecto y realice una reversión (roll back) si hay un error. +* Evite llamadas síncronas bloqueantes en los hilos de solicitud (use asíncronas/no bloqueantes, establezca tiempos de espera (timeouts), límites de concurrencia, etc.). +* Pruebe cuidadosamente su funcionalidad de manejo de errores. +* Implemente patrones de resiliencia como interruptores (circuit breakers), mamparos (bulkheads), lógica de reintento (retry logic) y degradación elegante (graceful degradation). +* Realice pruebas de rendimiento y carga; añada ingeniería de caos (chaos engineering) si tiene el apetito de riesgo para ello. +* Implemente y diseñe arquitecturas con redundancia donde sea razonable y asequible. +* Implemente monitorización, observabilidad y alertas. +* Filtre las direcciones de remitente no válidas de acuerdo con RFC 2267. +* Bloquee botnets conocidas mediante huellas digitales (fingerprints), IPs o dinámicamente por comportamiento. +* Prueba de Trabajo (Proof-of-Work): inicie operaciones que consuman recursos en el lado del *atacante*, lo que no tiene grandes impactos en los usuarios normales pero afecta a los bots que intentan enviar una gran cantidad de solicitudes. Haga que la Prueba de Trabajo sea más difícil si la carga general del sistema aumenta, especialmente para los sistemas que son menos confiables o parecen ser bots. +* Limite el tiempo de sesión en el lado del servidor basándose en la inactividad y un tiempo de espera final. +* Limite el almacenamiento de información vinculada a la sesión. + + +### Escenarios de ataque de ejemplo + +**Escenario #1:** Los atacantes consumen intencionadamente los recursos de la aplicación para provocar fallas en el sistema, lo que resulta en una denegación de servicio (Denial of Service). Esto podría ser el agotamiento de la memoria, el llenado del espacio en disco, la saturación de la CPU o la apertura de conexiones infinitas. + +**Escenario #2:** Fuzzing de entrada que conduce a respuestas manipuladas que rompen la lógica de negocio de la aplicación. + +**Escenario #3:** Los atacantes se centran en las dependencias de la aplicación, derribando APIs u otros servicios externos, y la aplicación no puede continuar. + + +### Referencias + +* [OWASP Cheat Sheet: Denegación de Servicio](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html) +* [OWASP MASVS‑RESILIENCE](https://mas.owasp.org/MASVS/11-MASVS-RESILIENCE/) +* [Mejores prácticas de ASP.NET Core (Microsoft)](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices?view=aspnetcore-9.0) +* [Resiliencia en microservicios: Bulkhead vs Circuit Breaker (Parser)](https://medium.com/@parserdigital/resilience-in-microservices-bulkhead-vs-circuit-breaker-54364c1f9d53) +* [Patrón Bulkhead (Geeks for Geeks)](https://www.geeksforgeeks.org/system-design/bulkhead-pattern/) +* [Marco de Ciberseguridad del NIST (CSF)](https://www.nist.gov/cyberframework) +* [Evite llamadas bloqueantes: Vuelva asíncrono en Java (Devlane)](https://www.devlane.com/blog/avoid-blocking-calls-go-async-in-java) + +### Lista de CWEs Mapeados +* [CWE-73 Control Externo del Nombre o Ruta del Archivo (External Control of File Name or Path)](https://cwe.mitre.org/data/definitions/73.html) +* [CWE-183 Lista Permisiva de Entradas Permitidas (Permissive List of Allowed Inputs)](https://cwe.mitre.org/data/definitions/183.html) +* [CWE-256 Almacenamiento de Contraseña en Texto Plano (Plaintext Storage of a Password)](https://cwe.mitre.org/data/definitions/256.html) +* [CWE-266 Asignación Incorrecta de Privilegios (Incorrect Privilege Assignment)](https://cwe.mitre.org/data/definitions/266.html) +* [CWE-269 Gestión Inadecuada de Privilegios (Improper Privilege Management)](https://cwe.mitre.org/data/definitions/269.html) +* [CWE-286 Gestión de Usuarios Incorrecta (Incorrect User Management)](https://cwe.mitre.org/data/definitions/286.html) +* [CWE-311 Falta de Cifrado de Datos Sensibles (Missing Encryption of Sensitive Data)](https://cwe.mitre.org/data/definitions/311.html) +* [CWE-312 Almacenamiento de Información Sensible en Texto Claro (Cleartext Storage of Sensitive Information)](https://cwe.mitre.org/data/definitions/312.html) +* [CWE-313 Almacenamiento en Texto Claro en un Archivo o en Disco (Cleartext Storage in a File or on Disk)](https://cwe.mitre.org/data/definitions/313.html) +* [CWE-316 Almacenamiento de Información Sensible en Texto Claro en Memoria (Cleartext Storage of Sensitive Information in Memory)](https://cwe.mitre.org/data/definitions/316.html) +* [CWE-362 Ejecución Concurrente utilizando un Recurso Compartido con Sincronización Inadecuada ('Condición de Carrera') (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))](https://cwe.mitre.org/data/definitions/362.html) +* [CWE-382 Malas Prácticas de J2EE: Uso de System.exit() (J2EE Bad Practices: Use of System.exit())](https://cwe.mitre.org/data/definitions/382.html) +* [CWE-419 Canal Primario No Protegido (Unprotected Primary Channel)](https://cwe.mitre.org/data/definitions/419.html) +* [CWE-434 Carga sin Restricciones de Archivos con un Tipo Peligroso (Unrestricted Upload of File with Dangerous Type)](https://cwe.mitre.org/data/definitions/434.html) +* [CWE-436 Conflicto de Interpretación (Interpretation Conflict)](https://cwe.mitre.org/data/definitions/436.html) +* [CWE-444 Interpretación Inconsistente de Solicitudes HTTP ('HTTP Request/Response Smuggling') (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))](https://cwe.mitre.org/data/definitions/444.html) +* [CWE-451 Tergiversación de Información Crítica en la Interfaz de Usuario (UI) (User Interface (UI) Misrepresentation of Critical Information)](https://cwe.mitre.org/data/definitions/451.html) +* [CWE-454 Inicialización Externa de Variables Confiables o Almacenes de Datos (External Initialization of Trusted Variables or Data Stores)](https://cwe.mitre.org/data/definitions/454.html) +* [CWE-472 Control Externo de un Parámetro Web Supuestamente Inmutable (External Control of Assumed-Immutable Web Parameter)](https://cwe.mitre.org/data/definitions/472.html) +* [CWE-501 Violación del Límite de Confianza (Trust Boundary Violation)](https://cwe.mitre.org/data/definitions/501.html) +* [CWE-522 Credenciales Insuficientemente Protegidas (Insufficiently Protected Credentials)](https://cwe.mitre.org/data/definitions/522.html) +* [CWE-525 Uso de la Caché del Navegador Web que Contiene Información Sensible (Use of Web Browser Cache Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/525.html) +* [CWE-539 Uso de Cookies Persistentes que Contienen Información Sensible (Use of Persistent Cookies Containing Sensitive Information)](https://cwe.mitre.org/data/definitions/539.html) +* [CWE-598 Uso del Método de Solicitud GET con Cadenas de Consulta Sensibles (Use of GET Request Method With Sensitive Query Strings)](https://cwe.mitre.org/data/definitions/598.html) +* [CWE-602 Ejecución en el Lado del Cliente de la Seguridad del Lado del Servidor (Client-Side Enforcement of Server-Side Security)](https://cwe.mitre.org/data/definitions/602.html) +* [CWE-628 Llamada a Función con Argumentos Especificados Incorrectamente (Function Call with Incorrectly Specified Arguments)](https://cwe.mitre.org/data/definitions/628.html) +* [CWE-642 Control Externo de Datos de Estado Críticos (External Control of Critical State Data)](https://cwe.mitre.org/data/definitions/642.html) +* [CWE-646 Dependencia en el Nombre o Extensión de un Archivo Suministrado Externamente (Reliance on File Name or Extension of Externally-Supplied File)](https://cwe.mitre.org/data/definitions/646.html) +* [CWE-653 Aislamiento o Compartimentación Inadecuados (Improper Isolation or Compartmentalization)](https://cwe.mitre.org/data/definitions/653.html) +* [CWE-656 Dependencia en la Seguridad por Oscuridad (Reliance on Security Through Obscurity)](https://cwe.mitre.org/data/definitions/656.html) +* [CWE-657 Violación de los Principios de Diseño Seguro (Violation of Secure Design Principles)](https://cwe.mitre.org/data/definitions/657.html) +* [CWE-676 Uso de una Función Potencialmente Peligrosa (Use of Potentially Dangerous Function)](https://cwe.mitre.org/data/definitions/676.html) +* [CWE-693 Falla del Mecanismo de Protección (Protection Mechanism Failure)](https://cwe.mitre.org/data/definitions/693.html) +* [CWE-799 Control Inadecuado de la Frecuencia de Interacción (Improper Control of Interaction Frequency)](https://cwe.mitre.org/data/definitions/799.html) +* [CWE-807 Dependencia en Entradas No Confiables en una Decisión de Seguridad (Reliance on Untrusted Inputs in a Security Decision)](https://cwe.mitre.org/data/definitions/807.html) +* [CWE-841 Ejecución Inadecuada del Flujo de Trabajo de Comportamiento (Improper Enforcement of Behavioral Workflow)](https://cwe.mitre.org/data/definitions/841.html) +* [CWE-1021 Restricción Inadecuada de Capas o Marcos de la Interfaz de Usuario Renderizados (Improper Restriction of Rendered UI Layers or Frames)](https://cwe.mitre.org/data/definitions/1021.html) +* [CWE-1022 Uso de un Enlace Web a un Destino No Confiable con Acceso a window.opener (Use of Web Link to Untrusted Target with window.opener Access)](https://cwe.mitre.org/data/definitions/1022.html) +* [CWE-1125 Superficie de Ataque Excesiva (Excessive Attack Surface)](https://cwe.mitre.org/data/definitions/1125.html) + + +## X02:2025 Fallas en la Gestión de Memoria + +### Antecedentes + +Lenguajes como Java, C#, JavaScript/TypeScript (node.js), Go y Rust "seguro" (safe) son seguros en memoria (memory safe). Los problemas de manejo de memoria suelen ocurrir en lenguajes no seguros en memoria, como C y C++. Esta categoría obtuvo la puntuación más baja en la encuesta de la comunidad y baja en los datos, a pesar de tener el tercer mayor número de CVE relacionados. Creemos que esto se debe al predominio de las aplicaciones web sobre las aplicaciones de escritorio más tradicionales. Las vulnerabilidades de manejo de memoria suelen tener las puntuaciones CVSS más altas. + + +### Tabla de puntuación + + + + + + + + + + + + + + + + + + + + + + + + + +
CWEs Mapeados + Tasa de Incidencia Máxima + Tasa de Incidencia Promedio + Cobertura Máxima + Cobertura Promedio + Explotación Ponderada Promedio + Impacto Ponderado Promedio + Ocurrencias Totales + CVEs Totales +
24 + 2.96% + 1.13% + 55.62% + 28.45% + 6.75 + 4.82 + 220,414 + 30,978 +
+ + + +### Descripción + +Cuando una aplicación se ve obligada a gestionar la memoria por sí misma, es muy fácil cometer errores. Los lenguajes seguros en memoria se utilizan cada vez más, pero todavía hay muchos sistemas heredados (legacy) en producción en todo el mundo, nuevos sistemas de bajo nivel que requieren el uso de lenguajes no seguros en memoria y aplicaciones web que interactúan con mainframes, dispositivos IoT, firmware y otros sistemas que pueden verse obligados a gestionar su propia memoria. Los CWE representativos son el *CWE-120 Copia de Búfer sin Comprobar el Tamaño de la Entrada ('Desbordamiento de Búfer Clásico') (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))* y el *CWE-121 Desbordamiento de Búfer basado en Pila (Stack-based Buffer Overflow)*. + +Las fallas en el manejo de memoria pueden ocurrir cuando: + +* No se asigna suficiente memoria para una variable. +* No se valida la entrada, lo que provoca un desbordamiento del montón (heap), la pila (stack) o un búfer. +* Se almacena un valor de datos que es mayor de lo que el tipo de variable puede contener. +* Se intenta utilizar memoria o espacios de direcciones no asignados. +* Se crean errores por uno (off-by-one errors) (contar desde 1 en lugar de desde cero). +* Se intenta acceder a un objeto después de haber sido liberado. +* Se utilizan variables no inicializadas. +* Se producen fugas de memoria (memory leaks) o se agota de otro modo toda la memoria disponible por error hasta que la aplicación falla. + +Las fallas en el manejo de memoria pueden provocar la falla de la aplicación o incluso de todo el sistema, consulte también [X01:2025 Falta de Resiliencia de la Aplicación](#x012025-lack-of-application-resilience). + + +### Cómo prevenir + +La mejor manera de prevenir las fallas en el manejo de memoria es utilizar un lenguaje seguro en memoria (memory-safe). Los ejemplos incluyen Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript, etc. Al crear nuevas aplicaciones, intente convencer a su organización de que vale la pena la curva de aprendizaje para cambiar a un lenguaje seguro en memoria. Si se realiza una refactorización completa, presione para una reescritura en un lenguaje seguro en memoria cuando sea posible y factible. + +Si no puede utilizar un lenguaje seguro en memoria, realice lo siguiente: + +* Habilite las siguientes características del servidor que dificultan la explotación de los errores de manejo de memoria: aleatorización del diseño del espacio de direcciones (ASLR), protección de ejecución de datos (DEP) y protección contra la sobrescritura del manejo de excepciones estructuradas (SEHOP). +* Supervise su aplicación en busca de fugas de memoria. +* Valide cuidadosamente todas las entradas a su sistema y rechace cualquier entrada que no cumpla con las expectativas. +* Estudie el lenguaje que está utilizando y haga una lista de las funciones inseguras y las más seguras, luego comparta esa lista con todo su equipo. Si es posible, añádala a su guía o estándar de codificación segura. Por ejemplo, en C, prefiera strncpy() sobre strcpy() y strncat() sobre strcat(). +* Si su lenguaje o entorno de trabajo (framework) ofrece librerías de seguridad de memoria, úselas. Por ejemplo: Safestringlib o SafeStr. +* Utilice búferes y cadenas gestionados en lugar de matrices (arrays) y punteros brutos siempre que sea posible. +* Realice una formación en codificación segura que se centre en los problemas de memoria y/o en el lenguaje de su elección. Informe a su instructor que le preocupan las fallas en el manejo de memoria. +* Realice revisiones de código y/o análisis estáticos. +* Utilice herramientas del compilador que ayuden con la gestión de la memoria, como StackShield, StackGuard y Libsafe. +* Realice pruebas de fuzzing en cada entrada de su sistema. +* Si realiza una prueba de penetración, informe a su evaluador que le preocupan las fallas en el manejo de memoria y que le gustaría que prestara especial atención a esto durante las pruebas. +* Corrija todos los errores *y* advertencias del compilador. No ignore las advertencias solo porque su programa se compile. +* Asegúrese de que su infraestructura subyacente se parchea, escanea y robustece (hardened) regularmente. +* Supervise su infraestructura subyacente específicamente para detectar posibles vulnerabilidades de memoria y otros fallas. +* Considere el uso de [canarios](https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries) para proteger su pila de direcciones de los ataques de desbordamiento. + +### Escenarios de ataque de ejemplo + +**Escenario #1:** Los desbordamientos de búfer (buffer overflows) son la vulnerabilidad de memoria más famosa, una situación en la que un atacante envía más información a un campo de la que puede aceptar, de modo que desborda el búfer creado para la variable subyacente. En un ataque exitoso, los caracteres de desbordamiento sobrescriben el puntero de la pila, permitiendo al atacante insertar instrucciones maliciosas en su programa. + +**Escenario #2:** El uso después de la liberación (Use-After-Free (UAF)) ocurre con la frecuencia suficiente como para ser una entrega semi-común en programas de recompensas por errores (bug bounty) de navegadores. Imagine un navegador web que procesa JavaScript que manipula elementos DOM. El atacante diseña una carga útil de JavaScript que crea un objeto (como un elemento DOM) y obtiene referencias a él. A través de una manipulación cuidadosa, provocan que el navegador libere la memoria del objeto mientras mantienen un puntero colgante (dangling pointer) hacia él. Antes de que el navegador se dé cuenta de que la memoria ha sido liberada, el atacante asigna un nuevo objeto que ocupa el *mismo* espacio de memoria. Cuando el navegador intenta utilizar el puntero original, ahora apunta a datos controlados por el atacante. Si este puntero era para una tabla de funciones virtuales, el atacante puede redirigir la ejecución del código a su carga útil. + +**Escenario #3:** Un servicio de red que acepta la entrada del usuario, no la valida ni sanea adecuadamente y luego la pasa directamente a la función de registro (logging). La entrada del usuario se pasa a la función de registro como `syslog(user_input)` en lugar de `syslog("%s", user_input)`, lo que no especifica el formato. El atacante envía cargas útiles maliciosas que contienen especificadores de formato como `%x` para leer la memoria de la pila (divulgación de datos sensibles) o `%n` para escribir en direcciones de memoria. Al encadenar múltiples especificadores de formato, podrían mapear la pila, localizar direcciones importantes y luego sobrescribirlas. Esto sería una vulnerabilidad de cadena de formato (Format string vulnerability) (formato de cadena no controlado). + +Nota: los navegadores modernos utilizan muchos niveles de defensa para protegerse contra tales ataques, incluyendo el aislamiento de procesos del navegador (browser sandboxing), ASLR, DEP/NX, RELRO y PIE. Un ataque de falla en el manejo de memoria en un navegador no es un ataque sencillo de realizar. + +### Referencias + +* [OWASP community pages: Memory leak,](https://owasp.org/www-community/vulnerabilities/Memory_leak) [Doubly freeing memory,](https://owasp.org/www-community/vulnerabilities/Doubly_freeing_memory) [& Buffer Overflow](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow) +* [Awesome Fuzzing: a list of fuzzing resources](https://github.com/secfigo/Awesome-Fuzzing) +* [Project Zero Blog](https://googleprojectzero.blogspot.com) +* [Microsoft MSRC Blog](https://www.microsoft.com/en-us/msrc/blog) + +### Lista de CWEs Mapeados +* [CWE-14 Eliminación por el Compilador de Código para Limpiar Búferes (Compiler Removal of Code to Clear Buffers)](https://cwe.mitre.org/data/definitions/14.html) +* [CWE-119 Restricción Inadecuada de las Operaciones dentro de los Límites de un Búfer de Memoria (Improper Restriction of Operations within the Bounds of a Memory Buffer)](https://cwe.mitre.org/data/definitions/119.html) +* [CWE-120 Copia de Búfer sin Comprobar el Tamaño de la Entrada ('Desbordamiento de Búfer Clásico') (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))](https://cwe.mitre.org/data/definitions/120.html) +* [CWE-121 Desbordamiento de Búfer basado en Pila (Stack-based Buffer Overflow)](https://cwe.mitre.org/data/definitions/121.html) +* [CWE-122 Desbordamiento de Búfer basado en Montón (Heap-based Buffer Overflow)](https://cwe.mitre.org/data/definitions/122.html) +* [CWE-124 Subescritura de Búfer ('Subdesbordamiento de Búfer') (Buffer Underwrite ('Buffer Underflow'))](https://cwe.mitre.org/data/definitions/124.html) +* [CWE-125 Lectura Fuera de Límites (Out-of-bounds Read)](https://cwe.mitre.org/data/definitions/125.html) +* [CWE-126 Sobrelectura de Búfer (Buffer Over-read)](https://cwe.mitre.org/data/definitions/126.html) +* [CWE-190 Desbordamiento de Enteros o Envolvimiento (Integer Overflow or Wraparound)](https://cwe.mitre.org/data/definitions/190.html) +* [CWE-191 Subdesbordamiento de Enteros (Envolvimiento) (Integer Underflow (Wrap or Wraparound))](https://cwe.mitre.org/data/definitions/191.html) +* [CWE-196 Error de Conversión de Sin Signo a Con Signo (Unsigned to Signed Conversion Error)](https://cwe.mitre.org/data/definitions/196.html) +* [CWE-367 Condición de Carrera de Tiempo de Comprobación a Tiempo de Uso (TOCTOU) (Time-of-check Time-of-use (TOCTOU) Race Condition)](https://cwe.mitre.org/data/definitions/367.html) +* [CWE-415 Liberación Doble (Double Free)](https://cwe.mitre.org/data/definitions/415.html) +* [CWE-416 Uso Después de la Liberación (Use After Free)](https://cwe.mitre.org/data/definitions/416.html) +* [CWE-457 Uso de Variable No Inicializada (Use of Uninitialized Variable)](https://cwe.mitre.org/data/definitions/457.html) +* [CWE-459 Limpieza Incompleta (Incomplete Cleanup)](https://cwe.mitre.org/data/definitions/459.html) +* [CWE-467 Uso de sizeof() en un Tipo de Puntero (Use of sizeof() on a Pointer Type)](https://cwe.mitre.org/data/definitions/467.html) +* [CWE-787 Escritura Fuera de Límites (Out-of-bounds Write)](https://cwe.mitre.org/data/definitions/787.html) +* [CWE-788 Acceso a una Ubicación de Memoria Después del Final del Búfer (Access of Memory Location After End of Buffer)](https://cwe.mitre.org/data/definitions/788.html) +* [CWE-824 Acceso a un Puntero No Inicializado (Access of Uninitialized Pointer)](https://cwe.mitre.org/data/definitions/824.html) + + + +## X03:2025 Confianza Inapropiada en el Código Generado por IA ('Vibe Coding') + +### Antecedentes + +Actualmente, todo el mundo habla y utiliza la IA, y esto incluye a los desarrolladores de software. Aunque actualmente no existen CVE o CWE relacionados con el código generado por IA, es bien sabido y está documentado que el código generado por IA a menudo contiene más vulnerabilidades que el código escrito por seres humanos. + + +### Descripción + +Estamos viendo cómo cambian las prácticas de desarrollo de software para incluir no solo código escrito con la ayuda de la IA, sino código escrito y entregado casi por completo sin supervisión humana (a menudo denominado *vibe coding*). Así como nunca fue una buena idea copiar fragmentos de código de blogs o sitios web sin pensarlo dos veces, el problema se agrava en este caso. Los fragmentos de código buenos y seguros eran y son escasos, y la IA podría ignorarlos estadísticamente debido a las limitaciones del sistema. + + +### Cómo prevenir +Instamos a todas las personas que escriben código a que consideren lo siguiente cuando utilicen la IA: + +* Debe ser capaz de leer y comprender completamente todo el código que envíe, incluso si ha sido escrito por una IA o copiado de un foro en línea. Usted es responsable de todo el código que entregue. +* Debe revisar a fondo todo el código asistido por IA en busca de vulnerabilidades, idealmente con sus propios ojos y también con herramientas de seguridad creadas para este fin (como el análisis estático). Considere el uso de técnicas clásicas de revisión de código como las descritas en [OWASP Cheat Sheet Series: Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html). +* Idealmente, escriba su propio código, deje que la IA sugiera mejoras, verifique el código de la IA y deje que la IA haga correcciones hasta que esté satisfecho con el resultado. +* Considere el uso de un servidor de Generación Aumentada por Recuperación (RAG) con sus propias muestras de código seguro y documentación recopiladas y revisadas, como la guía, estándar o política de codificación de seguridad de su organización, y haga que el servidor RAG aplique cualquier política o estándar. +* Considere la compra de herramientas que implementen salvaguardas (guardrails) para la privacidad y la seguridad para su uso con la(s) IA(s) de su elección. +* Considere la compra de una IA privada, idealmente con un acuerdo contractual (incluyendo un acuerdo de privacidad) que estipule que la IA no debe ser entrenada con los datos, consultas, código o cualquier otra información sensible de su organización. +* Considere la implementación de un servidor de Protocolo de Contexto de Modelo (MCP) entre su IDE y la IA, y luego configúrelo para imponer el uso de su herramienta de seguridad preferida. +* Implemente políticas y procesos como parte de su SDLC para informar a los desarrolladores (y a todos los empleados) sobre cómo deben y no deben usar la IA dentro de su organización. +* Cree una lista de prompts (instrucciones) buenos y efectivos que tengan en cuenta las mejores prácticas de seguridad de TI. Idealmente, también deberían considerar sus pautas internas de codificación segura. Los desarrolladores pueden usar estos prompts como punto de partida para sus programas. +* Es probable que la IA se convierta en parte de cada fase del ciclo de vida de desarrollo de su sistema; aprenda cómo usarla de manera efectiva y segura. Úsela sabiamente. +* De hecho, **no** se recomienda utilizar *vibe coding* para funciones complejas, programas críticos para el negocio o programas que se utilicen durante mucho tiempo. +* Implemente comprobaciones técnicas y salvaguardas contra el uso de IA en la sombra (Shadow AI). +* Capacite a sus desarrolladores en sus políticas, así como en el uso seguro de la IA y las mejores prácticas para usar la IA en el desarrollo de software. + + +### Referencias + +* [OWASP Cheat Sheet: Revisión de Código Seguro](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html) + + +### Lista de CWEs Mapeados +-ninguno- diff --git a/2025/docs/es/index.md b/2025/docs/es/index.md new file mode 100644 index 000000000..7c99d1f97 --- /dev/null +++ b/2025/docs/es/index.md @@ -0,0 +1,40 @@ +# OWASP Top 10:2025 + +Bienvenido al lanzamiento de OWASP Top 10:2025. + +El OWASP Top 10 es un documento estándar de concienciación para desarrolladores y seguridad de aplicaciones web. Representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web. + +## Sobre este lanzamiento + +Esta es la versión **2025** del OWASP Top 10. Esta versión incluye actualizaciones basadas en los últimos datos y tendencias de seguridad. + +## Página principal del proyecto +La [página principal del proyecto](https://github.com/OWASP/www-project-top-ten) contiene información sobre versiones anteriores y metadatos sobre este proyecto. + +## Primeros pasos + +Comience con la [Introducción](0x00_2025-Introduction.md) para conocer las novedades de la versión 2025. + +## Navegación + +- [Introducción](0x00_2025-Introduction.md) +- [Sobre OWASP](0x01_2025-About_OWASP.md) +- [¿Qué son los riesgos de seguridad de las aplicaciones?](0x02_2025-What_are_Application_Security_Risks.md) +- [Establecimiento de un programa moderno de seguridad de aplicaciones](0x03_2025-Establishing_a_Modern_Application_Security_Program.md) + +### Lista Top 10:2025 + +1. [A01:2025 - Pérdida de Control de Acceso](A01_2025-Broken_Access_Control.md) +2. [A02:2025 - Configuración de Seguridad Incorrecta](A02_2025-Security_Misconfiguration.md) +3. [A03:2025 - Fallas en la Cadena de Suministro de Software](A03_2025-Software_Supply_Chain_Failures.md) +4. [A04:2025 - Fallas Criptográficas](A04_2025-Cryptographic_Failures.md) +5. [A05:2025 - Inyección](A05_2025-Injection.md) +6. [A06:2025 - Diseño Inseguro](A06_2025-Insecure_Design.md) +7. [A07:2025 - Fallas de Autenticación](A07_2025-Authentication_Failures.md) +8. [A08:2025 - Fallas en la Integridad del Software o de los Datos](A08_2025-Software_or_Data_Integrity_Failures.md) +9. [A09:2025 - Fallas en el Registro, Alerta y Monitoreo de Seguridad](A09_2025-Security_Logging_and_Alerting_Failures.md) +10. [A10:2025 - Manejo Inadecuado de Condiciones Excepcionales](A10_2025-Mishandling_of_Exceptional_Conditions.md) + +--- + +**Nota:** Las traducciones se añadirán a medida que estén disponibles. diff --git a/2025/mkdocs.yml b/2025/mkdocs.yml index 35bee0cc0..dbcbc83e9 100644 --- a/2025/mkdocs.yml +++ b/2025/mkdocs.yml @@ -14,6 +14,7 @@ theme: - navigation.instant - search.suggest + nav: - Home: 'en/index.md' - Introduction: 'en/0x00_2025-Introduction.md' @@ -33,9 +34,11 @@ nav: - A10 Mishandling of Exceptional Conditions: 'en/A10_2025-Mishandling_of_Exceptional_Conditions.md' - Next Steps: 'en/X01_2025-Next_Steps.md' + markdown_extensions: - attr_list + plugins: - search - i18n: @@ -48,8 +51,30 @@ plugins: default: true name: en - English build: true + - locale: es + name: es - Español + build: true + nav_translations: + Home: Inicio + Introduction: Introducción + About OWASP: Acerca de OWASP + What are Application Security Risks?: ¿Qué son los Riesgos de Seguridad en Aplicaciones? + Establishing a Modern Application Security Program: Estableciendo un Programa Moderno de Seguridad en Aplicaciones + Top 10:2025 List: Lista Top 10:2025 + A01 Broken Access Control: A01 Control de Acceso Roto + A02 Security Misconfiguration: A02 Configuración de Seguridad Incorrecta + A03 Software Supply Chain Failures: A03 Fallos en la Cadena de Suministro de Software + A04 Cryptographic Failures: A04 Fallos Criptográficos + A05 Injection: A05 Inyección + A06 Insecure Design: A06 Diseño Inseguro + A07 Authentication Failures: A07 Fallos de Autenticación + A08 Software or Data Integrity Failures: A08 Fallos de Integridad de Software o Datos + A09 Security Logging and Alerting Failures: A09 Fallos en el Registro y Alertas de Seguridad + A10 Mishandling of Exceptional Conditions: A10 Manejo Incorrecto de Condiciones Excepcionales + Next Steps: Próximos Pasos nav_translations: + SAMPLE: Home: Startseite Notice: Anmerkung @@ -69,30 +94,31 @@ plugins: A09 Security Logging and Monitoring Failures: A09 - Unzureichendes Logging und Sicherheitsmonitoring A10 Server Side Request Forgery (SSRF): A10 - Server-Side Request Forgery (SSRF) Next Steps: Nächste Schritte - - macros: # needs to be the last plugin to export the final osib-YAML file for all languages + - macros: module_name: '../osib/osib_macro' include_dir: '../osib/include' - verbose: false # debug + verbose: false on_error_fail: true extra: - alternate: # see https://squidfunk.github.io/mkdocs-material/setup/changing-the-language/#site-language-selector + alternate: - name: en - English link: ./en/ lang: en + - name: es - Español + link: ./es/ + lang: es # - name: de - Deutsch # link: ./de/ # lang: de osib: document: osib.owasp.top10 version: 2025-0-1 -# document: # e.g. osib.owasp.top10 -# version: # e.g. 4-0, 2025-1-0 - categories: [document, awareness] # list of all default categories + categories: [document, awareness] default_lang: en yaml_file: ../osib/include/osib.yml export_dir: ../osib/export - latest: 2 # 2: add the latest version(s), if successor(s) exist, log an info - debug: 0 # debug level (0-3); default is 2 + latest: 2 + debug: 0 cre: osib.owasp.cre.1-0 successor_texts: en: successor