Tema 3

3. Principales amenazas web y OWASP Top 10

Las aplicaciones web suelen fallar en patrones que se repiten. Conocer las amenazas más frecuentes y usar OWASP Top 10 como mapa permite identificar riesgos reales antes de que se conviertan en incidentes de seguridad.

Objetivo Reconocer las amenazas web más importantes
Enfoque Riesgos recurrentes y criterio de análisis
Resultado Interpretar OWASP Top 10 con sentido práctico

3.1 Introducción

Las aplicaciones web modernas comparten tecnologías, patrones de desarrollo y errores frecuentes. Eso hace que muchas vulnerabilidades se repitan entre sistemas distintos. Un sitio de comercio electrónico, una intranet administrativa, un portal educativo o una API móvil pueden diferir en funcionalidad, pero suelen exponerse a familias de riesgos muy parecidas.

Conocer estas amenazas no sirve solo para memorizar nombres técnicos. Sirve para aprender a hacer preguntas correctas: qué pasa si un usuario manipula una entrada, si intenta acceder a datos ajenos, si inyecta contenido en una respuesta, si automatiza miles de solicitudes o si el sistema confía en una configuración insegura.

OWASP Top 10 ayuda justamente a ordenar esa mirada. No reemplaza el análisis del sistema real, pero ofrece una referencia clara sobre categorías de riesgo que aparecen una y otra vez en aplicaciones web.

3.2 Qué entendemos por amenaza web

Una amenaza web es una posibilidad de abuso, explotación o afectación sobre una aplicación accesible mediante tecnologías web. La amenaza puede materializarse por una vulnerabilidad técnica, una mala decisión de diseño, una configuración débil, una exposición innecesaria o una combinación de varias fallas.

Desde el punto de vista práctico, una amenaza web importa porque puede comprometer alguno de estos objetivos:

  • La confidencialidad de los datos.
  • La integridad de la información o de las operaciones.
  • La disponibilidad del sistema.
  • La autenticidad de identidades y sesiones.
  • La autorización correcta sobre recursos y funciones.

3.3 Vulnerabilidad, amenaza, explotación e impacto

Conviene separar algunos conceptos que a menudo se mezclan:

  • Vulnerabilidad: debilidad concreta en código, diseño, configuración o proceso.
  • Amenaza: posibilidad de que esa debilidad sea aprovechada.
  • Explotación: uso efectivo de la debilidad para producir un resultado indebido.
  • Impacto: consecuencia sobre datos, cuentas, operaciones o negocio.

Por ejemplo, una consulta SQL construida con datos del usuario puede ser la vulnerabilidad. La amenaza es que un atacante inserte instrucciones maliciosas. La explotación ocurre cuando lo hace con éxito. El impacto puede ser lectura, modificación o borrado de datos.

No todas las vulnerabilidades tienen el mismo impacto, pero casi todas se vuelven más peligrosas cuando afectan autenticación, autorización, datos sensibles o funciones administrativas.

3.4 Qué es OWASP

OWASP, sigla de Open Worldwide Application Security Project, es una comunidad abierta dedicada a mejorar la seguridad del software. Produce guías, proyectos, materiales educativos y referencias ampliamente utilizadas por desarrolladores, auditores y equipos de seguridad.

Su valor no está solo en listar problemas. Su utilidad práctica consiste en ofrecer lenguaje común, priorización y enfoques de mitigación. En seguridad web, hablar de XSS, control de acceso roto o configuración insegura suele apoyarse en categorías difundidas por OWASP.

3.5 Qué es OWASP Top 10

OWASP Top 10 es una lista de categorías de riesgos de seguridad relevantes en aplicaciones web. No es un ranking cerrado de técnicas ni una lista exhaustiva de todas las vulnerabilidades posibles. Es una guía de alto nivel para recordar qué tipos de fallas aparecen con frecuencia y merecen revisión prioritaria.

Su mayor utilidad es conceptual:

  • Ayuda a no olvidar riesgos comunes.
  • Facilita conversaciones entre desarrollo y seguridad.
  • Permite organizar revisiones, pruebas y capacitación.
  • Sirve como marco inicial para analizar una aplicación.

También tiene límites. Una aplicación puede no tener varias categorías del Top 10 y aun así sufrir una falla grave de lógica de negocio o una exposición muy específica de su contexto.

3.6 Por qué estas amenazas se repiten tanto

Las amenazas web más comunes se repiten por varias razones estructurales:

  • Las aplicaciones reciben datos no confiables de forma constante.
  • Muchos sistemas crecen rápido y priorizan funcionalidad antes que seguridad.
  • Los desarrolladores reutilizan patrones inseguros o desconocen ciertos riesgos.
  • Se confía demasiado en el cliente o en validaciones superficiales.
  • Las dependencias y configuraciones se arrastran entre proyectos sin revisión.
  • Los flujos complejos de negocio suelen quedar insuficientemente modelados.

