Entendiendo el protocolo HTTP: funcionamiento, métodos y ejemplos prácticos orientado a ciberseguridad

Cada vez que visitas una página web, se produce una conversación silenciosa entre tu navegador y un servidor. Esa conversación ocurre gracias a HTTP, el protocolo que hizo posible la Web como la conocemos. Pero HTTP no es solo una herramienta de comunicación: es también un punto crítico desde la perspectiva de la ciberseguridad. En este artículo exploramos cómo funciona (métodos, códigos, headers, etc.), por qué importa y cómo identificar riesgos asociados a su uso.

¿Qué es HTTP?

HTTP (HyperText Transfer Protocol) es el protocolo que permite que tu navegador se comunique con los servidores web. Fue creado entre 1989 y 1991 por Tim Berners-Lee, y permite solicitar y recibir contenido como HTML, imágenes, archivos JSON, etc. Su arquitectura cliente-servidor es la base del funcionamiento web.

Evolución de HTTP

A lo largo de los años se han desarrollado varias versiones de HTTP, cada una mejorando aspectos clave como la seguridad y el rendimiento:

Fuente: tryhackme.com

Anatomía de una URL y su importancia en ciberseguridad

Una URL (Uniform Resource Locator) identifica un recurso online. Está compuesta por varios elementos que pueden ser utilizados —o manipulados— en ataques cibernéticos.

• Esquema: protocolo usado, puede ser http, https, ftp, etc.
• User: algunos servicios requieren autenticación (usuario y contraseña).
• Host/Domain: nombre de dominio o IP del servidor.
• Port: puerto de conexión, usualmente 80 para HTTP y 443 para HTTPS, aunque puede ser cualquiera entre 1 y 65535.
• Path: recurso que intentas acceder.
• Query String/Parámetros: valores adicionales que se agregan a la URL para enviar datos o mostrar contenido dinámico.
• Fragment: una ubicación interna dentro de la página actual.

Partes críticas de una URL para la ciberseguridad

