Desde el DNS al Navegador

Cuando escribes una dirección en el navegador y pulsas Enter, parece que el sitio aparece de inmediato y por arte de magia. Pero en realidad, en esos milisegundos ocurre una secuencia de pasos bien definida, en la que tu instrucción dio varias vueltas por el mundo.

Estos pasos se secuencian de la siguiente manera:

  • Ingresas la URL en el navegador y presionas Enter.

  • Tu máquina consulta internamente si conoce esa dirección por medio de una tabla de hosts.

  • De no conocerla, consulta al resolver por el DNS registrado.

  • Se establece una conexión entre tu máquina y el DNS público.

  • El DNS actúa como una guía telefónica y devuelve la dirección IP que corresponde al dominio consultado.

  • Se encapsula la petición HTTP en un contexto cifrado (TLS).

  • Se envía el contenido cifrado al servidor por medio de una conexión socket, normalmente al puerto 443.

  • El servidor, con la llave privada, descifra la petición HTTP.

  • Luego, este enruta y procesa la petición para devolver el contenido respectivo.

  • Se envían las cabeceras y el contenido al navegador original, donde este renderiza el sitio web.

    Entender ese camino es la base de todo lo demás: cada salto es, además, un punto donde algo puede analizarse o fallar. Desmenucemos esto paso a paso.

DNS — Domain Name System

Al momento de ingresar a un sitio, tu equipo no sabe llegar a d4rk-sh3ll.ninja; necesita su dirección IP, que es, de alguna manera, el "número de teléfono" de la máquina en el internet público. El DNS (Domain Name System) es la guía telefónica que traduce uno en otro.

En el sistema operativo, este trabajo lo hace un resolver: el resolver va recorriendo la jerarquía de los DNS declarados hasta encontrar la IP del dominio y devolverla.

Resolvers públicos comunes

┌─────────────────┬──────────────────┬────────────────────────────────────────────────┐
│ Resolver        │ IPv4             │ Nota                                           │
├─────────────────┼──────────────────┼────────────────────────────────────────────────┤
│ Cloudflare      │ 1.1.1.1          │ Suele ser el más rápido en benchmarks;         │
│                 │ 1.0.0.1          │ 1.1.1.2, 1.0.0.2 bloquea malware, y 1.1.1.3,   │
│                 │                  │ 1.0.0.3 malware + contenido adulto.            │
├─────────────────┼──────────────────┼────────────────────────────────────────────────┤
│ Google          │ 8.8.8.8          │ Neutro, sin filtrado.                          │
│                 │ 8.8.4.4          │                                                │
├─────────────────┼──────────────────┼────────────────────────────────────────────────┤
│ Quad9           │ 9.9.9.9          │ Fundación suiza; bloquea dominios maliciosos y │
│                 │ 149.112.112.112  │ no registra tu IP.                             │
├─────────────────┼──────────────────┼────────────────────────────────────────────────┤
│ OpenDNS (Cisco) │ 208.67.222.222   │ Bajo rendimiento y telemetría; tiene           │
│                 │ 208.67.220.220   │ FamilyShield (208.67.222.123, 208.67.220.123). │
└─────────────────┴──────────────────┴────────────────────────────────────────────────┘

Existen muchas características de un DNS a considerar: privacidad, nivel de protección, velocidad, entre muchas otras. Sin embargo, en cuanto a la velocidad, puedes verificar el tiempo de conexión a cada uno con el siguiente comando.

dig @1.1.1.1 d4rk-sh3ll.ninja +stats | grep "Query time"

Caché

No todas las consultas recorren la jerarquía completa. Las respuestas se guardan temporalmente en el navegador (caché), el sistema operativo y el resolver, durante el tiempo que indica el TTL (Time To Live) del registro. Por eso un cambio de DNS "tarda en propagarse": muchos equipos siguen usando la respuesta vieja hasta que su caché expira. Ese mismo caché es lo que ataca el DNS cache poisoning, donde se intenta infiltrar una respuesta falsa o manipulada.

Ataques a DNS — Si la resolución de nombres cae, el servidor de origen puede estar funcionando perfectamente y aun así ser inalcanzable, porque nadie sabe a qué IP ir. El caso de referencia es el ataque DDoS contra Dyn del 21 de octubre de 2016: usando el botnet Mirai (formado por dispositivos IoT mal protegidos —cámaras, routers, DVRs—), saturaron a este proveedor de DNS y dejaron inaccesibles durante horas a Twitter, Reddit, Spotify, Netflix, PayPal y GitHub, entre otros. La lección práctica: usar más de un proveedor DNS es una medida básica de resiliencia.

