Parte: 0 — Fundamentos y prerrequisitos · Fuente: RFC 9110 (HTTP Semantics) / MDN Web Docs ⏱️ Duración estimada: 110 min · Nivel: Fundamentos
Dominar el protocolo sobre el que corre la web y, con él, la mayor parte de la superficie de ataque moderna. Al terminar entenderás peticiones y respuestas HTTP, métodos, códigos de estado, cabeceras, cookies y sesiones, y cómo HTTPS/TLS añade confidencialidad e integridad al canal.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Modelo petición/respuesta | Base de toda interacción web |
| 2 | Métodos HTTP | GET, POST, PUT, DELETE y su semántica |
| 3 | Códigos de estado | 2xx/3xx/4xx/5xx diagnostican todo |
| 4 | Cabeceras | Control, seguridad y contexto |
| 5 | Cookies y sesiones | Estado sobre un protocolo sin estado |
| 6 | HTTPS/TLS | Confidencialidad e integridad |
| 7 | Cabeceras de seguridad | HSTS, CSP, etc. |
| 8 | HTTP/2 y HTTP/3 | La web moderna |
HttpOnly, Secure, SameSite la protegen.Usa curl, el navegador con sus DevTools (pestaña Network), y un proxy de interceptación como Burp Suite Community o OWASP ZAP. Para inspeccionar TLS, openssl s_client. Practica contra una app de laboratorio (DVWA, o un servidor propio), nunca contra sitios ajenos sin permiso.
bash
curl -v http://10.10.10.6/ 2>&1 | head -40
Identifica la línea de estado, cabeceras y cuerpo. 2. Métodos y estados. Prueba distintos métodos y observa el código:
bash
curl -s -o /dev/null -w "%{http_code}\n" -X POST http://10.10.10.6/login
HttpOnly, Secure, SameSite?bash
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Lee el emisor y la validez del certificado. 6. Cabeceras de seguridad. Comprueba si un sitio envía HSTS/CSP:
bash
curl -sI https://example.com | grep -iE 'strict-transport|content-security'
⚠️ Nota ética: la interceptación y manipulación de tráfico web se realiza solo contra aplicaciones propias o autorizadas. Usar un proxy contra sitios de terceros sin permiso es ilegal.
Content-Security-Policy y da un ejemplo que mitigue XSS.Usando un proxy de interceptación, captura el flujo completo de autenticación de una app de laboratorio: la petición de login, la respuesta que establece la cookie de sesión, y una petición autenticada posterior. Documenta las cabeceras de seguridad presentes y ausentes, y propón mejoras.
Criterio de aceptación: la evidencia muestra la cookie de sesión con sus atributos reales, e identificas correctamente al menos dos cabeceras de seguridad faltantes (p. ej. HSTS, CSP, SameSite) con una recomendación concreta por cada una. Reproducible contra la misma app.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Burp no intercepta HTTPS | Falta instalar el certificado CA de Burp en el navegador. Impórtalo. |
curl da error de certificado |
Certificado autofirmado en el lab. Usa -k solo en laboratorio, nunca en producción. |
| La cookie no se envía en peticiones | Atributo SameSite/Secure o dominio/ruta incorrectos. Revisa el scope. |
| 405 Method Not Allowed | El recurso no admite ese método. Comprueba la API. |
| HTTP/2 no aparece en la captura | Negociado por ALPN dentro de TLS. Usa herramientas que lo soporten. |
❓ ¿HTTPS hace segura mi aplicación? No: cifra el canal, pero no protege contra fallos de la app (inyección, XSS, lógica). Es necesario pero no suficiente.
❓ ¿Por qué HTTP es "sin estado" si hay sesiones? El protocolo no recuerda peticiones anteriores; las cookies y tokens simulan estado guardándolo en cliente/servidor.
❓ ¿Qué cambia HTTP/2 y HTTP/3? HTTP/2 multiplexa varias peticiones en una conexión; HTTP/3 corre sobre QUIC (UDP) reduciendo latencia. La semántica (métodos, estados) se mantiene.
❓ ¿Burp o ZAP? Ambos interceptan y modifican tráfico. Burp es el estándar profesional; ZAP es open source y gratuito. Para aprender, cualquiera sirve.
Clase 012 — DNS, DHCP y ARP: funcionamiento y riesgos