Asegurando las cabeceras de respuestas HTTP en servidores web IIS

Josmell Chavarri
Feb 6, 2018 · 5 min read

En el artículo Asegurando las cabeceras de respuestas HTTP en servidores web Apache y NGINX realizamos algunos cambios a las cabeceras de respuestas HTTP en estos servidores web. Ahora toca el turno de realizar algunas configuraciones que se pueden realizar en los servidores web IIS, con el fin de tener una mejor postura de seguridad en nuestros sistemas operativos de Microsoft.

Antes de comenzar me gustaría compartir algunos datos que desde Guayoyo Labs hemos venido estudiando, con respecto a los servidores web más utilizados actualmente. Realizando una simple búsqueda en Shodan podemos obtener un aproximado de los servidores web IIS, APACHE y NGINX que actualmente se encuentran expuestos y que al igual que nosotros, cualquier posible atacante tiene acceso a esta información.

Viendo la cantidad de servidores, podríamos preguntarnos en cuántos de éstos podríamos obtener información sobre versiones o software que se está ejecutando a través de las cabeceras de las respuestas HTTP.

Para configurar las cabeceras HTTP en los servidores de Windows, debemos cumplir estos tres pasos:

1.- Abrir el Administrador de IIS

2.- Seleccionar el sitio al que se desea agregar el encabezado

3.- Seleccionar “HTTP Response Headers”

Content Security Policy

El encabezado CSP le permite definir una lista blanca de fuentes de contenido aprobadas para su sitio. Al restringir los activos que un navegador puede cargar para su sitio, como JS y CSS, CSP puede actuar como una contramedida efectiva para los ataques XSS.

HTTP Strict Transport Security (HSTS)

HSTS permite decirle a un navegador que siempre quiere que un usuario se conecte usando HTTPS en lugar de HTTP. Esto significa que cualquier marcador, enlace o dirección, forzará a los usuarios a usar HTTPS, incluso si especifican HTTP.

X-Frame-Options

El encabezado X-Frame-Options ( RFC ) protege a los visitantes contra ataques de clickjacking. Un atacante puede cargar un iFrame en su sitio y establecer su sitio web como la fuente. Es bastante fácil, por ejemplo: <iframe src="https://tudominio.com"></iframe>.

Posibles valores para la cabecera X-Frame-Options:

DENY: Esta configuración es la más restrictiva e impide que la página del sitio se incluya en un iFrame. Esta opción es óptima si no tiene usuarios válidos para un iFrame.
SAMEORIGIN: Si una página padre es para el mismo dominio que la página del sitio, la página del sitio puede incluirse en el iFrame.
ALLOW-FROM: Puede especificar un URI única permitida para enmarcar la página del sitio.

X-Xss-Protection

Este encabezado se usa para configurar la protección contra un XSS reflejado. Las configuraciones válidas para el encabezado son:

  • 0 desactiva la protección
  • 1 habilita la protección
  • 1; mode=block le dice al navegador que bloquee la respuesta si detecta un ataque en lugar de desinfectar el script.

X-Content-Type-Options

Esta cabecera sólo tiene un valor válido, nosniff. Impide que Google Chrome e Internet Explorer intenten detectar el tipo de contenido de una respuesta distinta de la que el servidor declara.

Removiendo cabecera “Server”

Una de las cabeceras que es importante eliminar es la “SERVER”. Este encabezado muestra la versión del servidor web que se está ejecutando. Esta información sería un buen punto de inicio para un atacante, ya que podría investigar todas las posibles vulnerabilidades que estén asociadas a esa versión y realizar ataques más efectivos.

Para realizar este trabajo necesitamos tener instalado la extensión URL-Rewrite, luego nos dirigimos al administrador, seleccionamos nuestro sitio y luego reescritura de URL.

Seleccionamos la variables de servidor y agregamos una nueva variable llamada RESPONSE_SERVER

Luego de que tengamos la nueva variable de servidor, regrese a la página de reglas, agregue una nueva regla y seleccione una regla de salida en blanco.

Coloque el nombre a la regla, el nombre de la variable es RESPONSE_SERVER y colocar el patrón en * , esto es para que coincida con cualquier contenido que tengamos en nuestros servidor web. Luego “aplicar” y listo, se crea la nueva regla.

Como resultado obtendremos algo como esto:

Como vemos para IIS se realizaron muchos más pasos, pero igual se logró eliminar esa información que sería útil para un atacante. Con esto estaríamos agregando una capa de seguridad a nuestro servidor web, y por ende mejoraríamos la postura de seguridad de los sistemas que se ejecuten en ese servidor web.

Artículo relacionado:

Asegurando las cabeceras de respuestas HTTP en servidores web Apache y NGINX

Josmell Chavarri

Written by

Especialista en Seguridad de la Información. Co-Fundador de @GuayoyoLabs #Venezolano “Lee y conducirás, no leas y serás conducido”.

Guayoyo

Guayoyo

Blog oficial de Guayoyo — Anuncios, actualizaciones, noticias e información de interés

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade