W3Techs: Estadísticas de WebServers en Internet a finales de 2025: Nginx, Cloudflare Server & Apache

Hoy quería hablaros de la conocida W3Techs, que es un sitio especializado en el análisis y monitoreo de las tecnologías utilizadas en sitios Web a nivel mundial. Sirve como análisis de tendencias tecnológico de la infraestructura de Internet y su funcionamiento principal consiste en escanear las páginas web de Internet para detectar y registrar información sobre los sistemas de gestión de contenidos (CMS), lenguajes de programación, frameworks, servidores web, plugins, temas y otros elementos tecnológicos que emplean los sitios.

Figura 1: W3Techs - Estadísticas de WebServers en Internet a finales de 2025.

 Nginx, Cloudflare Server & Apache

Para realizar el proceso de análisis W3Techs utiliza técnicas de crawling y análisis de cabeceras HTTP, análisis del código fuente y búsqueda de metadatos para identificar la tecnología subyacente de cada sitio web. La herramienta compara los datos recopilados con una base de datos propia y, en ocasiones, integra información de fuentes externas como Alexa, Google, Tranco o IPinfo para enriquecer sus informes y tener buenos datos de tendencias tecnológicas.

Figura 2: Estadísticas de Web Servers en W3Trends

Entre todos los daos que ofrece, la plataforma tiene informes detallados sobre el uso de tecnologías en el ecosistema web, permitiendo a los usuarios, por ejemplo, consultar estadísticas de mercado, rankings de CMS, frameworks y otros elementos. Por ejemplo, puede mostrar qué porcentaje de sitios web utilizan WordPress, qué lenguajes de programación son más populares o qué servidores web predominan en la red.

Figura 3: Estadísticas de Web Servers en W3Trends por meses

De esto último quería hablaros, porque el pasado 1 de Diciembre se produjo un pequeño cambio en las estadísticas de servidores web utilizados para soportar a los sitios web expuestos en Internet, donde por primera vez Cloudflare supera a Apache como servidor web detectado en dominios. 

Figura 4: Evolución de porcentajes en Web Servers

Esto no quiere decir que detrás de Cloudflare no se encuentren otros muchos servidores Apache que lo sigan haciendo el más popular, no. Esto quiere decir que el uso de las tecnologías de Cloudflare para proteger los sitios web y los servicios digitales creados en la web, sigue creciendo..

Figura 5: Web Servers en W3Trends cruzados

por número de sitios web y sitios de alto tráfico

Además, por cada tecnología, en W3Techs se proporciona un análisis detallado de tendencias, donde se ve la evolución de, en este caso Cloudflare, con datos de uso cruzados por número de sitios y sitos de "High Traffic", como podéis ver en la Figura 5.

Figura 6: Plataforma de Workers en Cloudflare

A esto han contribuido no sólo la protección de los sitios web que ofrece Cloudflare como frontal a todos los sitios web, sino también toda la plataforma de programación y desarrollo de servicios digitales basados en Workers en Cloudflare. 

Figura 7: Despliegue en Region:Earth con Workers de Cloudflare

Esto es porque cuando un servicio digital está creado para ser global, ejecutarse cerca de los clientes tiene sentido, pero además tener protecciones que hagan que no haya un solo punto de ataque que permita ser tumbado de manera selectiva por un ataque DDoS hace que el despliegue de estos servicios se haga en "Region:Earth".

Figura 8: Evolución de Cloudflare como Web Server

En la lista, también tenéis ejemplos de sitios populares que están reportando el uso de cada una de las plataformas, donde por ejemplo se puede ver que Paypal, Linkedin, ChatGPT, X.com o Discord, por ejemplo, están reportando Cloudflare como Web Server.

Figura 9: Sitios populares usando Cloudflare Server

Al final, W3Techs funciona como una herramienta de inteligencia para analizar lo que está sucediendo en la web, que facilita el análisis tecnológico de sitios, tanto para fines informativos como para investigación de seguridad y desarrollo, pero también para dar una clara imagen de qué tecnologías están marcando la evolución de Internet, y está claro que Cloudflare está siendo una pieza clave de ello. 

