2. Funcionamiento de una aplicación web, HTTP, sesiones, cookies y superficie de ataque

2.1 Introducción

Muchas vulnerabilidades web se entienden mal porque se estudian como listas de ataques o payloads, sin comprender primero cómo funciona una aplicación web en condiciones normales. Sin esa base, es fácil memorizar nombres pero difícil razonar sobre riesgo real.

Una aplicación web es, en esencia, un sistema distribuido que intercambia mensajes entre clientes y servidores. En ese intercambio viajan rutas, parámetros, formularios, cookies, encabezados, archivos, tokens y respuestas. Cada uno de esos elementos puede ser útil para el funcionamiento y también convertirse en un vector de ataque si se maneja con confianza excesiva.

En este tema analizaremos el funcionamiento general de una aplicación web, el rol de HTTP y HTTPS, la diferencia entre autenticación y sesión, el uso de cookies, la noción de estado y la construcción de la superficie de ataque.

2.2 Qué es una aplicación web desde el punto de vista técnico

Una aplicación web es un conjunto de componentes que permiten a un usuario o sistema interactuar con información y lógica de negocio mediante protocolos web. Aunque el usuario vea solo una interfaz visual, detrás hay múltiples piezas coordinadas.

Entre los componentes más comunes se encuentran:

• Navegador o cliente HTTP.
• Servidor web o reverse proxy.
• Backend de aplicación.
• Base de datos.
• Servicios de autenticación.
• Almacenamiento de archivos.
• APIs internas o externas.
• Servicios de monitoreo, logs y caché.

Desde seguridad, cada una de estas piezas importa porque participa en el procesamiento, almacenamiento o transporte de datos que pueden ser sensibles o críticos.

2.3 El modelo cliente-servidor

La mayoría de las aplicaciones web siguen el modelo cliente-servidor. El cliente, normalmente un navegador, envía solicitudes. El servidor las recibe, las procesa y devuelve respuestas.

En apariencia este flujo es simple, pero implica varias decisiones de seguridad:

• Qué datos acepta el servidor.
• Cómo interpreta esos datos.
• Qué identidad asigna al usuario.
• Qué permisos aplica sobre cada acción.
• Qué información devuelve en cada respuesta.
• Qué evidencias registra sobre la operación.

2.4 HTTP: el protocolo base de la web

HTTP, HyperText Transfer Protocol, es el protocolo de aplicación que define cómo se intercambian solicitudes y respuestas entre clientes y servidores web. Es un protocolo textual, extensible y ampliamente adoptado.

Una solicitud HTTP suele contener:

• Un método, por ejemplo GET, POST, PUT o DELETE.
• Una ruta o recurso solicitado.
• Encabezados con metadatos.
• Parámetros en URL o cuerpo de la solicitud.
• Cookies u otros datos de contexto.

La respuesta HTTP suele incluir:

• Un código de estado, por ejemplo 200, 302, 403, 404 o 500.
• Encabezados de respuesta.
• Un cuerpo con HTML, JSON, texto, archivo u otro contenido.
• Cookies o instrucciones de caché y redirección.

Comprender HTTP es esencial porque la mayoría de los ataques web consisten, en el fondo, en manipular solicitudes, respuestas o el significado que la aplicación les asigna.

2.5 Métodos HTTP y su significado

Los métodos HTTP expresan la intención de la solicitud. Aunque en la práctica algunas aplicaciones los usan de forma desordenada, desde diseño tienen propósitos distintos.

Un error frecuente es implementar acciones críticas por GET porque resultan cómodas. Eso puede facilitar abusos, cacheos indeseados o problemas relacionados con CSRF y automatización.

2.6 Estructura de una solicitud y de una respuesta

Desde seguridad conviene imaginar cada solicitud como un paquete de información que la aplicación debe interpretar con cuidado. Nada de lo que venga en una solicitud debe considerarse verdadero por defecto.

Entre los elementos más importantes de una solicitud se encuentran:

• La URL y sus parámetros.
• El método HTTP.
• Los encabezados, como Host, User-Agent, Referer, Origin o Authorization.
• Las cookies.
• El cuerpo, por ejemplo JSON, formularios o archivos.

Del lado de la respuesta, también hay decisiones críticas:

