Publicada OWASP Top Ten 2017 Release Candidate 1

El proyecto OWASP (Open Web Application Security Project) nació hace más de una década y desde entonces se ha dedicado a trabajar en la mejora de la seguridad de las aplicaciones web (y más tarde en las apps móviles que al final usan backends web). Entre las iniciativas que empujan la principal es la de la formación de los desarrolladores y expertos en seguridad, mediante conferencias, documentación y generación de herramientas que sirvan para auditar y mejorar la seguridad de las apps.

Figura 1: OWASP Top 10 - 2017 RC1
"The Ten Most Critical Web Application Security Risks"

Dentro de estas iniciativas, una de ellas es el proyecto OWASP TOP TEN, donde se recogen los 10 riesgos de seguridad más importantes en el mundo de la seguridad web. En él se enumeran de 1 a 10 en orden de importancia, cuales son los riesgos más críticos que un proyecto web debe atacar.

Figura 2: OWASP TOP TEN 2017 RC1

La nueva versión de la lista de OWASP TOP TEN ha sido publicada recientemente. Es la versión 2017 RC1 (aún está en proceso de debate y es susceptible de poder ser cambiada en algo). El documento completo de la guía lo he subido a SlideShare para verlo en este artículo y lo tenéis en la web del proyecto.

OWASP TOP TEN 2017 RC1

Los ataques de Inyección, donde se encuentran los de SQL Injetcion, LDAP Injection, XPath Injection, Command Injection, en todas sus variedades, es decir, Blind, Time-Based, In-band, Out-band, etcétera, siguen siendo los más importantes. Nada nuevo bajo el sol y en los libros de SQL Injection y Hacking Web Technologies los tratamos extensamente debido a su importancia.

Figura 3: A1 - Injection

En segundo lugar están los ataques que se producen por una mala gestión de la autenticación o de la gestión de las sesiones. Desde sesiones que no caducan que se envían por GET y quedan indexadas en buscadores y proxies, hasta zonas de la aplicación donde no se comprueba correctamente la autenticación de la sesión. Aquí son conocidos los ataques de Session Fixation, Pass-the-hash, Session Hijacking, etcétera.

Figura 4: A2 - Broken Authentication & Session Management

En tercer lugar, los populares Ataques de XSS que aún siguen apareciendo constantemente. Por GET, por POST, en formato HTML Injection donde hay que ingeniarse más la ejecución de comandos para saltarse los filtros Anti-XSS o las protecciones CORS, y donde también hay que poner los ataques de Cross-Site SWF Scripting.

Figura 5: A3 - Cross-Site Scripting (XSS)

En el número 4 está el Broken Access Control, o lo que es lo mismo, zonas de la aplicación que no están correctamente protegidas y usuarios no autenticados pueden acceder a ella y hacer cosas que no deberían. Yo os dejé un ejemplo de cómo pasé una tarde jugando con un panel de administración que tenía este tipo de fallo... allá por el año 2011. En el mundo del Big Data, son muchos los ejemplos que os he contado en los Big Security Tales.

Figura 6: A4 - Broken Access Control

En el quinto puesto, Fallos de la configuración de seguridad. Desde errores en los mensajes de error, hasta fallos en la configuración del servidor web. Ejemplos de estos hay muchos, desde el Multiple Choices de Apache, hasta el IIS Shortname de Microsoft, pasando por los errores no controlados de los frameworks o las configuraciones inseguras de paneles de administración.

Figura 7: A5 - Security Misconfiguration

El sexto es para la exposición de datos sensibles. Es decir, para entornos en los que los datos personales, datos médicos, etcétera, no están correctamente protegidos en las apps. Estos datos deben estar protegidos de una forma especial, con un cifrado mayor, con acceso más restringido utilizando segundos factores de autenticación o verificación robusta de accesos mediante sistemas de autenticación fuerte de las personas que acceden a ellos.

Figura 8: A6 - Sensitive Data Exposure

En la séptima posición tenemos "Protecciones frente a ataques insuficientes" donde se habla de la carencia de mecanismos de seguridad en las áreas de Prevención (con sistemas WAF, Anti-DDOS, sin auditoría/pentesting periódico o persistente), de Detección de ataques (sin sistemas de logs, SIEM, IDS, etc..) y de Respuesta (sin sistemas de respaldo, backups, cifrado de datos sensibles en la base de datos de forma robusta, etc...). Muy a tener en cuenta si tu aplicación es core para tu negocio.

Figura 9: A7 - Insufficient Attack Protection

En la posición 8 un viejo conocido. Fallos de Cross-Site Request Forgery. Aún es fácil localizar aplicaciones web sin ninguna protección anti-CSRF en sus enlaces internos. Así nos encontramos con que los APTs tienen un fuerte impacto en las grandes organizaciones con ataques de Spear-Phishing.

Figura 10: A8 - Cross-Site Request Forgery (CSRF)

En la posición novena se encuentra el Uso de componentes con vulnerabilidades conocidas. Esto es algo que hemos visto hasta en grandes compañías como Apple, que utilizaban para iTunes librerías con vulnerabilidades conocidas.

Figura 11: A9 - Using Components with Known Vulnerabilites

Y por último, en la posición décima, una novedad pero que lleva años explotándose. APIs mal protegidas. Esto es algo que hemos visto muchas veces. En las apps móviles, utilizando Tacyt nosotros localizamos gran cantidad de backends con APIs totalmente expuestas, como os dejé en los artículos de Dorking with Tacyt o en el artículo de localización de los backends con WebServices.

Figura 12: A10 - Underprotected APIs

La última versión que hubo de este proyecto fue en el año 2013, y si miramos la lista de diez riesgos en aquella versión y la nueva, podemos ver que no hay tantos cambios.

Figura 13: Comparación de riesgos entre OWASP TOP TEN 213 y 2017

Como se ve, los riesgos A7 - Insufficient Attack Protection y A10 - Underprotected APIs son nuevas en esa versión. Además, dos riesgos en la versión de 2013 se han juntado en una única nueva categoría, así que la mayoría sigue estando presente.

Saludos Malignos!