• Cloudflare Radar: Open (Security & Network) Data para CERTs & CSIRTs
• Cloudflare Radar: Bots Verificados & Signed Agents Identificados con Web Bot Auth
• ¿Cuál es la mejor solución AntiDDos para defenderse de los Ataques DDoS en Internet?
• Cuánto del tráfico en Internet funciona con Post-Quantum Cryptography
• Cloudflare Pay-Per-Crawl: Un servicio que ayuda a las webs a negociar el pago por acceso al contenido que hacen los crawlers de IA
• Tu WebSite con Smart Honeypots contra el WebScrapping usando AI Labyrinth de Cloudflare

El número de tecnologías que ofrece Cloudflare a un sitio web para desarrollo, alto rendimiento y seguridad es enorme, y yo he ido publicando algún artículo sobre eso, así que por si quieres leer algo más, os dejo los otros artículos que he publicado relacionados con Cloudflare:

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Sí, un Task Manager en tu sitio web... sin darte ni cuenta!!

Hacía tiempo que no tenía tiempo de investigar algunos de los leaks que mi amigo rootkit me envía, pero aprovechando que en las siestas de verano he sacado algo de tiempo, he mirado este de WestWind Technologies que me ha resultado peculiar.

Figura 1: Un Task Manager en tu servidor web... Sin darte ni cuenta!!

A simple vista, cuando lo ves, es la típica página de administración de servicios Microsoft Internet Information Services que la propia Microsoft ofrecía desde las primeras versiones de su servidor web & FTP. En ella, se pueden ver un montón de opciones, que van desde subir ficheros, hasta tocar configuraciones del servidor, lo que puede resultar muy peligroso. No debería estar expuesta a Internet.

Figura 2: Panel de control de WestWind Technologies

Por supuesto, cuando haces clic en los enlaces, todos llevan a ficheros que están protegidos, ya que de no estarlo los servidores durarían unos segundos en la vorágine de la red, pero sin embargo, se pueden hacer cosas muy curiosas con este página web de administración que no es de Microsoft, sino de Westwind Technologies.

Figura 3: Firma que aparece en el panel del fabricante

Haciendo un poco de Hacking con buscadores con la firma que la compañía pone a sus paneles de administración web se pueden encontrar un buen número de otras herramientas de ayuda, y ejemplos de la compañía, pero yo me voy a centrar en la original.

Figura 4: Buscando paneles de Westwind indexados en Google. Bing y Shodan dan aún más.

Aquí tenéis otro de los paneles de Westwind Technologies con muchas Demos "peligrosas" que recuerdan a los ejemplos que instalaba Microsoft FrontPage en Server-Side.

Figura 5: Otro panel de Westwind Technologies con "Demos" jugosas

En la página original, lo primero que llama la atención es que se puede acceder a la ruta de instalación del software, lo que ya es un leak en sí mismo que puede ser de utilidad en ataques LFI o RFI, como hemos visto en tantas ocasiones (véase Hacking Web Technologies).

Figura 6: Ruta de instalación del sitio web

La segunda cosa que llama poderosamente la atención es que hay un buscador de procesos... What?. Sí en la parte inferior del panel puedes poner una letra por la que quieres filtrar, y accedes a la lista completa de los procesos del sistema - más los del servicio web - que están corriendo, con su PID incluido si pasas el ratón por encima de la opción de matar el proceso, ya que lo usa como parámetro POST.

Figura 7: Lista de procesos que comienzan por s

Con ello, puedes averiguar todo el software de seguridad que está en ejecución, pero también si tiene DNS, servicios extras, etcétera. En este ejemplo se puede ver que este servidor utiliza un antivirus avp.exe que apunta directamente a Kaspersky.

Figura 8: Procesos del antivirus avp.exe

