Aprovechando parámetros GET para ejecutar un XSS reflejado

Imaginemos que estamos en un tienda virtual y nos topamos con un formulario de búsqueda que solicita dos campos, categoría y producto respectivamente, ademas, usa el método GET del protocolo HTTP para enviar los datos, es decir , usa la url, algo parecido a lo que se ve en la siguiente imagen para ser mas precisos:

Podemos ver claramente que el script php que va a procesar este formulario (Atributo action del formulario) es "vulnerable.php", cuyo código fuente es el siguiente:

¡Bueno!, es claro que no se necesita ser un genio para entender que este código es vulnerable a XSS reflected, a simple vista se puede notar que las variables $categoria y $producto pueden ser manipuladas por un usuario malintencionado y por ende llevar a la ejecución arbitraria de código del lado del cliente, pero echemos mejor un ojo a las siguientes imágenes:

En este primer caso no se ve riesgo alguno, ya que lo que se paso vía get desde los parámetros categoría y producto, fue "juguetes" y "Cubo de rubik" respectivamente, pero, ¿qué pasa si enviamos en cualquiera de los parámetros algo como esto:

<script>alert(/XSS HERE/)<script>

Pues probemos, pero ahora no usemos el formulario, si no que directamente modifiquemos la url y manipulemos los parámetros categoría y producto, es decir, hagamos que nuestra url tenga un aspecto parecido a este:

http://domain/vulnerable.php?categoria=<script>alert(/XSS HERE/)</script>&producto=<script>alert(/XSS HERE/)</script>

Esto es lo que obtenemos si visitamos nuestra url desde el navegador firefox:

¡Bingo!, hemos logrado ejecutar código javascript, si ese enlace se lo enviamos a una persona y lo visita, el limite de lo que podemos lograr hacer es directamente proporcional al grado de sofisticación de nuestro script inyectado, para fines prácticos el mio solo muestra un alert :P.

Pero, y si el navegador es google chrome? pues nos jodimos temporalmente, porque gracias a la inexistencia de la cabecera X-XSS-Protection dentro del código vulnerable, el XSS-Auditor de chrome bloquea automáticamente este intento de Cross-Site-Scripting y no ejecuta nuestro hermoso alert :( como se observa en la siguiente imagen:

Auditor XSS de chrome, evitando se ejecute nuestro alert

Pero epa, les dije que la joda era temporal así que intentemos ver si logramos hacer saltar ese alert... Sabemos que nuestro código imprime nuestras dos variables get (Categoría y Producto), así que usemos el poder del conjunto he intentemos armar una carga útil (Payload) usando ambas, como primer intento probemos lo siguiente:

?categoria=<script>&producto=</script>

mmm, nuevamente el mensaje del xss-auditor, aunque por ningún lado se ve nuestro alert, y esto se debe a que estamos metiendo en orden incorrecto las etiquetas <script></script> , si miramos bien el código de vulnerable.php vemos que imprime primero la variable producto y después la variable categoría, así que hagamos un segundo intento pero ahora con esto:

?categoria=</script>&producto=<script>alert()

Ok, esta vez si que vemos algo parecido a nuestro payload, no se lanzo el mensaje del xss-auditor pero si un error de sintaxis, ya que después del alert esta el texto "en la categoría", intentemos ver que logramos si comentamos ese string basura:

?categoria=</script>&producto=<script>alert()/*

Pues ahí esta, otro intento fallido, pensemos... ¿Y si metemos ese string basura dentro de una variable?, es decir, junk='en la categoría', venga que por un ultimo intento no perdemos nada, así que probemos nuestro nuevo payload:

?categoria=';alert(junk)</script>&producto=<script>junk='

¡Eureka!, ahí esta nuestro deseado alert, sin mensajes del xss-auditor y sin ningún error de sintaxis que frene su ejecución, como ven no ha sido imposible, y ahora tenemos una url como prueba de concepto:

http://hlabdlinux/XSS_Reflected/vulnerable.php?categoria=';alert(a)</script>&producto=<script>a='

No es el caso, pero en una aplicación en producción, una falla de este tipo puede ser aprovechada por un usuario mal intencionado y en vez de un simple alert puede redireccionar a portales infectados con malware, obtener cookies, hacer campañas de phishing, conocer la ip del cliente, entre muchas otras cosas más, que como investigadores nosotros no haremos, ya que lo expuesto anteriormente solo es con fines educativos y como recordatorio de que ...

"Si estáis tratando de resolver un problema del que sois un experto, cuanta mayor sea la dificultad del problema, más se agudizarán y aumentarán vuestros talentos".