¿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 del sector 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 OWASP Top 10 se revisa periódicamente para reflejar estos cambios. En la última versión de OWASP Top 10 publicada en 2021, algunos tipos de vulnerabilidades que ya no representan una amenaza grave se sustituyeron por otras que tienen más probabilidades de suponer un riesgo importante.

Aunque el OWASP Top 10 es un buen punto de partida para proteger las aplicaciones, no debe considerarse 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 de 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 SQL, LDAP, XPath o consultas de bases de datos dinámicas NoSQL con entrada suministrada por el usuario. Los atacantes inyectan código en la entrada del usuario, engañando al intérprete de la consulta 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 Fortify ayudar con los defectos de inyección?

• Si es usted desarrollador: Fortify detecta los fallos de inyección y ofrece 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. Los ejemplos se encuentran a menudo 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 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 eres desarrollador: Fortify detecta y recomienda soluciones para los problemas de autenticación.
• Si se encuentra en QA u Operaciones: Fortify valida la autenticación y la seguridad de la gestión de sesiones de forma dinámica.
• Si se encuentra en Operaciones: Fortify instrumenta la supervisión en tiempo de ejecución de los eventos de las 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?

• Puesta en peligro de datos regulados (por ejemplo, HIPAA o GDPR) que da 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 Fortify ayudar 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

Los problemas de entidades externas XML pueden surgir 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 entradas XML de fuentes no fiables, cuando están activadas las definiciones de tipo de documento (DTD) o que utilizan marcos no parcheados como SOAP 1.0. XML está en todas partes, desde archivos SVG e imágenes hasta protocolos de red y formatos de documentos como PDF y RSS. Los atacantes hacen referencia a entidades externas en la entrada XML que resulta en 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 Fortify ayudar con las entidades externas XML?

• Si es usted desarrollador: Fortify detecta los analizadores XML vulnerables y recomienda medidas paliativas.
• Si trabaja en control de calidad o en operaciones: Fortify busca automáticamente analizadores XML vulnerables y valida las cargas útiles de los 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

Los problemas de control de acceso pueden introducirse cuando el código y las restricciones del entorno se superponen de forma incompleta o se definen en múltiples lugares para una funcionalidad similar. 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 Fortify ayudar con el control de accesos rotos?

• Si eres desarrollador: Fortify automatiza la auditoría y permite crear plantillas para eliminar problemas mitigados en otros sitios.
• Si está en QA y Operaciones: Fortify agentes detectan superficie de ataque oculta 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 seguridad por desconfiguración 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 las cuentas y configuraciones por defecto, mensajes de error "con fugas", o marcos 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 Fortify ayudar con la desconfiguración de la seguridad?

• Si es usted desarrollador: Fortify identifica las dependencias de las aplicaciones y los archivos de configuración durante las exploraciones.
• Si está en QA y Operaciones: Fortify evalúa dinámicamente la aplicación y las configuraciones del servidor 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. A menudo se encuentran ejemplos cuando se aceptan construcciones de código conocidas 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 posteriormente por 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 Fortify ayudar con el cross-site scripting (XSS)?

• Si es usted desarrollador: Fortify detecta las 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 sanitizadas vulnerables a XSS.
• Si se encuentra 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 no fiables 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 autoejecutarse 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 Fortify ayudar con la deserialización insegura?

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

---

A9: Uso de componentes con vulnerabilidades conocidas

Estos fallos pueden introducirse cuando se introducen en una aplicación marcos 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 (por ejemplo, un error de codificación) o intencionados (por ejemplo, un componente antirretorno).
• 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?

Mientras que algunas vulnerabilidades conocidas sólo provocan impactos menores, algunas de las mayores brechas 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 dar lugar a la ejecución remota de código en el servidor afectado, otorgando al atacante el control total de la máquina.

¿Cómo puede Fortify contribuir a la seguridad del código abierto?

• Si eres desarrollador: Fortify proporciona análisis de componentes de software a través de integraciones Sonatype.
• Si trabaja en control de calidad y operaciones: Fortify automatiza la validación dinámica de vulnerabilidades conocidas en tiempo de ejecución.
• Si se encuentra 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 peligro, pueden producirse fallos en el registro y la supervisión. Los ejemplos se encuentran a menudo 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 unos 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 con éxito comienzan con el sondeo de vulnerabilidades. Permitir que tales sondeos continúen puede aumentar la probabilidad de éxito de los exploits. Los atacantes pueden establecer una persistencia, respaldando aplicaciones y sistemas operativos, robando datos u obteniendo de otro modo un control desapercibido y 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 Fortify ayudar con un registro y una supervisión insuficientes?

• Si eres desarrollador: Fortify escanea las capacidades de registro en aplicaciones y APIs en busca de vulnerabilidades.
• Si usted está en QA y Operaciones: Fortify escaneos dinámicos producen registros de aplicaciones para la revisión de la suficiencia, como las pruebas de pluma.
• 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 defectos de diseño. Esto es necesario porque el movimiento para cambiar a la izquierda en el desarrollo requiere un cambio a la izquierda también para el modelado de amenazas.

A08:2021

Fallos en la integridad del software y los datos: Se centra en las 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 en el top 10 de la encuesta de la comunidad. 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 el 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 - Uso 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 la situó en el puesto 2 de su lista.
• A10:2017 - Insufficient Logging & Monitoring pasó a A09 y ahora se llama Security Logging and Monitoring Failures.

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