Pero también se puede saber si el administrador de este sitio navega, como en este caso, donde se puede ver cómo se está utilizando el web browser de Moxilla Firefox. Todo esto es debido a que el formulario que refresca la lista de procesos no está llamando a ningún otro fichero del servidor web, sino que es una petición directa sobre la página web que estamos visitando. Es decir, es el propio panel el que gestiona las llamadas al sistema para acceder a la lista de procesos. Y además hay opción de parar procesos, o actualizar constantemente para ver si hay cambios.

Figura 9: Procesos de Firefox

En la imagen superior se puede ver cómo el administrador ha dejado de utilizar Firefox, o bien alguien ha matado los procesos, o simplemente ha cambiado de navegador de Internet. Si alguien pudiera matar desde un sitio web un proceso - incluso los de los vhosts - corriendo en escritorio daría medida de cuáles son los privilegios con los que corre el sitio web (probablemente sin Application Pool), el servicio web, y la falta de uso de niveles de integridad - luego apuntaría a versiones de Windows concretas -.

Figura 10: Procesos de Firefox cerrados

Lo cierto es que estos paneles de Westwind Technologies son de gran utilidad para muchos administradores web, pero nunca, nunca, nunca, deberían estar expuestos a Internet sin estar protegidos por credenciales.

Saludos Malignos!

Pon un "Referrer Policy" y mejora la seguridad de tu web

Una de las opciones que se puede configurar a nivel de hipervínculo, de documento o de servidor web en los navegadores es el funcionamiento de la política para el HTTP Header "Referrer", para mejorar la seguridad de una aplicación web. Para entender en qué consiste esta política, primero hay que hacer un pequeño resumen de cómo funciona el campo HTTP Referrer que se envía desde los navegadores que cada vez que se hace clic en un hipervínculo de un documento HTML.

Figura 1: Pon una "Referrer Policy" y mejora la seguridad de tu aplicación web

La idea es que cuando se llega a un sitio al que llamaremos URI_destino, a través de hacer un clic en un enlace en un sitio al que llamaremos URI_origen, el navegador envía una cabecera HTTP al servidor URI_destino que se identifica como "Referrer" y donde se encuentra la dirección absoluta o relativa del URI_origen donde estaba el enlace que le llevó al lugar en que el navegador está ahora.

Figura 2: IETF RFC 7231 sección Referrer Header

Esto puede ser muy útil o muy peligroso si no se controla, ya que se podrían enviar direcciones internas de sistemas privados, o direcciones URL de aplicaciones privilegiadas que necesitan de unas credenciales para entrar a sitios no deseados. El uso de esta cabecera no se creo pensando en los posibles riesgos de seguridad, sino como se recoge en el RFC del IETF, para que los administradores de los sitios pudieran hacer estadísticas, crear backlinks, etc...

Figura 3: Campo Referrer enviado desde el cliente con una URL completa

Sin embargo, tiene una fuerte implicación en la seguridad, y alguien podría plantear un ataque de CSRF (Cross-Site Request Forgery), XSPA (Cross-Site Port Attack), o simplemente de phishing, a través de las direcciones URL que quedaran filtradas en las cabeceras HTTP Referrer que envían los navegadores de Internet. Para mitigar esta problemática existen varias configuraciones distintas.

Políticas Referrer: Configuraciones

Como se puede ver a continuación, se pueden establecer diferentes políticas de seguridad para evitar que la URL con los parámetros y sus valores - donde pueden filtrarse nombres de usuarios, directorios privados, cookies de sesión o información sensible de una organización - acaben en las estadísticas de un sitio remoto o en las manos de un tercero. Los valores que pueden configurarse en las políticas Referrer son los siguientes, y cada uno forzará un comportamiento diferente en el navegador.

- no-referrer: En este caso, no se enviará nunca el HTTP Header Referrer desde el cliente. 

- no-referrer-when-downgrade: Este es el valor por defecto en muchos navegadores y consiste en que se envía Referrer con la URL de la web si el destino es igual o más seguro. Es decir,  se envía cuando el hipervínculo va de una página HTTP a una página HTTP, cuando va de una página HTTP  a una página HTTPs y cuando va de una página HTTPs a una página HTTPs, pero no cuando va de una página HTTPs a una página HTTP.

Figura 4: Ejemplos no-referrer-when-downgrade en Mozilla

