ShellTI · Marcos y Estándares
El ranking de vulnerabilidades más referenciado en desarrollo de software seguro, publicado por el Open Worldwide Application Security Project. Indispensable para equipos de desarrollo, QA y seguridad de aplicaciones.
Resumen Ejecutivo
El Open Worldwide Application Security Project (OWASP) es una fundación sin fines de lucro que produce recursos gratuitos y abiertos sobre seguridad de aplicaciones. Su proyecto más conocido, el OWASP Top 10, es una lista de las vulnerabilidades de aplicaciones web más críticas, actualizada periódicamente basándose en datos de organizaciones de seguridad globales.
La versión vigente, OWASP Top 10:2021, se basa en análisis de más de 500.000 aplicaciones reales y es referenciada por PCI DSS, ISO 27001, NIST CSF y regulaciones sectoriales como requisito de desarrollo seguro.
Más allá del Top 10, OWASP produce proyectos clave como: OWASP WSTG (Web Security Testing Guide), OWASP ASVS (Application Security Verification Standard), OWASP SAMM (Software Assurance Maturity Model) y OWASP ZAP (herramienta de pentesting gratuita).
El Top 10:2021
Primera posición desde 2021. Ocurre cuando usuarios pueden actuar fuera de sus permisos previstos: acceder a recursos de otros usuarios, modificar datos sin autorización o acceder a funciones administrativas. Prevención: denegación por defecto, control en servidor, registro de intentos fallidos.
Antes "Exposición de Datos Sensibles". Incluye transmisión de datos en texto claro, uso de algoritmos criptográficos obsoletos (MD5, SHA1, DES) y almacenamiento de contraseñas sin hash. Fundamental para la Ley 21.719 (deber de seguridad).
SQL, NoSQL, OS, LDAP y otras formas de inyección. Ocurre cuando datos no confiables se envían a un intérprete. Prevención: consultas parametrizadas, validación de entrada, ORMs con escape automático.
Nueva categoría en 2021. Se centra en riesgos de diseño arquitectónico: ausencia de modelado de amenazas, flujos de negocio inseguros, ausencia de controles de compensación. Requiere diseño seguro desde el inicio (Security by Design).
A05: Configuración de Seguridad Incorrecta. A06: Componentes Vulnerables y Desactualizados. A07: Fallos de Identificación y Autenticación. A08: Fallos de Integridad de Software y Datos. A09: Fallos en el Registro y Monitoreo de Seguridad. A10: Falsificación de Solicitudes del Lado del Servidor (SSRF).
Prevención
Para prevenir A03 (Inyección). Usar consultas preparadas o stored procedures en todas las interacciones con bases de datos. Nunca concatenar input del usuario en queries.
Para prevenir A01. Implementar control de acceso basado en roles (RBAC) o atributos (ABAC), verificado en el servidor. Denegar todo por defecto.
Para prevenir A02. TLS 1.2+ obligatorio, HSTS, PBKDF2/Argon2 para contraseñas, cifrado AES-256 para datos sensibles en reposo.
Para prevenir A06. Usar herramientas como OWASP Dependency-Check, npm audit o Snyk. Mantener un inventario de bibliotecas y actualizar regularmente.
Para prevenir A05. Eliminar funcionalidades no usadas, cambiar credenciales por defecto, configurar cabeceras de seguridad HTTP (CSP, X-Frame-Options, etc.).
Para prevenir A09. Registrar eventos de autenticación, acceso fallido y errores de validación. Implementar alertas automáticas ante patrones sospechosos.
Aplicación Práctica
Aplicar STRIDE u OWASP Threat Dragon para identificar riesgos de seguridad en la arquitectura antes de escribir código. Mapear los activos críticos y sus posibles vectores de ataque.
Integrar análisis estático de código (SAST) en el pipeline CI/CD con herramientas como SonarQube, Semgrep o Checkmarx para detectar vulnerabilidades como inyección y criptografía incorrecta en tiempo de compilación.
Ejecutar análisis dinámico (DAST) con OWASP ZAP, Burp Suite o similar contra ambientes de staging. Las pruebas dinámicas detectan vulnerabilidades que el análisis estático no puede ver, como A01 y A05.
Para aplicaciones críticas, realizar un pentest de caja gris por equipo externo antes de cada release mayor. Los hallazgos deben documentarse y remediarse con SLA definidos.
DevSecOps
La integración de OWASP en un pipeline DevSecOps permite que la seguridad sea un proceso continuo y automatizado, no un gate de seguridad al final del desarrollo.
Código → SAST (SonarQube/Semgrep) → Build → SCA (Dependency-Check) → Deploy Staging → DAST (ZAP) → Deploy Prod → Pentesting periódico → Monitoreo continuo (SIEM/WAF). Cada fase bloquea vulnerabilidades del Top 10 en diferentes momentos del ciclo.
El Art. 14 quater exige medidas técnicas apropiadas al estado del arte. Las vulnerabilidades del OWASP Top 10 son de conocimiento público; su presencia en producción evidencia falta de diligencia técnica ante reguladores y puede agravar sanciones por brechas de seguridad.
Preguntas Frecuentes
El OWASP Top 10 se actualiza aproximadamente cada 3-4 años. La versión actual es 2021. Además del Top 10 web, OWASP publica listas para APIs (OWASP API Security Top 10), aplicaciones móviles y LLMs (AI/ML applications).
OWASP ZAP es excelente para ambientes de desarrollo y staging. Para producción se recomienda complementarlo con un WAF (Web Application Firewall) comercial o open source como ModSecurity. Las pruebas activas con ZAP nunca deben ejecutarse en producción sin autorización explícita.
SAST (Static Application Security Testing) analiza el código fuente sin ejecutar la aplicación, detectando vulnerabilidades en el código. DAST (Dynamic Application Security Testing) prueba la aplicación en ejecución desde afuera, simulando un atacante. Una estrategia completa combina ambos.
OWASP se mapea principalmente a los controles tecnológicos del Anexo A de ISO 27001:2022: A.8.8 (gestión de vulnerabilidades), A.8.28 (codificación segura), A.8.25 (ciclo de vida de desarrollo seguro) y A.8.29 (pruebas de seguridad en desarrollo y aceptación).
ShellTI acompaña a empresas chilenas desde el diagnóstico hasta la certificación, con foco en Ley 21.719 e ISO 27001.