Tema 13
Muchas vulnerabilidades web no comprometen directamente al servidor en primer lugar, sino al navegador de la víctima. Cuando una aplicación permite ejecutar código no previsto en el cliente o abusar de la confianza que el navegador ya tiene en un sitio, el atacante puede robar sesiones, manipular acciones, alterar la interfaz o utilizar al usuario autenticado como canal de ataque.
Hasta ahora vimos varias categorías que afectan sobre todo al servidor, al diseño o a la infraestructura. En este tema nos enfocaremos en vulnerabilidades donde el navegador de la víctima pasa a ser un actor clave del ataque. El hecho de que una persona visite una página, tenga una sesión activa o confíe en una interfaz puede convertirse en la base del compromiso.
El navegador no es un simple visor pasivo. Ejecuta JavaScript, almacena cookies, interpreta HTML, sigue redirecciones, envía automáticamente credenciales a ciertos orígenes y mantiene relaciones de confianza con los sitios donde el usuario inició sesión. Si la aplicación no controla adecuadamente qué código se ejecuta o qué solicitudes pueden inducirse desde ese contexto, el impacto puede ser severo.
Las dos categorías principales que abordaremos aquí son XSS y CSRF, además de algunas ideas más amplias sobre vulnerabilidades del lado cliente y del navegador.
Cuando el usuario interactúa con una aplicación web, el navegador se convierte en un entorno de ejecución y almacenamiento con mucho valor para un atacante. Allí pueden vivir:
Por eso una vulnerabilidad del lado cliente no debe subestimarse. Aunque no comprometa directamente el servidor, puede permitir secuestro de sesión, robo de información, fraude o abuso del contexto autenticado de la víctima.
XSS ocurre cuando la aplicación permite que contenido controlado por un atacante sea interpretado por el navegador como código activo dentro del contexto del sitio vulnerable. En lugar de tratar ese contenido como texto o dato, el navegador lo ejecuta o lo incorpora al DOM con privilegios del origen legítimo.
Esto le da al atacante una ventaja poderosa: su código corre como si perteneciera al sitio confiable desde la perspectiva del navegador.
Una explotación XSS puede tener consecuencias muy diversas según el contexto de la aplicación y lo que la víctima tenga abierto o autenticado.
En cuentas privilegiadas, el impacto puede ser especialmente severo.
El XSS reflejado ocurre cuando la carga maliciosa enviada por el atacante vuelve en la respuesta inmediata de la aplicación y es interpretada por el navegador. Suele aparecer en parámetros de búsqueda, mensajes, filtros o páginas de error que reflejan entrada sin escape adecuado.
Este tipo de XSS generalmente requiere que la víctima visite una URL o interacción preparada por el atacante, pero sigue siendo peligroso porque puede usarse en campañas dirigidas o combinadas con ingeniería social.
El XSS almacenado ocurre cuando el contenido malicioso se guarda en la aplicación y luego se entrega a otros usuarios. Puede aparecer en comentarios, perfiles, mensajes, publicaciones, tickets de soporte, campos administrativos o cualquier dato persistente que luego se renderice sin protección adecuada.
Este tipo de XSS suele ser más grave porque no depende de una URL puntual: la carga queda alojada en la propia aplicación y afecta a quienes acceden luego al contenido.
En el XSS basado en DOM, el problema aparece del lado cliente cuando JavaScript manipula valores no confiables y los inserta en el documento de forma insegura. En estos casos, la respuesta del servidor puede ser relativamente "limpia", pero el código del navegador termina construyendo un DOM vulnerable a partir de datos controlados por el usuario o por la URL.
Este escenario es especialmente relevante en aplicaciones con mucho JavaScript, SPA y lógica cliente compleja.
La persistencia de XSS se explica por varios factores:
Una de las ideas más importantes para prevenir XSS es entender que la salida debe tratarse según el contexto donde se inserta. No es lo mismo mostrar texto en HTML que incrustarlo en JavaScript, en atributos, en URLs o en estilos.
El error frecuente es aplicar una única "limpieza genérica" y asumir que eso resuelve todo. En realidad, la protección correcta depende del lugar exacto donde el dato será interpretado por el navegador.
Estos tres conceptos suelen confundirse:
Para XSS, el encoding de salida correcto suele ser la defensa central, complementado por sanitización estricta cuando el negocio necesita aceptar contenido enriquecido.
Content Security Policy, CSP, ayuda a restringir qué scripts y recursos puede ejecutar el navegador. No reemplaza una codificación segura, pero sí agrega una capa importante para reducir impacto de ciertos escenarios XSS.
Su valor está en:
Una CSP mal diseñada o demasiado permisiva aporta poco. Su efectividad depende de implementación coherente con la aplicación real.
CSRF, Cross-Site Request Forgery, ocurre cuando una aplicación permite que un sitio o contenido externo induzca al navegador de una víctima autenticada a enviar una solicitud no deseada al sitio legítimo. La clave aquí es que el navegador, al confiar en el origen donde el usuario ya tiene sesión, puede enviar automáticamente cookies u otras credenciales asociadas.
En este caso, el atacante no necesita robar la sesión; le alcanza con aprovechar que el navegador de la víctima ya la tiene activa.
La secuencia típica es:
CSRF es especialmente grave en acciones que cambian estado o producen efectos de negocio.
Si la aplicación acepta estas acciones confiando solo en la presencia de la sesión, sin otra señal de legitimidad, el riesgo aumenta mucho.
| Vulnerabilidad | Idea central |
|---|---|
| XSS | El atacante logra ejecutar o inyectar código en el contexto del sitio |
| CSRF | El atacante induce al navegador a enviar acciones autenticadas no deseadas |
Aunque son distintas, se potencian entre sí. Una XSS puede hacer trivial explotar acciones CSRF o directamente saltar defensas adicionales del lado cliente.
La defensa clásica contra CSRF consiste en asegurar que las solicitudes sensibles incluyan una prueba adicional de legitimidad que un tercero no pueda inducir fácilmente desde otro origen.
Medidas habituales:
SameSite en cookies.Origin o Referer cuando corresponda.Una idea útil para este tema es que el navegador no es confiable, pero sí mantiene ciertos comportamientos automáticos de confianza entre usuario y sitio. Las cookies se envían, el DOM se interpreta, los scripts se ejecutan según origen y las sesiones persisten. Los ataques del lado cliente intentan precisamente abusar de esos comportamientos.
Por eso la defensa no debe basarse en asumir que el navegador "hará lo correcto", sino en delimitar qué contenido puede ejecutar y qué solicitudes deben considerarse legítimas.
Además de XSS y CSRF, el ecosistema cliente puede verse afectado por otras debilidades o malas prácticas:
La defensa frente a vulnerabilidades del navegador exige combinar varias capas.
Estas fallas se combinan con varias de las categorías anteriores.
Esto muestra que el navegador no es una capa aislada: es un punto de encuentro entre múltiples decisiones de seguridad.
XSS, CSRF y otras vulnerabilidades del navegador muestran que la seguridad web no se limita al backend. El cliente, la sesión y la interfaz también forman parte del sistema de confianza. Si la aplicación permite ejecutar código no previsto o inducir acciones autenticadas sin legitimidad suficiente, el atacante puede convertir al propio usuario en vector de compromiso.
En el próximo tema estudiaremos la subida de archivos, la deserialización insegura aplicada en escenarios prácticos y la ejecución remota, tres áreas donde una entrada aparentemente inocente puede transformarse en ejecución o control sobre el entorno.