Top10owasp v29 09 2021

VERSIÓN: 29-09-2021
www.qualityfactory.cl
Traducción OWASP TopTen:2021 (BORRADOR-2 )
Contenido
Traducción en chileno (spanish).......................................................................................................... 3
Introducción ........................................................................................................................................ 4
Los cambios en OWASP TOPTEN:2021................................................................................................ 4
Metodología ........................................................................................................................................ 8
Cómo están estructuradas las categorías ........................................................................................... 8
Cómo se utilizan los datos para seleccionar categorías ...................................................................... 9
¿Por qué no solo datos estadísticos puros? ...................................................................................... 10
¿Por qué tasa de incidencia en lugar de frecuencia? ........................................................................ 11
¿Cuál es su proceso de recopilación y análisis de datos? ................................................................. 12
Factores de datos .............................................................................................................................. 13
Cómo utilizar OWASP Top 10 como estándar ................................................................................... 15
Cómo iniciar un programa AppSec con OWASP Top 10 .................................................................... 17
Sobre OWASP .................................................................................................................................... 21
Lista de TOPTEN:2021 ....................................................................................................................... 22
A01: 2021 - Control de acceso roto................................................................................................... 22
A02: 2021 - Fallos criptográficos ....................................................................................................... 27
A03:2021 - Inyección ......................................................................................................................... 32
A04:2021 - Diseño inseguro .............................................................................................................. 37
A05:2021 - Configuración incorrecta de seguridad .......................................................................... 41
A06:2021 - Componentes vulnerables y obsoletos........................................................................... 46
A07:2021 - Fallos de identificación y autenticación.......................................................................... 50
A08:2021 - Fallos de integridad de datos y software ........................................................................ 54
A09:2021 - Fallos de seguimiento y registro de seguridad ............................................................... 57
A10:2021 - Falsificación de solicitud del lado del servidor (SSRF) .................................................... 61
A11: 2021 - Próximos pasos .............................................................................................................. 65
A11.1 Problemas de calidad del código ............................................................................................ 65
A11.2 Denegación de servicio ........................................................................................................... 67
A11.3 Errores de administración de memoria .................................................................................. 68
Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

2 Revisor: callendes@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!
Traducción en chileno (spanish)

Agradecemos este trabajo de actualización, a nuestra colega Andrea Mujica, responsable
de la coordinación del material educativo y formación continua en www.QualityFactory.cl
Esperamos que sea de utilidad para nuestros clientes, asociados y colegas.
Desde ahora, Top10:2021 se incorpora en la malla de entrenamientos que dicta

QualityFactory para:
 Desarrollo Seguro en el Ciclo de Vida del Software

 Técnicas de Programación Segura
 Testing de Seguridad y Rendimiento
 Redacción de RFP y Licitaciones de Proyectos de Software

Introducción
Bienvenido al OWASP TOPTEN- 2021
¡Bienvenido a la última entrega del OWASP TOPTEN! El OWASP TOPTEN 2021 es

completamente nuevo, con un nuevo diseño gráfico y una infografía de una página
disponible que puede imprimir u obtener desde nuestra página de inicio.
Un enorme agradecimiento a todos los que contribuyeron con su tiempo y datos para esta
iteración. Sin Uds., esta entrega no sucedería. ¡GRACIAS!
Los cambios en OWASP TOPTEN:2021

Se crearon tres nuevas categorías, y en cuatro ya existentes, se les cambió el nombre y/o
sus alcances.

A01:2021- Control de acceso roto; sube desde posición #5 a #1; El 94% de las
aplicaciones fueron probadas para detectar algún tipo de control de acceso roto. Los 34
CVE asignados a “Broken Access Control” tuvieron más ocurrencias en las aplicaciones
que en cualquier otra categoría.
A02:2021-Fallas criptográficas sube una posición desde #3 a #2, anteriormente conocida

como Exposición a Datos Sensibles, que era un síntoma amplio en lugar de una causa raíz.
El enfoque renovado aquí está en las fallas relacionadas con la criptografía que a menudo
conducen a la exposición de datos confidenciales o al compromiso del sistema.
A03:2021- Inyección; baja de #1 a #3. El 94% de las aplicaciones se probaron para alguna
forma de inyección, y los 33 CVE mapeados en esta categoría tienen la segunda mayor
cantidad de ocurrencias en las aplicaciones. Cross-site Scripting (XSS) ahora forma parte
de esta categoría.
A04:2021- Diseño inseguro; es una nueva categoría para 2021, con un enfoque en los
riesgos relacionados con los defectos de diseño. Si realmente queremos "movernos a la
izquierda" como industria, se requiere un mayor uso del modelado de amenazas, patrones
y principios de diseño seguros y arquitecturas de referencia.
A05:2021- Configuración incorrecta de seguridad; sube de #6 a #5. El 90% de las

aplicaciones se probaron para detectar algún tipo de configuración incorrecta. Con el auge
del software altamente parametrizable, no es sorprendente ver que esta categoría subió.
La ex categoría de Entidades externas XML (XXE) ahora forma parte de esta categoría.

A06:2021- Componentes vulnerables y obsoletos; se tituló anteriormente “Uso de

componentes con vulnerabilidades conocidas” y es #2 en la encuesta de la industria, pero
también tenía suficientes datos para llegar al TOPTEN a través del análisis de datos. Esta
categoría sube de #9 a #6 y es un problema conocido que requiere gestionar dicho riesgo.
Es la única categoría que no tiene ningún CVE asignado a los CVE incluidos, por lo que en
sus puntajes se asume la existencia de un exploit predeterminado y ponderaciones de
impacto de 5.0.
A07:2021- Fallas de identificación y autenticación anteriormente era “Autenticación

rota”, baja de #2 a #7, y ahora incluye CVE que están más relacionadas con fallas de
identificación. Esta categoría sigue siendo una parte integral del TOPTEN, pero con la
potencia de los framework estandarizados, parece estar mejorando.
A08:2021- Fallas de integridad del software y datos es una nueva categoría para 2021,
se trata de gestionar riesgos y verificar la integridad pre y post tareas relacionadas con
actualizaciones de software, datos críticos y pipelines CI/CD, sin una verificación de
integridad. En esta categoría se agregó el riesgo por “Deserialización Insegura”, y que
estadísticamente (en esta categoría) tiene los impactos ponderados más altos de los datos
CVE/CVSS mapeado a los 10 CVE.
A09:2021- Fallas de registro y monitoreo de seguridad; sube desde #10 a #9,