En otras palabras, el problema no es solo técnico. También es de diseño, de proceso y de disciplina de desarrollo.

3.7 Control de acceso roto

Una de las categorías más críticas es el control de acceso roto. Ocurre cuando la aplicación no verifica correctamente qué recursos o funciones puede usar cada usuario.

Esto incluye situaciones como:

  • Acceder a registros de otro usuario cambiando un identificador.
  • Invocar funciones administrativas sin el rol adecuado.
  • Modificar datos ajenos manipulando parámetros.
  • Confiar en valores enviados por el cliente para decidir permisos.

Su gravedad es alta porque muchas veces no requiere explotar una técnica sofisticada. Basta con probar recursos que la aplicación expone sin verificar correctamente la autorización.

3.8 Fallas criptográficas y protección de datos

Otra categoría importante aparece cuando la aplicación no protege adecuadamente datos sensibles. Esto puede ocurrir si transmite información sin HTTPS, si guarda contraseñas de forma insegura, si expone tokens en lugares incorrectos o si utiliza mecanismos criptográficos débiles o mal aplicados.

No se trata solo de "usar cifrado". Se trata de usarlo en el lugar correcto, con claves adecuadas, para el tipo de dato correcto y evitando errores de implementación.

Error Consecuencia técnica Impacto posible
Contraseñas mal almacenadas Recuperación o crackeo más simple Toma de cuentas y reutilización de credenciales
Tráfico sin HTTPS Exposición en tránsito Robo de credenciales o sesión
Claves o secretos expuestos Acceso a sistemas o integraciones Escalada del incidente
Datos sensibles devueltos en exceso Filtración por respuestas o logs Impacto legal y reputacional

3.9 Inyección

Las fallas de inyección aparecen cuando datos controlados por el usuario se mezclan de forma insegura con comandos, consultas o expresiones que el sistema interpreta. El caso más conocido es SQL Injection, pero existen otras variantes: NoSQL Injection, inyección de comandos del sistema operativo, LDAP Injection, XPath Injection y más.

La idea central es siempre la misma: el sistema esperaba datos, pero termina ejecutando instrucciones alteradas por el atacante.

Sus efectos pueden ser graves:

  • Lectura no autorizada de información.
  • Alteración o borrado de registros.
  • Bypass de autenticación.
  • Ejecución de acciones administrativas.
  • Compromiso del servidor si la cadena de explotación avanza.

3.10 Diseño inseguro

No todos los problemas se deben a una línea de código mal escrita. A veces el riesgo nace en la arquitectura o en la lógica del sistema. El diseño inseguro aparece cuando los flujos, supuestos o mecanismos centrales de la aplicación ya son débiles desde su concepción.

Ejemplos típicos:

  • No limitar intentos en recuperación de contraseña o login.
  • No separar adecuadamente roles críticos.
  • Permitir operaciones sensibles sin reautenticación.
  • Modelar procesos de negocio sin pensar en abuso intencional.

Este tipo de falla es importante porque puede sobrevivir incluso si el código está "bien programado".

3.11 Configuración insegura

Muchas aplicaciones no caen por una vulnerabilidad exótica sino por configuraciones débiles. Una configuración insegura puede aparecer en el servidor, en el framework, en el contenedor, en la base de datos, en las cabeceras HTTP o en funciones auxiliares expuestas sin necesidad.

Algunos ejemplos frecuentes son:

  • Mensajes de error demasiado detallados.
  • Servicios o paneles de administración expuestos.
  • Cabeceras de seguridad ausentes.
  • Defaults peligrosos del framework o servidor web.
  • Directorios listables o archivos de respaldo publicados.
  • Entornos de desarrollo visibles en producción.

3.12 Componentes vulnerables o desactualizados

Las aplicaciones modernas dependen de frameworks, librerías, paquetes y servicios de terceros. Si alguno de esos componentes contiene vulnerabilidades conocidas y no se actualiza, la aplicación hereda el riesgo.

Esto es especialmente importante porque:

  • Muchas dependencias se incorporan automáticamente.
  • El equipo puede no conocer realmente todo lo que usa.
  • Una vulnerabilidad conocida suele estar documentada y ser explotable.
  • La cadena de suministro amplía el riesgo más allá del código propio.

3.13 Fallas de autenticación e identificación

La autenticación es el proceso por el cual el sistema verifica la identidad de un usuario o servicio. Cuando este proceso es débil, todo lo demás pierde valor. Una mala autenticación puede incluir contraseñas triviales, recuperación de cuenta insegura, falta de MFA, sesiones mal protegidas o tokens fáciles de reutilizar.

El impacto puede ser directo: toma de cuenta, fraude, acceso administrativo o movimiento lateral hacia otros sistemas integrados.

3.14 Fallas de integridad de software y datos

Esta categoría apunta a escenarios donde el sistema confía en software, actualizaciones, dependencias o datos sin validar adecuadamente su origen o su integridad. Puede involucrar procesos de despliegue inseguros, paquetes manipulados, dependencias alteradas o flujos de actualización débiles.

