¿Qué es OWASP Top 10?

El Open Web Application Security Project (OWASP) es una comunidad de seguridad de aplicaciones de código abierto cuyo objetivo es mejorar la seguridad del software. El OWASP Top 10 es una guía estándar de la industria que enumera los riesgos más críticos para la seguridad de las aplicaciones con el fin de ayudar a los desarrolladores a proteger mejor las aplicaciones que diseñan e implantan.

Dado que los riesgos de seguridad evolucionan constantemente, la lista de los 10 principales de OWASP se revisa periódicamente para reflejar estos cambios. En la última versión de OWASP Top 10, publicada en 2021, se sustituyeron algunos tipos de vulnerabilidades que ya no representan una amenaza grave por otras que tienen más probabilidades de suponer un riesgo significativo.

Aunque el OWASP Top 10 es un buen punto de partida para proteger las aplicaciones, no debe considerarse como un objetivo final, ya que algunas de las vulnerabilidades más citadas no se incluyeron en el OWASP Top 10 2021. Para protegerse contra los puntos débiles del software, los defensores deben tener una visión más amplia de su pila de tecnologías de la información. Esto significa que los profesionales de la seguridad informática deben centrarse en todo el ecosistema del software y mirar más allá de las fuentes "tradicionales" de vulnerabilidades.

¿Cuáles son las 10 categorías principales de OWASP (2021)?

A1: Inyección

Se pueden introducir fallos de inyección siempre que se envíe una fuente de datos no fiable a un intérprete. Los ejemplos se encuentran a menudo en consultas de bases de datos dinámicas SQL, LDAP, XPath o NoSQL con entradas suministradas por el usuario. Los atacantes inyectan código en la entrada del usuario, engañando al intérprete de consultas para que ejecute comandos maliciosos.

¿Qué hace que una aplicación sea vulnerable a los fallos de inyección?

• Los datos facilitados por los usuarios no están suficientemente validados.
• Las consultas dinámicas se ejecutan sin suficiente limpieza de entrada.
• Datos hostiles utilizados dentro de los sistemas para comportamientos maliciosos.

¿Cuál es el impacto de los fallos de inyección?

• Compromiso de la aplicación o del host subyacente.
• Exposición de datos sensibles.
• Pérdida de productividad, reputación o ingresos.

¿Cómo puede ayudar Fortify con los fallos de inyección?

• Si eres desarrollador: Fortify detecta los fallos de inyección y proporciona consejos de corrección específicos para cada tipo.
• Si estás en QA o en Operaciones: Fortify valida el código en tiempo de ejecución para mitigar los controles.
• Si está en Operaciones: Fortify proporciona registro y protección en tiempo de ejecución para intentos de inyección en Java y .NET.

A2: Autenticación rota

La autenticación rota puede introducirse cuando se gestionan datos de identidad o de sesión en aplicaciones con estado. A menudo se encuentran ejemplos cuando el registro, la recuperación de credenciales y las vías API son vulnerables a tokens de sesión no caducados, fuerza bruta o enumeración de cuentas. Los atacantes asumen la identidad de usuarios legítimos, toman el control de las cuentas y comprometen datos, procesos o sistemas.

¿Qué hace que una aplicación sea vulnerable a una autenticación rota?

• Expone, no invalida correctamente o no rota los identificadores de sesión.
• No adapta las políticas de contraseñas a normas como la NIST 800-63B.
• Carece de autenticación de dos factores (2FA) o permite ataques automatizados.

¿Cuál es el impacto de una autenticación defectuosa?

• Robo de identidad de usuarios.
• Pérdida de confianza de los usuarios.
• Compromiso de datos sensibles.

¿Cómo puede ayudar Fortify?

• Si es desarrollador: Fortify detecta y recomienda remediar los problemas de autenticación rotos.
• Si estás en QA o en Operaciones: Fortify valida la autenticación y la seguridad de la gestión de sesiones de forma dinámica.
• Si está en Operaciones: Fortify instrumenta el monitoreo en tiempo de ejecución para eventos de aplicaciones Java y .NET.

A3: Exposición de datos sensibles