- origin: Con este modificador, el valor Referrer que se envía no especificará la dirección URL completa, y solo llevará en nombre del dominio y el protocolo. Es decir, se elimina el Path de la dirección URL de origen del hipervínculo. 

Figura 5: Ejemplo con valor origin

- origin-when-cross-origin: En este caso, cuando el hipervínculo es dentro del mismo dominio, se envía la URL completa, y cuando el hipervínculo es a otro origen, se envía entonces solo el dominio y el protocolo de la URL, sin el Path.

Figura 6: Ejemplos de origin-when-cross-origin

- same-origin: Con este valor, el HTTP header Referrer se enviará cuando el hipervínculo sea dentro del mismo dominio y no se enviará cuando sea entre distintos dominios.

Figura 7: Ejemplos con same-origin

- strict-origin: Solo se envía en el Referrer el origen del hipervínculo (solo el dominio y el protocolo de la URL sin el path) a un destino más seguro. Nunca en un hipervínculo HTTPs-HTTP.

Figura 8: Ejemplos con strict-origin

- strict-origin-when-cross-origin: Se envía en Referrer la URL completa a un destino dentro del mismo dominio más seguro, y solo el dominio y el puerto a un destino igual o más seguro, pero nada a un destino menos seguro.

Figura 9: Ejemplos con strict-origin-when-cross-origin

- unsafe-URL: En este caso, se envía la URL completa a cualquier destino pero sin valores en los parámetros de la URL (para evitar el envío de nombres de usuarios, cookies de sesión o información sensible).

Políticas Referrer: Establecimiento de política

La primera forma de configurar el comportamiento del navegador con los campos Referrer es a nivel de documento HTML con el uso de una META Tag llamada Referrer donde se establece una política para todos los hipervínculos que se generen - tanto de forma estática como de forma dinámica - desde esa URL.

Figura 10: Algunos valores de la Meta Tag "referrer" en HTML

Añadir un código Javascript que configure la política de tu aplicación web que tú quieras sería algo como lo que tienes en la imagen siguiente, y te permitiría automatizarlo en todas las webs si lo introduces en alguna de las librerías que uses siempre.

Figura 11: Configuración de Meta Tag Referrer desde Javascript

Si no se ha establecido la política a nivel de META Tag, ésta se puede cambiar a nivel de hipervínculo en la etiqueta "A" con el atributo rel="noreferrer", que permitiría evitar en un enlace filtrar la URL de la ubicación del enlace actual.

Figura 12: atributo "noreferrer" en hipervínculos

Éste, como se puede ver en la imagen siguiente suele ir acompañado del modificador noopener que evita ataques de phishing en enlaces con target=_blank, como ya os conté hace tiempo, y que pueden ser muy peligrosos para la seguridad de tu sitio web.

Figura 13: HTTP Header Server-Side "Referrer-Policy"

Por último, y esto es algo que es bastante novedoso, se puede utilizar un HTTP Header llamado Referrer-Policy a nivel de servidor web, para que el propio servidor, sin necesidad de que una aplicación web manualmente lo configure, pueda establecer la política que considere adecuada.

Figura 14: HTTP Header Server-Side "Referrer Policy"

En la Figura 14 se puede ver cómo el servidor envía este Header para establecer cuál es la política que se quiere configurar en el navegador. Y utilizando el servicio de Security Headers puedes comprobar si un determinado sitio la está utilizando o no.

Figura 15: Referrer-Policy en Security Headers

Reflexiones finales

Lo importante de esto es que entiendas que cualquier enlace - ya sea dinámico o estático - que no tenga una política Referrer controlada puede ser un leak de información. Si tienes una aplicación web que permite a usuarios inyectar código HTML y generar hipervínculos, o tu aplicación genera enlaces a partir de información dinámica, y no tienes controlada la política Referrer a nivel de enlaces, documentos o servidor web, puedes estar abriendo la puerta a ataques que no te esperas.

