¿Confías tu seguridad al XSS auditor de Chrome?

En esta entrada vamos a ver por qué no podemos confiar la seguridad de nuestra web al XSS auditor de Chrome.

Hace un tiempo ya realizamos una introducción a los ataques Cross-Site Scripting XSS. En estos el atacante utiliza las entradas de datos de un sitio web para inyectar scripts maliciosos (normalmente JavaScript) que después se ejecutarán en el navegador de otros usuarios.

Como estos ataques se basan en la entrada de datos en un sitio web, Chrome, entre otros navegadores, tiene un mecanismo de seguridad para evitarlos. El problema es que este mecanismo de seguridad tiene varios problemas según el tipo de XSS al que se enfrente.

El auditor de Chrome se ejecuta durante la fase de análisis del HTML e intenta encontrar reflejos de la solicitud en el cuerpo de la respuesta. Por lo tanto, en ningún caso podrá mitigar los ataques XSS almacenados, ya que la inyección no tiene porque producirse en la misma petición, o DOM, ya que la página en sí (la respuesta HTTP) no cambia, pero el código del lado del cliente contenido en la página se ejecuta de forma diferente debido a las modificaciones maliciosas que se han producido en el DOM.

En el caso de encontrar una posible reflexión, el auditor de Chrome puede ignorar el script malicioso, o puede bloquear la página para que esta no cargue y por el contrario aparezca una página de error ERR_BLOCKED_BY_XSS_AUDITOR.

Veamos un ejemplo. Tenemos la web de ejemplo: https://test-xss.000webhostapp.com en la cual, si introducimos el parámetro name, este aparece reflejado:

https://test-xss.000webhostapp.com/?name=donttouchmynet

Si analizamos el código vemos lo siguiente:

<script>document.write("donttouchmynet")</script>

Vemos que el contenido aparece reflejado dentro de un script. Así que, para realizar un ataque XSS reflejo, bastaría con cerrar el script actual con </script> y añadir nuestro propio script:

<script>document.write("</script><script>alert("donttouchmynet")</script>")</script>

Así que la URL sería:

https://test-xss.000webhostapp.com/?name=</script>

Si intentamos acceder a la URL con Chrome veremos que el XSS auditor nos bloquea la petición. Esto sucede ya que detecta que la ejecución de código es debido a un script enviado previamente desde la URL.

Pero, ¿Qué sucede si en lugar de cargar nuestro propio script nos aprovechamos del script actual ?

El punto de inyección, como hemos visto, es un script. Por lo tanto, podemos ejecutar código Javascript directamente. Para esto primero debemos cerrar las comillas, después el paréntesis y finalizar la línea con un punto y coma. Después de cerrar la línea, podemos escribir el código Javascript que deseemos. Una vez finalizado nuestro código añadimos // para comentar el código restante:

<script>document.write("");alert("donttouchmynet")//")</script>

Así que la URL sería:

https://test-xss.000webhostapp.com/?name=«);alert(«donttouchmynet»)//;alert(%22donttouchmynet%22)//)

Con esto podemos ver que el código se ejecuta y el XSS auditor no puede bloquearlo.

Esto es debído a que para ejecutar nuestro código nos apoyamos del código ya existente en la web y el auditor de Chrome no puede detectar la inyección.

Con esta demostración podemos ver que, el auditor XSS, además de no poder detectar ataques XSS almacenados y DOM, tampoco los podrá detectar en caso de que el punto de inyección sea un script.

En el caso de que el punto de inyección no sea un script, será más difícil poder evitar el auditor XSS, pero no imposible como ya han demostrado en varias ocasiones en brutelogic.

Por todo esto, en ningún caso podemos confiar en el auditor de Chrome como medida de protección de nuestra web.

Si queremos proteger nuestra web frente a ataques cross-site scripting, recomendamos seguir la guía de prevención de OWASP

Saludos!