16. XSS, CSRF, SSRF, deserialización insegura y fallas de control de acceso

16.1 Introducción

En el tema anterior vimos inyecciones, donde una entrada se interpreta como instrucción. En este tema estudiaremos otras familias críticas de vulnerabilidades web: XSS, CSRF, SSRF, deserialización insegura y fallas de control de acceso.

Estas fallas pueden permitir ejecución de JavaScript en navegador, acciones involuntarias, acceso a redes internas desde el servidor, manipulación de objetos o acceso indebido a funciones y datos.

La validación debe realizarse con cuentas de laboratorio, endpoints controlados y evidencia mínima, evitando afectar usuarios reales, servicios internos no autorizados o datos sensibles.

16.2 Relación entre estas vulnerabilidades

Aunque son categorías distintas, comparten una causa común: confianza indebida. La aplicación confía en datos, estados, orígenes o permisos que pueden ser manipulados.

16.3 Cross-Site Scripting

XSS ocurre cuando una aplicación permite que contenido controlado por el usuario se ejecute como JavaScript en el navegador. Su severidad depende de dónde se ejecuta, quién lo ve y qué puede hacer la sesión afectada.

Impactos posibles:

• Ejecutar acciones en nombre del usuario.
• Modificar contenido de la página.
• Capturar datos mostrados en pantalla.
• Abusar de APIs accesibles desde el navegador.
• Redirigir a flujos engañosos.
• Afectar cuentas privilegiadas si el payload es almacenado.

16.4 Tipos de XSS

16.5 Validación segura de XSS

La validación debe confirmar ejecución en el contexto vulnerable sin capturar información sensible ni afectar usuarios reales.

• Usar cuentas de laboratorio.
• Probar en campos y flujos autorizados.
• Usar payloads inocuos que muestren un marcador de prueba.
• Evitar captura de cookies, tokens o datos personales.
• Limpiar contenido almacenado después de la prueba.
• Registrar URL, parámetro, contexto de salida y rol afectado.
• Evaluar si CSP, HttpOnly y SameSite reducen impacto.

16.6 Prevención de XSS

La prevención depende del contexto de salida. No se escapa igual contenido dentro de HTML, atributo, JavaScript, CSS o URL.

• Escapar salida según contexto.
• Usar plantillas y frameworks de forma segura.
• Validar y normalizar entradas.
• Evitar insertar HTML no confiable.
• Sanitizar contenido rico con librerías confiables.
• Aplicar Content Security Policy como capa adicional.
• Usar cookies HttpOnly y Secure para reducir impacto.

16.7 Cross-Site Request Forgery

CSRF ocurre cuando una aplicación permite que un sitio externo fuerce al navegador de un usuario autenticado a ejecutar una acción. El navegador envía automáticamente cookies, por lo que la aplicación puede creer que la acción fue intencional.

Es especialmente relevante en acciones con cambio de estado:

• Cambiar correo o contraseña.
• Crear, modificar o eliminar registros.
• Enviar formularios administrativos.
• Activar integraciones.
• Realizar transferencias, compras o aprobaciones.

16.8 Validación segura de CSRF

La validación debe usar cuentas y recursos de laboratorio. No se debe inducir a usuarios reales ni ejecutar acciones irreversibles.

• Identificar una acción con cambio de estado.
• Comprobar si existe token CSRF impredecible.
• Verificar si el token está ligado a sesión y acción.
• Revisar SameSite en cookies.
• Probar con una acción reversible de laboratorio.
• Confirmar si requiere reautenticación o MFA.
• Documentar petición, ausencia de control e impacto.

16.9 Prevención de CSRF

• Tokens CSRF únicos, impredecibles y validados en servidor.
• Cookies con SameSite adecuado.
• Validación de Origin o Referer como capa adicional.
• Reautenticación para acciones sensibles.
• No usar GET para acciones con cambio de estado.
• Separar APIs con tokens explícitos en cabeceras cuando aplique.

16.10 Server-Side Request Forgery

SSRF ocurre cuando una aplicación permite que el servidor realice solicitudes hacia destinos influenciados por el usuario. El riesgo aumenta porque el servidor puede alcanzar redes internas, servicios cloud o endpoints que el usuario externo no ve.

Superficies frecuentes:

• Importar imágenes por URL.
• Webhooks configurables.
• Generadores de PDF o capturas.
• Validadores de URL.
• Integraciones con almacenamiento remoto.
• Procesamiento de XML o documentos con referencias externas.

16.11 Validación segura de SSRF

La validación segura debe confirmar que el servidor realiza una solicitud controlada sin escanear redes internas ni consultar metadatos sensibles sin autorización.

• Usar un endpoint controlado por el equipo evaluador.
• Registrar si llega la solicitud y desde qué origen.
• Evitar probar rangos internos no autorizados.
• No consultar endpoints cloud de metadatos salvo permiso explícito.
• Probar restricciones de esquema, host y red de forma gradual.
• Documentar cabeceras, método y comportamiento observado.

16.12 Prevención de SSRF

16.13 Deserialización insegura

La serialización convierte objetos en un formato que puede almacenarse o transmitirse. La deserialización reconstruye esos objetos. Si la aplicación deserializa datos no confiables, un atacante puede alterar estado, tipos, propiedades o incluso provocar ejecución de código según el lenguaje y librerías.

Puede aparecer en:

• Cookies o tokens con objetos serializados.
• Parámetros ocultos.
• Colas de mensajes.
• APIs internas.
• Archivos importados.
• Sesiones almacenadas en cliente.

16.14 Señales de deserialización insegura

• Datos codificados que cambian comportamiento al modificarse.
• Errores que mencionan clases, objetos o serialización.
• Cookies largas con estructuras reconocibles.
• Firmas ausentes o no verificadas.
• Objetos que contienen roles, precios, permisos o estados.
• Uso de formatos nativos de lenguaje para datos no confiables.

16.15 Validación segura de deserialización

La validación debe empezar por cambios inocuos que demuestren confianza indebida, no por payloads agresivos.

• Modificar un campo no sensible en datos de prueba.
• Observar si el servidor acepta valores alterados.
• Comprobar si existe firma o integridad.
• Evitar gadgets o payloads de ejecución sin autorización explícita.
• No manipular roles o privilegios en cuentas reales.
• Documentar formato, campo, cambio y resultado.

16.16 Prevención de deserialización insegura

• No deserializar datos no confiables en formatos nativos peligrosos.
• Usar formatos simples y validables, como JSON con esquema estricto.
• Firmar y verificar integridad de datos del lado cliente.
• No confiar en roles, precios o permisos enviados por el cliente.
• Aplicar listas permitidas de tipos cuando la deserialización sea inevitable.
• Ejecutar con privilegios mínimos.
• Actualizar librerías con historial de gadgets conocidos.

16.17 Fallas de control de acceso

Las fallas de control de acceso permiten que un usuario acceda a datos o funciones que no le corresponden. Suelen ser críticas porque afectan directamente confidencialidad e integridad.

Tipos comunes:

• Vertical: usuario común accede a función de administrador.
• Horizontal: usuario accede a datos de otro usuario del mismo nivel.
• Por objeto: manipulación de IDs permite acceso a recursos ajenos.
• Por función: endpoint oculto ejecuta acción sin validar rol.
• Por estado: acción permitida en una etapa incorrecta del flujo.

16.18 IDOR y BOLA

IDOR, Insecure Direct Object Reference, ocurre cuando una aplicación expone referencias directas a objetos y no valida correctamente si el usuario puede acceder a ellos. En APIs se habla con frecuencia de BOLA, Broken Object Level Authorization.

16.19 Validación segura de control de acceso

La prueba debe usar usuarios y recursos creados para el pentest. No se debe acceder a datos reales de clientes o empleados para demostrar el hallazgo.

• Crear o solicitar cuentas de prueba con roles distintos.
• Crear recursos controlados para cada cuenta.
• Capturar peticiones legítimas.
• Cambiar identificadores o roles de forma controlada.
• Comparar respuestas y permisos reales.
• Registrar impacto sin exponer datos sensibles.
• Detenerse al confirmar acceso indebido.

16.20 Prevención de fallas de autorización

• Validar autorización del lado servidor en cada operación.
• No confiar en controles de interfaz o botones ocultos.
• Implementar políticas centralizadas y consistentes.
• Verificar propiedad del objeto antes de leer, modificar o borrar.
• Usar pruebas automatizadas por rol y por objeto.
• Negar por defecto cuando no exista regla explícita.
• Registrar intentos de acceso indebido.

16.21 Encadenamiento de vulnerabilidades

Estas vulnerabilidades pueden encadenarse. Un XSS puede ejecutar acciones que se parecen a CSRF. Un SSRF puede acceder a endpoints internos que exponen objetos serializados. Un IDOR puede exponer datos que facilitan otra explotación.

• XSS almacenado en panel admin más sesión privilegiada.
• SSRF hacia metadatos cloud más credenciales temporales.
• IDOR que expone token usado en API interna.
• Deserialización que permite modificar rol más control de acceso débil.
• CSRF sobre acción administrativa sin reautenticación.

La severidad final debe considerar la cadena completa, no solo cada hallazgo aislado.

16.22 Evidencia y reporte

La evidencia debe mostrar la vulnerabilidad, el contexto y el impacto sin dañar usuarios ni exponer datos reales.

16.23 Errores frecuentes

• Validar XSS robando cookies o datos reales.
• Probar CSRF sobre acciones irreversibles.
• Usar SSRF para escanear redes internas sin autorización.
• Empezar deserialización con payloads de ejecución de código.
• Probar control de acceso con recursos de usuarios reales.
• Confiar en que ocultar botones equivale a autorización.
• No probar APIs porque la interfaz web no muestra la función.
• No limpiar payloads almacenados después de la prueba.

16.24 Flujo práctico de pruebas

Un flujo responsable para estas vulnerabilidades puede ser:

1. Mapear flujos, roles, recursos y endpoints.
2. Preparar cuentas y datos de laboratorio.
3. Probar salidas controladas para XSS.
4. Revisar acciones sensibles para CSRF.
5. Validar SSRF solo contra endpoints propios o autorizados.
6. Analizar objetos serializados con cambios inocuos.
7. Comparar autorización entre roles y propietarios.
8. Recolectar evidencia mínima.
9. Limpiar payloads y recursos de prueba.
10. Priorizar hallazgos por impacto real y posibilidad de encadenamiento.

16.25 Qué debes recordar de este tema

• XSS ejecuta código en el navegador y debe validarse con payloads inocuos.
• CSRF abusa de sesiones autenticadas para ejecutar acciones involuntarias.
• SSRF convierte al servidor en origen de solicitudes y puede exponer redes internas.
• La deserialización insegura aparece cuando el servidor confía en objetos manipulables.
• El control de acceso debe verificarse en servidor para cada objeto y función.
• La evidencia debe usar cuentas y datos de prueba, no información real de terceros.

16.26 Conclusión

XSS, CSRF, SSRF, deserialización insegura y fallas de control de acceso muestran que la seguridad web depende de validar contexto, permisos, origen y datos en cada operación. Muchas de estas fallas requieren análisis manual y comprensión del flujo de negocio.

En el próximo tema profundizaremos en pruebas de autenticación, sesiones, MFA y gestión de credenciales, áreas centrales para proteger el acceso a aplicaciones y servicios.