Cuando las aplicaciones acceden a datos sin cifrar, en particular a información personal identificable (IPI) y otros tipos de datos regulados, pueden surgir problemas de exposición a datos sensibles. Los ejemplos suelen encontrarse cuando se utilizan cifrados criptográficos débiles en aplicaciones heredadas, se implementan incorrectamente protocolos de transporte seguros o no se utiliza la seguridad centrada en los datos. Los atacantes obtienen acceso a datos sensibles de los usuarios que les dan el control en la vida real.

¿Qué hace que una aplicación sea vulnerable a la exposición de datos sensibles?

• Transmisión de datos en texto claro a través de protocolos como HTTP, SMTP y FTP.
• Datos sensibles almacenados, transmitidos o utilizados innecesariamente en texto claro.
• Uso de algoritmos criptográficos antiguos, débiles o no basados en estándares.

¿Cuál es el impacto de la exposición de datos sensibles?

• Compromiso de datos regulados (p. ej. HIPAA o GDPR) que dan lugar a multas.
• Secuestro de identidades, con los consiguientes costes de depuración o control de datos.
• Situación de incumplimiento de las leyes y normativas sobre privacidad.

¿Cómo puede ayudar Fortify con la exposición de datos sensibles?

• Si eres desarrollador: Fortify identifica la exposición de datos sensibles y automatiza la auditoría de problemas.
• Si estás en QA o en Operaciones: Fortify elimina los hallazgos mitigados fuera del contexto de la aplicación con plantillas.
• Si está en Operaciones: Fortify instrumentos de registro y protección para aplicaciones en Java y .NET.

A4: Entidades externas XML

Pueden surgir problemas con entidades externas XML cuando un analizador mal configurado procesa una entrada XML que contiene una referencia a una entidad externa. Los ejemplos se encuentran a menudo en aplicaciones que analizan la entrada XML de fuentes no fiables, cuando las Definiciones de Tipo de Documento (DTD) están activadas, o que utilizan marcos no parcheados como SOAP 1.0. XML está en todas partes: desde SVG y archivos de imagen hasta protocolos de red y formatos de documentos como PDF y RSS. Los atacantes hacen referencia a entidades externas en la entrada XML que da lugar a procesadores explotados para extraer datos, ejecutar código de forma remota o afectar a los servicios de red.

¿Qué hace que una aplicación sea vulnerable a entidades externas XML?

• La aplicación analiza documentos XML y los procesadores tienen DTD activados.
• Uso de SAML para SSO, SOAP anterior a v1.2 o .NET Framework anterior a v2.0.
• El analizador acepta fuentes no fiables o inserta datos XML no fiables.

¿Cuál es el impacto de las entidades externas XML?

• Robo de datos sensibles.
• Carga de URL controlada por el atacante.
• Ataques de denegación de servicio (DoS).

¿Cómo puede ayudar Fortify con las entidades externas XML?

• Si eres desarrollador: Fortify detecta los analizadores XML vulnerables y recomienda medidas paliativas.
• Si estás en QA o en Operaciones: Fortify busca automáticamente analizadores XML vulnerables y valida las cargas útiles de exploits.
• Si está en Operaciones: Fortify proporciona registro y protección en tiempo de ejecución para problemas en aplicaciones Java y .NET.

A5: Control de acceso roto

Pueden surgir problemas de control de acceso cuando las restricciones de código y entorno se solapan de forma incompleta o se definen en varios lugares para funcionalidades similares. Los ejemplos se encuentran a menudo cuando la seguridad por oscuridad se rompe a través de la navegación forzada a páginas restringidas, o cuando la aplicación define métodos complejos para el control de acceso en múltiples formas y lugares. Los atacantes pueden comprometer los límites de acceso para robar datos confidenciales o interrumpir las operaciones.

¿Qué hace que una aplicación sea vulnerable a un control de acceso roto?

• Posibilidad de actuar como usuario sin iniciar sesión, o como administrador cuando se inicia sesión como usuario.
• Manipulación de metadatos o tokens para obtener privilegios elevados o no autorizados.
• Lógica de control de acceso bizantina, no aplicada o dispersa.