Dentro del proceso de fortificación de una aplicación web debes tener en cuenta estas opciones, y por supuesto, si lo que estás haciendo es una auditoría de seguridad o un pentesting, deberías informar al cliente de cuál es el nivel de la política que tiene establecida. Nosotros en nuestro sistema de pentesting persistente Faast miramos con cariño la políticas políticas de fortificación, que van desde los Referrers, la configuración SRI, los filtros AntiXSS y Anti-ClickJacking, las fugas por Metadatos, etcétera,  para reportar una alerta si no están controladas las opciones de fortificación.

Saludos Malignos!

Análisis de un HPP (HTTP Parameter Pollution) en Apple @Owasp #Apple #HPP #pentesting

Las técnicas de HPP (HTTP Parameter Pollution) llevan ya un tiempo entre nosotros. Fueron publicadas por Stefano Di Paola y Luca Carretano en la conferencia OWASP 2009, y desde entonces han sido utilizadas en muchos ataques distintos. Se basan en conseguir un comportamiento anómalo en las aplicaciones web duplicando (polucionando) los valores de los parámetros de entrada. Es decir, vamos a suponer que una aplicación recibe el parámetro1 con valor 23. Lo que se preguntan las técnicas de HPP es... ¿Qué pasa si le enviamos a la aplicación web el parámetro1 dos veces con valores 23 en el primero y 24 en el segundo? ¿Usará el primero? ¿El segundo? ¿Todos?

Figura 1: Análisis de un HPP (HTTP Parameter Polluiton) en Apple.com

Con esa idea de polucionar los parámetros, en este caso los parámetros de las cadenas de conexión a bases de datos, construimos las técnicas de Connection String Parameter Pollution [PDF] que me tocó explicar en detalle en el libro de Hacking Web Technologies. Todo partió de la idea de polucionar todo lo que teníamos por delante, gracias a la aparición del HPP, y de eso hablamos Stefano y yo cuando nos conocimos. 

Figura 2: Comportamiento con parámetros polucionados según las tecnologáis

En el caso de las aplicaciones web, el comportamiento que se va a obtener en cada caso depende de la tecnología de backend que tengamos. Según el estudio inicial realizado, esta tabla sería la lista de casos que se esperan cuando se poluciona un parámetro en el QueryString de una aplicación web.

Un bug de HPP en los foros de Apple

Nosotros tenemos un plugin en nuestro sistema de Pentesting Persistente Faast creado exclusivamente para descubrir este tipo de bugs, y a veces te lo encuentras de forma muy sencilla en sitios como los Foros de Apple, como es el caso de hoy.

Figura 3: El buscador de temas por etiquetas en los foros de Apple

Vamos a ver este ejemplo en detalle. En esta imagen tenemos la lista de etiquetas con las que han sido marcados los diferentes temas del foro. Con el interfaz, basta con seleccionar una de las etiquetas para ver que queda añadida el QueryString con el parámetro tags que coge como valor el de la etiqueta pulsada. Esta etiqueta es pintada en el buscador y recibimos la lista de temas que la tienen asignada.

Figura 4: Se elige la etiqueta, se envía en el Querystring, se imprime y salen los artículos

Esto es un funcionamiento normal y habitual, pero quería remarcarlo para explicar que hay una aplicación en el backend que está recibiendo el QueryString, extrayendo el valor de tags, buscando los temas y pintando la página de respuesta en función del valor de tags.

Si seleccionamos dos etiquetas, vemos que la aplicación está preparada para ello, añadiendo las dos etiquetas en el mismo parámetro tags separándolas por el operador de suma. Algo bastante habitual. Esto significa que la aplicación en el backend está preparada para procesar el string que le llega en el parámetro tags y sacar la lista de etiquetas.

Figura 5: Comportamiento con selección múltiple de etiquetas

Pero ¿qué pasaría si polucionamos el parámetro tags? Pues bien, en este caso la tecnología del backend ha generado una lista con todos los valores separados por commas. Esto es interesante, porque cuando el QueryString ha procesado la lista CSV (Comma Separated Values) generada en el parámetro tags, ha sido capaz de descubrir las dos tags, pero luego no ha sido capaz de imprimirlas correctamente.

