X-XSS-Protection HTTP Header y los filtros Anti-XSS

Cuando salió el filtro Anti-XSS en Internet Explorer 8 - el primer navegador de Internet que lo aplicó - se generó mucha polémica. El que un filtro del lado del cliente pudiera modificar el contenido que venía mostrado desde el servidor - pese incluso a que pudiera ser mediante un ataque de XSS Reflejado - levantó muchas opiniones a favor y en contra. De hecho, rápidamente los investigadores buscaron formas de saltarse el filtro e, incluso, de utilizar la manipulación del filtro para convertir páginas no vulnerables en páginas vulnerables.

Figura 1: Bugs de XSS Reflejados reportados a Apple

Hoy en día Google Chrome, Apple Safari e Internet Explorer lo implementan por defecto, pero queda en manos del usuario el poder deshabilitarlo en caso de así desearlo, sobre todo por si le da problemas al trabajar con alguna web que, más que probablemente, está mal diseñada. En un ataque de XSS, saltárselo siempre es un paso que hay que hacer, por lo que los bugs de estos filtros de seguridad se hacen también muy populares, como los casos que os he publicado por aquí en algunos artículos:

- El 0day para saltarse el Anti-XSS de Google Chrome que duró 24 horas.
- Unos trucos para pasar el filtro AntiXSS en Chrome y Safari
- Saltándose el filtro Anti XSS de Google Chrome 11

Por otro lado, al mismo tiempo que se da al usuario la posibilidad de controlar el filtro Anti-XSS, los servidores web también tienen un HTTP header que pueden enviar al navegador para habilitar o deshabilitar dicho filtro, en caso de que el usuario haya deshabilitado el filtro y el servidor web no quiera que así sea, o viceversa, es decir, en caso de que el filtro esté habilitado en el cliente y el servidor web desee que se deshabilite. Ese HTTP header es el X-XSS-Protection.

Figura 2: Filtro Anti XSS en Internet Explorer 8 modificando la web

Los HTTP headers que empiezan por X- son variables extendidas que no se encuentran dentro del estándar, pero que se pueden popularizar más o menos dependiendo de quién las utilice. De estos hay muchos, como el famoso X-Frame-Options para evitar ataques de Clickjacking, o como alguna que otra política de contenido que ya os contaré más adelante en algún post. En este caso, el HTTP header X-XSS-Protection se entendido tanto por Google Chrome, Apple Safari como por Internet Explorer desde la versión 8 hasta la actual y permite configurar el filtro Anti-XSS del navegador por medio de esta política.

Figura 3: Google Chrome permite deshabilitar el filtro Anti-XSS,
llamado XSS Auditor, por parámetros en el arranque de la aplicación

Cuando el valor del HTTP Header X-XSS-Protection de una web tiene un valor 1; mode=block, está forzando a que el filtro Anti-XSS esté habilitado en el navegador - incluso si el cliente lo ha deshabilitado -, mientras que si se configura con valor 0 se está deshailitando incluso si el cliente lo tuviera habilitado. Si no se pone el HTTP Header X-XSS-Protection con ningún valor, entonces es elección del cliente habilitar o deshabilitar el filtrado Anti-XSS, aunque por defecto casi todo el mundo lo tiene activo en Google Chrome, Apple Safari e Internet Explorer.

Figura 4: X-XSS-Protection:1 en un servidor de Google

Dicho esto, la recomendación de seguridad es forzar la activación del mismo, consiguiendo una mejor fortificación del entorno, ya que un ataque de XSS puede afectar a la seguridad de los clientes y por tanto a la seguridad del servidor web completo. Sin embargo, puede pasar que, como se ve en este caso de Facebook, temporalmente hayan forzado deshabilitarlo.

Figura 5: X-XSS-Protection 0 en un frontal de Facebook

Hacer esto tiene unos riesgos que se asumen por problemas de compatiblidad, pero que son un mal menor en un proceso de continuidad de negocio. Este HTTP Header de X-XSS-Protection = 0 en Facebook está dejando sin protección Anti-XSS a los clientes de Google Chrome, Apple Safari e Internet Explorer que se conecten a estos frontales, por lo que se deben extremar la protección contra este tipo de ataques dificultándolos con algunas otras medidas, como las Content Security Policies, algo que Facebook sí que utiliza.

Saludos Malignos!