TLS — Cifrado de la comunicación

Con la IP ya conocida, el navegador abre una conexión hacia el servidor mediante un socket (la combinación entre IP y puerto), donde el 443 se utiliza comúnmente para HTTPS y el 80 para HTTP sin cifrar. Esa conexión viaja normalmente sobre TCP (o sobre QUIC en HTTP/3). Véase HTTP Origins.

Si el sitio usa HTTPS, antes de enviar nada se realiza el handshake TLS, que en términos sencillos hace tres cosas:

  • Autentica al servidor: Este presenta un certificado firmado por una autoridad de confianza, que prueba que realmente es quien dice ser.

  • Acuerda el cifrado: Cliente y servidor negocian las claves con las que se cifrará la conversación, de modo que nadie en medio pueda leerla.

  • Indica a qué dominio te conectas mediante SNI (Server Name Indication), necesario cuando una misma IP aloja varios sitios.

    A partir de aquí, todo lo que viaja va cifrado. Esto es relevante en seguridad, ya que para inspeccionar ese tráfico durante una auditoría se usa un proxy de interceptación (como Burp Suite) que se sitúa en medio de la comunicación para manipular el tráfico directamente como texto plano.

HTTP Request

La petición HTTP es, en el fondo, texto estructurado. Saber leerlo y modificarlo es una de las habilidades centrales en seguridad web, porque es exactamente lo que se manipula con un proxy.

Una Request se compone de:

  • URL: Su estructura es esquema://[usuario:contraseña]@host[:puerto]/ruta?parámetros#fragmento. La ruta y los parámetros son los más relevantes en un análisis. Ya que es donde se suele encontrar la superficie de ataque.
  • Método o verbo: La "intención" de la petición, se describen los mas relevante más abajo.
  • Protocolo: La versión de HTTP: HTTP/1.1, HTTP/2 o HTTP/3. Véase HTTP Origins.
  • Cabeceras: Metadatos en pares clave-valor. Muchas decisiones del servidor dependen de cabeceras que envía el cliente. Se describen posteriormente en detalle.
  • Cookies: La cabecera Cookie, que el navegador adjunta en el contexto de una sesión; suele llevar tu identificador, lo cual se utiliza tanto para mantenerte autenticado en un sitio como para telemetría y para otras funciones y configuraciones asociadas a esta sesión.
  • Body (cuerpo): Los datos que envías (presente sobre todo en POST/PUT), con el formato que indique Content-Type (formulario, JSON, etc.).
  • Autenticación: Es cómo la aplicación valida tu identidad. Es importante hacer la distinción entre autenticación = "quién eres" y autorización = "qué tienes permiso de hacer". Los esquemas más comunes en la cabecera Authorization son:
    • Basic: Envía usuario:contraseña codificado en Base64. No es cifrado; sobre HTTP sin TLS, las credenciales viajan en texto plano recuperable de inmediato.
    • Bearer: Presenta un token (típicamente un JWT) que representa los parámetros de la sesión, tales como usuario, rol, u otros. Poseen una firma que asegura su integridad. En otra publicación se hablará en detalle de los JWT.
    • Digest: Autentica con un hash (reto-respuesta) en lugar de enviar la contraseña directa. Evita el texto plano de Basic, pero es antiguo y poco usado en aplicaciones modernas.
    • NTLM: Esquema propietario de Microsoft basado en reto-respuesta, frecuente en entornos Windows e Active Directory.

Métodos HTTP

El método declara la intención de la operación. Los principales son:

  • GET: Solicita un recurso sin modificar el estado del servidor. Sus parámetros viajan en la URL, por lo que quedan en logs e historial.
  • POST: Envía datos al servidor para crear o procesar un recurso. Los datos viajan en el cuerpo.
  • PUT: Crea o reemplaza por completo un recurso en una ruta determinada. Si está habilitado sin control, puede permitir subir archivos al servidor.
  • DELETE: Elimina el recurso indicado. Conviene verificar siempre el control de acceso sobre este método.
  • HEAD: Idéntico a GET pero el servidor devuelve solo las cabeceras, sin cuerpo. Útil para reconocimiento de forma silenciosa.
  • OPTIONS: Consulta qué métodos y capacidades admite un recurso. En el reconocimiento revela métodos habilitados y forma parte del intercambio CORS (preflight).
  • TRACE: Devuelve en eco la petición recibida. Históricamente asociado al ataque Cross-Site Tracing (XST).
  • CONNECT: Establece un túnel TCP a través del servidor, usado típicamente por proxies para HTTPS. Mal configurado, puede convertir un servidor en un proxy abierto.

Cabeceras de Petición

Algunas de las cabeceras más comunes y relevantes, que vale la pena conocer al momento de revisar un sitio, se muestran a continuación:

  • Host: Dominio solicitado. Obligatoria en HTTP/1.1 y base del virtual hosting. Manipularla habilita ataques de Host header injection y envenenamiento de caché web.
  • User-Agent: Identifica el cliente, navegador y sistema operativo. El servidor puede variar su respuesta según su valor; es un campo controlado por el cliente y, por tanto, falsificable e inyectable.
  • Referer: Indica la URL desde la que se originó la petición. Puede filtrar información sensible (tokens en la URL, rutas internas) hacia terceros.
  • Origin: Indica el origen (esquema + host + puerto) que inició la petición. Es central en CORS y en la defensa contra CSRF; a diferencia de Referer, no expone la ruta completa.
  • Cookie: Transporta las cookies de la sesión hacia el servidor. Suele contener el identificador de sesión, objetivo frecuente de robo o manipulación.
  • Authorization: Transporta las credenciales de autenticación según el esquema en uso.
  • Content-Type: Declara el formato del cuerpo (application/json, application/x-www-form-urlencoded, multipart/form-data). Cambiarlo puede alterar cómo el backend interpreta los datos.
  • Content-Length: Longitud en bytes del cuerpo. Su relación con Transfer-Encoding es la base de los ataques de HTTP request smuggling.
  • Transfer-Encoding: Indica que el cuerpo viaja en fragmentos (chunked). La discrepancia de interpretación entre servidores frontend y backend habilita el request smuggling.
  • Content-Encoding: Indica la compresión aplicada al cuerpo (gzip, br, deflate).
  • Accept-Encoding: Anuncia qué compresiones admite el cliente. Relevante en ataques de compresión como BREACH sobre respuestas cifradas.

El Servidor Web

Al otro lado escucha un servidor web. Este se trata de una aplicación o servicio en el sistema operativo de un equipo (o en un datacenter), el cual tiene una dirección IP pública y que, dentro del software de la aplicación, lee la petición y decide qué entregar de dos maneras:

  • Sirviendo un archivo del sistema (típico del contenido estático: HTML, imágenes, CSS).
  • Invocando una ruta de la aplicación definida por el código del backend (lo habitual en APIs y frameworks), donde la URL ejecuta una función en lugar de devolver un archivo.

Dentro de las aplicaciones utilizadas como servidores web, las más usadas son:

  • Nginx
  • Apache
  • LiteSpeed
  • Cloudflare Server
  • Node.js
  • Microsoft-IIS

Lenguajes de Backend

El servidor web es solo la puerta de entrada; detrás corre la lógica de la aplicación, escrita en algún lenguaje de programación con su framework asociado. Algunos de los más extendidos en la industria son:

  • Java (Spring, Jakarta EE): Común en banca y grandes empresas.

  • C# / ASP.NET: Ecosistema de Microsoft, frecuente sobre IIS.

  • PHP (Laravel, Symfony, WordPress): Domina una enorme porción de la web.

  • Ruby on Rails: Popular en startups y productos SaaS.

  • Python (Django, Flask).

  • JavaScript / Node.js (Express): Muy presentes en aplicaciones modernas y APIs.

    Esto es relevante para un análisis de seguridad porque el lenguaje y el framework condicionan la superficie de ataque. Muchas vulnerabilidades se comportan de forma distinta según la tecnología, e incluso existen clases de vulnerabilidad específicas de un lenguaje concreto (por ejemplo, ciertos fallos de deserialización asociados a Java o a PHP). Identificar la tecnología del backend durante el reconocimiento orienta qué vectores tiene sentido probar.

Bases de datos

Casi toda aplicación necesita almacenar datos de forma persistente, y para ello el backend se conecta a una base de datos. A grandes rasgos, se dividen en dos familias:

  • Relacionales (SQL): Organizan los datos en tablas con esquemas definidos y relaciones entre ellas, y se consultan con el lenguaje SQL. Ejemplos: MySQL, PostgreSQL, SQLite, Microsoft SQL Server (MSSQL) y Oracle Database. La inyección sobre estas bases es la clásica SQL Injection (SQLi).

  • No relacionales (NoSQL): No usan tablas ni un esquema rígido; almacenan documentos, pares clave-valor, grafos o columnas. Ejemplos: MongoDB, Redis, Cassandra y Neo4j. También son susceptibles de inyección, conocida como NoSQL Injection, con una sintaxis distinta a la de SQL.

    Conocer qué motor hay detrás cambia por completo la forma de un payload de inyección, por lo que identificarlo es parte del trabajo de reconocimiento.