Su relevancia creció porque hoy gran parte del desarrollo depende de automatización, repositorios de paquetes y cadenas de construcción complejas.

3.15 Logging y monitoreo insuficientes

Una aplicación puede ser atacada y no detectarlo a tiempo si registra poco, registra mal o no observa los eventos relevantes. La ausencia de logging y monitoreo adecuados no crea por sí sola la vulnerabilidad inicial, pero agrava enormemente el impacto.

Si no hay visibilidad suficiente:

  • No se detectan intentos de abuso o automatización.
  • No se puede investigar un incidente con precisión.
  • No se sabe qué cuentas o recursos fueron afectados.
  • La respuesta es más lenta y menos confiable.

3.16 Server-Side Request Forgery y otros riesgos frecuentes

Además de las categorías más conocidas, existen amenazas web que merecen atención especial según el tipo de aplicación. Un ejemplo importante es SSRF, donde el atacante induce al servidor a realizar solicitudes a destinos que él elige. Esto puede exponer servicios internos, metadatos cloud o sistemas no accesibles desde internet.

También son frecuentes:

  • XSS almacenado, reflejado o basado en DOM.
  • CSRF en operaciones sensibles.
  • Subida insegura de archivos.
  • Deserialización peligrosa.
  • Exposición excesiva de datos en APIs.
  • Fallas de lógica de negocio fuera de categorías clásicas.

3.17 XSS y CSRF como amenazas transversales

Aunque después los veremos en detalle, conviene ubicarlos desde ahora porque aparecen con frecuencia y suelen confundirse.

  • XSS: el atacante logra que el navegador ejecute contenido controlado por él dentro del contexto del sitio vulnerable.
  • CSRF: el atacante induce al navegador de una víctima autenticada a ejecutar una acción no deseada contra el sitio.

En ambos casos el navegador del usuario cumple un papel central, pero la naturaleza del abuso es distinta. XSS explota salida insegura y ejecución de scripts. CSRF explota confianza indebida en solicitudes originadas desde el navegador de un usuario ya autenticado.

3.18 Cómo leer una categoría de riesgo

Cuando analizamos una amenaza del estilo OWASP Top 10, conviene pensarla siempre con este esquema:

  1. Qué supone el sistema para que ese riesgo exista.
  2. Qué controla el atacante.
  3. Qué valida o no valida la aplicación.
  4. Qué impacto técnico puede obtenerse.
  5. Qué impacto de negocio produce ese resultado.

Este enfoque evita memorizar la categoría como un nombre y obliga a comprender el mecanismo real de explotación.

3.19 Ejemplo integrado: portal de clientes

Imaginemos un portal donde los clientes inician sesión, consultan facturas, cambian datos personales y descargan documentos. En ese solo sistema podrían convivir varias amenazas:

  • Control de acceso roto si un cliente cambia el identificador de una factura y ve la de otro.
  • XSS si el sistema refleja entradas sin escape en mensajes o búsquedas.
  • CSRF si permite cambiar email o contraseña sin protección adicional.
  • Autenticación débil si no limita intentos o revela cuentas existentes.
  • Configuración insegura si expone trazas de error en producción.
  • Dependencias vulnerables si el framework usado tiene fallas conocidas sin parchear.

Este ejemplo muestra que OWASP Top 10 no describe problemas aislados. Describe familias de riesgos que suelen combinarse en una misma aplicación.

3.20 Errores frecuentes al estudiar OWASP Top 10

  • Creer que es un checklist completo y suficiente.
  • Tomarlo como una lista de herramientas en lugar de categorías de riesgo.
  • Memorizar nombres sin entender mecanismos de explotación.
  • Asumir que si una aplicación usa framework moderno ya está protegida.
  • Ignorar la lógica de negocio por concentrarse solo en fallas técnicas clásicas.
OWASP Top 10 es muy útil como mapa. El error es confundir el mapa con el territorio completo de la aplicación real.

3.21 Qué debes recordar de este tema

  • Las amenazas web se repiten porque muchas aplicaciones comparten patrones y errores similares.
  • OWASP Top 10 ayuda a organizar y priorizar riesgos frecuentes, pero no reemplaza el análisis específico del sistema.
  • Control de acceso roto, autenticación débil, inyección, XSS, configuración insegura y dependencias vulnerables son riesgos especialmente relevantes.
  • El impacto real de una vulnerabilidad depende de qué datos, funciones o privilegios afecta.
  • Entender el mecanismo de cada categoría es más importante que memorizar su nombre.

3.22 Conclusión

Las principales amenazas web no son una colección de conceptos abstractos, sino patrones de fallo que aparecen repetidamente en sistemas reales. Conocerlos permite revisar mejor una aplicación, diseñar controles más sólidos y detectar antes las debilidades que suelen pasar desapercibidas.

En el próximo tema entraremos en una de las bases prácticas de casi toda defensa web: validación de entradas, sanitización y manejo seguro de datos.