El Open Web Application Security Project publica cada pocos años la lista de las vulnerabilidades más peligrosas en aplicaciones web. Entenderlas es obligatorio para cualquier desarrollador o profesional de seguridad.
La Open Web Application Security Project (OWASP) es una fundación sin fines de lucro fundada en 2001, compuesta por voluntarios de todo el mundo. Su misión es mejorar la seguridad del software a través de proyectos de código abierto, documentación gratuita, herramientas y comunidades.
El OWASP Top 10 es su publicación más conocida — una lista de las diez categorías de vulnerabilidades web más críticas, basada en datos reales de aplicaciones analizadas por cientos de organizaciones. Se actualiza aproximadamente cada 3-4 años. Es el estándar de facto más citado en contratos de seguridad, auditorías, requisitos de desarrollo y certificaciones de la industria.
Por qué es #1: El 94% de las aplicaciones probadas tenían alguna forma de este problema en la edición 2021, haciéndola la categoría más prevalente.
Qué es: Las restricciones sobre lo que los usuarios autenticados pueden hacer no se aplican correctamente. Un atacante puede acceder a funcionalidades o datos para los que no tiene permiso.
Ejemplo — IDOR (Insecure Direct Object Reference): Un usuario accede a su perfil en https://banco.com/cuenta?id=1234. Si el sistema no verifica que el ID 1234 pertenece al usuario autenticado, el atacante simplemente cambia el parámetro a id=1235 y accede a la cuenta de otra persona. Esta vulnerabilidad simple ha causado brechas masivas.
Otros ejemplos: escalada horizontal de privilegios (acceder a datos de otro usuario con el mismo rol), escalada vertical (un usuario normal accede a funciones de administrador), CORS mal configurado (permite solicitudes de orígenes no autorizados), acceder a la consola de administración sin autenticación.
Prevención: denegar acceso por defecto; implementar listas de control de acceso en el servidor (nunca en el cliente); verificar permisos en cada solicitud, no solo al login; registrar y alertar sobre intentos de acceso fallidos repetidos.
Antes llamada: "Exposición de Datos Sensibles" — el nombre cambió para enfocarse en la causa raíz.
Qué es: Uso inadecuado (o ausencia) de criptografía para proteger datos sensibles en tránsito o en reposo.
Ejemplos del mundo real:
Prevención: usar bcrypt, Argon2 o scrypt para contraseñas (nunca MD5, SHA-1 o SHA-256 sin sal para contraseñas); exigir TLS 1.2+ en todas las comunicaciones; usar AES-256 para datos en reposo; nunca hardcodear secretos.
Qué es: Datos no confiables enviados a un intérprete (SQL, sistema operativo, LDAP, etc.) como parte de un comando o consulta, haciendo que el intérprete ejecute comandos no intencionados.
SQL Injection — el ejemplo clásico:
Un formulario de login con código vulnerable:
SELECT * FROM usuarios WHERE user='$user' AND pass='$pass'
Si el atacante ingresa como usuario: ' OR '1'='1
La consulta resultante es: SELECT * FROM usuarios WHERE user='' OR '1'='1' AND pass=''
Como '1'='1' siempre es verdadero, la consulta devuelve todos los usuarios y el atacante inicia sesión como administrador sin conocer ninguna contraseña.
Técnicas avanzadas: union-based (extraer datos de otras tablas), blind boolean (inferir datos por el comportamiento del sitio), time-based blind (inferir datos midiendo tiempos de respuesta), out-of-band (exfiltrar datos por DNS).
Command Injection: Si una app pasa input del usuario directamente al shell del sistema operativo, el atacante puede ejecutar comandos arbitrarios. Ejemplo: una app que hace ping a una IP ingresada por el usuario, y el atacante ingresa 127.0.0.1; cat /etc/passwd.
Prevención: consultas parametrizadas (prepared statements) en TODAS las consultas SQL; usar ORMs; validación de input del lado servidor; WAF como capa adicional.
Nueva en 2021. Esta categoría se diferencia de las demás porque se refiere a fallas en la arquitectura y diseño del sistema, no en la implementación. No puedes parchear un diseño fundamentalmente inseguro — debes rediseñar.
Ejemplos:
Prevención: modelado de amenazas (STRIDE) antes de escribir código; definir requisitos de seguridad junto con los de negocio; usar patrones de diseño seguros establecidos; ciclos de revisión de diseño con el equipo de seguridad.
Qué es: La configuración del sistema, servidor, base de datos, framework o plataforma cloud está mal configurada o usa valores por defecto inseguros.
Ejemplos comunes:
Prevención: proceso de hardening documentado para cada entorno; eliminar características, componentes y documentación no necesarios; mostrar solo errores genéricos al usuario; escanear regularmente con herramientas de configuración.
Qué es: Usar librerías, frameworks o componentes de software con vulnerabilidades conocidas.
Log4Shell (CVE-2021-44228) — el caso más impactante de la historia reciente: En diciembre de 2021 se descubrió una vulnerabilidad crítica (CVSS 10.0 — la puntuación máxima posible) en Log4j, una librería de logging de Java usada en millones de aplicaciones y sistemas en todo el mundo. Un atacante podía ejecutar código arbitrario de forma remota simplemente enviando una cadena de texto especial como input a cualquier aplicación que usara Log4j para registrar ese input. La vulnerabilidad afectó a Apple, Amazon, Google, Microsoft, Twitter, Steam, Minecraft y miles más. Los parches se publicaron pero aplicarlos requería identificar cada instancia de Log4j en la infraestructura — muchas veces dentro de dependencias de dependencias de dependencias.
Prevención: mantener un inventario de todos los componentes (Software Bill of Materials — SBOM); usar herramientas de SCA (Software Composition Analysis): OWASP Dependency-Check, Snyk, retire.js; suscribirse a alertas de CVE; política de actualización de dependencias en el pipeline CI/CD.
Qué es: Debilidades en los mecanismos de autenticación que permiten a atacantes suplantar identidades.
Ejemplos:
Prevención: MFA obligatoria para cuentas privilegiadas; verificar contraseñas contra listas de contraseñas comprometidas (API de HIBP); rate limiting en endpoints de login; timeouts de sesión; bcrypt para contraseñas.
Nueva en 2021. Cubre fallas relacionadas con actualizaciones de software, datos críticos y pipelines CI/CD que no verifican integridad.
SolarWinds (2020) — el ataque a la cadena de suministro más significativo de la historia: Los atacantes (APT29/Cozy Bear, atribuido al SVR ruso) comprometieron el sistema de compilación de SolarWinds Orion. Durante meses, cada actualización legítima del software contenía código malicioso (SUNBURST) firmado digitalmente con el certificado oficial de SolarWinds. Aproximadamente 18,000 organizaciones descargaron e instalaron voluntariamente el software comprometido, incluyendo agencias del gobierno de EE.UU. (Tesoro, Estado, Homeland Security), Microsoft, Intel y FireEye. Permanecieron en las redes víctima durante meses sin ser detectados.
Prevención: firma digital de código; verificar checksums de dependencias; pipelines CI/CD seguros con acceso controlado; revisar cambios en dependencias automáticamente; Software Bill of Materials (SBOM).
Qué es: Sin logs adecuados y monitoreo activo, los ataques no se detectan. El tiempo medio de detección de una brecha es de 207 días (IBM Cost of Data Breach 2023) — y sin logging, puede ser nunca.
Qué debe registrarse:
Log injection: si los logs registran input del usuario sin sanitización, un atacante puede insertar entradas falsas en el log para ocultar sus acciones o confundir al investigador forense.
Prevención: logging centralizado (SIEM: Splunk, ELK Stack, AWS CloudWatch); alertas automáticas para eventos anómalos; proteger los logs contra modificación; retención de logs por al menos 12 meses.
Qué es: El servidor web hace solicitudes HTTP a recursos internos basándose en input controlado por el atacante, permitiendo acceder a sistemas internos que no deberían ser accesibles desde internet.
Ejemplo: Una función de "importar imagen desde URL" en la que el atacante ingresa http://169.254.169.254/latest/meta-data/iam/security-credentials/ — la IP especial del servicio de metadatos de AWS — y el servidor devuelve las credenciales IAM de la instancia EC2. Exactamente como ocurrió en Capital One.
Prevención: validar y sanitizar toda URL provista por el usuario; implementar lista blanca (allowlist) de dominios permitidos; deshabilitar redirecciones HTTP en el cliente; segmentar la red para que los servidores de aplicación no puedan acceder a recursos internos innecesarios; usar IMDSv2 en AWS (requiere token de sesión, más difícil de explotar vía SSRF).
| Herramienta | Tipo | Uso | Costo |
|---|---|---|---|
| Burp Suite Community | Proxy de intercepción | Interceptar, modificar y repetir solicitudes HTTP/HTTPS; scanner básico | Gratuita |
| Burp Suite Pro | Scanner activo | Scanner automático de vulnerabilidades web, intruder avanzado | $449/año |
| OWASP ZAP | Scanner web | Scanner automático de vulnerabilidades, ideal para integrar en CI/CD | Gratuita (open source) |
| sqlmap | SQL injection | Detección y explotación automatizada de SQL injection | Gratuita (open source) |
| Nikto | Scanner de servidor web | Detectar configuraciones inseguras, archivos sensibles, versiones obsoletas | Gratuita (open source) |
Si encuentras una vulnerabilidad en un sistema real sin autorización de pentesting, el proceso correcto es la divulgación responsable (responsible disclosure): contactar al equipo de seguridad de la organización afectada (busca security.txt o security@dominio.com), describir la vulnerabilidad sin publicarla, dar un plazo razonable para remediarla (generalmente 90 días, el estándar de Google Project Zero), y solo publicar si no hay respuesta o la vulnerabilidad no es parcheada en ese plazo.