OWASP Top 10 (2017)
El OWASP Top 10 – 2017 marcó una de las transformaciones más profundas en la historia del proyecto. Fue la primera edición en seis años, y durante ese período la web cambió radicalmente:
• APIs REST y microservicios
• SaaS masivos
• DevOps y automatización
• JavaScript del lado del servidor
• Frameworks como Angular, React, Laravel, Django, Spring
Todo esto produjo nuevos riesgos, cambios en incidencias y la necesidad de redefinir la taxonomía. Además, 2017 fue una edición polémica, ya que se introdujeron categorías nuevas (unas muy necesarias, otras discutidas).
A1 – Injection
Injection se mantuvo en el primer puesto, como en 2010 y 2013.
Incluía:
• SQL Injection
• NoSQL Injection
• Command Injection
• ORM Injection
• LDAP/XPath/XML Injection
Por qué seguía siendo #1:
Las brechas masivas seguían teniendo origen en SQLi, especialmente en aplicaciones legacy.
A2 – Broken Authentication
Evolución del “Broken Authentication and Session Management”.
Ahora separado y más enfocado en:
• passwords débiles
• mal uso de tokens
• autenticación insuficiente
• mecanismos de login inseguros
• problemas derivados de sesiones sin protección
Contexto histórico:
Con la masificación de APIs y autenticación móvil, los errores se multiplicaron.
A3 – Sensitive Data Exposure
Se puso en el top 3 debido a:
• leaks masivos de datos personales
• brechas por mala protección de bases de datos
• cifrado incorrecto o inexistente
• falta de TLS o configuraciones débiles
Dato clave:
En 2016–2017 se filtraron cientos de millones de registros, lo que justificó esta posición.
A4 – XML External Entities (XXE) (Nueva categoría)
Una de las novedades más importantes.
XXE aparecía en:
• servicios SOAP
• procesadores XML
• parsers con DTD habilitado
Permitía ataques como:
• lectura de archivos locales
• escaneo interno
• SSRF
• RCE (según parser)
Motivo de su incorporación:
El auge de APIs basadas en XML en banca y empresas la hacía crítica.
A5 – Broken Access Control (Unificación con IDOR)
Por primera vez, OWASP agrupa:
• IDOR
• Missing Function Level Access Control
• Fallas en control horizontal/vertical
Fue un paso enorme:
la seguridad web tenía un problema sistémico de autorización, no solo de parámetros.
A6 – Security Misconfiguration
Misconfig no cambió mucho, pero subió en prioridad.
Incluía:
• servidores por defecto
• errores expuestos
• archivos sensibles accesibles
• permisos incorrectos
• falta de hardening
• paneles admin abiertos
Motivo:
El auge de contenedores y cloud aumentaba la complejidad y la probabilidad de errores.
A7 – Cross-Site Scripting (XSS)
Por primera vez, XSS deja el top 3 y cae al puesto 7.
Motivo directo:
Los frameworks modernos empezaron a sanitizar por defecto (Angular, React).
Sin embargo, DOM XSS seguía siendo frecuente.
A8 – Insecure Deserialization (Nueva categoría y muy controversial)
Una de las inclusiones más debatidas en la historia.
La deserialización insegura afectaba a aplicaciones:
• Java (muy afectadas)
• PHP
• Python
• .NET
Permitía:
• RCE
• manipulación de objetos
• escalamiento de privilegios
• bypass de autenticación
Polémica:
Era peligrosa y grave, pero algunos argumentaban que no era tan común en todas las industrias.
A9 – Using Components with Known Vulnerabilities
Consolidada desde 2013, cobra aún más relevancia.
Incluía:
• librerías desactualizadas
• CVEs sin aplicar
• frameworks vulnerables
• módulos de terceros inseguros
Motivo:
Ataques como Struts2 en 2017 demostraron el impacto devastador de una sola dependencia vulnerable.
A10 – Insufficient Logging & Monitoring (Nueva categoría)
Otra categoría polémica, pero muy acertada.
Incluía fallas como:
• falta de logs
• logs incompletos
• ausencia de alertas
• monitoreo deficiente
Esto impedía:
• detectar ataques
• responder incidentes
• cumplir requisitos forenses
• identificar brechas
Importancia histórica:
Grandes filtraciones se detectaban meses después, lo que impulsó esta categoría.