22. Explotación web y de servicios: inyección, deserialización y fallas de autenticación

22.1 Introducción

Las aplicaciones web, APIs y servicios de red son objetivos frecuentes porque procesan datos externos, autentican usuarios, administran permisos y conectan con bases de datos, colas, archivos y sistemas internos.

Una vulnerabilidad web no siempre implica ejecución de código. Puede permitir leer datos, modificar registros, actuar como otro usuario, saltar controles, provocar indisponibilidad o encadenarse con otras fallas.

Este tema estudia categorías comunes desde una mirada educativa y defensiva. Las pruebas deben realizarse solo en laboratorios, entornos propios o sistemas con autorización explícita.

22.2 Superficie web y de servicios

La superficie incluye todo punto donde un cliente o sistema externo puede enviar datos o activar comportamiento.

• Formularios, parámetros y rutas.
• Cabeceras, cookies y tokens.
• APIs REST, GraphQL, gRPC o SOAP.
• Subidas de archivos y parsers.
• Webhooks y callbacks.
• Servicios TCP/UDP propios o de terceros.
• Paneles administrativos y endpoints internos expuestos.

22.3 Inyección

Una inyección ocurre cuando datos del usuario se interpretan como instrucciones, comandos, consultas o expresiones dentro de otro contexto. La raíz del problema suele ser mezclar datos y lógica ejecutable.

22.4 Señales defensivas de inyección

La detección defensiva debe observar entradas anómalas, errores, cambios de comportamiento y eventos posteriores.

• Errores de base de datos o parser expuestos al usuario.
• Parámetros con caracteres de control inesperados.
• Consultas con tiempos anómalos o patrones repetitivos.
• Procesos del sistema iniciados por servicios web.
• Respuestas con volumen o estructura no esperada.
• Uso de cuentas de base de datos con permisos excesivos.

22.5 Cross-Site Scripting

XSS aparece cuando una aplicación permite que datos no confiables se interpreten como código en el navegador de otro usuario. Afecta sesiones, acciones de usuario y confianza en la interfaz.

Tipos comunes:

• Reflejado: la entrada vuelve en la respuesta inmediata.
• Almacenado: el contenido queda persistido y afecta a otros usuarios.
• DOM-based: el problema ocurre en lógica del cliente.

La mitigación combina codificación de salida por contexto, validación, Content Security Policy, cookies protegidas y revisión de uso de datos en el cliente.

22.6 Deserialización insegura

La deserialización transforma datos en objetos. Si una aplicación acepta datos serializados no confiables, puede reconstruir objetos manipulados, alterar lógica o activar comportamientos no previstos.

Riesgos:

• Manipulación de estado interno.
• Abuso de tipos o clases disponibles.
• Bypass de validaciones posteriores.
• Ejecución de lógica durante construcción o destrucción de objetos.
• Lectura o modificación de datos fuera del flujo esperado.

22.7 Mitigación de deserialización

La defensa debe evitar deserializar datos no confiables o reducir drásticamente lo que se acepta.

• No aceptar objetos arbitrarios desde clientes.
• Usar formatos simples de datos cuando sea posible.
• Permitir solo tipos esperados.
• Firmar y verificar integridad de datos serializados.
• Validar antes de usar el objeto para decisiones sensibles.
• Ejecutar parsers con permisos mínimos y monitoreo.

22.8 Autenticación

La autenticación verifica identidad. Las fallas en autenticación permiten ingreso indebido, toma de cuentas o abuso de sesiones.

22.9 Autorización

La autorización decide qué puede hacer una identidad autenticada. Muchas brechas ocurren porque una aplicación verifica identidad, pero no permisos en cada acción.

Fallas típicas:

• Acceso a objetos por ID sin verificar propietario.
• Endpoints administrativos ocultos pero no protegidos.
• Roles aplicados solo en frontend.
• Permisos heredados o excesivos.
• APIs que confían en parámetros enviados por el cliente.

La autorización debe verificarse del lado del servidor en cada operación sensible.

22.10 IDOR y BOLA

IDOR, o Insecure Direct Object Reference, y BOLA, Broken Object Level Authorization, describen fallas donde un usuario puede acceder a objetos que no le pertenecen modificando identificadores o rutas.

Desde la defensa, se valida que:

• Cada acceso a objeto compruebe relación con usuario, rol o tenant.
• Los IDs no sean considerados secretos.
• Las APIs no devuelvan datos de otros usuarios.
• Las operaciones de escritura tengan controles más estrictos que lectura.
• Los logs registren intentos de acceso cruzado.

22.11 Fallas de sesión

Una sesión representa continuidad de identidad entre solicitudes. Si se maneja mal, un actor puede reutilizar, fijar, robar o prolongar sesiones indebidamente.

• Cookies sin Secure, HttpOnly o SameSite adecuados.
• Tokens largos sin expiración o revocación.
• No rotar sesión después de login o cambio de privilegio.
• Guardar tokens en lugares accesibles por scripts.
• No invalidar sesiones al cambiar contraseña o cerrar sesión.

22.12 SSRF

SSRF ocurre cuando una aplicación del servidor realiza solicitudes a destinos controlados por el usuario. Puede afectar redes internas, metadatos de nube o servicios no expuestos públicamente.

Mitigaciones:

• Usar allowlists estrictas de destinos.
• Bloquear rangos internos y direcciones especiales cuando no sean necesarias.
• Validar después de redirecciones y resolución DNS.
• Separar servicios que realizan fetch de redes sensibles.
• Registrar destino final y respuestas anómalas.