anteriormente se llamaba “Registro y monitoreo insuficientes” y se origina a partir de la
encuesta de la industria (#3). Esta categoría ahora incluye más tipos de fallas, pero es difícil
de probar y no está bien representada en los datos CVE/CVSS. Sin embargo, las fallas en
esta categoría pueden afectar directamente la visibilidad, las alertas de incidentes y los
análisis forenses.

A10:2021- Falsificación de solicitud del lado del servidor (SSRF). se agrega a partir de
la encuesta de la industria (#1). Los datos muestran una tasa de incidencia relativamente
baja con una cobertura de pruebas superior a la media, junto con calificaciones superiores
a la media para el potencial de explotación e impacto. Esta categoría representa el
escenario en el que los profesionales de la industria nos dicen que esto es importante,
aunque no esté ilustrado en los datos en este momento.

Metodología
Esta entrega del TOPTEN está basada más que nunca en los datos, pero no ciegamente
impulsada por datos. Seleccionamos 8 de las 10 categorías a partir de datos aportados y
dos categorías de una encuesta de la industria a un alto nivel. Hacemos esto por una razón
fundamental, mirar los datos aportados es mirar hacia el pasado. Los investigadores de
AppSec se toman el tiempo para encontrar nuevas vulnerabilidades y nuevas formas de
probarlas. Se necesita tiempo para integrar estas pruebas en herramientas y procesos.
Para cuando podamos probar de manera confiable una debilidad a escala real, es probable
que hayan pasado años. Para equilibrar ese punto de vista, utilizamos una encuesta de la
industria para preguntar a las personas en primera línea qué ven como debilidades
esenciales, que los datos aún no muestran.
Hay algunos cambios críticos que adoptamos para continuar madurando en el TOPTEN.
Cómo están estructuradas las categorías

Algunas categorías han cambiado con respecto a la entrega anterior del TopTen de
OWASP. Aquí hay un resumen de alto nivel de los cambios de categoría.
La recopilación de datos anteriores se centraba en un subconjunto predefinido de

aproximadamente 30 CWE pero con una realidad en terreno, que solicitaba hallazgos
adicionales. Aprendimos, por experiencia, que las organizaciones se enfocan en ese
conjunto predefinido de 30 CWE y rara vez agregan otros CWE “candidatos”. En esta
iteración, lo dejamos abierto y solo pedimos datos, sin restricción en CWE. Solicitamos la
cantidad de aplicaciones probadas para un año determinado (a partir de 2017) y la cantidad
de aplicaciones con al menos una instancia de CWE encontrada en las pruebas. Este
formato nos permite realizar un seguimiento de la prevalencia de cada CWE dentro de la
población de aplicaciones. Ignoramos la frecuencia para nuestros propósitos; si bien puede
ser necesario para otras situaciones, solo oculta la prevalencia real en la población de
aplicaciones. Si una aplicación tiene cuatro instancias de CWE o 4,000 instancias no es
parte del cálculo para el TOPTEN. Pasamos de aproximadamente 30 CWE a casi 400 CWE
para analizar en el conjunto de datos. Planeamos hacer análisis de datos adicionales como

complemento en el futuro. Este aumento significativo en el número de CWE requiere

cambios en la forma en que se estructuran las categorías.
Pasamos varios meses agrupando y categorizando los CWE y podríamos haber continuado
durante meses adicionales. Tuvimos que parar en algún momento. Existen tanto la causa
raíz como los tipos de síntomas de los CWE, donde los tipos de causa raíz pueden ser
como "Fallo criptográfico" y " Configuración incorrecta", en contraste con los tipos de
síntomas 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 proporcionar
una guía de identificación y corrección. Centrarse en la causa raíz sobre el síntoma no es
un concepto nuevo; el Top Ten ha sido una mezcla de síntoma y causa raíz. Los CWE
también son una combinación de síntomas y causas raíz; simplemente estamos siendo más
deliberados al respecto y lo enunciamos. Hay un promedio de 19.6 CWE por categoría en
esta entrega, con los límites inferiores en 1 CWE para A10: 2021-Falsificación de solicitudes
del lado del servidor (SSRF) a 40 CWE en A04: 2021-Diseño inseguro. Esta estructura de
categorías actualizada ofrece beneficios de capacitación adicionales, ya que las empresas
pueden enfocarse en CWE que tengan sentido para un determinado lenguaje/framework.
Cómo se utilizan los datos para seleccionar categorías

En 2017, seleccionamos categorías por tasa de incidencia para determinar la probabilidad,
luego, por discusión en equipo, las clasificamos según décadas de experiencia en
Explotabilidad , Detectabilidad (también probabilidad ) e Impacto técnico. Para 2021,
queremos usar datos para la explotabilidad y el impacto (técnico) si es posible.
Descargamos OWASP Dependency Check y extrajimos los puntajes CVSS para Exploit e
Impact, agrupados por CWE relacionados. Tomó un poco de investigación y esfuerzo ya
que todos los CVE tienen puntajes CVSSv2, pero hay fallas en CVSSv2 que CVSSv3
debería solucionar. Después 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 actualizarón
entre CVSSv2 y CVSSv3.

En CVSSv2, tanto Exploit como (Technical) Impact podrían ser de hasta 10.0, pero en
CVSSv3 la fórmula los redujo al 60% para Exploit y al 40% para Impact. En CVSSv3, el
máximo teórico se limitó a 6.0 para Exploit y 4.0 para Impact. Teniendo en cuenta la
ponderación, la puntuación de impacto subió más, casi un punto y medio en promedio en
CVSSv3, y la explotabilidad se movió casi medio punto más bajo en promedio.
Hay 125,000 registros de un CVE mapeados a un CWE en los datos de la base de datos
nacional de vulnerabilidades (NVD) extraídos desde OWASP Dependency Check, y hay
241 CWE únicos mapeados a un CVE. Los mapas de 62,000 CWE tienen una puntuación
CVSSv3, que es aproximadamente la mitad de la población en el conjunto de datos.
Para el Top Ten 2021, calculamos los puntajes promedio de explotación e impacto de la
siguiente manera. Agrupamos todos los CVE con puntuaciones CVSS por CWE y
ponderamos tanto el aprovechamiento como el impacto puntuados por el porcentaje de la
población que tenía CVSSv3 + la población restante de puntuaciones CVSSv2, para
obtener un promedio general. Trazamos los promedios presentados a los CWES en el
conjunto de datos para su uso como puntuación para la otra mitad de la ecuación de riesgo,
en el caso de Exploit y (Technical) Impact.
¿Por qué no solo datos estadísticos puros?

Los resultados de los datos se limitan principalmente a lo que podemos probar de forma
automatizada. Cualquier profesional experimentado de AppSec le puede comentar sobre
los hallazgos y las tendencias que ellos detectan, y que aún no están en los datos. Se
necesita tiempo para que las personas desarrollen metodologías de prueba para ciertos
tipos de vulnerabilidad y luego más tiempo para que esas pruebas se automaticen y se
ejecuten en una gran cantidad de aplicaciones. Todo lo que encontramos esta atrás en el
pasado y es posible que falten tendencias del último año, que aún no están presentes en
los datos.
Por lo tanto, solo seleccionamos ocho de diez categorías de los datos porque están
incompletos. Las otras dos categorías son de la encuesta de la comunidad TOPTEN.
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 es posible que nunca se expresen
en los datos).
¿Por qué tasa de incidencia en lugar de frecuencia?

Hay tres fuentes principales de datos. Los identificamos como herramientas asistidas por
humanos (HaT), humanos asistidops por herramientas (TaH) y herramientas en bruto
(Tooling).
Tooling y HaT son los que generan la mayor frecuencia de hallazgos. Las herramientas
buscarán vulnerabilidades específicas e intentarán incansablemente encontrar cada
instancia de esa vulnerabilidad y generarán un alto número de hallazgos para algunos tipos
de vulnerabilidad. Por ejemplo Cross-Site Scripting, que es un error aislado más pequeño
o un problema sistémico. Cuando se trata de un problema sistémico, los recuentos de
hallazgos pueden ser de miles para una sola aplicación. Esta alta frecuencia ahoga la
mayoría de las otras vulnerabilidades encontradas en informes o datos.
TaH, por otro lado, encontrará una gama más amplia de tipos de vulnerabilidad, pero con
una frecuencia mucho menor debido a las limitaciones de tiempo. Cuando los humanos
prueban una aplicación y ven algo como Cross-Site Scripting, normalmente encontrarán
tres o cuatro instancias y se detendrán. Pueden determinar un hallazgo sistémico y
escribirlo con una recomendación para fijarlo en una escala de toda la aplicación. No hay
necesidad (ni tiempo) para encontrar cada instancia.
Supongamos que tomamos estos dos conjuntos de datos distintos e intentamos fusionarlos
basados en la frecuencia. En ese caso, los datos de Tooling y HaT ahogarán los datos de
TaH más precisos (pero amplios) y es en buena parte de por qué algo como Cross-Site
Scripting se ha clasificado tan alto en muchas listas cuando el impacto es generalmente
bajo a moderado. Es por el gran volumen de hallazgos. (Cross-Site Scripting también es
razonablemente fácil de probar, por lo que también hay muchas más pruebas).
En 2017, introdujimos el uso de la tasa de incidencia para echar un vistazo a los datos y
fusionar limpiamente los datos de herramientas y HaT con los datos de TaH. La tasa de
incidencia pregunta qué porcentaje de la población de aplicaciones tenía al menos una

instancia de un tipo de vulnerabilidad. No nos importa si fue único o sistémico. Eso es

irrelevante para nuestros propósitos; solo necesitamos saber cuántas aplicaciones tenían
al menos una instancia, lo que ayuda a proporcionar una visión más clara de los resultados
de las pruebas en varios tipos de pruebas sin ahogar los datos en resultados de alta
frecuencia. Esto corresponde a una vista relacionada con el riesgo, ya que un atacante solo
necesita una instancia para atacar una aplicación con éxito a través de la categoría.
¿Cuál es su proceso de recopilación y análisis de datos?

Formalizamos el proceso de recopilación de datos de OWASP TOPTEN en la Open Security
Summit en 2017. Los líderes de OWASP TOPTEN y la comunidad pasaron dos días
trabajando para formalizar un proceso transparente de recopilación de datos. La edición de
2021 es la segunda vez que utilizamos esta metodología.
Publicamos una convocatoria de datos a través de los canales de redes sociales disponibles
para nosotros, tanto del proyecto como de OWASP. En la página del Proyecto OWASP,
enumeramos los elementos de datos y la estructura que estamos buscando y cómo
enviarlos. En el proyecto de GitHub, tenemos archivos de ejemplo que sirven como
plantillas. Trabajamos con organizaciones según sea necesario para ayudar a determinar
la estructura y el mapeo de los CWE.
Obtenemos datos de organizaciones comerciales que realizan testing, otros proveedores

de recompensas por errores (Bug Bounty) y organizaciones que contribuyen con datos de
prueba internos. Una vez que tenemos los datos, los cargamos juntos y ejecutamos un
análisis fundamental de lo que los CWE asignan a las categorías de riesgo. Existe una
superposición entre algunos CWE y otros están muy relacionados (por ejemplo,
vulnerabilidades criptográficas). Todas las decisiones relacionadas con los datos brutos
enviados se documentan y publican para que sean abiertas y transparentar la forma en que
normalizamos los datos.
Examinamos las 8 categorías con las tasas de incidencia más altas para su inclusión en el
TOPTEN. También los resultados de la encuesta de la comunidad TOPTEN para ver cuáles
pueden estar ya presentes en los datos. Los dos de mayor votación que aún no están
presentes en los datos, fueron seleccionados para completar los otros 2 lugares en el

TOPTEN. Una vez que se seleccionaron los diez, aplicamos factores generalizados de
explotabilidad e impacto; para ayudar a clasificar el TOPTEN 2021 en un orden basado en
el riesgo.
Factores de datos
Para cada una de las 10 categorías principales, se enumeran factores de datos, y esto es
lo que significan:
 CWEs Mapeados: Número de CWEs mapeados a una categoría por equipo Top10.
 Tasa de incidencia: Es el porcentaje de aplicaciones vulnerables a ese CWE de la
población probada por esa organización para ese año.
 Exploit ponderado: La sub-escala del Exploit, según las puntuaciones CVSSv2 y
CVSSv3 asignadas a CVEs mapeadas a CWEs, normalizadas y colocadas en una
escala de 10pt.
 Impacto ponderado: La sub-escala de impacto de los puntajes CVSSv2 y CVSSv3
asignados a los CVE asignados a los CWE, normalizados y colocados en una escala
de 10pt.
 (Pruebas) Cobertura: El porcentaje de aplicaciones probadas por todas las
organizaciones para un CWE determinado.
 Ocurrencias totales: Número total de aplicaciones que tienen los CWE asignados
a una categoría.
 Total de CVE: número total de CVE en la base de datos NVD que se asignaron a
los CWEs mapeados a una categoría.

Gracias a nuestros colaboradores de datos
Las siguientes organizaciones (junto con algunos donantes anónimos) amablemente

donaron datos para más de 500,000 aplicaciones para hacer de este el conjunto de datos
de seguridad de aplicaciones más grande y completo. Sin Uds. esto no sería posible.
 AppSec Labs
 Cobalt.io
 Seguridad de contraste
 GitLab
 HackerOne
 Tecnologías HCL
 Enfoque micro
 PenTest-Tools
 Probely
 Sqreen
 Veracode
 WhiteHat (NTT)
Gracias a nuestro patrocinador
El equipo de OWASP TOPTEN 2021 agradece el apoyo financiero de Secure Code Warrior.

Cómo utilizar OWASP Top 10 como estándar

El OWASP Top 10 es principalmente un documento de concientización. Sin embargo, esto
no ha impedido que las organizaciones de la industria AppSec, lo utilicen como un estándar
de facto desde su creación en 2003. Si desea utilizar el OWASP Top 10 como un estándar
de codificación o prueba, sepa que es lo mínimo y solo un punto de partida.
Una de las dificultades de utilizar OWASP Top 10 como estándar es que documentamos
los riesgos de AppSec y no necesariamente los problemas fácilmente comprobables. Por
ejemplo, A04: 2021-Diseño inseguro está más allá del alcance de la mayoría de las formas
de prueba. Otro ejemplo son las pruebas en el lugar, en uso, y el registro y el monitoreo
efectivos solo se pueden realizar con entrevistas y solicitando una muestra de respuestas
efectivas a incidentes. Una herramienta de análisis de código estático puede buscar la
ausencia de registro, pero puede ser imposible determinar si la lógica empresarial o el
control de acceso están registrando brechas de seguridad críticas. Los pentesters solo
pueden determinar que han invocado la respuesta a incidentes en un entorno de prueba,
que no se monitorea de la misma manera que los entornos de producción.
Aquí están las recomendaciones sobre cuándo es apropiado usar OWASP Top10:
Use Case OWASP OWASP Application Security

TopTen:2021 Verification Standard
Awareness SI
Training Nivel Básico Exahustivo
Design and architecture Ocasionalmente SI
Coding standard Mínimo exigible SI
Secure Code Review Mínimo exigible SI

Peer review Checklist Mínimo exigible SI
Unit testing Ocasionalmente SI
Integration testing Ocasionalmente SI
Penetration testing Mínimo exigible SI
Tool support Mínimo exigible SI
Secure Supply Chain Ocasionalmente SI
Alentamos a cualquiera que desee adoptar un estándar de seguridad de aplicaciones a usar

el Estándar de verificación de seguridad de aplicaciones (ASVS) de OWASP, ya que está
diseñado para ser verificable y probado, y puede usarse 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 manera integral contra los 10
principales riesgos de OWASP, debido a la naturaleza de varios de los 10 riesgos
principales de OWASP, con referencia a A04: 2021-Diseño inseguro. OWASP no respalda
ninguna declaración de cobertura completa del OWASP Top 10, porque simplemente no es
cierto.

Cómo iniciar un programa AppSec con OWASP Top 10

OWASP Top 10 nunca fue diseñado para ser la base de un programa AppSec. Sin embargo,
es esencial comenzar en algún lugar para muchas organizaciones que recién inician su
viaje de seguridad de aplicaciones. El OWASP Top 10 2021 es un buen comienzo como
base para las listas de verificación, etc., pero no es suficiente en sí mismo.
Etapa 1. Identifique brechas y objetivos de su programa AppSec

Muchos programas de seguridad de aplicaciones (AppSec) intentan correr antes de poder
gatear o caminar. Estos esfuerzos están condenados al fracaso. Recomendamos
encarecidamente a los CISO y a los líderes de AppSec que utilicen el Modelo de madurez
de garantía de software de OWASP (SAMM) para identificar debilidades y áreas de mejora
durante un período de 1 a 3 años. El primer paso es evaluar dónde se encuentra ahora,
identificar las brechas en la gobernanza, el diseño, la implementación, la verificación y las
operaciones que necesita resolver de inmediato frente a las que pueden esperar, y priorizar
la implementación o la mejora de las quince prácticas de seguridad de OWASP SAMM.
OWASP SAMM puede ayudarlo a construir y medir mejoras en sus esfuerzos de garantía
de software.
Etapa 2. Planificar un ciclo de vida de desarrollo seguro de

carreteras pavimentadas
El concepto de carretera pavimentada es "la forma más fácil es también la forma más
segura" y debe involucrar una cultura de asociaciones profundas entre el equipo de
desarrollo y el equipo de seguridad, preferiblemente de manera que sean el mismo equipo.
El camino pavimentado tiene como objetivo mejorar, medir, detectar y reemplazar
continuamente alternativas inseguras al tener una biblioteca de reemplazos seguros para
toda la empresa, con herramientas para ayudar a ver dónde se pueden hacer mejoras al
adoptar el camino pavimentado. Esto permite que las herramientas de desarrollo existentes
informen sobre compilaciones inseguras y ayude a los equipos de desarrollo a
autocorregirse desde las alternativas inseguras.

El camino pavimentado puede parecer mucho para asimilar, pero debe construirse
gradualmente con el tiempo. Existen otras formas de programas AppSec, en particular, el
ciclo de vida de desarrollo seguro ágil de Microsoft. No todas las metodologías de
programas de AppSec se adaptan a todas las empresas.
Etapa 3. Implementar la carretera pavimentada con sus equipos de

desarrollo.
Las carreteras pavimentadas se construyen con el consentimiento y la participación directa
de los equipos de desarrollo y operaciones pertinentes. La carretera pavimentada debe
estar alineada estratégicamente con el negocio y ayudar a entregar aplicaciones más
seguras con mayor rapidez. El desarrollo de la carretera pavimentada debería ser un
ejercicio holístico que cubra todo el ecosistema empresarial o de aplicaciones, no un
parche-curita para cada aplicación, como en los viejos tiempos.
Etapa 4. Migrar todas las aplicaciones existentes y futuras a la

carretera pavimentada.
Agregue herramientas para detección de carreteras pavimentadas, a medida que las
desarrolle y proporcione información a los equipos de desarrollo para mejorar la seguridad
de sus aplicaciones mediante la forma en que pueden adoptar directamente elementos de
la carretera pavimentada. Una vez que se ha adoptado un aspecto de la carretera
pavimentada, las organizaciones deben implementar controles de integración continuos
que inspeccionen el código existente y los controles que utilizan alternativas prohibidas y
advierten o rechazan la construcción o el registro. Esto evita que las opciones inseguras se
introduzcan en el código con el tiempo, evitando la deuda técnica y una aplicación insegura
defectuosa. Dichas advertencias deben vincularse a la alternativa segura, de modo que el
equipo de desarrollo reciba la respuesta correcta de inmediato. Pueden refactorizar y
adoptar rápidamente el componente de carretera pavimentada.

Etapa 5. Compruebe que la carretera pavimentada haya mitigado

los problemas encontrados en el Top 10 de OWASP
Los componentes de carreteras pavimentadas deben abordar un problema importante con
OWASP Top 10, esto es, cómo detectar o reparar automáticamente componentes
vulnerables, o usar plugins del IDE para realizar análisis estático del código y detectar
inyecciones, o mejor aún, comenzar a usar una biblioteca que se sabe que es segura contra
inyecciones. Cuantos más de estos reemplazos directos seguros se proporcionen a los
equipos, mejor. Una tarea vital del equipo de AppSec es garantizar que la seguridad de
estos componentes se evalúe y mejore continuamente. Una vez que se mejoran, debe
comunicarse al resto de los consumidores del componente, y debería ocurrir
preferiblemente de forma automática, pero si no, al menos resaltado en un tablero o similar.
Etapa 6. Lleve su programa hacia un programa maduro de AppSec

No debe detenerse en el Top 10 de OWASP. Solo cubre 10 categorías de riesgo.
Recomendamos encarecidamente a las organizaciones que adopten el Estándar de
verificación de seguridad de aplicaciones y agreguen progresivamente componentes y
pruebas de carreteras pavimentadas para los niveles 1, 2 y 3, según el nivel de riesgo de
las aplicaciones desarrolladas.
Avanzar más allá

Todos los grandes programas de AppSec van más allá del mínimo indispensable. Todos
deben seguir adelante si alguna vez vamos a superar las vulnerabilidades de AppSec.
 Integridad conceptual. Los programas maduros de AppSec deben contener algún

concepto de arquitectura de seguridad, ya sea una arquitectura formal de seguridad en
la nube o empresarial o modelado de amenazas.
 Automatización y escala. Los programas maduros de AppSec intentan automatizar la

mayor cantidad posible de sus entregables, utilizando scripts para emular pasos
complejos de pruebas de penetración, herramientas de análisis de código estático

directamente disponibles para los equipos de desarrollo, ayudando a los equipos de

desarrollo en la creación de pruebas de integración y unidad de AppSec, y más.
 Cultura. Los programas maduros de AppSec intentan eliminar el diseño inseguro y

eliminar la deuda técnica del código existente al ser parte del equipo de desarrollo y no
al margen. Los equipos de AppSec que ven a los equipos de desarrollo como "nosotros"
y "ellos" están condenados al fracaso.
 Mejora continua. Los programas maduros de AppSec buscan mejorar constantemente.

Si algo no funciona, deje de hacerlo. Si algo es torpe o no escalable, trabaje para
mejorarlo. Si algo no está siendo utilizado por los equipos de desarrollo y tiene un
impacto limitado o nulo, haga algo diferente. El hecho de que hayamos realizado
pruebas como comprobaciones de escritorio desde la década de 1970 no significa que
sea una buena idea. Mida, evalúe y luego cree o mejore.

Sobre OWASP
Open Web Application Security Project (OWASP) es una comunidad abierta dedicada a
permitir que las organizaciones desarrollen, compren y mantengan aplicaciones y API en
las que se pueda confiar.
En OWASP, encontrará gratis y disponible:
 Estándares y herramientas de seguridad de aplicaciones
 Investigación de vanguardia
 Bibliotecas y controles de seguridad estándar
 Libros completos sobre pruebas de seguridad de aplicaciones, desarrollo de código
seguro y revisión de código seguro
 Presentaciones y videos
 Hojas de trucos sobre muchos temas comunes
 Reuniones de capítulos
 Eventos, capacitaciones y conferencias .
 grupos de Google
Obtenga más información en: https://www.owasp.org .
Todas las herramientas, documentos, videos, 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, porque los enfoques más efectivos para la seguridad de las
aplicaciones requieren mejoras en estas áreas.
OWASP es un nuevo tipo de organización. Nuestra ausencia de presiones comerciales nos

permite brindar información imparcial, práctica y rentable sobre la seguridad de las
aplicaciones.
OWASP no está afiliada a ninguna empresa de tecnología, aunque apoyamos el uso

informado de la tecnología de seguridad comercial. OWASP produce muchos tipos de
materiales de manera colaborativa, transparente y abierta.
La Fundación OWASP es la entidad sin fines de lucro que garantiza el éxito a largo plazo
del proyecto. Casi todos los asociados con OWASP son voluntarios, incluida la junta de
OWASP, líderes de capítulo, de proyecto y los miembros del proyecto. Apoyamos la
investigación de seguridad innovadora con subvenciones e infraestructura.
¡Ven y únete a nosotros!
Copyright y licencia
Copyright © 2003-2021 La Fundación OWASP ™. Este documento se publica bajo la licencia

Creative Commons Attribution Share-Alike 4.0. Para cualquier reutilización o distribución, debe
dejar en claro a los demás los términos de la licencia de este trabajo.

Lista de TOPTEN:2021
A01: 2021 - Control de acceso roto

Factores
Visión general
Sube desde posición #5 a #1, el 94% de las aplicaciones se probaron para detectar algún
tipo de control de acceso defectuoso. Los CWE relevantes que incluye 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 y CWE-352: Falsificación de solicitudes
entre sitios.
Descripción
El control de acceso hace cumplir la política de modo que los usuarios no pueden actuar
fuera de sus permisos previstos. Las fallas generalmente conducen a la divulgación de
información no autorizada, la modificación o la destrucción de todos los datos o la
realización de una función comercial fuera de los límites del usuario. Las vulnerabilidades
comunes de control de acceso incluyen:
● Eludir las comprobaciones de control de acceso modificando la URL, el estado

interno de la aplicación o la página HTML, o simplemente usando una herramienta
de ataque API personalizada.
● Permitir que la clave principal se cambie al registro de otro usuario, lo que permite
ver o editar la cuenta de otra persona.
● Elevación de privilegios. Actuar como usuario sin iniciar sesión o actuar como
administrador cuando inicie sesión como usuario.

● Manipulación de metadatos, como reproducir o alterar un token de control de acceso

JSON Web Token (JWT), o una cookie o campo oculto manipulado para elevar
privilegios o abusar de la invalidación de JWT.
● La configuración incorrecta de CORS permite el acceso no autorizado a la API.
● Forzar la navegación a páginas autenticadas como usuario no autenticado o páginas
privilegiadas como usuario estándar. Acceso a API con controles de acceso faltantes
para POST, PUT y DELETE.
Cómo Prevenir
El control de acceso solo es efectivo usando código confiable del lado del servidor o usar
server-less API, donde el atacante no puede modificar la verificación de control de acceso
o los metadatos.
● Denegar por defecto todos los accesos. A excepción de los recursos públicos.
● Implemente mecanismos de control de acceso una vez y reutilícelos en toda la
aplicación, incluida la minimización del uso de CORS.
● Los controles de acceso del modelo deben imponer la propiedad de los registros en
lugar de aceptar que el usuario pueda crear, leer, actualizar o eliminar cualquier
registro.
● Los modelos de dominio deben reforzar el cumplimiento de los requisitos límite del
negocio, en las aplicaciones únicas.
● Desactive la lista de directorios del servidor web y asegúrese de que los metadatos
del archivo (por ejemplo,.git) y los archivos de respaldo no estén presentes en las
raíces web.
● Registre las fallas de control de acceso, avise a los administradores cuando sea
apropiado (por ejemplo, fallas repetidas).
● Limite el acceso a la API y al controlador para minimizar el daño de las herramientas
de ataque automatizadas.
● Los tokens JWT deben invalidarse en el servidor después de cerrar la sesión.
● Los desarrolladores y el personal de control de calidad deben incluir una unidad de
control de acceso funcional y pruebas de integración.

Ejemplos de escenarios de ataque

Escenario nro.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 simplemente modifica el parámetro 'acct' del navegador para enviar el número
de cuenta que desee. Si no se verifica correctamente, el atacante puede acceder a la cuenta
de cualquier usuario.
https://example.com/app/accountInfo?acct=notmyacct
Escenario nro. 2: Un atacante simplemente obliga a los navegadores a apuntar a las URL.
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

una persona que no es administrador puede acceder a la página de administración, eso
también es una falla.
Referencias
● OWASP Proactive Controls: Enforce Access Controls
● OWASP Application Security Verification Standard: V4 Access Control
● OWASP Testing Guide: Authorization Testing
● OWASP Cheat Sheet: Access Control
● PortSwigger: Exploiting CORS misconfiguration

Lista de CWE mapeados

CWE-22 Limitación incorrecta de un nombre de ruta a un directorio restringido (‘ transversal
Path')
CWE-23 Recorrido de ruta relativo
CWE-35 Recorrido de ruta: '... /... //'
CWE-59 Resolución de enlace incorrecta antes del acceso al archivo ('Enlace siguiente')
CWE-200 Exposición de información confidencial a un actor no autorizado
CWE-201 Exposición de información confidencial a través de datos enviados
CWE-219 Almacenamiento de archivos con datos confidenciales en la raíz web
CWE-264 Permisos, privilegios y controles de acceso (ya no debe usarse)
CWE-275 Problemas de permisos
CWE-276 Permisos predeterminados incorrectos
CWE-284 Control de acceso inadecuado
CWE-285 Autorización incorrecta
CWE-352 Falsificación de solicitud entre sitios (CSRF)
CWE-359 Exposición de información personal privada a un actor no autorizado
CWE-377 Archivo temporal inseguro
CWE-402 Transmisión de recursos privados a una nueva esfera ('Fuga de recursos')
CWE-425 Solicitud directa ('Navegación forzada')
CWE-441 Proxy o intermediario involuntario ('Delegado confundido')
CWE-497 Exposición de información sensible del sistema a una esfera de control no
autorizada
CWE-538 Inserción de información confidencial en un archivo o directorio de acceso
externo
CWE-540 Inclusión de información confidencial en el código fuente
CWE-548 Exposición de información a través de la lista de directorios
CWE-552 Archivos o directorios accesibles a terceros
CWE-566 Omisión de autorización a través de la clave principal SQL controlada por el
usuario

CWE-601 Redirección de URL a un sitio que no es de confianza ('Redirección abierta')

CWE-639 Omisión de autorización a través de una clave controlada por el usuario
CWE-651 Exposición de archivos WSDL que contienen información confidencial
CWE-668 Exposición de recursos a una esfera incorrecta
CWE-706 Uso de nombre o referencia resueltos incorrectamente
CWE-862 Falta la autorización
CWE-863 Autorización incorrecta
CWE-913 Control inadecuado de recursos de código administrados dinámicamente
CWE-922 Almacenamiento inseguro de información confidencial
CWE-1275 Cookie sensible con atributo de SameSite incorrecto

A02: 2021 - Fallos criptográficos
Factores
Visión general
Sube desde #3 a #2, antes era conocido como Exposición de datos confidenciales, que es
más un síntoma amplio que una causa raíz. Ahora la atención se centra en las fallas
relacionadas con la criptografía (o la falta de ella). Lo que a menudo conduce a la exposición
de datos confidenciales. Los CWE relevantes que incluye son CWE-259: Uso de
contraseña codificada, CWE-327: Algoritmo criptográfico roto o riesgoso, y CWE-331
Entropía insuficiente.
Descripción
Lo primero es determinar las necesidades de protección de los datos en tránsito y en
reposo. Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros
médicos, la información personal y los secretos comerciales requieren protección adicional,
principalmente si estos datos se rigen por las leyes de privacidad, por ejemplo, el
Reglamento general de protección de datos (GDPR) de la UE, o las regulaciones, por
ejemplo, la protección de datos financieros, como PCI Data Security Standard (PCI DSS).
Para todos esos datos:
● ¿Se transmiten datos en texto claro? Esto se refiere a protocolos como HTTP, SMTP y
FTP. El tráfico externo de Internet es peligroso. Verifique todo el tráfico interno, por
ejemplo, entre balanceadores de carga, servidores web o sistemas de back-end.

● ¿Se utilizan algoritmos criptográficos antiguos o débiles de forma predeterminada o en

código antiguo?
● ¿Se utilizan claves criptográficas predeterminadas, se generan o reutilizan claves

criptográficas débiles, o falta la gestión o rotación de claves adecuadas?
● ¿No se aplica el cifrado? Por ejemplo, ¿faltan encabezados o directivas de seguridad

del agente de usuario (navegador)?
● ¿El agente de usuario (por ejemplo, aplicación, cliente de correo) no verifica si el

certificado de servidor recibido es válido?
● Consulte ASVS Crypto (V7), Protección de datos (V9) y SSL / TLS (V10)
Cómo Prevenir
Haga lo siguiente, como mínimo, y consulte las referencias:
● Clasifique los datos procesados, almacenados o transmitidos por una aplicación.

Identifique qué datos son confidenciales de acuerdo con las leyes de privacidad, los
requisitos reglamentarios o las necesidades comerciales.
● Aplicar controles según la clasificación.
● No almacene datos sensibles innecesariamente. Deséchelo lo antes posible o utilice la

tokenización compatible con PCI DSS o incluso el truncamiento. Los datos que no se
conservan no se pueden robar.
● Asegúrese de cifrar todos los datos confidenciales en reposo.
● Garantizar la implementación de algoritmos, protocolos y claves estándar sólidos y

actualizados; Utilice una gestión de claves adecuada.
● Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrado de
secreto directo perfecto (PFS), priorización de cifrado por parte del servidor y
parámetros seguros. Aplique el cifrado mediante directivas como HTTP Strict Transport
Security (HSTS).
● Deshabilite el almacenamiento en caché para respuestas que contengan datos

confidenciales.

● Almacene las contraseñas utilizando fuertes funciones de hash adaptativas y saladas

con un factor de trabajo (factor de retraso), como Argon2, scrypt, bcrypt o PBKDF2.
● Verifique de forma independiente la eficacia de la configuración y los ajustes.

Escenario nro. 1: Una aplicación cifra los números de tarjetas de crédito en una base de
datos mediante el cifrado automático de la base de datos. Sin embargo, estos datos se
descifran automáticamente cuando se recuperan, lo que permite que un error de inyección
SQL recupere números de tarjetas de crédito en texto sin cifrar.
Escenario nro. 2: un sitio no usa ni aplica TLS para todas las páginas o admite un cifrado
débil. Un atacante monitorea el tráfico de la red (por ejemplo, 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. En lugar
de lo anterior, podrían alterar todos los datos transportados, por ejemplo, el destinatario de
una transferencia de dinero.
Escenario nro. 3: la base de datos de contraseñas utiliza hashes simples o sin “salto” para
almacenar las contraseñas de todos. Una falla en la carga de archivos permite a un atacante
recuperar la base de datos de contraseñas. Todos los hashes sin “salto” se pueden exponer
con una tabla rainbow de hashes pre-calculados. Los hash generados por funciones hash
simples o rápidas pueden ser descifrados por las GPU, incluso si fueron creados con “salto”.
Referencias
● OWASP Proactive Controls: Protect Data Everywhere
● OWASP Application Security Verification Standard (V7, 9, 10)
● OWASP Cheat Sheet: Transport Layer Protection
● OWASP Cheat Sheet: User Privacy Protection
● OWASP Cheat Sheet: Password and Cryptographic Storage
● OWASP Cheat Sheet: HSTS
● OWASP Testing Guide: Testing for weak cryptography

Lista de CWE mapeados

CWE-261 Weak Encoding for Password
CWE-296 Improper Following of a Certificate's Chain of Trust
CWE-310 Cryptographic Issues
CWE-319 Cleartext Transmission of Sensitive Information
CWE-321 Use of Hard-coded Cryptographic Key
CWE-322 Key Exchange without Entity Authentication
CWE-323 Reusing a Nonce, Key Pair in Encryption
CWE-324 Use of a Key Past its Expiration Date
CWE-325 Missing Required Cryptographic Step
CWE-326 Inadequate Encryption Strength
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
CWE-328 Reversible One-Way Hash
CWE-329 Not Using a Random IV with CBC Mode
CWE-330 Use of Insufficiently Random Values
CWE-331 Insufficient Entropy
CWE-335 Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)
CWE-336 Same Seed in Pseudo-Random Number Generator (PRNG)
CWE-337 Predictable Seed in Pseudo-Random Number Generator (PRNG)
CWE-338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
CWE-340 Generation of Predictable Numbers or Identifiers
CWE-347 Improper Verification of Cryptographic Signature
CWE-523 Unprotected Transport of Credentials
CWE-720 OWASP Top Ten 2007 Category A9 - Insecure Communications
CWE-757 Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
CWE-759 Use of a One-Way Hash without a Salt
CWE-760 Use of a One-Way Hash with a Predictable Salt
CWE-780 Use of RSA Algorithm without OAEP

CWE-818 Insufficient Transport Layer Protection

CWE-916 Use of Password Hash With Insufficient Computational Effort

A03:2021 - Inyección
Factores
Visión general
La inyección baja de la posición #1 a #3. El 94% de las aplicaciones fueron probadas para
alguna forma de inyección.
Los CWE destacables que incluye son CWE-79: Cross-site Scripting, CWE-89: SQL
Injection y CWE-73: Control externo de nombre de archivo o ruta.
Descripción
Una aplicación es vulnerable a ataques de inyección, cuando:
● La aplicación no valida, ni filtra ni sanitiza los datos proporcionados por el usuario.
● Las consultas dinámicas o las llamadas no parametrizadas, se utilizan directamente en

el intérprete, y sin haber hecho un escapado sensible al contexto
● Los datos hostiles se utilizan dentro de los parámetros de búsqueda de mapeo

relacional de objetos (ORM) para extraer registros confidenciales e información sensible
adicional al objetivo inicial.
● Los datos hostiles se utilizan o concatenan directamente. El SQL o comando 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, comando del sistema
operativo (OS), mapeo relacional de objetos (ORM), LDAP y lenguaje de expresión (EL)
o la inyección de biblioteca de navegación de gráficos de objetos (OGNL). El concepto

es idéntico entre todos los intérpretes. La revisión del código fuente es el mejor método
para detectar si las aplicaciones son vulnerables a las inyecciones. Se recomienda
encarecidamente realizar pruebas automatizadas de todos los parámetros,
encabezados, URL, cookies, JSON, SOAP y entradas de datos XML. Las
organizaciones pueden incluir herramientas de prueba estática (SAST) y las
herramientas de prueba de aplicación dinámica (DAST) en las pipelines de CI/CD para
identificar las fallas de inyección introducidas antes de la implementación de la
producción.
Cómo Prevenir
La prevención de la inyección requiere mantener una separación entre los datos y los
comandos o consultas.
● La opción preferida es utilizar una API segura, que evita el uso del intérprete por
completo, proporciona una interfaz parametrizada o migrar a Object Relational
Mapping Tools (ORM).
Nota: Incluso cuando están parametrizados, los procedimientos almacenados

pueden introducir inyección SQL si PL/SQL o T-SQL concatenan consultas y datos
o ejecutan datos hostiles con EXECUTE IMMEDIATE o exec ().
● Utilice la validación de entrada del lado del servidor positiva o de "lista blanca". Esta
no es una defensa completa, ya que muchas aplicaciones requieren caracteres
especiales, como áreas de texto o API para aplicaciones móviles.
● Para cualquier consulta dinámica residual, escape los caracteres especiales

utilizando la sintaxis de escape específica para ese intérprete.
Nota: las estructuras SQL como nombres de tablas, nombres de columnas, etc. no
se pueden escapar y, por lo tanto, los nombres de estructuras proporcionados por
el usuario son peligrosos. Este es un problema común en el software de redacción
de informes.
● Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la divulgación
masiva de registros en caso de inyección SQL.


Escenario nro. 1: una aplicación utiliza datos que no son de confianza en la construcción
de la siguiente llamada SQL vulnerable:
String query = "SELECT * FROM accounts WHERE custID = '" +

request.getParameter ("id") + "'";
Escenario nro.2: De manera similar, la confianza absoluta de una aplicación al usar un

framework (asumiendo que el framework es seguro “per se”) puede resultar en consultas
que aún son vulnerables (por ejemplo, Hibernate Query Language (HQL)):
Consulta HQLQuery = session.createQuery ("DESDE las cuentas

DONDE custID = '" + request.getParameter ("id") + "'");
En ambos casos, el atacante modifica el valor del parámetro 'id' en su navegador para
enviar: 'o' 1 '=' 1. Por ejemplo:
http://example.com/app/accountView?id= 'o' 1 '=' 1
Esto cambia el significado de ambas consultas para devolver todos los registros de la tabla
de cuentas. Los ataques más peligrosos podrían modificar o eliminar datos o incluso invocar
procedimientos almacenados.
Referencias
● OWASP Proactive Controls: Secure Database Access
● OWASP ASVS: V5 Input Validation and Encoding
● OWASP Testing Guide: SQL Injection, Command Injection, and ORM Injection
● OWASP Cheat Sheet: Injection Prevention
● OWASP Cheat Sheet: SQL Injection Prevention
● OWASP Cheat Sheet: Injection Prevention in Java
● OWASP Cheat Sheet: Query Parameterization
● OWASP Automated Threats to Web Applications – OAT-014
● PortSwigger: Server-side template injection

Lista de CWE mapeadas

CWE-20 Improper Input Validation
CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream
Component ('Injection')
CWE-75 Failure to Sanitize Special Elements into a Different Plane (Special Element
Injection)
CWE-77 Improper Neutralization of Special Elements used in a Command ('Command
Injection')
CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS
Command Injection')
CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site
Scripting')
CWE-80 Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic
XSS)
CWE-83 Improper Neutralization of Script in Attributes in a Web Page
CWE-87 Improper Neutralization of Alternate XSS Syntax
CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument
Injection')
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL
Injection')
CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP
Injection')
CWE-91 XML Injection (aka Blind XPath Injection)
CWE-93 Improper Neutralization of CRLF Sequences ('CRLF Injection')
CWE-94 Improper Control of Generation of Code ('Code Injection')
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval
Injection')
CWE-96 Improper Neutralization of Directives in Statically Saved Code ('Static Code
Injection')
CWE-97 Improper Neutralization of Server-Side Includes (SSI) Within a Web Page
CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program
('PHP Remote File Inclusion')

CWE-99 Improper Control of Resource Identifiers ('Resource Injection')

CWE-100 Deprecated: Was catch-all for input validation issues
CWE-113 Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response
Splitting')
CWE-116 Improper Encoding or Escaping of Output
CWE-138 Improper Neutralization of Special Elements
CWE-184 Incomplete List of Disallowed Inputs
CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
CWE-471 Modification of Assumed-Immutable Data (MAID)
CWE-564 SQL Injection: Hibernate
CWE-610 Externally Controlled Reference to a Resource in Another Sphere
CWE-643 Improper Neutralization of Data within XPath Expressions ('XPath Injection')
CWE-644 Improper Neutralization of HTTP Headers for Scripting Syntax
CWE-652 Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')
CWE-917 Improper Neutralization of Special Elements used in an Expression Language
Statement ('Expression Language Injection')

A04:2021 - Diseño inseguro
Factores
Visión general
Esta nueva categoría para 2021 se centra en los riesgos relacionados con el diseño y las
fallas de arquitectura, con énfasis en un mayor uso del modelado de amenazas, patrones
de diseño seguros y arquitecturas de referencia. Los CWE más relevantes que incluye, son:
CWE-209: Generación de mensaje de error que contiene información confidencial, CWE-
256: Almacenamiento desprotegido de credenciales, CWE-501: Infracción de límites de
confianza y CWE-522: Credenciales insuficientemente protegidas.
Descripción
El diseño inseguro es una categoría amplia que representa muchas debilidades diferentes,
expresadas como "diseño de control faltante o ineficaz". Un diseño inseguro debido a que
falta un control. Por ejemplo, imagine un código que debería cifrar datos confidenciales,
pero no existe un método de encriptación.
Un diseño inseguro debido a que un control es ineficaz, es donde frente a una amenaza,
se activa una validación de la lógica de dominio (empresarial) pero es insuficiente para
impedir la acción. Por ejemplo, imagine una lógica de dominio que se supone procesa una
reducción de impuestos, en función de los tramos de ingresos, pero que no valida que todas
las entradas estén correctamente firmadas y proporcione un beneficio de reducción de
impuestos mucho más significativo de lo que debería concederse.

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 diseño seguro requiere un ciclo de vida de desarrollo seguro,
alguna forma de patrón de diseño seguro o biblioteca o herramientas de componentes de
carreteras pavimentadas y modelado de amenazas.
Cómo Prevenir
● Establecer y usar un ciclo de vida de desarrollo seguro con profesionales de AppSec
para ayudar a evaluar y diseñar controles relacionados con la seguridad y la
privacidad.
● Establecer y usar una biblioteca de patrones de diseño seguros o componentes

listos para usar.
● Usar modelado de amenazas para la autenticación crítica, el control de acceso, la

lógica empresarial y los flujos clave.
● Escribir pruebas unitarias y de integración para validar que todos los flujos críticos
son resistentes al modelo de amenazas.
Ejemplo de Escenarios de Ataque

● Escenario nro. 1: Un flujo de trabajo de recuperación de credenciales puede incluir
"preguntas y respuestas", lo cual está prohibido por NIST 800-63b, OWASP ASVS
y OWASP TOPTEN. No se puede confiar en las preguntas y respuestas como
evidencia de identidad como más de una persona puede conocer las respuestas,
por lo que están prohibidas. Dicho código debe eliminarse y reemplazarse por un
diseño más seguro.
● Escenario nro. 2: una cadena de cines permite descuentos en la reserva de grupos

y tiene un máximo de quince asistentes antes de solicitar un depósito. Los atacantes
podrían modelar este flujo y probar si podían reservar seiscientos asientos y todos
los cines a la vez en unas pocas solicitudes, lo que provocaría una pérdida masiva
de ingresos.

● Escenario nro. 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 venderlas en sitios web de subastas. Esto crea una
publicidad terrible para los fabricantes de tarjetas de video y los propietarios de
cadenas minoristas y una mala sangre duradera con los entusiastas que no pueden
obtener estas tarjetas a ningún precio. El diseño cuidadoso de anti-bot y las reglas
de lógica de dominio, como las compras realizadas dentro de unos segundos de
disponibilidad, pueden identificar compras no auténticas y rechazar dichas
transacciones.
Referencias
● [OWASP Cheat Sheet: Secure Design Principles] (TBD)
● NIST – Guidelines on Minimum Standards for Developer Verification of > Software
Lista de CWE Mapeados

CWE-73 External Control of File Name or Path
CWE-183 Permissive List of Allowed Inputs
CWE-209 Generation of Error Message Containing Sensitive Information
CWE-213 Exposure of Sensitive Information Due to Incompatible Policies
CWE-235 Improper Handling of Extra Parameters
CWE-256 Unprotected Storage of Credentials
CWE-257 Storing Passwords in a Recoverable Format
CWE-266 Incorrect Privilege Assignment
CWE-269 Improper Privilege Management
CWE-280 Improper Handling of Insufficient Permissions or Privileges
CWE-311 Missing Encryption of Sensitive Data
CWE-312 Cleartext Storage of Sensitive Information

CWE-313 Cleartext Storage in a File or on Disk

CWE-316 Cleartext Storage of Sensitive Information in Memory
CWE-419 Unprotected Primary Channel
CWE-430 Deployment of Wrong Handler
CWE-434 Unrestricted Upload of File with Dangerous Type
CWE-444 Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')
CWE-451 User Interface (UI) Misrepresentation of Critical Information
CWE-472 External Control of Assumed-Immutable Web Parameter
CWE-501 Trust Boundary Violation
CWE-522 Insufficiently Protected Credentials
CWE-525 Use of Web Browser Cache Containing Sensitive Information
CWE-539 Use of Persistent Cookies Containing Sensitive Information
CWE-579 J2EE Bad Practices: Non-serializable Object Stored in Session
CWE-598 Use of GET Request Method With Sensitive Query Strings
CWE-602 Client-Side Enforcement of Server-Side Security
CWE-642 External Control of Critical State Data
CWE-646 Reliance on File Name or Extension of Externally-Supplied File
CWE-650 Trusting HTTP Permission Methods on the Server Side
CWE-653 Insufficient Compartmentalization
CWE-656 Reliance on Security Through Obscurity
CWE-657 Violation of Secure Design Principles
CWE-799 Improper Control of Interaction Frequency
CWE-807 Reliance on Untrusted Inputs in a Security Decision
CWE-840 Business Logic Errors
CWE-841 Improper Enforcement of Behavioral Workflow
CWE-927 Use of Implicit Intent for Sensitive Communication
CWE-1021 Improper Restriction of Rendered UI Layers or Frames
CWE-1173 Improper Use of Validation Framework

A05:2021 - Configuración incorrecta de seguridad
Factores
CWEs Tasa de Tasa de Cobertura Cobertura Exploit Impacto Incidencias CVE
mapeados incidencia incidencia máxima promedio ponderado ponderado totales totales
máxima media promedio medio
20 19,84% 4,51% 89,58% 44,84% 8.12 6.56 208,387 789
Visión general
Sube del puesto #6 al #5, el 90% de las aplicaciones se probaron para detectar algún tipo
de configuración incorrecta. Con más cambios en software altamente configurable, no es
sorprendente ver que esta categoría asciende. Los CWE relevantes que incluye son
Configuración CWE-16 y CWE-611 Restricción incorrecta de la referencia de entidad
externa XML.
Descripción
La aplicación puede ser vulnerable si la aplicación es:
● Falta el refuerzo de seguridad adecuado en cualquier parte de la pila de aplicaciones

o permisos configurados incorrectamente en los servicios en la nube.
● Se habilitan o instalan funciones innecesarias (por ejemplo, puertos, servicios,

páginas, cuentas o privilegios innecesarios).
● Las cuentas predeterminadas y sus contraseñas aún están habilitadas y sin

cambios.
● El manejo de errores revela a los usuarios rastros de pila u otros mensajes de error
demasiado informativos.
● Para los sistemas actualizados, las últimas funciones de seguridad están

deshabilitadas o no configuradas de forma segura.

● Las configuraciones de seguridad en los servidores de aplicaciones, marcos de

aplicaciones (por ejemplo, Struts, Spring, ASP.NET), bibliotecas, bases de datos,
etc., no están configuradas para valores seguros.
● El servidor no envía encabezados o directivas de seguridad, o no están configurados

para valores seguros.
● El software está desactualizado o es vulnerable (consulte A06: 2021-Componentes

vulnerables y desactualizados).
● Sin un proceso de configuración de seguridad de aplicaciones coordinado y

repetible, los sistemas corren un mayor riesgo.
Cómo Prevenir
Se deben implementar procesos de instalación seguros, que incluyen:
● Un proceso de endurecimiento repetible agiliza y facilita la implementación de otro

entorno que esté adecuadamente bloqueado. Los entornos de desarrollo, control de
calidad y producción deben configurarse de forma idéntica, con diferentes
credenciales utilizadas en cada entorno. Este proceso debe automatizarse para
minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.
● Una plataforma mínima sin funciones, componentes, documentación ni ejemplos

innecesarios. Elimine o no instale funciones y marcos no utilizados.
● Una tarea para revisar y actualizar las configuraciones apropiadas para todas las
notas de seguridad, actualizaciones y parches como parte del proceso de
administración de parches (consulte A06: 2021-Componentes vulnerables y
obsoletos). Revise los permisos de almacenamiento en la nube (p. Ej., Permisos de
depósito de S3).
● Una arquitectura de aplicación segmentada proporciona una separación efectiva y

segura entre componentes o inquilinos, con segmentación, contenedorización o
grupos de seguridad en la nube (ACL).

● Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de

seguridad.
● Un proceso automatizado para verificar la efectividad de las configuraciones y

ajustes en todos los entornos.

Escenario nro. 1: El servidor de aplicaciones incluye aplicaciones de muestra que no se
eliminan del servidor de producción. Estas aplicaciones de muestra 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 no se modificaron las
cuentas predeterminadas. En ese caso, el atacante inicia sesión con las contraseñas
predeterminadas y toma el control.
Escenario nro. 2: La lista de directorios no está deshabilitada en el servidor. Un atacante

descubre que simplemente puede enumerar directorios. El atacante encuentra y descarga
las clases Java compiladas, que descompila y aplica ingeniería inversa para ver el código.
El atacante luego encuentra una falla severa de control de acceso en la aplicación.
Escenario nro. 3: la configuración del servidor de aplicaciones permite que se devuelvan

a los usuarios mensajes de error detallados, por ejemplo, seguimientos de pila. Esto
potencialmente expone información confidencial o fallas subyacentes, como versiones de
componentes que se sabe que son vulnerables.
Escenario nro. 4: un proveedor de servicios en la nube tiene permisos de uso compartido

predeterminados abiertos a Internet por otros usuarios de CSP. Esto permite acceder a los
datos confidenciales almacenados en el almacenamiento en la nube.

Referencias
● OWASP Testing Guide: Configuration Management
● OWASP Testing Guide: Testing for Error Codes
● Application Security Verification Standard V19 Configuration
● NIST Guide to General Server Hardening
● CIS Security Configuration Guides/Benchmarks
● Amazon S3 Bucket Discovery and Enumeration
Lista de CWEs Mapeados

CWE-2 Configuration
CWE-11 ASP.NET Misconfiguration: Creating Debug Binary
CWE-13 ASP.NET Misconfiguration: Password in Configuration File
CWE-15 External Control of System or Configuration Setting
CWE-16 Configuration
CWE-260 Password in Configuration File
CWE-315 Cleartext Storage of Sensitive Information in a Cookie
CWE-520.NET Misconfiguration: Use of Impersonation
CWE-526 Exposure of Sensitive Information Through Environmental Variables
CWE-537 Java Runtime Error Message Containing Sensitive Information
CWE-541 Inclusion of Sensitive Information in an Include File
CWE-547 Use of Hard-coded, Security-relevant Constants
CWE-611 Improper Restriction of XML External Entity Reference
CWE-614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
CWE-756 Missing Custom Error Page
CWE-776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity
Expansion')
CWE-942 Overly Permissive Cross-domain Whitelist
CWE-1004 Sensitive Cookie Without 'HttpOnly' Flag
CWE-1032 OWASP Top Ten 2017 Category A6 - Security Misconfiguration

CWE-1174 ASP.NET Misconfiguration: Improper Model Validation

A06:2021 - Componentes vulnerables y obsoletos
Factores
CWEs Tasa de Tasa de Cobertura Cobertura Exploit Impacto Incidencia CVE
mapeados incidencia incidenci máxima promedio ponderado ponderado s totales totales
máxima a media promedio medio
3 27,96% 8,77% 51,78% 22,47% 5,00 5,00 30,457 0
Visión general
Fue el número 2 de la encuesta de la industria, pero también tenía suficientes datos para
llegar al TOPTEN a través de la estadística. Los componentes vulnerables son un problema
conocido que nos cuesta comprobar y evaluar el riesgo y es la única categoría que no tiene
ningún CVE asignado a los CWE incluidos, por lo que se utiliza un peso de impacto / exploits
predeterminado de 5.0. Los CWE relevantes que incluye son CWE-1104: Uso de
componentes de terceros no mantenidos y los dos CWE del TOPTEN 2013 y 2017.
Descripción
Probablemente seas vulnerable:
● Si no conoce las versiones de todos los componentes que utiliza (tanto del lado del
cliente como del lado del servidor). Esto incluye los componentes que usa
directamente, así como las dependencias anidadas.
● Si el software es vulnerable, no es compatible o no está actualizado. Esto incluye el

sistema operativo, el servidor web / de aplicaciones, el sistema de administración de
bases de datos (DBMS), las aplicaciones, las API y todos los componentes, los
entornos de ejecución y las bibliotecas.
● Si no busca vulnerabilidades con regularidad y se suscribe a los boletines de

seguridad relacionados con los componentes que utiliza.
● Si no repara o actualiza la plataforma subyacente, los marcos y las dependencias

de manera oportuna y basada en el riesgo. Esto suele ocurrir en entornos en los que

la aplicación de parches es una tarea mensual o trimestral bajo control de cambios,

lo que deja a las organizaciones abiertas a días o meses de exposición innecesaria
a vulnerabilidades reparadas.
● Si los desarrolladores de software no prueban la compatibilidad de las bibliotecas

actualizadas, actualizadas o parcheadas.
● Si no asegura las configuraciones de los componentes (consulte A05: 2021-

Configuración incorrecta de seguridad).
Cómo Prevenir
Debe existir un proceso de administración de parches para:
● Elimine las dependencias no utilizadas, las funciones, los componentes, los archivos
y la documentación innecesarios.
● Realice un inventario continuo de las versiones de los componentes del lado del
cliente y del lado del servidor (por ejemplo, marcos, bibliotecas) y sus dependencias
utilizando herramientas como versiones, OWASP Dependency Check, retire.js, etc.
componentes. Utilice herramientas de análisis de composición de software para
automatizar el proceso. Suscríbase para recibir alertas por correo electrónico sobre
vulnerabilidades de seguridad relacionadas con los componentes que utiliza.
● Solo obtenga componentes de fuentes oficiales a través de enlaces seguros.

Prefiera los paquetes firmados para reducir la posibilidad de incluir un componente
malicioso modificado (consulte A08: 2021-Fallos de integridad de datos y software).
● Supervise las bibliotecas y los componentes que no se mantienen o no crean

parches de seguridad para versiones anteriores. Si no es posible aplicar un parche,
considere implementar un parche virtual para monitorear, detectar o protegerse
contra el problema descubierto.
● Cada organización debe garantizar un plan continuo para monitorear, clasificar y

aplicar actualizaciones o cambios de configuración durante la vida útil de la
aplicación o cartera.


Escenario nro. 1: los componentes normalmente se ejecutan 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 (p. Ej., Error de codificación) o
intencionales (p. Ej., Una puerta trasera en un componente). Algunos ejemplos de
vulnerabilidades de componentes explotables descubiertos son:
● CVE-2017-5638, una vulnerabilidad de ejecución remota de código de Struts 2 que

permite la ejecución de código arbitrario en el servidor, ha sido culpada de
violaciones importantes.
● Si bien el Internet de las cosas (IoT) es con frecuencia difícil o imposible de parchear,
la importancia de parchearlo puede ser grande (por ejemplo, dispositivos
biomédicos).
● Existen herramientas automatizadas para ayudar a los atacantes a encontrar
sistemas sin parches o mal configurados. Por ejemplo, el motor de búsqueda
Shodan IoT le puede ayudar a encontrar dispositivos que aún sufren la
vulnerabilidad Heartbleed parcheada en abril de 2014.
Referencias
● Estándar de verificación de seguridad de aplicaciones OWASP: arquitectura V1,
diseño y modelado de amenazas
● Comprobación de dependencia de OWASP (para bibliotecas Java y.NET)
● Guía de pruebas de OWASP: arquitectura de la aplicación de mapas (OTG-INFO-
010)
● Mejores prácticas de parcheo virtual de OWASP
● La desafortunada realidad de las bibliotecas inseguras
● Búsqueda de MITRE Common Vulnerabilities and Exposures (CVE)
● Base de datos nacional de vulnerabilidades (NVD)
● Retire.js para detectar bibliotecas de JavaScript vulnerables conocidas
● Avisos de seguridad de bibliotecas de nodos
● Herramientas y base de datos de asesoramiento de seguridad de las bibliotecas
Ruby
● https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf


CWE-937 OWASP TOPTEN 2013: Using Components with Known Vulnerabilities
CWE-1035 2017 TOPTEN A9: Using Components with Known Vulnerabilities
CWE-1104 Use of Unmaintained Third Party Components

A07:2021 - Fallos de identificación y autenticación
Factores
22 14,84% 2,55% 79,51% 45,72% 7,40 6,50 132,195 3.897
Visión general
Anteriormente conocida como “Autenticación Rota”, bajo desde la posición #2 a #7, y ahora
incluye CWE relacionados con fallas de identificación. Los CWE relevantes que incluye son
CWE-297: Validación incorrecta del certificado con discrepancia de host, CWE-287:
Autenticación incorrecta y CWE-384: Corrección de sesión.
Descripción
La confirmación de la identidad, la autenticación y la administración de sesiones del usuario
es fundamental para proteger contra los ataques relacionados con la autenticación. Puede
haber debilidades de autenticación si la aplicación:
● Permite ataques automatizados como el relleno de credenciales, donde el atacante

tiene una lista de nombres de usuario y contraseñas válidos.
● Permite la fuerza bruta u otros ataques automatizados.
● Permite contraseñas predeterminadas, débiles o conocidas, como "Contraseña1" o

"admin / admin".
● Utiliza procesos de recuperación de credenciales débiles o ineficaces y de olvido de

contraseñas, como "respuestas basadas en el conocimiento", que no pueden
protegerse.
● Utiliza contraseñas de texto sin formato, cifradas o con un hash débil (consulte A3:
Exposición de datos confidenciales de 2017).
● Tiene autenticación multifactor falta o ineficaz.

● Expone los ID de sesión en la URL (por ejemplo, reescritura de URL).
● No gire los ID de sesión después de iniciar sesión correctamente.
● No invalida correctamente los ID de sesión. Las sesiones de usuario o los tokens de

autenticación (principalmente los tokens de inicio de sesión único (SSO)) no se
invalidan correctamente durante el cierre de sesión o un período de inactividad.
Cómo Prevenir
● Siempre que sea posible, implementar la autenticación multifactor para evitar el
relleno automatizado de credenciales, la fuerza bruta y los ataques de reutilización
de credenciales robadas.
● No envíe ni implemente con credenciales predeterminadas, especialmente para

usuarios administradores.
● Implemente comprobaciones de contraseñas débiles, como probar contraseñas

nuevas o cambiadas en la lista de las 10.000 peores contraseñas.
● Alinee las políticas de longitud, complejidad y rotación de contraseñas con las

pautas de NIST 800-63b en la sección 5.1.1 para Secretos memorizados u otras
políticas de contraseñas modernas basadas en evidencia.
● Asegúrese de que el registro, la recuperación de credenciales y las rutas de API

estén reforzadas contra los ataques de enumeración de cuentas mediante el uso de
los mismos mensajes para todos los resultados.
● Limite o retrase cada vez más los intentos fallidos de inicio de sesión. Registre todas
las fallas y avise a los administradores cuando se detecten ataques de relleno de
credenciales, ataques de fuerza bruta u otros ataques.
● Utilice un administrador de sesiones integrado, seguro y del lado del servidor que
genere una nueva ID de sesión aleatoria con alta entropía después de iniciar sesión.
Los ID de sesión no deben estar en la URL, almacenarse de forma segura e invalidar
después del cierre de sesión, inactivo y tiempos de espera absolutos.


Escenario nro. 1: El relleno de credenciales, el uso de listas de contraseñas conocidas, es
un ataque común. Suponga que una aplicación no implementa protección automatizada de
relleno de credenciales o amenazas. En ese caso, la aplicación se puede utilizar como un
oráculo adivinador de contraseñas para determinar si las credenciales son válidas.
Escenario nro. 2: la mayoría de los ataques de autenticación se producen debido al uso

continuo de contraseñas como único factor. Una vez consideradas, las mejores prácticas,
la rotación de contraseñas y los requisitos de complejidad alientan a los usuarios a usar y
reutilizar contraseñas débiles. Se recomienda a las organizaciones que dejen de realizar
estas prácticas según NIST 800-63 y utilicen la autenticación multifactor.
Escenario nro. 3: los tiempos de espera de la sesión de la aplicación no están configurados

correctamente. Un usuario usa una computadora pública para acceder a una aplicación. En
lugar de seleccionar "cerrar sesión", el usuario simplemente cierra la pestaña del navegador
y se aleja. Un atacante usa el mismo navegador una hora más tarde y el usuario aún está
autenticado.
Referencias
● OWASP Proactive Controls: Implement Digital Identity
● OWASP Application Security Verification Standard: V2 authentication
● OWASP Application Security Verification Standard: V3 Session Management
● OWASP Testing Guide: Identity, Authentication
● OWASP Cheat Sheet: Authentication
● OWASP Cheat Sheet: Credential Stuffing
● OWASP Cheat Sheet: Forgot Password
● OWASP Cheat Sheet: Session Management
● OWASP Automated Threats Handbook
● NIST 800-63b: 5.1.1 Memorized Secrets

CWE-255 Credentials Management Errors

CWE-259 Use of Hard-coded Password
CWE-287 Improper Authentication
CWE-288 Authentication Bypass Using an Alternate Path or Channel
CWE-290 Authentication Bypass by Spoofing
CWE-294 Authentication Bypass by Capture-replay
CWE-295 Improper Certificate Validation
CWE-297 Improper Validation of Certificate with Host Mismatch
CWE-300 Channel Accessible by Non-Endpoint
CWE-302 Authentication Bypass by Assumed-Immutable Data
CWE-304 Missing Critical Step in Authentication
CWE-306 Missing Authentication for Critical Function
CWE-307 Improper Restriction of Excessive Authentication Attempts
CWE-346 Origin Validation Error
CWE-384 Session Fixation
CWE-521 Weak Password Requirements
CWE-613 Insufficient Session Expiration
CWE-620 Unverified Password Change
CWE-640 Weak Password Recovery Mechanism for Forgotten Password
CWE-798 Use of Hard-coded Credentials
CWE-940 Improper Verification of Source of a Communication Channel
CWE-1216 Lockout Mechanism Errors

A08:2021 - Fallos de integridad de datos y software
Factores
10 16,67% 2,05% 75,04% 45,35% 6,94 7,94 47,972 1,152
Visión general
Esta nueva categoría para 2021 se enfoca en hacer suposiciones relacionadas con
actualizaciones de software, datos críticos y pipelines CI/CD sin verificar la integridad. Uno
de los impactos más ponderados de los datos CVE / CVSS. Los CWE notables incluyen
CWE-502: deserialización de datos que no son de confianza, CWE-829: inclusión de
funcionalidad de una esfera de control que no es de confianza y CWE-494: descarga de
código sin verificación de integridad.
Descripción
Las fallas en la integridad del software y los datos se relacionan con el código y la
infraestructura que no protegen contra las violaciones de la integridad. Por ejemplo, cuando
los objetos o los datos se codifican o serializan en una estructura que un atacante puede
ver y modificar, es vulnerable a una deserialización insegura. Otra forma de esto es cuando
una aplicación se basa en complementos, bibliotecas o módulos de fuentes, repositorios y
redes de entrega de contenido (CDN) que no son de confianza. Una pipeline de CI/CD
insegura puede presentar la posibilidad de acceso no autorizado, código malicioso o
compromiso del sistema. Por último, muchas aplicaciones ahora incluyen la funcionalidad
de actualización automática, donde las actualizaciones se descargan sin una verificación
de integridad suficiente y se agregan a la aplicación de confianza anterior. Los atacantes
podrían cargar sus propias actualizaciones para distribuirlas y ejecutarlas en todas las
instalaciones.

Cómo prevenir
● Asegúrese de que los datos serializados no firmados o no cifrados no se envíen a
clientes que no sean de confianza, sin algún tipo de verificación de integridad o firma
digital para detectar alteraciones o reproducción de los datos serializados.
● Verifique que el software o los datos provengan de la fuente esperada mediante la

firma o mecanismos similares.
● Asegúrese de que las bibliotecas y dependencias, como npm o Maven, consuman

repositorios confiables
● Asegúrese de que se usa una herramienta de seguridad de la cadena de suministro

de software, como OWASP Dependency Check o como OWASP CycloneDX, para
verificar que los componentes no contengan vulnerabilidades conocidas.
● Asegúrese de que su pipeline de CI/CD tenga la configuración y el control de acceso

adecuados para garantizar la integridad del código que fluye a través de los
procesos de construcción e implementación.

Escenario nro. 1 Deserialización insegura: una aplicación React llama a un conjunto de
microservicios Spring Boot. Al ser programadores funcionales, intentaron asegurarse de
que su código sea 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 nota la firma del objeto
Java "R00" y utiliza la herramienta Java Serial Killer para obtener la ejecución remota de
código en el servidor de aplicaciones.
Escenario nro. 2 Actualización sin firmar: muchos enrutadores domésticos, firmware de

dispositivos, decodificadores y otros no verifican las actualizaciones a través del firmware
firmado. El firmware sin firmar es un objetivo creciente para los atacantes y se espera que
empeore. Esta es una preocupación importante, ya que muchas veces no hay ningún
mecanismo para remediarlo, que no sea arreglar en una versión futura y esperar a que las
versiones anteriores caduquen.

Escenario nro. 3 Actualización maliciosa de SolarWinds : Se sabe que los estados-nación

atacan los mecanismos de actualización, siendo un ataque notable reciente el ataque
SolarWinds Orion. La empresa que desarrolla el software tenía procesos de integridad
seguros de construcción y actualización. Aún así, estos pudieron ser subvertidos, y durante
varios meses, la empresa distribuyó una actualización maliciosa altamente dirigida a más
de 18,000 organizaciones, de las cuales alrededor de 100 se vieron afectadas. Se trata de
una de las infracciones de este tipo, más trascendentales y significativas de la historia.
Referencias
 [OWASP Cheat Sheet:
Deserialization]( https://www.owasp.org/index.php/Deserialization_Cheat_Sheet)
 [OWASP Cheat Sheet: Software Supply Chain Security]()
 [OWASP Cheat Sheet: Secure build and deployment]()
 [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)
 https://www.manning.com/books/securing-devops

CWE-345 Insufficient Verification of Data Authenticity
CWE-353 Missing Support for Integrity Check
CWE-426 Untrusted Search Path
CWE-494 Download of Code Without Integrity Check
CWE-502 Deserialization of Untrusted Data
CWE-565 Reliance on Cookies without Validation and Integrity Checking
CWE-784 Reliance on Cookies without Validation and Integrity Checking in a Security
Decision
CWE-829 Inclusion of Functionality from Untrusted Control Sphere
CWE-830 Inclusion of Web Functionality from an Untrusted Source
CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes

A09:2021 - Fallos de seguimiento y registro de seguridad
Factores
4 19,23% 6,51% 53,67% 39,97% 6,87 4,99 53,615 242
Visión general
El registro y el monitoreo de seguridad provienen de la encuesta de la industria (3er lugar),
respecto de TopTen:2017 subió de #10 a #9. El registro y el monitoreo pueden ser difíciles
de probar, a menudo implican entrevistas o preguntar si se detectaron ataques durante una
prueba de penetración. No hay muchos datos CVE / CVSS para esta categoría, pero
detectar y responder a las infracciones es fundamental. Aún así, puede ser muy impactante
para la visibilidad, las alertas de incidentes y el análisis forense. Esta categoría se expande
más allá de CWE-778 Registro insuficiente, para incluir CWE-117 Neutralización de salida
incorrecta para Logs, CWE-223 Omisión de información relevante para la seguridad y CWE-
532 Inserción de información confidencial en el archivo de Log.
Descripción
Esta categoría es para ayudar a detectar, escalar y responder a las infracciones activas.
Sin registros de Log ni monitoreo, no se pueden detectar las infracciones, y se produce esta
falta o insuficiencia de registros de Log, detección, supervisión y respuesta activa, en
cualquier situación relevante, como por ejemplo:
 Al no registrar en un Log, los eventos auditables, como inicios de sesión, inicios de

sesión fallidos y transacciones de alto valor.
 Al no registrar en un Log los mensajes de las advertencias y/o errores, o esos
mensajes son inadecuados o poco claros.

 Al no monitorear ni detectar actividades sospechosas, en los registros de LOG de

las aplicaciones y APIs.
 Al no asegurar los registros de Log y sólo almacenarlos localmente.
 No están establecidos y/o no son efectivos los umbrales de alerta apropiados y los
procesos de escalamiento de la respuesta.
 No se activan las alertas adecuadas, en los casos de escaneos mediante herramientas
DAST (como OWASP ZAP) y/o en pruebas de penetración.
 La aplicación no puede detectar, escalar ni alertar sobre ataques activos en tiempo real o
casi en tiempo real.
También se es vulnerable a la fuga de información, al exponer ante usuarios o atacantes

los registros de Log y alerta (consulte A01: 2021 - Control de acceso roto).
Cómo prevenir
Los desarrolladores deben implementar algunos o todos los siguientes controles,
dependiendo del riesgo de la aplicación:
 Asegúrese de que todas las fallas de validación de entrada, en el lado del servidor,
y de control de acceso, sean registradas con suficiente contexto de usuario para
identificar cuentas sospechosas o maliciosas y retenerlas durante el tiempo
suficiente para permitir un análisis forense tardío y/o retrasado.
 Asegúrese de que los registros se generen en un formato adecuado, para que las
herramientas de gestión de LOGs puedan consumirla fácilmente.
 Asegúrese de que los datos ingresados al Log, estén correctamente codificados

(encoded), para prevenir inyecciones o ataques a los sistemas de Log y monitoreo.
 Asegúrese de que las transacciones de alto valor tengan una pista de auditoría con
controles de integridad para evitar alteraciones o eliminaciones, como por ejemplo,
tablas de bases de datos que sólo permitan agregación de información (append-
only).
 Los equipos de DevSecOps deben establecer un monitoreo y alertas efectivos para

que las actividades sospechosas se detecten y se responda rápidamente.

 Establezca o adopte un plan de recuperación y respuesta a incidentes, como NIST

800-61r2 o posterior.
Existen frameworks open-source y de pago, para la protección de aplicaciones, que

cuentan con paneles de control personalizables y alertas, tales como OWASP
ModSecurity Core Rule Set, y Elastic Stack (ELK Stack) software para realizar la
correlación de registros de Logs.

Escenario nro. 1: el operador del sitio web del proveedor de un plan de salud para niños
no pudo detectar una infracción debido a la falta de monitoreo y registro. Una parte externa
informó al proveedor del plan de salud que un atacante había accedido y modificado miles
de registros médicos confidenciales de más de 3,5 millones de niños. Una revisión posterior
al incidente encontró que los desarrolladores del sitio web no habían abordado
vulnerabilidades significativas. Como no hubo registro ni monitoreo del sistema, la violación
de datos podría haber estado en curso desde 2013, un período de más de siete años.
Escenario nro.2: una importante aerolínea india sufrió una violación de datos que involucró
más de diez años de datos personales de millones de pasajeros, incluidos los datos de
pasaportes y tarjetas de crédito. La violación de datos se produjo en un proveedor de
alojamiento en la nube de terceros, que notificó a la aerolínea de la violación después de
un tiempo.
Escenario nro. 3: una importante aerolínea europea sufrió una infracción denunciable del
tipo GDPR. Según los informes, la infracción fue causada por vulnerabilidades de seguridad
de las aplicaciones de pago explotadas por los atacantes, que recopilaron más de 400.000
registros de pagos de clientes. Como resultado, la aerolínea fue multada con 20 millones
de libras por el regulador de privacidad.

Referencias
 OWASP Proactive Controls: Implement Logging and Monitoring
 OWASP Application Security Verification Standard: V8 Logging and Monitoring
 OWASP Testing Guide: Testing for Detailed Error Code
 OWASP Cheat Sheet: Logging
 Data Integrity: Recovering from Ransomware and Other Destructive Events
 Data Integrity: Identifying and Protecting Assets Against Ransomware and Other
Destructive Events
 Data Integrity: Detecting and Responding to Ransomware and Other Destructive
Events

CWE-117 Improper Output Neutralization for Logs
CWE-223 Omission of Security-relevant Information
CWE-532 Insertion of Sensitive Information into Log File
CWE-778 Insufficient Logging

A10:2021 - Falsificación de solicitud del lado del servidor (SSRF)
Factores
1 2,72% 2,72% 67,72% 67,72% 8.28 6,72 9,503 385
Visión general
Esta categoría surge desde la encuesta de la industria (# 1). Los datos muestran una baja
tasa de incidencia, pero con una cobertura de pruebas superior a la media y su potencial
de explotación y ratios de impacto son superiores a la media. Como todo riesgo nuevo, lo
habitual es que sólo hay un grupo único o pequeño de CWE para focalizar la atención y la
concientización, la expectativa es que puedan integrarse en una categoría más grande en
una edición futura de TopTen.
Descripción
Las fallas de SSRF ocurren cuando una aplicación web está obteniendo un recurso remoto,
sin validar la URL proporcionada por el usuario. Permite que un atacante coaccione a la
aplicación para que envíe una solicitud manipulada, a un destino inesperado, incluso
cuando está protegido por un firewall, VPN u otro tipo de ACL de red.
La incidencia de SSRF está aumentando, porque las aplicaciones web modernas brindan
al usuario final funciones convenientes, la búsqueda de una URL se convierte en un
escenario común y provoca este resultado. Además, la gravedad de SSRF es cada vez
mayor debido a los servicios en la nube y la complejidad de las arquitecturas.

Como prevenir
Los desarrolladores pueden prevenir SSRF implementando algunos o todos los siguientes
controles de defensa en profundidad:
Desde la capa de red

 Segmentar la funcionalidad de acceso a recursos remotos en redes separadas, para
reducir el impacto de SSRF
 Hacer cumplir las políticas de firewall de "denegación por defecto" o las reglas de
control de acceso a la red para bloquear todo el tráfico de la intranet excepto el
esencial.
Sugerencias:
~ Establezca un responsable (ownership) y un ciclo de vida para las reglas de
firewall basadas en aplicaciones.
~ Registre todos los flujos de red aceptados y bloqueados en firewalls
(consulte A09: 2021-Fallos de monitoreo y registro de seguridad ).
Desde la capa de aplicación:

 Sanitizar y validar todos los datos de entrada proporcionados por el cliente
 Hacer cumplir el esquema de URL, el puerto y el destino con una lista de permitidos
positiva
 No envíar a los clientes, ninguna respuesta sin procesar
 Deshabilitar las redirecciones HTTP
 Tenga en cuenta la coherencia de la URL para evitar ataques como el reenlace de
DNS y las condiciones de ejecución (race conditions) de "tiempo de verificación,
tiempo de uso" (TOCTOU)
No mitigue SSRF mediante el uso de una lista de denegación o una expresión regular. Los
atacantes tienen listas de ataques (payload), herramientas y habilidades para eludir las
listas de denegación.

Medidas adicionales a considerar:

 No implemente otros servicios relevantes para la seguridad en los sistemas frontales
(por ejemplo, OpenID). Controle el tráfico local en estos sistemas (por ejemplo,
localhost)
 Para interfaces con grupos de usuarios dedicados y manejables, use el cifrado de red
(por ejemplo, VPN) en sistemas independientes para considerar necesidades de
protección muy altas

Los atacantes pueden usar SSRF para atacar sistemas protegidos detrás de firewalls de
aplicaciones web, firewalls o ACL de red, utilizando escenarios como:
Escenario nro. 1: servidores internos de escaneo de puertos. Si la arquitectura de la red

no está segmentada, los atacantes pueden trazar redes internas y determinar si los puertos
están abiertos o cerrados en los servidores internos a partir de los resultados de la conexión
o del tiempo transcurrido para conectar o rechazar las conexiones del ataque SSRF.
Escenario nro. 2: exposición de datos sensibles. Los atacantes pueden acceder a archivos
locales y/o servicios internos para obtener información sensible, tales como:
file:///etc/passwd</span> and http://localhost:28017/.
Escenario nro. 3: Acceda al almacenamiento de metadatos de los servicios en la nube. La

mayoría de los proveedores de nube tienen almacenamiento de metadatos como
http://169.254.169.254/ Un atacante puede leer los metadatos para obtener información
confidencial.
Escenario nro. 4: comprometer los servicios internos: el atacante puede abusar de los
servicios internos para realizar otros ataques, más potentes, como la ejecución remota de
código (RCE) o la denegación de servicio (DoS).

Referencias
 OWASP - Server-Side Request Forgery Prevention Cheat Sheet
 PortSwigger - Server-side request forgery (SSRF)
 Acunetix - What is Server-Side Request Forgery (SSRF)?
 SSRF bible
 A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!
CWE-918 Server-Side Request Forgery (SSRF)

A11: 2021 - Próximos pasos
Por diseño, el OWASP TOPTEN se limita a los diez riesgos más importantes. Cada
selección TOPTEN mantiene varios riesgos “en la cúspide” que son evaluados en
profundidad para su inclusión, pero al final, quedaron afuera. No importa cómo intentemos
interpretar o amoldar los datos, los otros riesgos fueron más frecuentes e impactantes.
Las organizaciones que trabajan en pos de un programa de AppSec maduro o consultores

de seguridad o proveedores de herramientas que deseen ampliar la cobertura de sus
ofertas, vale la pena el esfuerzo de identificar y solucionar los siguientes tres problemas.
A11.1 Problemas de calidad del código
Factores
38 49,46% 2,22% 7.1 6,7 60,85% 23,42% 101736 7564
 Descripción. Los problemas de calidad del código incluyen patrones o defectos

de seguridad conocidos, reutilización de variables para múltiples propósitos,
exposición de información sensible al momento del debugging, condiciones de
ejecución de tiempo de verificación / tiempo de uso (TOCTOU), errores de
conversión numérica positivo/negativo, usar un recurso después de liberarlo. El
sello distintivo de esta sección es que generalmente se pueden identificar con
indicadores de compilación estrictos, herramientas de análisis de código estático
y en los IDE habilitar plugins linter (herramienta que ayuda a seguir las buenas
prácticas y guías de estilo del código fuente). Los lenguajes modernos eliminaron
muchos de estos problemas, por diseño, como la escritura estricta y la

verificación de límites de Go, y en RUST el diseño de subprocesos y el concepto

de propiedad y préstamo de memoria.
 Cómo prevenir. Habilite y use las opciones de análisis de código estático de su

editor de código. Use una herramienta de análisis de código estático. Considere
si es posible usar o migrar a un lenguaje o framework que elimine clases de
errores, como Rust o Go.
 Ejemplos de escenarios de ataque. Un atacante puede obtener o actualizar

información confidencial aprovechando una condición de ejecución, utilizando
una variable compartida estáticamente en varios subprocesos.
Referencias
 OWASP Code Review Guide
 Google Code Review Guide

A11.2 Denegación de servicio
Factores
8 17,54% 4,89% 8.3 5.9 79,58% 33,26% 66985 973
 Descripción. La denegación de servicio siempre es posible con suficientes

recursos. Sin embargo, las prácticas de diseño y codificación tienen una influencia
significativa en la magnitud de la denegación de servicio. Suponga que cualquier
persona con el enlace puede acceder a un archivo grande, o que se produce una
transacción computacionalmente costosa en cada página. En ese caso, la
denegación de servicio requiere menos esfuerzo para llevarse a cabo.
 Cómo prevenir. Hacer pruebas de rendimiento para el uso de CPU, I/O y memoria,
rediseñar, optimizar o almacenar en caché operaciones costosas. Considere los
controles de acceso para objetos más grandes para asegurarse de que solo las
personas autorizadas puedan acceder a archivos u objetos grandes o servirlos a
través de una red de almacenamiento en caché perimetral.
 Ejemplos de escenarios de ataque. Un atacante podría determinar que una

operación tarda entre 5 y 10 segundos en completarse. Cuando se ejecutan cuatro
subprocesos simultáneos, el servidor parece dejar de responder. El atacante utiliza
1000 subprocesos y desconecta todo el sistema.
Referencias
 OWASP Cheet Sheet: Denial of Service
 OWASP Attacks: Denial of Service

A11.3 Errores de administración de memoria
Factores
14 7,03% 1,16% 6,7 8.1 56,06% 31,74% 26576 16184
 Descripción. Las aplicaciones web tienden a escribirse en lenguajes de memoria

administrada, como Java,.NET o node.js (JavaScript o TypeScript). Sin embargo, estos
lenguajes están escritos en lenguajes de sistemas que tienen problemas de
administración de memoria, como desbordamientos de búfer o de heap, uso de recursos
después de haberlos liberado, desbordamiento de números enteros y más. A lo largo
de los años, ha habido muchos escapes de sandbox que demuestran que aunque un
lenguaje de aplicación web sea nominalmente "seguro" para la memoria, los cimientos
no lo son.
 Cómo prevenir. Muchas API modernas ahora están escritas en lenguajes seguros para
la memoria como Rust o Go. En el caso de Rust, la seguridad de la memoria es una
característica crucial del lenguaje. Para el código ya existente, se recomienda usar flags
de compilación estrictas, tipado fuerte, análisis de código estático y fuzz testing, para
identificar memory leaks, y desbordamientos de arreglos/matrices y de memoria
 Ejemplos de escenarios de ataque. Los desbordamientos de búfer y heap han sido

un objetivo de ataque a lo largo de los años. El atacante envía datos a un programa,
que almacena en un stack buffer de tamaño insuficiente. El resultado es que se
sobrescribe la información de la pila de llamadas, incluido el puntero de retorno de la
función. Los datos establecen el valor del puntero de retorno para que cuando la función
regrese, transfiera el control al código malicioso contenido en los datos del atacante.
Referencias
 OWASP Vulnerabilities: Buffer Overflow
 OWASP Attacks: Buffer Overflow
 Science Direct: Integer Overflow

Agradecimientos a los traductores, revisores y colaboradores de este

trabajo.
 Carlos Allendes (Traductor, Revisor)

 Andrea Mujica (Traductor)
 David Espinoza (Revisor)
 Felipe Cabrera (Revisor)
 Hugo González Rosas (panelista)
 Juan Carlos Saba (panelista)
https://www.youtube.com/watch?v=LU5SFrpsp50


Top10owasp v29 09 2021

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Top10owasp v29 09 2021

Cargado por

Copyright:

Formatos disponibles

VERSIÓN: 29-09-2021

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Traducción en chileno (spanish)

Esperamos que sea de utilidad para nuestros clientes, asociados y colegas.

Desde ahora, Top10:2021 se incorpora en la malla de entrenamientos que dicta

 Desarrollo Seguro en el Ciclo de Vida del Software

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

¡Bienvenido a la última entrega del OWASP TOPTEN! El OWASP TOPTEN 2021 es

Los cambios en OWASP TOPTEN:2021

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

A02:2021-Fallas criptográficas sube una posición desde #3 a #2, anteriormente conocida

A05:2021- Configuración incorrecta de seguridad; sube de #6 a #5. El 90% de las

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

A06:2021- Componentes vulnerables y obsoletos; se tituló anteriormente “Uso de

A07:2021- Fallas de identificación y autenticación anteriormente era “Autenticación

A09:2021- Fallas de registro y monitoreo de seguridad; sube desde #10 a #9,

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Cómo están estructuradas las categorías

La recopilación de datos anteriores se centraba en un subconjunto predefinido de

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

complemento en el futuro. Este aumento significativo en el número de CWE requiere

Cómo se utilizan los datos para seleccionar categorías

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

¿Por qué no solo datos estadísticos puros?

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

¿Por qué tasa de incidencia en lugar de frecuencia?

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

instancia de un tipo de vulnerabilidad. No nos importa si fue único o sistémico. Eso es

¿Cuál es su proceso de recopilación y análisis de datos?

Obtenemos datos de organizaciones comerciales que realizan testing, otros proveedores

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Gracias a nuestros colaboradores de datos

Las siguientes organizaciones (junto con algunos donantes anónimos) amablemente

Gracias a nuestro patrocinador

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Cómo utilizar OWASP Top 10 como estándar

Use Case OWASP OWASP Application Security

Training Nivel Básico Exahustivo

Design and architecture Ocasionalmente SI

Coding standard Mínimo exigible SI

Secure Code Review Mínimo exigible SI

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Peer review Checklist Mínimo exigible SI

Unit testing Ocasionalmente SI

Integration testing Ocasionalmente SI

Penetration testing Mínimo exigible SI

Tool support Mínimo exigible SI

Secure Supply Chain Ocasionalmente SI

Alentamos a cualquiera que desee adoptar un estándar de seguridad de aplicaciones a usar

El ASVS es la única opción aceptable para los proveedores de herramientas. Las

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Cómo iniciar un programa AppSec con OWASP Top 10

Etapa 1. Identifique brechas y objetivos de su programa AppSec

Etapa 2. Planificar un ciclo de vida de desarrollo seguro de

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Etapa 3. Implementar la carretera pavimentada con sus equipos de

Etapa 4. Migrar todas las aplicaciones existentes y futuras a la

Autor: amujica@qualityfactory.cl SI ENCUENTRA DEFECTOS AVISENOS!

Etapa 5. Compruebe que la carretera pavimentada haya mitigado

Etapa 6. Lleve su programa hacia un programa maduro de AppSec

Avanzar más allá