¿Cuál es el impacto de un control de acceso roto?

• Divulgación no autorizada de información o puesta en peligro de datos sensibles.
• Modificación o destrucción de datos.
• Toma de control de la administración del sitio o de los usuarios.

¿Cómo puede ayudar Fortify a controlar los accesos rotos?

• Si eres desarrollador: Fortify automatiza la auditoría y permite la creación de plantillas para eliminar los problemas mitigados en otros lugares.
• Si estás en QA y Operaciones: Los agentes de Fortify detectan superficies de ataque ocultas y sistemas de control de acceso rotos.
• Si se encuentra en Operaciones: Fortify instrumenta el registro de control de acceso en tiempo de ejecución para aplicaciones Java y .NET.

A6: Desconfiguración de la seguridad

Los fallos de configuración de la seguridad pueden introducirse durante la configuración de la aplicación o de su entorno subyacente. Los errores de configuración pueden producirse en cualquier nivel de una pila de aplicaciones, desde los servicios de red y los servidores de aplicaciones hasta los contenedores y el almacenamiento. Los ejemplos se encuentran a menudo en cuentas y configuraciones por defecto, "mensajes de error con fugas", o frameworks y servicios sin parches. Los atacantes pueden obtener información sobre el despliegue y acceso a datos privilegiados para interrumpir las operaciones.

¿Qué hace que una aplicación sea vulnerable a una mala configuración de seguridad?

• Puertos y cuentas por defecto activados innecesariamente o contraseñas no modificadas.
• Revelar el seguimiento de la pila u otros mensajes en caso de errores y excepciones.
• No reforzar adecuadamente la seguridad para el riesgo que plantea cualquier parte de la pila.

¿Cuál es el impacto de una mala configuración de seguridad?

El impacto puede variar desde la revelación de información hasta el compromiso completo del sistema.

¿Cómo puede ayudar Fortify en caso de desconfiguración de la seguridad?

• Si eres desarrollador: Fortify identifica las dependencias de las aplicaciones y los archivos de configuración durante las exploraciones.
• Si estás en QA y Operaciones: Fortify evalúa dinámicamente las configuraciones de aplicaciones y servidores para detectar problemas.
• Si está en Operaciones: Fortify proporciona análisis de código abierto para informar sobre riesgos medioambientales.

A7: Secuencias de comandos en sitios cruzados

Los fallos de Cross-Site Scripting (XSS) pueden introducirse cuando se ejecuta una entrada de usuario no fiable y no saneada como parte del HTML, o cuando se puede influir en los usuarios para que interactúen con enlaces maliciosos. Los ejemplos se encuentran a menudo cuando se aceptan construcciones de código familiares de lenguajes como JavaScript o Flash desde fuentes no fiables o se almacenan para su posterior visualización por otro agente de usuario. Los atacantes pueden ejecutar código remoto en la máquina del usuario, robar credenciales o distribuir malware desde sitios de redirección.

¿Qué hace que una aplicación sea vulnerable al cross-site scripting (XSS)?

Existen tres formas de XSS, normalmente dirigidas a agentes de usuario como los navegadores:

• XSS reflejado: La aplicación o API incluye entradas no fiables en la salida HTML.
• XSS almacenado: El código no desinfectado guardado en el disco se activa más tarde por la acción del usuario.
• DOM XSS: Aplicaciones, frameworks y API que consumen entradas no fiables.

¿Cuál es el impacto del cross-site scripting (XSS)?

• Adquisición de la cuenta de la víctima en la aplicación.
• Recuperación de datos de la aplicación web de destino.
• Modificación del contenido de la página.

¿Cómo puede ayudar Fortify con las secuencias de comandos en sitios cruzados (XSS)?

• Si eres desarrollador: Fortify detecta vulnerabilidades XSS en el código y predice la probabilidad de explotación.
• Si estás en QA y Operaciones: Fortify valida código dinámicamente para entradas no desinfectadas vulnerables a XSS.
• Si está en Operaciones: Fortify proporciona registro de eventos Java y .NET, incluida la redirección no autorizada.

A8: Deserialización insegura