• Qué datos se exponen al usuario.
• Qué cabeceras de seguridad se incluyen.
• Qué cookies se envían y con qué atributos.
• Qué mensajes de error se devuelven.
• Qué código de estado refleja el resultado real.

2.7 HTTP es stateless: qué significa eso

Una característica fundamental de HTTP es que, por diseño, es stateless, es decir, no mantiene estado entre una solicitud y la siguiente. El protocolo no recuerda automáticamente quién es el usuario, qué hizo antes o si ya inició sesión.

Eso obliga a las aplicaciones a construir mecanismos propios para mantener contexto entre solicitudes. Ese contexto puede incluir:

• Identidad del usuario autenticado.
• Preferencias de interfaz.
• Carrito de compras.
• Permisos o rol de la cuenta.
• Acciones en progreso.

Buena parte de la seguridad web gira alrededor de cómo se representa, protege y valida ese estado. Si el estado se maneja mal, aparecen problemas de secuestro de sesión, suplantación, acceso indebido o inconsistencia de controles.

2.8 Qué es una sesión web

Una sesión es el mecanismo por el cual la aplicación asocia múltiples solicitudes con un mismo contexto de usuario. Gracias a la sesión, un sistema puede reconocer que varias peticiones pertenecen a la misma persona autenticada.

En muchos sistemas, la sesión se representa mediante un identificador único que el navegador envía en cada solicitud posterior. Ese identificador suele almacenarse en una cookie, aunque también puede transportarse por otros medios.

Desde seguridad, una sesión debe cumplir varias condiciones:

• Ser difícil de adivinar.
• Expirar correctamente.
• Invalidarse al cerrar sesión.
• No quedar expuesta en lugares inseguros.
• No poder ser reutilizada indebidamente por terceros.

2.9 Autenticación, autorización y sesión: no son lo mismo

Estos tres conceptos suelen confundirse, pero cumplen funciones distintas.

• Autenticación: proceso por el cual el sistema verifica quién es el usuario. Ejemplo: login con usuario y contraseña.
• Autorización: decisión sobre qué puede hacer ese usuario una vez identificado. Ejemplo: acceso a panel de administración.
• Sesión: mecanismo que permite mantener la identidad o contexto entre solicitudes sucesivas.

Una aplicación puede autenticar correctamente y aun así fallar en autorización. También puede autorizar bien pero gestionar mal las sesiones. Por eso estas áreas deben analizarse por separado.

2.10 Cookies: qué son y para qué sirven

Las cookies son pequeños fragmentos de información que el servidor indica al navegador que almacene y reenvíe en solicitudes posteriores al mismo contexto. Son uno de los mecanismos más comunes para sostener sesiones y preferencias.

Una cookie puede contener:

• Identificador de sesión.
• Preferencias del usuario.
• Valores de seguimiento o analytics.
• Tokens temporales.

Desde seguridad, las cookies son muy importantes porque a menudo representan la identidad activa del usuario. Si un atacante roba una cookie de sesión válida, puede suplantar a la víctima sin conocer su contraseña.

2.11 Atributos de seguridad en cookies

No alcanza con usar cookies; deben configurarse correctamente. Algunos atributos reducen riesgos importantes.

Estos atributos ayudan, pero no reemplazan un diseño correcto de autenticación, expiración e invalidación de sesiones.

2.12 HTTPS y el rol de TLS

HTTPS es HTTP transportado sobre TLS. Su función es proteger la comunicación entre cliente y servidor contra observación y manipulación durante el tránsito.

Cuando HTTPS está bien implementado, aporta principalmente:

• Confidencialidad del tráfico.
• Integridad de los mensajes.
• Autenticidad del servidor mediante certificados.

Sin embargo, HTTPS no resuelve por sí solo vulnerabilidades lógicas o de aplicación. Una aplicación con SQL Injection, Broken Access Control o XSS seguirá siendo vulnerable aunque use HTTPS. Lo que cambia es que el canal de comunicación está mejor protegido.

2.13 Parámetros, formularios y datos de entrada

Las aplicaciones web existen para recibir datos: nombres, correos, contraseñas, búsquedas, filtros, comentarios, archivos, montos, identificadores, fechas, acciones. Ese flujo de entrada es necesario para operar, pero también representa una de las mayores fuentes de riesgo.

Las entradas pueden llegar por:

• Query strings en la URL.
• Formularios HTML.
• Cuerpos JSON en APIs.
• Cookies manipulables.
• Encabezados HTTP.
• Archivos subidos.
• Datos provenientes de otros sistemas.

La regla clave es simple: toda entrada externa debe considerarse potencialmente hostil hasta ser validada, normalizada y procesada de forma segura.

2.14 Validación del lado cliente y del lado servidor

Muchas interfaces web validan campos con JavaScript para mejorar experiencia de uso, por ejemplo verificar formato de correo o longitud mínima de contraseña. Eso es útil, pero no constituye seguridad real.

Un atacante puede omitir completamente la interfaz y enviar solicitudes directas mediante proxies, scripts o herramientas de testing. Por eso toda validación relevante debe replicarse y aplicarse en el servidor.

• La validación del cliente sirve para usabilidad.
• La validación del servidor sirve para seguridad y consistencia.

2.15 Headers HTTP que también importan en seguridad

Los encabezados HTTP no son un detalle menor. Muchos influyen directamente en cómo se interpreta una solicitud o cómo se protege una respuesta.

Algunos encabezados relevantes son:

• Host: indica el dominio solicitado.
• Authorization: transporta credenciales o tokens.
• Cookie: envía identificadores de sesión y otros valores.
• Origin y Referer: ayudan a entender el contexto desde el que se origina la petición.
• Content-Type: informa el formato del cuerpo.
• Set-Cookie: define cookies en la respuesta.
• Content-Security-Policy: ayuda a restringir ejecución de recursos en el navegador.

Una mala interpretación o confianza excesiva en estos encabezados puede abrir puertas a bypasses, spoofing, CSRF o errores de control de acceso.

2.16 Flujo típico de autenticación en una app web

Un flujo común de autenticación incluye varios pasos encadenados:

1. El usuario envía credenciales desde un formulario o cliente.
2. El servidor verifica esas credenciales contra una base de datos o proveedor externo.
3. Si la validación es correcta, genera o asocia una sesión.
4. La aplicación devuelve una cookie de sesión o token.
5. En solicitudes posteriores, el cliente reenvía ese identificador.
6. El servidor usa ese identificador para reconstruir el contexto del usuario.

Los riesgos pueden aparecer en cualquiera de esos pasos: credenciales débiles, enumeración de usuarios, sesiones predecibles, tokens mal protegidos, expiraciones incorrectas o ausencia de invalidación tras logout o cambio de contraseña.

2.17 Sesión basada en cookies versus tokens

Las aplicaciones modernas no siempre manejan estado de la misma forma. Dos enfoques comunes son sesiones basadas en cookies y autenticación basada en tokens.

En una sesión clásica, el servidor mantiene el estado y el navegador solo almacena un identificador. En un esquema con tokens, parte del contexto o las credenciales puede viajar en el propio token enviado por el cliente.

Ambos modelos pueden ser seguros o inseguros según su implementación. Lo importante es entender que cualquier elemento que represente identidad o privilegios debe tratarse como material sensible.

2.18 Recursos públicos y recursos protegidos

No todos los recursos de una aplicación requieren autenticación. Algunos son públicos, otros privados y otros administrativos. La seguridad depende de separar con claridad esos contextos.

Muchos problemas de seguridad aparecen cuando esta separación se aplica solo en la interfaz visual, pero no en el backend.

2.19 Qué es la superficie de ataque

La superficie de ataque de una aplicación web es el conjunto de puntos a través de los cuales un atacante puede interactuar con el sistema, influir en él o extraer información. No se limita a las páginas visibles; incluye toda interfaz expuesta o alcanzable.

La superficie de ataque puede verse como la suma de:

• Entradas.
• Funciones disponibles.
• Rutas y endpoints.
• Mecanismos de autenticación y sesión.
• Archivos públicos y paneles ocultos.
• Mensajes de error y metadatos.
• Integraciones con terceros.
• Configuraciones del servidor y del framework.

2.20 Superficie visible y superficie no evidente

Una parte de la aplicación es visible para cualquier usuario normal: páginas, formularios, botones, menús. Pero otra parte suele estar menos expuesta a simple vista y aun así ser atacable.

Ejemplos de superficie no evidente:

• Endpoints de API consumidos por JavaScript.
• Rutas administrativas no enlazadas desde la interfaz.
• Archivos de backup, logs o configuraciones mal publicados.
• Versiones antiguas o rutas olvidadas.
• Subdominios secundarios.
• Servicios auxiliares expuestos detrás del mismo dominio.

Un atacante no depende de la navegación visual. Puede enumerar rutas, observar tráfico, manipular solicitudes y buscar recursos no documentados.

2.21 Ejemplo completo de una interacción web

Imaginemos un usuario que inicia sesión en una tienda online y consulta su historial de compras.

1. El navegador solicita la página de login.
2. El usuario envía correo y contraseña por HTTPS.
3. El servidor valida credenciales.
4. La aplicación crea una sesión y envía una cookie.
5. El usuario accede a /mi-cuenta/historial.
6. El navegador reenvía la cookie de sesión.
7. El servidor identifica al usuario y consulta sus compras.
8. La respuesta devuelve datos solo de esa cuenta.

Ahora pensemos dónde pueden aparecer problemas:

• Las credenciales podrían ser débiles o reutilizadas.
• La cookie podría no tener atributos seguros.
• El servidor podría no verificar correctamente que el historial pertenece al usuario autenticado.
• La respuesta podría incluir más datos de los necesarios.
• El sistema podría registrar mal la acción o no detectar abuso automatizado.

Ese ejercicio muestra por qué entender el flujo es más valioso que memorizar nombres aislados.

2.22 Errores comunes en el manejo de estado

• Sesiones con identificadores predecibles.
• Cookies sin atributos Secure o HttpOnly.
• Sesiones que no expiran o persisten demasiado.
• Falta de invalidación al cerrar sesión.
• Permisos calculados una sola vez y no verificados por solicitud.
• Confianza en parámetros del cliente para definir rol o identidad.
• Exposición del identificador de sesión en URL o logs.

2.23 Qué observar desde seguridad cuando se analiza una aplicación

Antes de profundizar en vulnerabilidades concretas, conviene desarrollar una mirada sistemática sobre cualquier aplicación web.

• Qué entradas acepta y por dónde ingresan.
• Qué recursos son públicos, privados o administrativos.
• Cómo autentica a usuarios y cómo mantiene la sesión.
• Qué datos guarda en cookies, parámetros o respuestas.
• Qué acciones cambian estado y qué controles las protegen.
• Qué integraciones externas consume o expone.
• Qué mensajes de error, redirecciones y metadatos deja visibles.

Este enfoque ayuda a razonar sobre la aplicación como sistema, no solo como colección de páginas.

2.24 Relación entre este tema y OWASP Top 10

Todo lo visto aquí se conecta directamente con las categorías del OWASP Top 10. Por ejemplo:

• Si entendemos mal autorización, no podremos analizar Broken Access Control.
• Si no comprendemos sesiones y cookies, costará estudiar Authentication Failures, CSRF o secuestro de sesión.
• Si no sabemos cómo se transportan entradas, será difícil detectar Injection o XSS.
• Si no entendemos endpoints, integraciones y backend, SSRF parecerá un concepto abstracto.
• Si no vemos la aplicación como conjunto de componentes, Security Misconfiguration quedará reducida a una lista superficial.

En otras palabras, este tema es la base operativa para interpretar correctamente los siguientes.

2.25 Qué debes recordar de este tema

• Las aplicaciones web funcionan mediante intercambio de solicitudes y respuestas HTTP.
• HTTP es stateless, por eso las aplicaciones construyen mecanismos de sesión para mantener contexto.
• Autenticación, autorización y sesión son conceptos relacionados pero distintos.
• Las cookies suelen representar estado sensible y deben protegerse adecuadamente.
• HTTPS protege el canal, pero no corrige vulnerabilidades de lógica o de aplicación.
• Toda entrada del cliente debe considerarse potencialmente manipulable.
• La superficie de ataque incluye mucho más que lo visible en la interfaz.

2.26 Conclusión

Comprender el funcionamiento de una aplicación web es un requisito previo para estudiar seguridad con criterio. HTTP, sesiones, cookies, autenticación y superficie de ataque no son conceptos accesorios: son la base sobre la que se construyen tanto la experiencia de usuario como la mayoría de los riesgos.

En el próximo tema comenzaremos con la primera categoría del OWASP Top 10: Broken Access Control, una de las fallas más frecuentes y con mayor impacto en aplicaciones modernas.