Tema 12

Vulnerabilidades en aplicaciones web: inyección, XSS, CSRF y fallas de autenticación

Las aplicaciones web concentran procesos de negocio, identidades, datos y exposición a Internet. Esta unidad estudia algunas de las fallas más representativas de ese entorno y por qué siguen apareciendo en sistemas reales.

Objetivo Entender fallas típicas de aplicaciones web
Enfoque Entrada, sesión, autorización e interacción
Resultado Reconocer riesgos de diseño e implementación
Clave Internet convierte errores pequeños en exposición masiva

12.1 Introducción

Las aplicaciones web son uno de los objetivos más atractivos para un atacante porque suelen estar expuestas a Internet, procesan datos valiosos y conectan múltiples componentes: usuarios, bases de datos, APIs, sistemas internos y terceros. Una falla en esta capa puede traducirse rápidamente en robo de información, toma de cuentas, fraude o compromiso más amplio del entorno.

Muchas vulnerabilidades web nacen de un problema recurrente: la aplicación recibe datos del usuario, toma decisiones basadas en esos datos y no valida o protege correctamente el flujo completo. Otras veces la falla aparece en la gestión de autenticación, sesiones o permisos.

12.2 Qué hace especialmente expuestas a las aplicaciones web

  • Están accesibles desde redes públicas o por grandes volúmenes de usuarios.
  • Reciben entradas constantes desde formularios, parámetros, cookies, APIs y archivos.
  • Se integran con bases de datos y servicios internos.
  • Operan sobre identidades, sesiones y permisos.
  • Su lógica suele cambiar con frecuencia por necesidades de negocio.
Una aplicación web no es solo “una página”. Es un punto de encuentro entre entrada no confiable, lógica de negocio, autenticación, datos y exposición permanente.

12.3 Inyección

La inyección ocurre cuando la aplicación incorpora datos controlados por un usuario dentro de una instrucción, consulta o comando, sin separación o validación adecuada. El atacante consigue que su entrada sea interpretada como parte de la lógica interna, en lugar de ser tratada como dato puro.

El problema de fondo es la mezcla insegura entre datos de entrada y comandos ejecutables o interpretables por otro componente.

12.4 Inyección SQL

La inyección SQL es una de las variantes más conocidas. Aparece cuando una aplicación construye consultas a bases de datos usando entradas del usuario de manera insegura. Si esas entradas alteran la estructura de la consulta, el atacante puede leer, modificar o borrar datos, o incluso interferir con autenticación y lógica de aplicación.

Su impacto depende del contexto y de los privilegios con los que la aplicación accede a la base de datos, pero puede ser extremadamente severo.

  • Lectura de datos sensibles.
  • Modificación o destrucción de registros.
  • Bypass de autenticación.
  • Enumeración de estructura de base de datos.

12.5 Otras formas de inyección

Aunque SQL es la más conocida, la misma lógica se repite en otros contextos:

  • Inyección de comandos del sistema.
  • Inyección en consultas a directorios o servicios externos.
  • Inyección en lenguajes de plantillas o expresiones.
  • Inyección en motores de búsqueda o parsing interno.

La idea es siempre la misma: una entrada controlada por el atacante pasa a influir indebidamente sobre una instrucción que el sistema interpreta.

12.6 Qué habilita una inyección

Para que exista esta vulnerabilidad suelen combinarse varias condiciones:

  • Entradas del usuario sin validación robusta.
  • Construcción manual de consultas o comandos.
  • Ausencia de separación entre dato y lógica.
  • Permisos excesivos del componente afectado.

Esto muestra que no se trata solo de un problema de sintaxis, sino de diseño y control de confianza entre capas.

12.7 XSS

Cross-Site Scripting o XSS ocurre cuando una aplicación web permite que contenido controlado por un atacante se ejecute como script en el navegador de otra víctima. En lugar de atacar directamente al servidor, el atacante aprovecha la confianza que el navegador deposita en el sitio legítimo.

Esto puede permitir robo de sesiones, manipulación de interfaz, redirecciones, captura de datos y acciones en nombre del usuario.

12.8 Cómo funciona conceptualmente XSS