Los fallos de deserialización insegura pueden introducirse cuando los lenguajes y frameworks permiten que datos serializados que no son de confianza se expandan en un objeto, a menudo cuando las aplicaciones web están comunicando al usuario o guardando el estado de la aplicación. Los ejemplos se encuentran a menudo cuando los desarrolladores no ponen restricciones a los métodos que pueden auto-ejecutarse durante el proceso de deserialización. Los atacantes aprovechan estas cadenas de gadgets "" llamadas fuera de la lógica de la aplicación para ejecutar código de forma remota, denegar el servicio u obtener acceso no autorizado.

¿Qué hace que una aplicación sea vulnerable a una deserialización insegura?

• La aplicación deserializa datos de fuentes no fiables.
• La aplicación no verifica la fuente o el contenido antes de la deserialización.
• Las clases aceptables no están en la lista blanca para evitar la exposición innecesaria de los gadgets.

¿Cuál es el impacto de la deserialización insegura?

• Estos fallos pueden dar lugar a ataques de ejecución remota de código, uno de los ataques más graves posibles.

¿Cómo puede ayudar Fortify con la deserialización insegura?

• Si eres desarrollador: Fortify detecta vulnerabilidades en el código fuente y proporciona análisis de componentes.
• Si está en QA y Operaciones: Fortify los instrumentos de las aplicaciones que se ejecutan dinámicamente para validar los vectores de ataque.
• Si está en Operaciones: Fortify instrumentos de registro de eventos Java y .NET incluyendo deserialización.

A9: Uso de componentes con vulnerabilidades conocidas

Estos fallos pueden introducirse cuando se introducen en una aplicación frameworks y bibliotecas de código abierto o de terceros y se ejecutan con los mismos privilegios. A menudo se encuentran ejemplos en los que el desarrollo basado en componentes da lugar a una falta de comprensión de los riesgos asociados a las dependencias y los componentes o sistemas son difíciles o imposibles de parchear. Los atacantes han aprovechado componentes vulnerables para algunas de las mayores brechas de la historia, aunque las vulnerabilidades pueden ir desde el compromiso de la aplicación hasta la ejecución remota de código.

¿Qué hace que una aplicación sea vulnerable a frameworks y bibliotecas de código abierto o de terceros?

• Pueden ser accidentales (p. ej. error de codificación) o intencionada (p. ej. componente blindado).
• La aplicación o el entorno utilizan componentes sin parches u obsoletos (una de las razones por las que la modernización de las aplicaciones es esencial).
• Falta de análisis de vulnerabilidades en código de terceros o dependencias anidadas.
• Inventarios de componentes no disponibles o boletines de seguridad ignorados.

¿Cuál es el impacto del uso de componentes con vulnerabilidades conocidas?

Aunque algunas vulnerabilidades conocidas sólo tienen consecuencias menores, algunas de las mayores violaciones conocidas, como Heartbleed y Shellshock, se han basado en la explotación de vulnerabilidades conocidas en componentes compartidos. El uso de componentes con vulnerabilidades de código conocidas puede resultar en la ejecución remota de código en el servidor afectado, dando al atacante el control total de la máquina.

¿Cómo puede Fortify ayudar con la seguridad del código abierto?

• Si eres desarrollador: Fortify proporciona análisis de componentes de software a través de integraciones Sonatype.
• Si está en QA y Operaciones: Fortify automatiza la validación dinámica de vulnerabilidades conocidas en tiempo de ejecución.
• Si está en Operaciones: Fortify instrumentos de registro y protección para componentes de aplicaciones Java y .NET.

A10: Registro y supervisión insuficientes

Cuando no se comprenden bien los vectores de ataque o el mal comportamiento de las aplicaciones o no se siguen las mejores prácticas de supervisión de los indicadores de compromiso, pueden producirse fallos de registro y supervisión. Los ejemplos suelen encontrarse en sistemas heredados sin capacidad de registro, cuando los registros de las pruebas de penetración de aplicaciones no se examinan o cuando los registros no proporcionan detalles suficientes para comprender lo que hicieron los atacantes. Los atacantes cuentan con una media de alrededor de 200 días para la detección que normalmente se descubre externamente para establecer la persistencia y pivotar a sistemas vulnerables adicionales.

