HTTP a fondo: métodos, cabeceras, cookies y proxies

1Por qué importa

Casi todas las decisiones de seguridad de una aplicación web se toman leyendo campos de una petición HTTP: quién eres por una cookie, qué puedes hacer por una cabecera, desde dónde vienes por otra. Si no tienes claro cuáles de esos campos los controla el cliente y cuáles el intermediario, vas a confiar en el sitio equivocado. La lista de fallos que salen de ahí es larga y aburridamente repetida.

El malentendido más caro es tratar HTTP como si fuera una conversación directa entre el navegador y tu código. No lo es. Entre ambos hay una cadena de intermediarios, y cada uno reescribe cosas: el proxy inverso añade la dirección real del cliente en una cabecera, la red de distribución cachea respuestas según otras, el balanceador reparte según una tercera. Un fallo de seguridad clásico es que la aplicación confíe en una cabecera que un intermediario debía haber reescrito pero no lo hizo, dejando pasar el valor que puso el cliente.

Y hay una razón de método. Esta lección es la que conecta la fase de redes con la de seguridad web que viene después. Todo lo que verás en autenticación, control de acceso o inyección ocurre dentro de una petición HTTP. Aprender a leerla y a modificarla ahora convierte esas lecciones en algo que puedes reproducir con tus manos en vez de creer.

2Conceptos

3Explicación profunda

Una petición HTTP es texto con estructura: una línea de petición con método, ruta y versión; un bloque de cabeceras; una línea en blanco; y un cuerpo opcional. Esa simplicidad es la que permite leerla y escribirla a mano, y es también la que hace que cualquier intermediario del camino pueda alterarla sin esfuerzo. No hay nada en el protocolo que ate una cabecera a quien la escribió.

Los métodos tienen propiedades que importan para seguridad más de lo que parece. GET es seguro e idempotente: no debería cambiar nada, y por eso mandar una operación con efecto por GET es un error clásico que habilita ataques de petición forzada, porque un simple enlace o una imagen la disparan. POST no es idempotente, y esa es la razón de que un doble clic pueda cobrar dos veces. PUT y DELETE sí lo son. Diseñar la semántica correcta no es purismo: decide qué ataques son posibles y qué reintentos son seguros.

Las cabeceras hay que dividirlas en tres poblaciones y no mezclarlas nunca. Las que pone el cliente y por tanto controla por completo: User-Agent, Referer, cualquier cabecera personalizada. Ninguna de ellas puede sostener una decisión de seguridad, porque el cliente escribe lo que quiera. Las que pone el intermediario: X-Forwarded-For con la dirección real, X-Forwarded-Proto con el esquema original. Estas solo son fiables si tu aplicación únicamente es alcanzable a través de ese intermediario; si además escucha directamente, el cliente puede falsificarlas. Y las que pone el servidor en la respuesta, que son las que configuran al navegador: Set-Cookie, Content-Security-Policy, Strict-Transport-Security.

Las cookies son el mecanismo con más matices, porque cada atributo protege contra un ataque distinto y omitir uno abre una puerta concreta. HttpOnly impide que el código de la página lea la cookie, lo que limita el daño de un XSS a robar la sesión. Secure impide que viaje por texto claro, cerrando la captura en la red. SameSite controla si la cookie se envía en peticiones que vienen de otro sitio, que es la defensa de fondo contra la petición forzada. Un Domain demasiado amplio comparte la cookie con subdominios que quizá no controlas. No hay un atributo “seguro”: hay una combinación correcta para cada cookie según lo que guarde.

La distinción entre proxy directo y proxy inverso se entiende por la dirección de la confianza. Un proxy directo está del lado del cliente y actúa en su nombre: filtra su salida, oculta su origen, o intercepta su tráfico para inspeccionarlo. Un proxy inverso está del lado del servidor y protege la aplicación: termina el TLS, reparte carga, filtra peticiones y añade contexto. El mismo software hace de las dos cosas; lo que cambia es de qué lado de la frontera de confianza está y a quién representa. Confundirlos lleva a colocar el control en el sitio equivocado.