1. Protocolo (http:// o https://). Asegura si la conexión está cifrada. Riesgo: sitios maliciosos muchas veces usan HTTP o simulan ser HTTPS con íconos falsos.

2. Nombre de dominio (host). Clave para detectar phishing o suplantación. Dominios parecidos o engañosos (g00gle.com, paypa1.com) son muy usados en estafas. Mira siempre el dominio justo antes del .com, .net, etc.

3. Subdominio (sub.dominio.com). Legítimo: login.microsoftonline.com. Malicioso: microsoftonline.com.hack-site.xyz. Los atacantes usan subdominios para parecer confiables.

4. Ruta (/cuenta/actualizar). Rutas muy largas, confusas o codificadas pueden ocultar scripts maliciosos o redireccionamientos falsos.

5. Parámetros (query string). El signo ? inicia los parámetros; cada par clave=valor se separa con &:

https://tienda.com/productos?categoria=ropa&orden=precio_desc

En métodos GET los parámetros van en la URL; en POST suelen ir en el cuerpo. Riesgo: los enlaces de phishing incluyen IDs falsos, tokens o comandos maliciosos, y pueden usarse para inyección SQL o XSS. Buenas prácticas: no enviar información sensible por URL y codificar los valores con caracteres especiales (%20, etc.).

6. Fragmento. Es la parte que viene después del símbolo # (anchor). Lleva al navegador a una sección específica de la página sin recargarla y es muy usado en SPA (React, Vue, Angular con hash router). No se envía al servidor: lo interpreta el navegador del cliente. Riesgo: algunos ataques modernos usan el fragmento para inyectar scripts o robar tokens en apps mal diseñadas.

Ejemplo práctico: solicitud / respuesta web

Veamos un ejemplo real usando curl, la herramienta de línea de comandos para hacer solicitudes HTTP/HTTPS. Primero, una petición con HTTP:

curl -v http://google.com

Donde -v activa el modo verbose y muestra toda la conversación cliente-servidor. El proceso es:

1. Resolución DNS: el equipo resolvió google.com a la IP 142.251.132.142.
2. Conexión al puerto 80.
3. Solicitud del cliente:

GET / HTTP/1.1
Host: google.com
User-Agent: curl/8.13.0
Accept: */*

Las solicitudes HTTP siempre finalizan con una línea en blanco para informar al servidor que la solicitud ha terminado. La respuesta es un 301 Moved Permanently: el recurso ya no está en http://google.com, ahora está en http://www.google.com. Google redirige para asegurarse de que accedas a la versión con www.

Ahora, la misma petición con HTTPS:

curl -v https://google.com

1. Resolución DNS y conexión al puerto 443.
2. Negociación TLS (handshake): el servidor envía su certificado digital; el cliente lo valida (fecha, autoridad certificadora, coincidencia con el dominio) y se negocian las claves de cifrado. Aquí se establece confidencialidad, integridad y autenticación.
3. Solicitud HTTPS cifrada (usando HTTP/2).
4. Respuesta del servidor: 200 OK.

Métodos HTTP más comunes

• GET — «Dame esto». Solicita datos; no modifica nada.
• POST — «Aquí tienes estos datos». Envía datos para crear o procesar algo (p. ej. un login).
• PUT — «Crea o reemplaza esto». Si el recurso existe, lo reemplaza; si no, lo crea.
• PATCH — «Actualiza solo una parte». Similar a PUT pero más ligero y específico.
• DELETE — «Borra esto». Elimina un recurso del servidor.
• HEAD — Como GET, pero solo devuelve los encabezados; útil para comprobar si un recurso existe.
• OPTIONS — «¿Qué me permite hacer este servidor?». Muestra los métodos aceptados; útil en seguridad y depuración.

Códigos de estado HTTP

Una de las primeras respuestas del servidor es una línea con un código de estado que le dice al navegador qué ocurrió. Se organizan en cinco categorías:

• 1xx – Informativas: el servidor recibió parte de la solicitud; muy poco comunes.
• 2xx – Éxito: la solicitud fue recibida, entendida y procesada correctamente.
• 3xx – Redirecciones: el recurso cambió de ubicación.
• 4xx – Errores del cliente: URL incorrecta, falta de permisos, parámetros ausentes.
• 5xx – Errores del servidor: problema interno; fallos serios o caídas temporales.

Entender estos códigos no solo es útil para desarrolladores y administradores web, sino también para analistas de ciberseguridad, que pueden detectar problemas de configuración, ataques, errores de autenticación o caídas de servicio.

Headers HTTP

Los headers son pequeñas piezas de información adicional que viajan en cada solicitud y respuesta. Aunque técnicamente no son obligatorios, sin ellos muchas páginas no funcionarían correctamente.

Encabezados de solicitud (request)

• Host — indica el dominio específico solicitado (clave cuando un servidor aloja varios sitios).
• User-Agent — le dice al servidor qué navegador y versión usas.
• Content-Length — cuánta información estás enviando (p. ej. en un POST).
• Accept-Encoding — qué compresión puede manejar tu navegador (gzip, br).
• Cookie — envía las cookies guardadas del sitio.

Encabezados de respuesta (response)

• Set-Cookie — el servidor guarda información en tu navegador (sesión, carrito).
• Cache-Control — cuánto tiempo puede el navegador guardar la respuesta en caché.
• Content-Type — el tipo de archivo enviado (HTML, CSS, JS, imagen, PDF).
• Content-Encoding — qué compresión se utilizó al enviar la información.

Cabeceras enfocadas en ciberseguridad

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: DENY            # o SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: no-referrer-when-downgrade
Permissions-Policy: geolocation=(), camera=()
Content-Security-Policy: default-src 'self'; script-src 'self'
Access-Control-Allow-Origin: https://midominio.com
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Los headers protegen sesiones, reducen el riesgo de XSS o CSRF y optimizan la experiencia. Por ejemplo, Set-Cookie con HttpOnly y Secure protege contra robo de sesión, un Content-Type mal definido puede facilitar XSS, y Accept-Encoding mal gestionado podría permitir ataques de compresión tipo BREACH.

¿Qué son las cookies y cómo funcionan?

HTTP es un protocolo sin estado (stateless): no recuerda quién eres entre una solicitud y otra. Aquí entran las cookies, pequeños fragmentos de información que el servidor guarda en tu navegador. El flujo típico es:

1. El cliente solicita una página web.
2. El servidor responde con un formulario pidiendo, por ejemplo, tu nombre.
3. El cliente envía el formulario (nombre team) mediante POST.
4. El servidor responde con Set-Cookie: name=team.
5. En futuras solicitudes, el navegador envía automáticamente Cookie: name=team.
6. El servidor reconoce al usuario y muestra «Welcome back, team!».

Por qué le importa a tu empresa

La mayoría de ataques web (inyección, robo de sesiones, man-in-the-middle) explotan un mal uso de HTTP. Forzar HTTPS con TLS 1.3, configurar las cabeceras de seguridad, marcar las cookies como Secure/HttpOnly/SameSite y validar cada método y entrada son medidas básicas que reducen drásticamente tu superficie de ataque.

¿Quieres auditar las cabeceras, el HTTPS y las cookies de tu sitio? Hablemos.