APIs

Las aplicaciones modernas rara vez devuelven solo HTML: gran parte de la comunicación ocurre entre el frontend y una o varias APIs (Application Programming Interfaces) que exponen la lógica del backend. Los estilos más relevantes hoy son:

  • REST (Representational State Transfer): El más extendido. Usa los métodos HTTP (GET, POST, PUT, DELETE) sobre rutas que representan recursos, y suele intercambiar JSON. Su superficie de ataque se mapea bien con las técnicas HTTP habituales.

  • SOAP (Simple Object Access Protocol): Protocolo más antiguo y rígido, basado en XML y descrito mediante WSDL. Aún presente en entornos corporativos y bancarios; al usar XML, abre la puerta a ataques como XXE (XML External Entity).

  • GraphQL: Lenguaje de consulta para APIs en el que el cliente pide exactamente los campos que necesita a un único endpoint. Su flexibilidad introduce riesgos propios: introspección expuesta, consultas anidadas abusivas (denegación de servicio) y problemas de autorización a nivel de campo.

    Identificar el estilo de API y su documentación (Swagger/OpenAPI, WSDL, introspección de GraphQL) suele ser uno de los pasos más productivos del reconocimiento.

HTTP Response

El servidor responde con un mensaje que incluye un código de estado, cabeceras de respuesta, cookies y el contenido.

Códigos de estado

Tres dígitos que resumen el resultado: 1xx informativo · 2xx éxito · 3xx redirección · 4xx error del cliente · 5xx error del servidor. Para quien analiza, son pistas constantes:

  • 100: Continue. El servidor recibió las cabeceras y el cliente puede enviar el cuerpo. Aparece en envíos grandes con Expect: 100-continue.
  • 200: OK. La petición se procesó correctamente; la respuesta lleva el contenido solicitado.
  • 201: Created. Se creó un recurso nuevo (típico tras un POST/PUT exitoso); suele incluir la cabecera Location con la URL del recurso.
  • 301: Moved Permanently. Redirección permanente a otra URL. Útil en reconocimiento para detectar el dominio o esquema canónico.
  • 302: Found. Redirección temporal. Frecuente tras login; si el destino es controlable por el usuario, puede derivar en Open Redirect.
  • 304: Not Modified. El recurso no cambió desde la última petición; el cliente usa su copia en caché.
  • 400: Bad Request. La petición está malformada. A menudo es la respuesta del servidor cuando un payload rompe el formato esperado.
  • 401: Unauthorized. Falta autenticación o es inválida; suele acompañarse de WWW-Authenticate. En realidad significa "no autenticado".
  • 403: Forbidden. El servidor entiende la petición pero la rechaza. Un 403 en vez de un 404 puede delatar que un recurso existe pero está protegido.
  • 404: Not Found. No se encuentra la ruta declarada. Comparar 403 vs 404 ayuda a mapear recursos durante el reconocimiento.
  • 413: Payload Too Large. El cuerpo excede el límite del servidor. Relevante al probar subida de archivos o payloads extensos.
  • 414: URI Too Long. La URL excede el límite admitido. Puede aparecer al abusar de parámetros muy largos en la query.
  • 500: Internal Server Error. Error no controlado en el backend. Muy valioso en análisis: indica que cierto dato rompió algo y puede filtrar trazas o detalles internos.
  • 503: Service Unavailable. El servidor no puede atender la petición (sobrecarga o mantenimiento). Puede indicar rate limiting o un WAF respondiendo.

Cabeceras de Respuesta

