Fingerprinting web

Cuando un servidor web exponía directamente su banner, identificarlo podía parecer una lectura de cabeceras. Las arquitecturas actuales interponen CDN, terminadores TLS, WAF, balanceadores, proxies y plataformas gestionadas antes de llegar a la aplicación. Cada capa puede añadir, retirar o falsificar señales. El fingerprinting moderno consiste en reconstruir esa cadena, no en asignar un producto a toda la respuesta.

El objetivo es identificar tecnologías que cambien una decisión posterior: cómo dirigir la petición, qué rutas son plausibles, qué cliente reproduce el protocolo o qué hipótesis de versión merece validación. Terminación TLS, servidor HTTP, entorno de ejecución, framework, CMS y librerías se registran como componentes separados. La confianza aumenta cuando coinciden señales independientes y disminuye cuando todas proceden del mismo intermediario.

Empieza por una petición que no siga redirecciones. curl -sS mantiene visibles los errores, -D guarda las cabeceras y -o el cuerpo:

curl -sS \
  -D first-response.headers \
  -o first-response.html \
  BASE_URL

Registra el código y la cabecera Location. Una redirección puede cambiar de HTTP a HTTPS, añadir www, mover la petición a un proveedor de identidad o seleccionar otra aplicación. Para observar toda la cadena, añade -L. --max-redirs 10 limita el número de saltos y -w imprime la URL final:

curl -sS -L --max-redirs 10 \
  -D redirect-chain.headers \
  -o final-response.html \
  -w '%{url_effective}\n' \
  BASE_URL

No compares la primera respuesta de un endpoint con la final de otro. Conserva cada salto cuando la infraestructura de redirección forme parte del mapa.

Una matriz de evidencias evita confundir producto, versión e intermediario:

El certificado actual se obtiene con el flujo explicado en información de dominios. Para HTTP, revisa también cookies, Link, políticas de seguridad, nombres de ficheros JavaScript y rutas de APIs. Un prefijo /wp-content/ apoya la hipótesis de WordPress. Una referencia a /wp-json/ que responde de acuerdo con la API añade otra señal. La cabecera X-Powered-By: PHP solo identifica una tecnología publicada por esa respuesta.

Los errores controlados pueden aportar firmas, pero cambia una variable cada vez. Una petición a una ruta inexistente permite comparar la página 404 con la respuesta normal. Enviar métodos o cuerpos arbitrarios puede activar lógica de aplicación y deja de ser una simple observación de cabeceras.

WhatWeb aplica plugins de firmas. Una ejecución sin opciones utiliza el nivel de agresividad 1, que realiza una petición por objetivo y sigue redirecciones. Antes de aceptarla, conserva manualmente la primera respuesta para saber si la firma pertenece al origen inicial o al destino final:

whatweb BASE_URL

--log-json guarda resultados estructurados para correlacionarlos sin analizar el formato visual:

whatweb --log-json=whatweb.json BASE_URL

El nivel -a 3 realiza peticiones adicionales cuando las firmas lo necesitan. Úsalo después de entender qué falta en el primer resultado:

whatweb -a 3 --log-json=whatweb-active.json BASE_URL

WAFW00F intenta detectar productos WAF mediante respuestas y comportamiento conocidos:

wafw00f BASE_URL

Un resultado positivo identifica una firma compatible, no la ruta exacta de todas las peticiones. Un resultado vacío conserva la posibilidad de un WAF personalizado, una política que solo se activa con determinados probes o un intermediario configurado sin marcas.

Nmap puede reutilizar el endpoint ya confirmado. -p PORT limita el puerto, -sV activa la detección de versiones y --script http-headers solicita cabeceras mediante NSE:

nmap -sV -p PORT --script http-headers TARGET_IP

La página de Nmap explica privilegios, detección de versiones, NSE y lectura del resultado. Si la aplicación depende de un hostname, una petición por IP puede seleccionar el host virtual equivocado.

Nikto también dispone de pruebas de identificación. -h fija el endpoint y -Tuning b selecciona la categoría de identificación de software:

nikto -h BASE_URL -Tuning b

Esa categoría puede generar muchas más peticiones que curl o WhatWeb en su nivel inicial. Revisa la versión, el número de solicitudes y cada hallazgo. La afirmación «software obsoleto» depende de la base de firmas y puede ignorar backports de seguridad.

Separa tres niveles:

• observación: Server: Apache/2.4.57
• hipótesis: Apache genera o reenvía la respuesta
• validación pendiente: producto real, paquete de distribución, parches y componente afectado

Una versión publicada no demuestra que una vulnerabilidad sea aplicable. Un banner suprimido no demuestra ausencia. Los proxies pueden insertar cabeceras, los CMS permiten personalizar rutas y los paquetes de distribución conservan un número base mientras incorporan parches.

El resultado útil es un conjunto de tecnologías con evidencias, confianza y preguntas siguientes. Las rutas y scripts encontrados alimentan el crawling. Los nombres nuevos vuelven a hosts virtuales o a la enumeración de dominios.

Si WhatWeb identifica un framework y el contenido manual no muestra su señal, localiza el plugin que produjo el match y reproduce su condición. Si Nmap informa de un servidor diferente al banner de cURL, comprueba hostname, SNI, redirecciones y puerto. Si la firma solo aparece después de provocar un error, registra esa petición como origen de la evidencia en vez de atribuirla a la respuesta normal.

La versión exacta exige una señal que realmente varíe entre versiones: un asset con hash conocido, un endpoint introducido en una release, un comportamiento documentado o acceso al paquete. Un favicon, una cookie o una estructura de ruta pueden identificar una familia sin separar sus versiones. Esa granularidad debe quedar visible para que la búsqueda de vulnerabilidades no parta de una precisión inventada.

• OWASP WSTG: Fingerprint Web Server
• OWASP WSTG: Fingerprint Web Application Framework
• WhatWeb
• WAFW00F
• Nmap NSE: http-headers
• Nikto