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".

Mejorando un script php para mitigar ataques directory transversal

Muchas veces los desarrolladores web optan por brindar la funcionalidad de descarga o visualización de ficheros desde sus aplicaciones web, olvidando por desconocimiento o mero descuido que el no añadir medidas de seguridad a esta característica puede desembocar en una falla muy fácil de explotar pero a su vez muy seria, ya que como se vera a continuación la mala programación de esta funcionalidad puede permitir que un atacante se mueva por directorios y ficheros que se encuentra fuera del directorio web raíz, ficheros y directorios que a su vez pueden contener datos importantes de la aplicación y del servidor en general, es por ello que he decidido brindar una sencilla forma de mitigar esta problemática, que si bien no es la única ni mucho menos mejor manera de hacerlo, si que dará una idea a los iniciados en el desarrollo web, para empezar a mejorar la seguridad de sus aplicaciones.

Sin mas bla,bla,bla, empecemos diciendo que a un directory transversal también se le conoce con los nombres "dot-dot-slash" o "punto punto barra", escalada de directorios y backtracking , dicho esto, ahora sí, miremos el código vulnerable:

Código vulnerable a directory transversal

Dicho código no hace otra cosa mas que mostrar el contenido del fichero (Con sintaxis remarcada) que tiene como nombre el que le pasamos vía get usando el parámetro file, en nuestro caso el archivo que visualizamos se llama 0.txt y esto es lo que nos muestra:

Contenido del archivo 0.txt

Pero bueno, si son de los que creen que ese código no tiene riesgo alguno, pues abrir bien los ojos que enseguida les muestro lo que un curioso puede conseguir si juega un poco con ese jugoso parámetro file:

Contenido del fichero /etc/passwd

Información del uso de memoria que contiene el
fichero /proc/meminfo

Y bueno el limite lo pone el grado de conocimiento que tengas acerca del sistema de ficheros del S.O sobre el que esta montado el servidor web, y claro esta también de la aplicación web, ya que el contenido de ficheros con extensión .php seria visualizado de igual manera.

Pero bueno para evitar esta problemática y orientar un poco a quienes han sido victimas de este tipo de ataques , aquí les dejo el código fuente que mitiga hasta cierto grado esta vulnerabilidad, y algunos resultados al intentar obtener ficheros fuera del directorio desde donde se ejecuta este código:

Código mejorado

Respuesta al intentar acceder a /etc/passwd

Resultado al acceder a un fichero con extensión .asm (Esta permitida)

Resultado al intentar visualizar index.php (La extensión .php no esta permitida)

Como dije no es la única forma de lograr mitigar este tipo de ataques y mucho menos la mejor, ya que el script presenta algunas deficiencias en cuanto funcionalidad, pero bueno, para fines prácticos creo que cumple con el objetivo, así que son libres de usarlo, mejorarlo, intentar hacer bypass, compartirlo y ¡happy hacking! :) ...