De igual manera, a continuación se detalla en algunas de las cabeceras que devuelve el servidor, para entender que información nos entrega.

  • Server: Identifica el software del servidor y, a veces, su versión. Dato directo de reconocimiento; conviene ofuscarlo en producción.
  • Set-Cookie: Indica al navegador que almacene una cookie. Sus atributos (HttpOnly, Secure, SameSite) determinan la resistencia frente a robo de sesión y CSRF.
  • Content-Length: Longitud en bytes del cuerpo de la respuesta. Igual que en la petición, su relación con Transfer-Encoding es relevante para el request smuggling.
  • Cache-Control: Define cómo y por cuánto tiempo puede cachearse la respuesta. Una mala configuración puede almacenar datos sensibles en cachés intermedias.
  • Location: Indica la URL de destino en redirecciones (3xx) o el recurso creado (201). Si su valor depende de entrada del usuario.
  • WWW-Authenticate: Acompaña a un 401 e indica el esquema de autenticación esperado (Basic, Bearer, etc.). Revela el mecanismo de autenticación en uso.
  • RateLimit: Forma estandarizada actual para comunicar los límites de peticiones y las cuotas restantes; reemplaza a las variantes previas X-RateLimit-*. Útil para calibrar fuerza bruta y evitar bloqueos.
  • Access-Control-Allow-Origin: Define qué orígenes pueden leer la respuesta en el contexto de CORS. Un valor * o un reflejo del Origin sin validar es un fallo de configuración frecuente.
  • Content-Security-Policy: La CSP restringe desde qué orígenes se cargan scripts y recursos; es una defensa clave contra XSS. Una política laxa o mal construida reduce esa protección.
  • Strict-Transport-Security: HSTS; obliga al navegador a usar siempre HTTPS para el dominio. Su ausencia facilita ataques de degradación a HTTP.

El lado del cliente: DOM, AJAX y JSON

Cuando el navegador recibe el HTML, no lo trata como texto plano: lo convierte en una estructura de objetos navegable y modificable.

  • DOM (Document Object Model): Es la representación en memoria de la página como un árbol de nodos (elementos, atributos, texto). El JavaScript puede leerlo y modificarlo en tiempo real, lo que permite que la página cambie sin recargarse. En seguridad, la manipulación insegura del DOM con datos controlados por el usuario da lugar al DOM-based XSS.

  • AJAX (Asynchronous JavaScript and XML): Es la técnica por la cual el JavaScript hace peticiones HTTP en segundo plano (hoy típicamente con fetch o XMLHttpRequest) y actualiza solo una parte de la página, sin recargarla por completo. Es la base de las aplicaciones web modernas y multiplica la cantidad de endpoints que conviene mapear.

  • JSON (JavaScript Object Notation): Es el formato de intercambio de datos más usado hoy entre cliente y servidor. Es ligero, legible y se mapea de forma natural a objetos. La mayoría de las APIs REST intercambian JSON en el cuerpo de las peticiones y respuestas, por lo que entender su estructura es esencial para manipular tráfico durante una auditoría.

    Un detalle clave que el modelo simplificado oculta es que cargar una página no es una sola petición, sino muchas. El HTML inicial referencia decenas de recursos (estilos, scripts, imágenes, pixel trackers) y, ya en el navegador, el JavaScript puede lanzar más peticiones a APIs en segundo plano. Cada una de esas peticiones repite el ciclo completo. Para quien audita, esto significa que la superficie real de una aplicación es mucho mayor que la primera pantalla. Y recuerda: el JavaScript se ejecuta en tu propio equipo, por lo que es inspeccionable y modificable mediante las herramientas del navegador.

SOP — Same-Origin Policy

La Same-Origin Policy (SOP) es uno de los mecanismos de seguridad fundamentales del navegador. Establece que un documento o script cargado desde un origen (la combinación de esquema + host + puerto) solo puede acceder a recursos del mismo origen. Es decir, un script en https://a.com no puede, por defecto, leer las respuestas de https://b.com.

Su objetivo es evitar que un sitio malicioso lea datos de otro en el que la víctima tiene una sesión activa (por ejemplo, su correo o su banco). CORS (Cross-Origin Resource Sharing) es precisamente el mecanismo que permite relajar la SOP de forma controlada, mediante cabeceras como Access-Control-Allow-Origin. Una configuración CORS demasiado permisiva es un fallo común que rompe las garantías que la SOP busca proporcionar.

Codificaciones

En muchos casos los datos viajan codificados, y a menudo se recodifican varias veces entre capas. Reconocer y convertir entre codificaciones es una habilidad de uso diario:

  • ASCII: La tabla básica de caracteres (valores 0–127), sobre la que se construyen las simbologías.
  • Hexadecimal: Base 16; forma compacta de mostrar bytes.
  • URL: Representa caracteres especiales con % + valor hexadecimal. Definido en el RFC 3986. Así viajan los parámetros en una URL.
  • HTML (entidades): <, >, &. Es también la base de una defensa clave contra XSS.
  • Unicode: El estándar que asigna un código a cada carácter de casi cualquier idioma. Importa en seguridad por la normalización y los caracteres parecidos (homóglifos).
  • Base64: Convierte datos binarios en texto. No es cifrado: se revierte trivialmente.