¿Qué hace que una aplicación sea vulnerable a un registro y una supervisión insuficientes?

• Las advertencias y los errores no generan mensajes de registro, son inadecuados o poco claros.
• Los registros se almacenan localmente sin controles de manipulación y/o no están supervisados.
• Los umbrales de alerta y los procesos de respuesta son insuficientes o no dan lugar a ninguna acción.

¿Cuál es el impacto de un registro y una supervisión insuficientes?

La mayoría de los ataques exitosos comienzan con el sondeo de vulnerabilidades. Permitir que estas sondas continúen puede aumentar la probabilidad de que los exploits tengan éxito. Los atacantes pueden establecer la persistencia, backdooring aplicaciones y sistemas operativos, el robo de datos, o de otra manera ganar desapercibido, el control no autorizado de los sistemas. Si la información crítica para la seguridad no se registra o almacena adecuadamente, no habrá rastro para que el análisis forense descubra el origen del ataque. Comprender que existe un problema puede resultar más difícil, o imposible, si el atacante mantiene el control de las capacidades de registro.

¿Cómo puede ayudar Fortify con el registro y la supervisión insuficientes?

• Si eres desarrollador: Fortify escanea las capacidades de registro en aplicaciones y APIs en busca de vulnerabilidades.
• Si estás en QA y Operaciones: Las exploraciones dinámicas de Fortify producen registros de aplicaciones para la revisión de la suficiencia, como las pruebas de penetración.
• Si se encuentra en Operaciones: Fortify instrumentos de registro y protección para aplicaciones Java y .NET.

Novedades de OWASP (2021)

Aunque solo han pasado cuatro años desde que se publicó el último top 10 en 2017, se han producido muchos cambios en el sector de la ciberseguridad que nos han hecho replantearnos las preocupaciones más prioritarias o qué nuevas añadir.

Se introdujeron tres nuevas categorías:

A04:2021

Diseño inseguro: Esta categoría se centra en los fallos de diseño. Esto es necesario porque el movimiento para desplazarse hacia la izquierda en el desarrollo requiere un desplazamiento hacia la izquierda también para el modelado de amenazas.

A08:2021

Fallos en la integridad del software y los datos: Se centra en suposiciones en torno a las actualizaciones de software, los datos críticos y la canalización CI/CD sin verificar la integridad que pueden afectar. También incorpora la norma A08:2017 - Deserialización insegura.

A10:2021

Falsificación de peticiones del lado del servidor (SSRF): Esta categoría se encuentra mayoritariamente entre las 10 primeras de la encuesta comunitaria. Hicieron mucho hincapié en esta vulnerabilidad debido a su explotabilidad e impacto por encima de la media.

Otros cambios

Las demás categorías han cambiado de nombre, han cambiado de rango o se han consolidado en otras categorías:

• A01:2017 - Inyección desplazada a A:03.
• A02:2017 - Autenticación fallida pasó a llamarse Fallos de identificación y autenticación y se trasladó a A07.
• A03:2017 - Exposición de datos sensibles se trasladó a A02 con el nuevo nombre de Fallos criptográficos para abordar de forma más completa la causa raíz, no solo los síntomas.
• A05:2017 - Broken Access Control pasó a A01 porque 94% de las aplicaciones que probaron mostraron exposición a alguna forma de Broken Access Control.
• A06:2017 - Desconfiguración de seguridad se ha desplazado un puesto a A05.
• A07:2017 - Cross-Site Scripting (XSS) se consolidó en A03 Inyección.
• A09:2017 - Utilización de componentes con vulnerabilidades conocidas se trasladó a A06 y pasó a llamarse Componentes vulnerables y obsoletos. Este cambio se debió en gran medida a que la comunidad lo situó en el nº 2 de su lista.
• A10:2017 - Insufficient Logging & Monitoring pasó a A09 y ahora se llama Security Logging and Monitoring Failures.

¿Quieres ver cómo Fortify puede ayudar a tu organización?  Comience ahora su prueba gratuita de 15 días de Fortify on Demand de OpenText™