sábado, 22 de junio de 2013

Bypass del filtro XSS de Chrome con nombres de variable y caracteres especiales

[Artículo cedido como contribución a Security by Default]

A pesar de que el tique asignado siga privado y sin resolver a día de hoy, el equipo de Chrome me ha dado permiso para hacer público este fallo que descubrí a finales de marzo. Generalmente, los fallos que permiten bypassear el XSSAuditor de Chrome son calificados por su equipo técnico con un nivel de severidad nulo respecto a la seguridad del navegador, ya que consideran que la brecha se encuentra realmente en la página vulnerable. Tal como indicaron en el hilo de comentarios de la incidencia:

"We generally treat XSSAuditor bypasses as security non-issues, as the fault is in the server, not is ourselves."



Uno de los puntos de inyección olvidados en muchas ocasiones es el nombre de las variables en una petición web:

http://www.webvulnerable.com?coche=rojo&barco=negro



Mientras puede que te hayas vuelto loco probando ataques sin éxito en los valores "rojo" y "negro", quizá puedas ver la luz inyectando sobre los nombres de variable:

http://www.webvulnerable.com?coche<script>alert('XSS')</script>=rojo&barco=negro<script>alert('XSS2')</script>



El filtro XSS de Chrome, en principio, no debería tener problemas para parar estos ataques. Sin embargo, cuando se da este tipo de vulnerabilidad, los servidores pueden hacer ciertas transformaciones por su cuenta. En concreto, contra un servidor PHP, si introducimos uno de los siguientes caracteres en una cadena del nombre de la variable, será transformado automáticamente a un guión bajo "_":

"espacio", "[", "+", "."

El filtro de Chrome no esperará este cambio y será bypasseado. Como prueba de concepto, preparé una página con un sencillo código en el lado del servidor:


Podéis testear el bypass pulsando en el siguiente enlace:


Se puede comprobar que otros filtros XSS como el de NoScript para Firefox o el filtro por defecto de Internet Explorer sí protegen correctamente en este escenario.

Es interesante recordar que, actualmente, esta no es la única manera de burlar el filtro de Chrome en su última versión. También podemos hacerlo explotando estratégicamente más de una variable vulnerable, como  pudimos ver en este artículo, con el método descubierto por Nick Nikiforakis. En este último caso, el tique asignado fue resuelto con un "WontFix", lo que quiere decir que ni está arreglado, ni se piensa arreglar en el futuro. Una vez más, esta técnica es tratada correctamente por NoScript e Internet Explorer.

Esperemos que el equipo de Chrome no adopte como norma general restar importancia a estos casos de vulnerabilidades que son relativamente "poco comunes", ya que su acumulación podría generar un "cheat sheet" bastante molesto, y que lo dejara en mal lugar respecto a la competencia.

¡Saludos!