Asegurando las cabeceras de respuestas HTTP en servidores web IIS
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:
0desactiva la protección1habilita la protección1; mode=blockle 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