Una consecuencia que conviene interiorizar: la aplicación casi nunca ve al cliente de verdad. Ve lo que el último intermediario le contó del cliente. Por eso la seguridad web bien hecha define con precisión qué intermediario es de confianza, obliga a que todo el tráfico pase por él, y trata como sospechoso cualquier campo que ese intermediario no haya reescrito explícitamente.

4Ejemplo sencillo

# Una carta que pasa por varias manos

metodo         que quieres: "traeme" (GET), "guarda esto" (POST)
cabeceras      las notas al margen del sobre: idioma, remitente, sello
cuerpo         la carta dentro
cookie         una pulsera que te pusieron en la entrada y ensenas al volver

# Quien escribe cada nota al margen

el cliente      pone su remitente. Puede escribir el que quiera.
el proxy        tacha el remitente y escribe la direccion real desde
                donde llego la carta. En eso SI se puede confiar...
                ...solo si NADIE puede meter cartas sin pasar por el.

# Los atributos de la pulsera, uno por ataque

HttpOnly    la pulsera no se puede fotografiar desde dentro de la fiesta
Secure      la pulsera solo vale si entraste por la puerta buena
SameSite    la pulsera no funciona si te trajo alguien de otra fiesta

5Ejemplo técnico

Así se ve una petición cuando la lees desde el intermediario. Esta es la ruta /eco del laboratorio, que devuelve lo que la aplicación recibió de verdad, después de pasar por el proxy:

Mira la línea x-rol. El cliente envió usuario y la aplicación recibió administrador, porque el intermediario reescribió esa cabecera por el camino. Ese es el punto entero de la lección: una aplicación que autorizara por X-Rol estaría confiando en algo que un intermediario puede poner a voluntad, y en algo que el cliente puede falsificar si consigue hablar con la aplicación sin pasar por el proxy.

La tabla es el mapa de confianza que pedía el objetivo. La fila de X-Forwarded-For es la que más incidentes causa: parece fiable porque “la pone el proxy”, y deja de serlo en cuanto la aplicación escucha también por un camino que no pasa por el proxy.

6Diagrama

flowchart LR
    C[cliente: pone lo que quiere] --> P[proxy inverso: reescribe]
    P --> A[aplicacion: ve lo que le cuentan]
    C -. camino directo a cerrar .-> A

7Código

La configuración de una cookie de sesión es donde esta lección se vuelve código. Estos son los dos extremos, y la diferencia entre ellos es una lista de ataques:

# Cookie floja: la que emite el laboratorio a proposito
Set-Cookie: sesion=demo-de-laboratorio; Path=/

# Cookie endurecida: cada atributo cierra un ataque concreto
Set-Cookie: sesion=<valor opaco y aleatorio>;
            HttpOnly;          # el JS de la pagina no la lee: limita el XSS
            Secure;            # no viaja por HTTP en claro
            SameSite=Lax;      # no se envia en navegaciones desde otro sitio
            Path=/;            # alcance minimo dentro del origen
            Max-Age=3600       # caduca: una sesion robada no es eterna

Cada atributo de la versión endurecida corresponde a una entrada de la fase de seguridad web: HttpOnly aparece en la lección de XSS, SameSite en la de petición forzada, Secure en la de TLS que viene justo después de esta. Endurecer la cookie no es una casilla que marcar: es entender de qué te protege cada atributo, y por eso omitir uno es una decisión, no un olvido.

# Y la comprobacion, contra tu propio laboratorio
for attr in HttpOnly Secure SameSite; do
  if curl -sI http://localhost:8092/login | grep -i Set-Cookie | grep -qi "$attr"; then
    echo "presente  $attr"
  else
    echo "FALTA     $attr"
  fi
done

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

# en conf/app.conf, ruta /login
add_header Set-Cookie "sesion=demo-de-laboratorio; Path=/; HttpOnly; SameSite=Lax; Max-Age=3600";

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos