Rompiendo barreras: Analizando la fuente y encontrando XSS’s
#~ Intro:
Bueno, como muchos ya sabrán, o si no les comento, las vulnerabilidades Cross-Site Scripting(XSS) es una de las mas poderosas y TOP 10 del momento, según OWASP (Open Web Application Security Project). Por eso me decidí a escribir este texto, no como otro texto mas que trata de describir lo que es un XSS, para que una persona en una situación real pueda encontrar un XSS que no sea simplemente agregando tags HTML sino analizando en el momento el código y entendiendo el: Por Que?, Como?, Cuando? y Donde?. En realidad esta dedicado a la gente que tiene una mínima idea sobre XSS pero que esa idea esta latente y no sea solo una burda imagen (se entiende?). Como todo texto voy a explicar solo una base de lo que es XSS.
Según wikipedia:
“XSS es un ataque basado en explotar vulnerabilidades del sistema de validación de HTML incrustado. Su nombre original “Cross Site Scripting”, y renombrado XSS para que no sea confundido con las hojas de estilo en cascada (CSS), originalmente abarcaba cualquier ataque que permitiera ejecutar código de “scripting”, como VBScript o javascript, en el contexto de otro dominio.”
Para hacerlo mas entendible y corto: “Se trata de la capacidad de poder inyectar código HTML, mediante JavaScript y otros lenguajes, aunque actualmente puede ser usado en aplicaciones Flash, por ejemplo.”
Eso es todo lo que se necesita saber si ya se tiene una idea de lo que es XSS. Pero hay otra cosa que se debe tener en mente, que son: los Filtros. Estos filtros son scripts o funciones que filtran el XSS en búsqueda de caracteres o tags completos que indiquen un intento de inyectar HTML. Por ejemplo, buscan caracteres como “ (Hexadecimal:%22 - ASCII:34) o ‘ (Hex:%27 - ASCII:39) o < > (Hex:%3C %3E - ASCII:60 62) etc. O tags HTML como <script>, <img>, <iframe> etc. Para reemplazarlos por variables sanitizadas o borrarlos, dependiendo de el uso..
#~ Herramientas (principalmente Firefox):
Hay infinidad de herramientas pero yo les voy a presentar algunas que no van a hacer el trabajo por nosotros, sino, ayudarnos a encontrar un XSS de la mano de la fuente HTML, que es de lo que hablo. Una de estas herramientas va a ser simplemente un juego de caracteres, publicado por RSnake en ha.ckers.org:
”;!–”<XSS>=&{()}
Que es eso? Ese juego de caracteres los nombraron “XSS Locator”, lo que hace es, al ingresarlo puede pasar tres cosas (según mi punto de vista): se puede producir un “error” en el código fuente, lo que nos permitiría ver si algún carácter nos permite inyectar HTML, o se puede pasar el texto, pero nos permitiría ver como funciona el filtro y tratar de pasarlo o burlarlo, o directamente determinar que caracteres son permitidos y empezar a checkear vectores XSS para inyectar satisfactoriamente uno.
Firebug
Firebug es una extensión de firefox (altamente conocida) que nos permite modificar en-el-acto la fuente y recursos HTML y CSS, pero excluyendo scripts. Otra función que es muy importante es la capacidad de poder encontrar pedazos de código específicos en aplicaciones web muy extensas donde algo como esto es crucial y muy importante. Lo que también nos puede facilitar esta extensión es aplicar vectores extensos en inputs que solo permitan un numero de caracteres menores al de nuestro vector.
Ctrl+U
Ctrl+U es la combinación de teclas que nos permiten ver el código fuente en Firefox, lo menciono porque es lo mas importante (por lo menos para mi) al momento de localizar un hoyo XSS. Esto combinado con Ctrl+F (Buscar..) van a ser nuestras armas mas importantes.
Adicionales (Extenciones FF):
JSView
Nos permite ver que elementos adicionales nos presenta la app. web, como archivos JS o CSS.
Tamper Data
Por si Firebug no es suficiente, esta extención nos da la capacidad de editar las cabeceras HTTP en el acto.
#~ Al ataque: pruebas reales, XSSs reales
Ahora preparados, ya sabemos que hacer, buscar la web mas famosa o enemiga que encontremos XD. Para esta prueba voy a usar una que es conocida en estos momentos, se trata de el sitio oficial de uno de los candidatos a la presidencia de EEUU (se lo merecen). La URL es http://my.barackobama.com/ y la sección que es vulnerable http://my.barackobama.com/page/s/fellowsapp (aunque hay otra sección que es exactamente igual: http://my.barackobama.com/page/s/). Pero me dirán: Por que es vulnerable? Porque la aplicación nos permite ingresar cualquier tipo de caracteres luego de la URL, sin necesitar ningún tipo de petición, formulario, etc. Por ejemplo, si agregáramos: http://my.barackobama.com/page/s/fellowsapp+foo@bar nos daría como resultado lo siguiente:

Y el pedazo de código:
<div id=”content”>
<div id=”column1″><div id=”page_content”><h2>Invalid signup form requested: <strong>fellowsapp foo@bar</strong></h2>
</div>
Entonces como toda persona apresurada, probamos lo siguiente:
http://my.barackobama.com/page/s/fellowsapp”><script>alert(666)</script>
Pero lo que vemos en la fuente es lo siguiente:
<div id=”content”>
<div id=”column1″><div id=”page_content”><h2>Invalid signup form requested: <strong>fellowsapp\”><script>alert(666)<</strong></h2>
</div>
De aquí en mas solo queda PENSAR!. Las conclusiones que podemos llegar a sacar de esto son: la aplicación permite el ingreso de <tags> iniciales pero que no concluyan con la inyección, o sea </script> </iframe> etc. Porque borraría todo lo que sea ingresado despúes de la barra “/”. Y filtra las famosas “quotes” o comillas agregando una barra invertida, o sea ” -> \” o ‘ -> \’ .
Entonces, el método mas rápido que podríamos usar para resolver este problema serian <tags> que no necesiten la utilización de finales, por ejemplo <img> o <a href>, hay muchos mas solo hace falta el ingenio :-P. En este caso opte por el mas simple, <img>. La forma que utilice es la siguiente, que automáticamente la transforma en un vector XSS:
<img src=. onerror=alert(666)>
Para el que no lo entendió paso a explicarlo. Se crea el tag <img> con una fuente o “src” sin dirección o una dirección errónea, en este caso “.” . En ese momento explico que al producirse un error al cargarse la imagen, que estoy 100% seguro que va a ocurrir por la src especificada, se llebe acabo una acción usando “onerror”. Entonces digo que en caso de error se envie una alerta, o sea “alert(666)”. Para esa instancia no hay necesidad de cerrar ningún tag HTML dando por concluido la alerta.
http://my.barackobama.com/page/s/fellowsapp<img src=. onerror=alert(666)>

Con el código fuente:
<div id=”content”>
<div id=”column1″><div id=”page_content”><h2>Invalid signup form requested: <strong>fellowsapp<img src=”.” onerror=”alert(666)”></strong></h2>
</div>
TIP: a veces no se aceptan espacios, entonces se puede recurrir a el caracter “+”, agregando el vector <img+src=.+onerror=alert(666)> la aplicación web transforma los signos + en espacios.
Pero solamente se pueden utilizar números? En parte ya que, en este caso, el filtro pasa caracteres ” ‘ y todo lo que este detras de / haciéndonos imposible hacer alert(/XSS/). Pero hay una parte buena, podemos utilizar la funcion String.fromCharCode(). Esta función es muy importante, y hay que tenerla en mente cada vez que se trata de encontrar una de estas vulnerabilidades.
Para poder usar correctamente esta función hay que pasar cada una de las letras o caracteres de un texto a sus valores ASCII o Decimal. Por ejemplo
String.fromCharCode(88,83,83)
Representaría”XSS”, siendo 88=X 83=S. Entonces lo usaríamos de la siguiente manera:
http://my.barackobama.com/page/s/fellowsapp<img+onerror=alert(String.fromCharCode(67,49,99,52,84,114,49,90))+src=.>

Y de aquí en mas, alguien con un poco de conocimientos y un poco de creatividad podría agregar otras funciones que modifiquen la fuente de forma directa, como document.title, document.documentElement.innerHTML, document.location, etc. Sin preocuparse por no poder usar comillas dobles o simples ya que se puede especificar con String.fromCharCode().
#~Proceso de análisis:
En esta instancia lo único que se necesita es: creatividad. La creatividad en la seguridad en aplicaciones web es crucial, porque mas haya de que se tenga pregrabado en lo que consista el ataque, sin creatividad no se puede llevar acabo satisfactoriamente. Un ejemplo, si en un formulario de búsqueda, la aplicación web da nuestro texto insertado 3 veces, hay el triple de posibilidades de encontrar un XSS. 1º) Si el texto esta en el titulo y se pueden insertar tags finales, se podría insertar un tag que finalice el titulo y comience un script inyectado: </title><script>alert(/XSS/)</script>. 2º) Si al realizar la búsqueda nuestro texto sigue siendo visual en el “input” donde se ingresa el texto es porque en su fuente HTML se encuentra: value=”texto”. Entonces, agregando unas comillas dobles ” se cierra la propiedad “value” y agregando > se cierra el tag <input> y por ultimo se puede agregar un script. 3º) Esta parte es mas simple, porque el buscador nos puede informar: No se pudo encontrar “texto” en la base de datos. Y en ese momento es simplemente agregar un script.
A que voy? A que hay indicadores que nos dicen de forma directa o indirecta que se podría inyectar HTML, a veces con la dificultad de filtros y funciones que nos impiden hacer esto y a veces sin ellos, lo cual es peligroso. Siempre hay que tener en cuenta las deformaciones que sufre ta pagina al agregar caracteres como ” < > ‘ ya que cierran propiedades o concluyen <tags> mostrándonos varias posibilidades de inyectar.
Otra cosa es aprovechar errores PHP o SQL. Por ejemplo, http://www.uba.ar/comunicacion/difusion/noticia-c.php?id=%22%3E%3Cscript%3Ealert(/C1c4Tr1Z/)%3C/script%3E nos muestra un output de error con strings que indiquemos, que nos permite inyectar a su vez código HTML sin ser checkeado. Hay algunas funciones de MySQL que también son vulnerables a XSS.
En fin, otras veces hay que simplemente ver lo que la pagina nos devuelve, como información sobre cookies, tokens, hashes, IP, etc. Que pueden ser modificados cambiando el URL o las cookies para que se produzca un XSS.
#~Conclusión:
Espero que les haya ayudado este pequeño texto que hice, que también espero no sea otro mas del montón sino que represente lo que trato de transmitir que es la creatividad y “practicidad” ante todo. No trato de que se les quede la idea de que un XSS es un simple <h1></h1> sino un juego de funciones, caracteres y vectores totalmente diferentes y mas complejos.
Saludos a todo NB!

jaja.. Bueno Argenbyte, la verdad que lo que me dijiste es un aliento porque me gusta ver que algunos textos que aporto a todos sirve..
Saludos!
C1c4Tr1Z said this on May 22nd, 2008 at 1:17 am