La aplicación recibe un contenido que debería tratar como dato, pero termina devolviéndolo al navegador en un contexto ejecutable o peligroso. Si el navegador interpreta ese contenido como script, el atacante obtiene una capacidad de ejecución dentro de la sesión de la víctima.

El problema surge de no controlar adecuadamente cómo se muestra, escapa o inserta el contenido en HTML, atributos, scripts o componentes dinámicos.

12.9 Tipos habituales de XSS

Tipo Descripción Ejemplo conceptual
Reflejado El payload vuelve inmediatamente en la respuesta Parámetro malicioso en una búsqueda o error
Almacenado El payload queda guardado y afecta a múltiples víctimas Comentario o perfil visible para otros usuarios
Basado en DOM La vulnerabilidad ocurre en manipulación del lado del navegador Script cliente que inserta datos inseguros en la página

12.10 Impacto de XSS

  • Robo de cookies o tokens si las protecciones son insuficientes.
  • Secuestro de sesión.
  • Captura de datos ingresados por la víctima.
  • Alteración visual o funcional de la aplicación.
  • Redirección a sitios maliciosos.
  • Abuso de confianza de la aplicación frente al usuario.

El verdadero alcance depende de qué puede hacer el script en el contexto del navegador y de qué controles adicionales existan.

12.11 CSRF

Cross-Site Request Forgery o CSRF consiste en inducir al navegador de una víctima autenticada a enviar una solicitud no deseada a una aplicación en la que ya tiene una sesión válida. El servidor interpreta esa acción como legítima porque proviene del navegador autenticado.

La clave de este ataque es que el atacante no necesita robar la sesión: aprovecha la sesión ya existente para disparar acciones en nombre de la víctima.

12.12 Qué se necesita para que exista CSRF

  • La víctima debe estar autenticada en la aplicación objetivo.
  • La aplicación debe aceptar solicitudes sin protección específica contra CSRF.
  • Debe existir una acción sensible que pueda invocarse desde una solicitud forjada.

Ejemplos típicos incluyen cambios de correo, modificación de datos, ejecución de transferencias o acciones administrativas.

12.13 Diferencia entre XSS y CSRF

Aunque a veces se confunden, son vulnerabilidades distintas:

  • XSS: el atacante logra ejecutar código en el navegador dentro del contexto del sitio vulnerable.
  • CSRF: el atacante logra que el navegador autenticado envíe una acción no deseada, sin necesidad de ejecutar script en el sitio vulnerable.
XSS compromete la confianza del navegador en el contenido devuelto por el sitio. CSRF compromete la confianza del servidor en la solicitud autenticada que recibe del navegador.

12.14 Fallas de autenticación

Las fallas de autenticación aparecen cuando el proceso de verificar la identidad del usuario es débil, inconsistente o fácilmente abusado. En aplicaciones web esto puede derivar en toma de cuentas, bypass de login o acceso indebido a funcionalidades sensibles.

Estas fallas no se limitan al formulario de ingreso. También incluyen recuperación de contraseña, manejo de sesiones, recordatorios persistentes, MFA, cierre de sesión y rotación de credenciales.

12.15 Ejemplos de fallas de autenticación

  • Permitir contraseñas débiles o reutilizadas sin controles.
  • No limitar intentos fallidos de acceso.
  • Procesos de recuperación de cuenta inseguros.
  • Sesiones que no expiran adecuadamente.
  • Cookies de sesión sin atributos de protección suficientes.
  • MFA opcional o mal integrada en acciones sensibles.
  • Diferencias de comportamiento que permiten enumerar usuarios válidos.

12.16 Gestión insegura de sesiones

La sesión es lo que sostiene la identidad después del login. Si se gestiona mal, el atacante puede reaprovecharla o secuestrarla. Algunos problemas frecuentes son:

  • Tokens previsibles o demasiado persistentes.
  • No invalidar sesiones al cerrar sesión o cambiar contraseña.
  • No rotar identificadores después de autenticación o elevación de privilegio.
  • Almacenamiento inseguro de cookies o tokens.

Estas debilidades se conectan directamente con lo visto en el tema anterior sobre robo de sesiones.

