Anatomía de una petición y su respuesta

Una petición HTTP/1.1 es texto con un orden fijo. La primera línea dice qué se pide: el método (GET, POST…), el destino (la ruta y, si hay, la cadena de consulta después de ?) y la versión del protocolo. Después vienen las cabeceras, una por línea con la forma Nombre: valor; en HTTP/1.1 la cabecera Host es obligatoria, porque un mismo servidor atiende muchos nombres y necesita saber a cuál le hablan. Luego una línea vacía y, si el método lo usa, el cuerpo.

La respuesta tiene la misma forma: una línea de estado con la versión, un código de tres cifras y una frase; cabeceras; una línea vacía; el cuerpo. Las cabeceras de la respuesta son instrucciones para el navegador: qué tipo de contenido es, si puede guardarlo en caché, qué cookie debe guardar, a dónde debe ir después. El auditor lee las dos mitades, porque el fallo puede estar en lo que se pidió o en lo que se ordenó.

Cuando el servidor recibe un formulario, no suele devolver una página: responde con un código de la familia 3xx y una cabecera Location, que le dice al navegador a qué dirección ir a continuación. En la misma respuesta puede venir Set-Cookie, que es la orden de guardar un valor y devolverlo en las siguientes peticiones. Leer esa respuesta dice qué consideró el servidor un inicio de sesión correcto y a dónde lleva a la persona.

Abre peticion-entrar.http y lee la respuesta completa, no solo la línea de estado.

La cadena de consulta (lo que va después de ? en la URL) no es un lugar privado. La URL completa queda escrita en el registro de acceso del servidor y de cualquier proxy intermedio, en el historial del navegador y, según la política de referencia, en la cabecera Referer que se envía a la siguiente página. Por eso un dato que identifica a una persona, o que permite actuar en su nombre, no debería ir en la URL: va en el cuerpo de la petición o se deduce de la sesión en el servidor.

Abre peticion-buscar-pedido.http. Mira la primera línea y separa cada parámetro por el &; el %40 es una arroba codificada.

Encontrar el dato en la URL es la mitad del hallazgo; la otra mitad es decir cómo se corrige sin romper la función. La tienda necesita saber de quién es el pedido, y la clienta ya inició sesión: el servidor puede saberlo por la cookie de sesión, sin pedirlo en la dirección. Si de verdad hay que enviarlo (por ejemplo, alguien sin cuenta que consulta su pedido), se envía en el cuerpo de un POST, que no queda en el historial ni en el registro de acceso estándar.

En HTTP/2 los mensajes ya no viajan como líneas de texto sino en marcos binarios, y las herramientas del navegador los muestran de otra forma: la línea de petición se convierte en pseudo-cabeceras que empiezan por dos puntos (:method, :scheme, :path y :authority), y la de estado en :status. La pseudo-cabecera :authority cumple el papel que en HTTP/1.1 tiene Host. Los nombres de las cabeceras van en minúsculas. El auditor tiene que reconocer la misma petición en los dos formatos, porque una captura exportada puede venir en cualquiera.

Abre captura-api-h2.txt.