22.13 Subida de archivos

Las funciones de subida de archivos combinan parsers, almacenamiento, permisos y exposición. Un control débil puede permitir ejecución, exposición de datos o denegación de servicio.

• Validar tipo real y no solo extensión.
• Guardar fuera del directorio ejecutable.
• Renombrar archivos y controlar permisos.
• Limitar tamaño, cantidad y formatos.
• Procesar archivos en sandbox si hay parsers complejos.
• Evitar servir contenido con tipos peligrosos.

22.14 Servicios de red

Los servicios TCP/UDP propios o de terceros pueden tener fallas de parsing, autenticación, autorización o configuración. A diferencia de una aplicación web, a veces usan protocolos binarios o clientes especializados.

Aspectos defensivos:

• Reducir exposición a redes necesarias.
• Autenticar antes de operaciones sensibles.
• Validar tamaños y estados de protocolo.
• Registrar errores, timeouts y conexiones anómalas.
• Aplicar parches y versiones soportadas.
• Ejecutar servicios con permisos mínimos.

22.15 APIs

Las APIs exponen funciones para aplicaciones, móviles, terceros o servicios internos. Sus fallas suelen estar en autorización, validación, rate limiting, exposición excesiva de datos o confianza en el cliente.

22.16 Registro y monitoreo

Sin logs adecuados, una explotación web puede pasar inadvertida o ser difícil de reconstruir. Los logs deben permitir investigar sin exponer secretos.

• Autenticaciones exitosas y fallidas.
• Cambios de privilegios y configuración.
• Accesos a objetos sensibles.
• Errores de validación y excepciones.
• Uso de endpoints administrativos.
• Volumen anómalo de solicitudes.
• Correlación con usuario, IP, sesión y request ID.

22.17 Pruebas controladas

Las pruebas deben validar impacto sin dañar sistemas ni datos. En web y servicios, esto implica usar cuentas de prueba, datos sintéticos y entornos autorizados.

1. Confirmar alcance y permiso.
2. Preparar usuario y datos de prueba.
3. Definir hipótesis de vulnerabilidad.
4. Enviar entrada mínima para confirmar comportamiento.
5. Registrar solicitud, respuesta y evidencia.
6. Evitar extracción de datos reales.
7. Validar corrección luego del cambio.

22.18 Evidencia para reportes

Un reporte debe incluir evidencia suficiente y segura.

• Endpoint o servicio afectado.
• Rol o contexto de usuario usado.
• Condición que activa el fallo.
• Solicitud y respuesta minimizadas.
• Impacto demostrado con datos de prueba.
• Logs o request IDs asociados.
• Recomendación de mitigación.

22.19 Mitigaciones transversales

Muchas fallas web comparten controles defensivos.

• Validación y normalización de entrada.
• Codificación de salida por contexto.
• Consultas parametrizadas y APIs seguras.
• Autorización centralizada del lado servidor.
• MFA, protección de sesiones y rate limiting.
• Mínimo privilegio para cuentas y servicios.
• Logs, alertas y pruebas de regresión.

22.20 Detecciones defensivas

Las detecciones deben buscar señales de abuso con contexto suficiente para evitar ruido.

• Errores repetidos en endpoints sensibles.
• Acceso a muchos objetos secuenciales por el mismo usuario.
• Inicio de sesión desde ubicación o dispositivo inusual.
• Cambios de privilegio seguidos de acciones críticas.
• Servicios web iniciando procesos del sistema.
• Subidas de archivos rechazadas por tipo o tamaño.
• Solicitudes internas iniciadas por funcionalidad de fetch.

22.21 Checklist de revisión

1. Identificar entradas y operaciones sensibles.
2. Verificar validación, normalización y codificación.
3. Revisar autenticación, sesiones y recuperación de cuenta.
4. Comprobar autorización por objeto y acción.
5. Evaluar parsers, subidas y deserialización.
6. Revisar exposición de servicios y APIs.
7. Confirmar logging, monitoreo y alertas.
8. Documentar impacto con datos de prueba.
9. Validar correcciones con pruebas de regresión.

22.22 Errores frecuentes

• Probar sistemas reales sin alcance autorizado.
• Confiar en validaciones del lado cliente.
• Usar datos reales para demostrar acceso indebido.
• Corregir solo un parámetro y dejar otros endpoints vulnerables.
• Ignorar autorización porque la autenticación funciona.
• No revisar logs luego de una prueba.
• Tratar servicios internos como seguros solo por no estar publicados.

22.23 Qué debes recordar de este tema

• Las vulnerabilidades web suelen surgir de entradas no confiables, autorización incompleta o lógica insegura.
• Inyección ocurre cuando datos se interpretan como instrucciones en otro contexto.
• Autenticación y autorización son controles distintos y ambos deben verificarse en servidor.
• Las pruebas responsables usan datos sintéticos y demuestran impacto mínimo suficiente.
• Mitigación, logging y pruebas de regresión son parte del cierre real del hallazgo.

22.24 Conclusión

La explotación web y de servicios abarca más que payloads técnicos: implica entradas, sesiones, permisos, datos y flujos de negocio. Evaluarla bien requiere comprender contexto e impacto.

En el próximo tema veremos respuesta a incidentes con malware: contención, erradicación, recuperación y lecciones aprendidas, conectando análisis técnico con operación defensiva.