CyberSec 4you: Tu escudo en el mundo digital
Qué hay detrás de una solicitud HTTP..??
Cada vez que visitas una página web, se produce una conversación silenciosa entre tu navegador y un servidor. Esta 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, exploraremos cómo funciona HTTP (Métodos, Códigos, Headers, etc), por qué importa, y cómo identificar riesgos asociados a su uso.
Aprenderemos:
¿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.
Problema de seguridad: HTTP transmite datos en texto plano, lo que significa que la información puede ser interceptada. Por eso nació HTTPS, la versión cifrada mediante SSL/TLS, que protege la confidencialidad e integridad de los datos.
EVOLUCIÓN:
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. La primera versión, HTTP/0.9, se introdujo en 1991, proporcionando una forma sencilla de transferir archivos de texto. Con la llegada de HTTP/1.0 en 1996, se incorporaron características como la gestión de cabeceras y la posibilidad de manejar diversos tipos de contenido. Posteriormente, HTTP/1.1, que se lanzó en 1997, trajo consigo una mayor eficiencia, la capacidad de mantener conexiones persistentes y mejoras en el manejo de caché.
Más recientemente, HTTP/2 fue presentado en 2015, optimizando la velocidad de carga de páginas mediante técnicas como la multiplexión de solicitudes y la compresión de cabeceras. Con el crecimiento de la preocupación por la seguridad en internet, HTTP/3, la versión más reciente, utiliza el protocolo QUIC (Quick UDP Internet Connections) para mejorar significativamente la seguridad de las comunicaciones y reducir la latencia.
| VERSIÓN | AÑO | SEGURIDAD | RENDIMIENTO | COMENTARIOS |
|---|---|---|---|---|
| 0.9 | 1991 | Sin cifrado | Petición en una única linea, con el único método posible GET | Forma sencilla de transferir archivos de texto |
| 1.0 | 1996 | Sin cifrado nativo | Cada solicitud abre una conexión nueva | Obsoleto. No soporta conexiones persistentes. |
| 1.1 | 1997 | Soporta HTTPS | Introduce conexiones persistentes (keep-alive) | Amplio uso aún hoy. Soporta compresión y mejoras básicas. |
| 2 | 2015 | Cifrado opcional (pero casi siempre con TLS) | Multiplexación de múltiples solicitudes en una sola conexión | Mucho más rápido en carga de páginas. Reduce latencia. |
| 3 | 2022 | Cifrado obligatorio (TLS 1.3) | Basado en QUIC (sobre UDP), más rápido y resistente a pérdidas de conexión | Seguridad y rendimiento al siguiente nivel. Ideal para móviles. |
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.
Fuente (tryhackme.com)
Squeme: Protocolo usado, este puede ser http, https, ftp, etc
User: Algunos servicios requieren autenticación (user y password).
Host/Domain: Nombre de dominio o IP del servidor.
Port: Al puerto de conexión, usualmente 80 para http, 443 para https, pero estos pueden ser seteados a cualquier puerto entre 1 – 65535.
Path: Recurso que intentas acceder.
Query String/Parámetros: Son valores adicionales que se agregan a una URL para enviar datos al servidor o para que una página web muestre contenido dinámico.
Fragment: Se refiere a una ubicación interna dentro de la página actual.
Veamos partes críticas de una URL con respecto a la ciberseguridad
1. Protocolo (http:// o https://)
Importancia: Asegura si la conexión está cifrada.
- https:// → conexión segura (TLS/SSL).
- http:// → insegura; tus datos pueden ser interceptados.
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.
Riesgo: Dominios parecidos o engañosos (g00gle.com, paypa1.com) son muy usados en estafas.
Buenas prácticas: Mira el dominio justo antes del .com, .net, etc.
3. Subdominio (sub.dominio.com)
Subdominios legítimos: login.microsoftonline.com
Maliciosos: microsoftonline.com.hack-site.xyz Riesgo: Los atacantes usan subdominios para parecer confiables
Buenas prácticas:
- Evita utilizar o visitar subdominios que puedan parecer dominios falsos
- login.banco.com.seguro-clientes.net
- login.banco.com
- No delegues subdominios críticos a servicios externos sin control.
- app.miempresa.com → apunta a un servicio de terceros no monitoreado
- Si el proveedor cierra o libera esa ruta, alguien podría tomar el control del subdominio (ataque de Subdomain Takeover).
- Usa CNAME apuntando solo a servicios con control activo, y elimina registros obsoletos.
- Usa nombres de subdominios claros y específicos.
- Incorrecto: site.miempresa.com
- Correcto: panel.miempresa.com
- Correcto: intranet.miempresa.com
- Aplica certificados HTTPS únicos o SAN (Subject Alternative Names)
- Cada subdominio debe estar cubierto por: – Esto asegura que cada subdominio tenga cifrado HTTPS válido.
- Un certificado wildcard (*.miempresa.com)
- O un SAN con los subdominios listados.
- Cada subdominio debe estar cubierto por: – Esto asegura que cada subdominio tenga cifrado HTTPS válido.
- Audita subdominios regularmente, para identificar Subdominios activos y vulnerables, y Subdominios huérfanos o no utilizados
4 Ruta (/cuenta/actualizar)
Es la parte que sigue al dominio: https://banco.com/cuenta/actualizar
Riesgo: URLs con 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 & si hay varios.
¿Para qué se usan los parámetros?
| Función | Ejemplo de parámetro |
| Búsquedas | ?q=zapatos |
| Paginación | ?pagina=2 |
| Filtros | ?color=azul&talla=M |
| Identificadores | ?id=1234 |
| Idioma o región | ?lang=es |
| Seguimiento o campañas | ?utm_source=facebook |
¿Cómo los recibe el servidor?
Riesgo:
Buenas prácticas:
6. Fragmento:
Un fragmento es la parte de una URL que viene después del símbolo #, también conocido como anchor (ancla). El propósito principal del fragmento es llevar al navegador a una sección específica de la página, sin recargarla. Si una página HTML tiene elementos con un id, el fragmento hace que el navegador salte directamente a esa sección.
Uso en aplicaciones web modernas (SPA). En aplicaciones de una sola página (Single Page Applications – SPA), los fragmentos:
Se debe tomar en cuenta que no se envían al servidor, por lo cual es clave en seguridad y arquitectura, no se incluye en la solicitud HTTP al servidor, lo interpreta el navegador del cliente
Casos de uso comunes:
| Escenario | Ejemplo de fragmento | Resultado |
| Saltar a una sección del sitio | #contacto | Desplaza la vista al formulario de contacto |
| SPA o navegación interna | #/perfil | Muestra la sección «perfil» sin recargar |
| Documentación técnica | #parametros | Enfoca el lector en el apartado de parámetros |
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 práctico de una solicitud web, utilizando la herramienta de línea de comando (curl) para realizar solicitudes HTTP/HTTPS.
Primero hagamos una petición con HTTP:
curl: herramienta de línea de comandos para hacer solicitudes HTTP/HTTPS.
-v: modo verbose, muestra toda la conversación cliente-servidor.
http://google.com: realiza una solicitud HTTP (no cifrada) al sitio web.
1. Resolución DNS
El equipo resolvió el dominio google.com a la IP 142.251.132.142 mediante una consulta DNS.
2. Conexión al puerto
3. Solicitud del cliente enviada
| Campo | Significado |
| GET / | Utiliza el método GET. Solicita la raíz del sitio web (/) |
| HTTP/1.1 | Usa HTTP versión 1.1 |
| Host: | Indica el nombre del dominio consultado (google.com) |
| User-Agent: | Identifica la herramienta (en este caso, curl/8.13.0) |
| Accept: | El cliente acepta cualquier tipo de contenido (*/*) |
Las solicitudes HTTP siempre finalizan con una línea en blanco para informar al servidor que la solicitud ha finalizado.
4. Respuesta del Servidor
| Código | Significado |
| 301 | El recurso solicitado 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.
5. Cabeceras importantes de seguridad
Estas cabeceras protegen al sitio de ciertos ataques web:
| Cabecera | Función |
|---|---|
Content-Security-Policy-Report-Only | Controla de dónde se pueden cargar scripts, objetos, etc. (mitiga XSS) |
X-XSS-Protection: 0 | Desactiva la protección anti-XSS del navegador (porque Google usa su propia lógica) |
X-Frame-Options: SAMEORIGIN | Evita que el sitio se incruste en un iframe de otro sitio (previene clickjacking) |
Server: gws | Indica que es el Google Web Server |
6. Contenido HTML
Es una página HTML mínima que acompaña la redirección.
Ahora, veamos una conexión con HTTPS:
Petición https:
1. Resolución DNS y conexión al puerto
2. Negociación TLS (Handshake)
Una vez que el cliente tiene la IP, se conecta al puerto 443 (HTTPS) y se establece una conexión segura mediante TLS.
Aquí se establece la confidencialidad, integridad y autenticación.
3. Solicitud HTTPS mediante GET
Una vez que la conexión TLS está lista, se envía la solicitud HTTP cifrada:
Se usa la versión 2 de HTTP
4. Respuesta del Servidor
Estado 200 OK: Respuesta exitosa. El servidor respondió satisfactoriamente.
5. Cabeceras importantes de seguridad
De acuerdo a la salida, las cabeceras de seguridad utilizadas son:
content-security-policy-report-only:
Limita desde qué fuentes se pueden cargar scripts, imágenes, objetos, etc.
En modo report-only, lo registra pero no bloquea — útil para pruebas.
x-frame-options: SAMEORIGIN:
Protege contra clickjacking, impidiendo que la página sea embebida en un iframe desde otro dominio.
x-xss-protection: 0:
Desactiva la protección contra XSS del navegador. No es ideal; Google lo desactiva porque tiene otras defensas más fuertes.
set-cookie:
Google establece varias cookies con atributos de seguridad:
6. Cabeceras de control y comportamiento.
cache-control: private, max-age=0:
No almacenar en cachés compartidas. La respuesta es específica para el usuario.
vary: Accept-Encoding:
El contenido puede cambiar según la codificación aceptada por el navegador (gzip, br, etc.)
server: gws:
Indica que responde el Google Web Server.
7. Contenido HTML
Esto indica que el contenido es:
Esto es el inicio del código fuente de la página principal de Google. A continuación, vendrían los elementos del formulario de búsqueda, scripts, imágenes, etc.
Detalles importantes desde ciberseguridad:
| Elemento | Evaluación |
| HTTPS activo y TLS 1.3 | Cifrado fuerte para proteger confidencialidad e integridad |
| Cookies con Secure y HttpOnly | Buenas prácticas contra robo de sesión y ataques XSS |
| CSP (en modo report-only) | Aún en pruebas; se recomienda habilitarla en modo enforce |
| X-Frame-Options: SAMEORIGIN | Protege contra clickjacking |
| X-XSS-Protection: 0 | Se desactiva por motivos internos, pero no es recomendable para sitios normales |
Métodos HTTP más comunes:
1. GET “Dame esto”
2. POST “Aquí tienes estos datos”
3. PUT “Crea o reemplaza esto”
4. PATCH “Actualiza solo una parte”
5. DELETE “Borra esto”
6. HEAD “Quiero saber si esto está ahí”
7. OPTIONS “¿Qué me permite hacer este servidor?”
Códigos de estado HTTP:
¿Qué Significan las Respuestas de los Servidores?
Cuando visitamos una página web, detrás de escena ocurre una conversación entre tu navegador (el cliente) y el servidor web. Una de las primeras respuestas que da el servidor es una línea con un código de estado HTTP, que le dice al navegador qué ocurrió con su solicitud.
Estos códigos están organizados en cinco categorías principales, cada una con un propósito distinto:
1xx – Respuestas Informativas
Este grupo indica que el servidor ha recibido parte de la solicitud y que el navegador puede continuar enviando el resto. Estos códigos son muy poco comunes.
2xx – Solicitud Exitosa
Cuando todo sale bien, el servidor responde con un código en este rango. Es la señal de que tu solicitud fue recibida, entendida y procesada correctamente.
3xx – Redirecciones
Estos códigos le indican al navegador que la información no está en la URL solicitada y que debe buscarla en otra dirección. Se usan mucho para redirigir a los usuarios o motores de búsqueda. Es decir el recurso ha cambiado de ubicación.
4xx – Errores del Cliente
Aquí el error viene del lado del usuario. Puede deberse a una URL incorrecta, falta de permisos, parámetros ausentes, etc.
5xx – Errores del Servidor
Cuando el servidor tiene un problema interno y no puede manejar la solicitud, devuelve uno de estos códigos. Suelen indicar fallos más serios o caídas temporales del servicio.
Códigos Comunes que Deberías Conocer
A continuación, te explico los códigos HTTP más frecuentes que seguramente has visto en el navegar:
¿Por qué es importante conocerlos?
Entender estos códigos no solo es útil para desarrolladores y administradores web, sino también para analistas de ciberseguridad, quienes pueden detectar problemas de configuración, ataques, errores de autenticación o caídas de servicio.
HTTP Headers:
¿Qué son y por qué importan?
Cuando tu navegador se comunica con un servidor web, no solo envía una solicitud para cargar una página. También envía una serie de «encabezados HTTP» (headers), que son pequeñas piezas de información adicionales que ayudan al servidor a entender mejor qué se está solicitando y cómo debe responder.
Aunque técnicamente no son obligatorios, pero sin ellos muchas páginas no funcionarían correctamente.
Encabezados Comunes de Solicitud (Request Headers)
Estos headers los envía tu navegador (u otra herramienta cliente) cuando haces una solicitud a un sitio web:
Host
Indica el dominio específico que estás solicitando. Esto es clave cuando un mismo servidor aloja varios sitios web. Sin este header, podrías terminar viendo el sitio web «por defecto» del servidor.
User-Agent
Le dice al servidor qué navegador estás usando (y su versión). Esto permite que el contenido se adapte a tu navegador, ya que no todos los navegadores interpretan HTML, CSS o JavaScript de la misma manera.
Content-Length
Cuando envías información (como al llenar un formulario – como POST), este header le indica al servidor cuánta información estás enviando. Así se asegura que no se pierdan datos durante la transmisión.
Accept-Encoding
Este encabezado le dice al servidor qué tipos de compresión puede manejar tu navegador (como gzip o br). Esto ayuda a reducir el tamaño de los archivos para que carguen más rápido.
Cookie
Aquí viajan las cookies que tu navegador guarda del sitio. Esto permite que el servidor recuerde quién eres, qué has hecho antes en la web, o tus preferencias (como el idioma).
Encabezados Comunes de Respuesta (Response Headers)
Estos headers los envía el servidor web como parte de su respuesta a tu solicitud. Son clave para entender cómo se entrega el contenido.
Set-Cookie
Permite que el servidor guarde información en tu navegador. Por ejemplo, una sesión iniciada o tu carrito de compras. Cada vez que visites el sitio, estas cookies se volverán a enviar al servidor.
Cache-Control
Controla cuánto tiempo puede tu navegador guardar la información en caché antes de volver a solicitarla. Esto ayuda a que las páginas carguen más rápido y reduce la carga en el servidor.
Content-Type
Indica el tipo de archivo que se está enviando: HTML, CSS, JavaScript, imagen, PDF, video, etc. Con esta información, tu navegador sabe cómo manejar el contenido recibido.
Content-Encoding
Le dice al navegador qué tipo de compresión se utilizó al enviar la información (por ejemplo, gzip). Así, el navegador puede descomprimir los datos y mostrarlos correctamente.
¿Por qué es relevante en ciberseguridad?
Los headers juegan un papel fundamental en la ciberseguridad y el rendimiento de los sitios web. Ayudan a proteger sesiones, a reducir el riesgo de ataques como XSS o CSRF, y a optimizar la experiencia del usuario.
Set-Cookie con HttpOnly y Secure ayuda a proteger contra robo de sesión (XSS).
Content-Type mal definido puede facilitar ataques XSS si el navegador interpreta contenido incorrecto.
Cache-Control puede proteger datos sensibles de ser almacenados localmente.
Accept-Encoding mal utilizado podría permitir ataques de compresión tipo BREACH si no se gestiona bien.
Además, hay cabeceras adicionales enfocadas en ciberseguridad, las cuales complementarían la ciberseguridad a un sitio web, estas son:
| Cabecera | ¿Qué hace? | Ejemplo / Valor recomendado |
| Strict-Transport-Security (HSTS) | Obliga al navegador a usar solo HTTPS (incluso si escriben http://). | Strict-Transport-Security: max-age=31536000; includeSubDomains; preload |
| X-Frame-Options | Evita que tu web sea embebida en un iframe (previene ataques clickjacking). | X-Frame-Options: DENY o SAMEORIGIN |
| X-Content-Type-Options | Evita que el navegador «adivine» el tipo de contenido (previene ejecución de scripts). | X-Content-Type-Options: nosniff |
| X-XSS-Protection | Activa (o desactiva) la protección básica del navegador contra Cross-site Scripting (XSS). | X-XSS-Protection: 1; mode=block |
| Referrer-Policy | Controla cuánta información del URL de origen se comparte con otros sitios. | Referrer-Policy: no-referrer-when-downgrade |
| Permissions-Policy (antes Feature-Policy) | Restringe APIs del navegador (cámara, micrófono, geolocalización). | Permissions-Policy: geolocation=(), camera=() |
| Content-Security-Policy (CSP) | Define de dónde se pueden cargar recursos (scripts, imágenes, CSS). Ayuda a prevenir XSS. | Content-Security-Policy: default-src ‘self’; script-src ‘self’ |
| Access-Control-Allow-Origin | Controla qué sitios pueden hacer solicitudes CORS a tu servidor (evita fuga de datos). | Access-Control-Allow-Origin: https://midominio.com |
| Cross-Origin-Opener-Policy (COOP) | Protege frente a ataques tipo Spectre y mejora aislamiento entre sitios. | Cross-Origin-Opener-Policy: same-origin |
| Cross-Origin-Embedder-Policy (COEP) | Requiere permisos para embebidos de otros sitios. | Cross-Origin-Embedder-Policy: require-corp |
¿Qué son las Cookies en la Web y Cómo Funcionan?
Cuando visitas un sitio web, tu navegador y el servidor web se comunican utilizando el protocolo HTTP. Pero hay un pequeño problema: HTTP es un protocolo sin estado (stateless), lo que significa que no recuerda quién eres entre una solicitud y otra. Aquí es donde entran las cookies.
¿Qué es una cookie?
Una cookie es simplemente un pequeño fragmento de información que el servidor web guarda en tu navegador. Este dato puede ser un nombre, una identificación, una preferencia de idioma o un token de autenticación.
¿Cómo funciona?
Vamos a desglosarlo paso a paso con un ejemplo ilustrativo:
1. El cliente solicita una página web
El navegador (cliente) envía una solicitud al servidor para visitar, por ejemplo, https://cybersec4you.net
2. El servidor responde con un formulario
El servidor entrega una página web que contiene un formulario pidiendo al usuario su nombre.
3. El cliente envía el formulario
El usuario llena el formulario (por ejemplo, con el nombre team) y lo envía al servidor mediante una solicitud POST.
4. El servidor crea la cookie
El servidor responde con un encabezado especial llamado Set-Cookie: name=team. Esto le dice al navegador que guarde esa cookie con el nombre del usuario.
5. El cliente envía la cookie en futuras solicitudes
Desde este punto, cada vez que el cliente haga una nueva solicitud al servidor, su navegador enviará automáticamente esa cookie con el encabezado Cookie: name=team.
6. El servidor reconoce al usuario
Gracias a la cookie, el servidor ya no necesita mostrar el formulario nuevamente, y en su lugar, puede mostrar un mensaje personalizado como: “Welcome back, team!”
¿Para qué se usan las cookies?
Aunque se pueden usar para múltiples fines (recordar idioma, productos en el carrito, preferencias de visualización), su uso más común y crítico es la autenticación.
En estos casos, la cookie no contiene datos sensibles como contraseñas, sino un token único (string aleatorio) que identifica tu sesión. Este token lo valida el servidor en cada interacción.
¿Por qué son importantes en ciberseguridad?