Figura 6: Comportamiento con polución del parámetro tags

Esto quiere decir que la tecnología en el backend está generando una lista CSV con los valores de los parámetros polucionados, que la aplicación en el backend está preparada parcialmente para procesarlos, y parcialmente no está preparada. 

¿Es esto un bug? 

Visto el entorno, no parece que sea un "security bug" de ninguna manera, pero sí que existen casos sin controlar, por lo que podría darse una situación no deseada más allá del fallo de impresión de las etiquetas en el campo de texto en otros entornos, como ya se ha visto con estos bugs de HPP en el pasado.

Corolario tecnológico

Para terminar, tras ver que se generaba una lista de valores separada por comas, siguiendo la tabla de casos publicada en HPP, decidí comprobar si había algún cambio, así que pasé por BuiltWith el sitio web para ver qué tecnologías son las que hay detrás y que han generado este comportamiento.

Figura 7: Tecnologías detrás de Forum.Apple.com

Como podéis ver, sale que es un Apache con J2EE, que no estaba contemplada en la tabla, pero que si nos basamos en este comportamiento funciona igual que un servidor IIS o un servidor Apache con Python.

Saludos Malignos!

Paint.NET en metadatos de Internet Information Services #Microsoft #metadata #IIS

Hoy domingo os voy a traer un post con sólo una curiosidad - que hoy ya habrá mucho denso que leer con eso de ser día de elecciones generales - sobre el mundo de los metadatos que descubrimos revisando en Eleven Paths los resultados de un escaneo hecho con Faast, nuestro sistema de Pentesting Persistente. Se trata en este caso de un metadato que aparece en la imagen que se utiliza por defecto en los servidores Microsoft Internet Information Services 8.5 y que apuntan a que ha sido creada con el software Paint.NET, tal y como se dio cuenta nuestro compañero Ioseba Palop que siempre anda con el ojo abierto.

Figura 1: Paint.NET en metadatos de IIS 8.5

Como podéis ver, la imagen es un fichero en formato PNG que, a pesar de lo que muchos puedan pensar, también tiene sus propios metadatos. De hecho, en MetaShield Protector es una de las cosas que miramos en todas las imágenes para poder evitar que se filtre información como los programas que se están utilizando.

Figura 2: Imagen de Microsoft para los servicios IIS 8.5

El que se conozca el software en uso puede abrir un problema de seguridad, al poderse descubrir alguna vez algún fallo relativo a él. No hay que irse muy lejos en el tiempo para ver cómo un software de tratamiento de imágenes se convirtió en la peor pesadilla para la seguridad de las empresas con el 0day de ImageMagick que afectó a tantos servidores GNU/Linux.

En otras ocasiones, el problema de que se conozca el software que está en uso es más reputacional que otra cosa, ya que puede dejar mal a la compañía por su posicionamiento público o peor, que se descubra que se está utilizando una copia pirata del software para la que la compañía no tiene licencia.

El caso de la imagen de IIS 8.5

Si analizamos esta imagen con un editor hexadecimal podemos ver que en la cabecera del fichero ya aparece el nombre del software Paint.Net dentro del mismo.

Figura 3: Head del fichero PNG

Si queremos hacer un análisis más detallado, podemos usar cualquier software de análisis de ficheros PNG, en este caso Inspect PNG de Simon Strandgaard para OS X y está disponible dentro de Mac App Store.

Figura 4: Inspect PNG para OS X

Como se puede ver, dentro de los metadatos es posible acceder al nombre del software que ya habíamos visto. El software en concreto es Paint.Net, una popular herramienta gratuita que es freeware y vive de donaciones.

Figura 5: El software utilizado es Paint.NET v3.5.10 (no es la última versión)

Así que esperamos que los ingenieros de Microsoft que la hayan utilizado, hayan puesto algo de los fondos que normalmente estas compañías destinan para donar a los creadores de software independientes, dentro de las arcas de los creadores de Paint.Net. O mejor, ¿y si se cambiara Paint por Paint.Net en futuras versiones de Windows?

Saludos Malignos!