12.17 Autorización rota y control de acceso insuficiente

Aunque el título de este tema pone foco en autenticación, es importante distinguirla de autorización. Autenticación responde “quién sos”; autorización responde “qué podés hacer”. Una aplicación puede autenticar bien y, aun así, permitir acceso a funciones o datos que no corresponden.

Cuando la autorización es débil, un usuario autenticado puede acceder a recursos de otros usuarios o ejecutar acciones no permitidas simplemente cambiando parámetros, rutas o identificadores.

12.18 Errores de validación y confianza en el cliente

Muchas vulnerabilidades web surgen porque la aplicación confía demasiado en lo que sucede del lado del cliente: formularios, scripts, valores ocultos o restricciones visuales. Sin embargo, cualquier dato enviado desde el cliente debe considerarse potencialmente manipulable.

  • Campos ocultos modificables.
  • Validaciones solo en JavaScript.
  • Controles visuales tratados como si fueran controles de seguridad reales.
  • Suposiciones sobre el origen o formato de los datos.

12.19 Impacto de las vulnerabilidades web

Vulnerabilidad Impacto posible
Inyección Lectura, modificación o destrucción de datos; bypass de lógica
XSS Robo de sesión, captura de datos, manipulación de interfaz
CSRF Acciones no deseadas ejecutadas con la sesión de la víctima
Fallas de autenticación Toma de cuentas, acceso indebido y persistencia no autorizada
Autorización insuficiente Acceso a recursos o funciones fuera de permiso

12.20 Prevención de inyección

  • Separar datos y lógica mediante mecanismos seguros de consulta o ejecución.
  • Validar entradas según contexto y necesidad.
  • Evitar construcción manual insegura de comandos o consultas.
  • Aplicar mínimo privilegio en las cuentas usadas por la aplicación.
  • Registrar y monitorear errores sin exponer detalles sensibles.

12.21 Prevención de XSS y CSRF

Para XSS, el foco está en cómo se procesa y representa el contenido. Para CSRF, el foco está en validar la legitimidad de la solicitud.

  • Escapar y codificar salida según contexto.
  • Restringir inserción insegura de contenido dinámico.
  • Aplicar políticas que limiten ejecución no prevista en navegador.
  • Usar mecanismos anti-CSRF en acciones sensibles.
  • Configurar correctamente cookies y protección de sesión.
  • Exigir reautenticación o confirmaciones en operaciones críticas.

12.22 Prevención de fallas de autenticación

  • Contraseñas robustas y políticas razonables.
  • MFA para cuentas sensibles o de alto riesgo.
  • Control de intentos fallidos y monitoreo de acceso.
  • Procesos seguros de recuperación de cuenta.
  • Sesiones bien gestionadas, revocables y de duración adecuada.
  • Separación clara entre autenticación y autorización.

12.23 Errores comunes

  • Validar solo del lado del cliente.
  • Asumir que un framework elimina por sí solo todos los riesgos.
  • Tratar cookies, parámetros o identificadores como si fueran confiables.
  • Olvidar que una cuenta autenticada aún necesita controles de autorización estrictos.
  • No revisar la seguridad de flujos menos visibles como recuperación de contraseña o cierre de sesión.

12.24 Qué debe quedar claro

  • Las aplicaciones web concentran gran parte de la superficie de ataque moderna.
  • La inyección aparece cuando los datos del usuario alteran lógica interna.
  • XSS aprovecha la confianza del navegador en el sitio vulnerable.
  • CSRF aprovecha la confianza del servidor en la sesión autenticada del navegador.
  • Las fallas de autenticación y sesión pueden convertir una cuenta en puerta de entrada al entorno.

12.25 Conclusión

Las vulnerabilidades web muestran cómo pequeños errores de validación, representación o control de acceso pueden producir impactos severos cuando una aplicación está expuesta y maneja datos críticos. Entender estos patrones permite analizar mejor riesgos reales y diseñar aplicaciones con menos puntos de ruptura.

En el próximo tema se estudiarán las vulnerabilidades en software, bibliotecas y cadena de suministro, ampliando el foco desde la aplicación visible hacia sus dependencias y componentes.