Security Headers & SRI Test: Para los bookmarks

Cuando estas revisando la seguridad de la infraestructura expuesta en Internet de una organización, como hacemos nosotros con Faast, se deben revisar todos los detalles. Fugas de información, configuraciones inseguras, vulnerabilidades o cualquier otra debilidad que pueda ser utilizada por un atacante para afectar la seguridad de la organización, ya sea de forma directa o encadenando varios fallos. Como sabéis, miramos cosas como los leaks de información por culpa de los metadatos, los fallos OWASP, la calidad de los certificados digitales, las versiones de software, etc...

Figura 1: Security Headers & SRI Test. Para los favoritos

Para hacer tests puntuales de seguridad en la web, existen muchas utilidades que puntualmente puedes utilizar para ello. Desde revisar los archivos que tiene una web enviándolos a Virus Total, revisar la configuración de los certificados digitales con SSL Server Test de Qualys o usar nuestro MetaShield Analyzer para revisar los metadatos de los documentos públicos de una web. Son útiles para pruebas puntuales porque se ofrecen desde la nube y te permiten ver rápidamente la información relevante de un determinado aspecto.

Security Headers para comprobar tus HTTP Headers

Hoy os traigo un par de webs que sirven para revisar algo de forma rápida. La primera de ellas es Security Headers, que revisa algo que es muy útil en la configuración de un sitio web que quiere ser robusto frente a todo tipo de ataques. Son los HTTP Headers que un servidor envía a un navegador para fortificar la plataforma. 

Figura 2: Revisión de Security HTTP Headers en Google.com

Basta con poner el nombre del sitio y obtener información de cómo están configurados los HTTP Headers relativos a la seguridad del sitio. Algunos de los más importantes ya los hemos tratado en multitud de artículos, por lo que os dejo algunas referencias:

- Server: Este header puede ser muy "verbose" y llegar a dar la información de la versión exacta del servidor, así que su revisión es más para evitar fugas de información que para configurar algo robusto en el cliente. 

- X-Powered-By: Normalmente este campo también puede ser una fuente de información de leaks que informe al visitante del framework con que se construye una web.  

- X-Frame-Options: Este header es para fortificar el navegador frente a ataques de ClickJacking. 

- X-XSS-Protection: Esta cabecera sirve para que el servidor fuerce el uso del filtro AntiXSS en el navegador. También, por supuesto, para deshabilitarlo. 

- X-Content-Type-Options: Los navegadores, sobre todo al principio, intentaban averiguar el tipo del documento que estaban cargando independientemente de su extensión. Esto era un problema con sistemas de correo electrónico donde archivos HTML enviados como TXT se acababan ejecuntando en el navegador. Con este header el servidor le puede decir al navegador que no intente averiguar el MIME Type del documento. 

- Strict-Transport-Policy: Es la cabecera que se utiliza para configurar las funcionalidades de Certificate Pinning disponibles en el protocolo HSTS. 

- Access-Control-Allow-Origin: Es el header que configurar la política CORS (Cross-Origin Resource Sharing) que indica de qué puntos se puede cargar o no cierto contenido. 

- CSP (Content Security Policies): Son los headers que se usan para configurar de forma completa cómo debe ser la ejecución de los contenidos de una web. Desde carga de contenido script, plugins o servidores a utilizar.

SRI Test para comprobar SubResource Integrity

La segunda de las webs que os dejo, de diseño similar, se encarga de revisar la política SRI (SubResource Integrity) de la que os hablé hace no mucho. En esta web - SRI Test - se comprueba si hay algún archivo de un servidor tercero que tenga o no configurada los hashes de integridad para evitar cargar contenido manipulado por un atacante.

Figura 3: SRI Test en Apple.com. Ninguna protección SRI pero ninguna
carga de contenido de fuera del dominio apple.com

Al final, son dos pequeñas utilidades que te pueden ayudar a revisar la configuración de tus sitios web expuestos a Internet y recibir algunas recomendaciones de fortificación que son útiles y que si no las conoces te pueden ayudar.

Saludos Malignos!