Tema 3

Vulnerabilidades web
[3.1] Cmo estudiar este tema?
[3.2] OWASP
[3.3] Plataformas de aprendizaje
[3.4] Herramientas para hacking web
[3.5] Tipos de vulnerabilidades
3
TEMA
Vulnerabilidades web
OWASP Plataformas de Herramientas Tipos de

aprendizaje vulnerabilidades
Esquema
TEMA 3 Esquema
Introduccin DVWA BurpSuite Authentication bypass
Qu es? Introduccin Herramientas de
Fuerza bruta
Qu busca? Instalacin la suite
CSRF
Mutillidae Ejecucin maliciosa de

OWASP - ZAP ficheros
Top 10 Introduccin
Herramientas XSS
Instalacin
de la suite
2
Referencia directa insegura a
objetos
WebGoat
SQLMap
Introduccin Configuraciones inseguras
Instalacin
Hydra
Inyeccin
Tamper Data
Redirecciones y reenvos
Subida de archivos sin restriccin
Gestin de sesin
Almacenamiento criptogrfico inseguro
Proteccin insuficiente en la capa de

transporte
Universidad Internacional de La Rioja, S. A. (UNIR)

Anlisis de Vulnerabilidades
Ideas clave
3.1. Cmo estudiar este tema?
Para estudiar este tema lee las Ideas clave que se exponen a continuacin.
En la actualidad, casi todo est relacionado con Internet y las aplicaciones y servicios
web que proporciona, ya sea para ver el correo o para hacer compras online. Pero hay
datos sensibles y debe haber una seguridad en todos estos servicios y aplicaciones.
En este tercer tema se hablar de las vulnerabilidades web ms importantes, de las

diferentes herramientas que tenemos para encontrarlas y explotarlas y de diferentes
plataformas de aprendizaje para el alumno.
En primer lugar hablaremos de OWASP, un proyecto de cdigo abierto creado para

luchar contra las vulnerabilidades web. Este proyecto ha creado diferentes
herramientas y guas tanto para la defensa como para el ataque. Adems, cada 3 aos
publica un documento con el Top 10 de las vulnerabilidades ms importantes para
prevenir a los administradores y ayudar a evitarlas.
Despus veremos tres plataformas de aprendizaje: DVWA, Mutillidae y WebGoat.

Mediante estas plataformas el alumno podr practicar lecciones de ataque web a
pginas y aplicaciones vulnerables (sin que tenga que atacar sitios reales).
Luego se vern diferentes herramientas para poder analizar y explotar vulnerabilidades

web. Todas las que se vern forman parte del Top 10 de herramientas de Kali Linux por
su gran versatilidad y potencial. Son:
BurpSuite, una suite de diferentes herramientas para analizar peticiones web y
reenviarlas para explotar vulnerabilidades.
OWASP-ZAP, otra suite de herramientas similar a BurpSuite diseada por el
proyecto OWASP.
SQLMap, una herramienta para realizar inyecciones SQL de cualquier tipo
(normales, blind)
Hydra, una herramienta para realizar ataques por fuerza bruta a servicios en
Internet.
TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

3
Tamper Data, un plugin muy til que realiza la funcin de captura y modificacin de
peticiones HTTP.
Finalmente, se hablar de los diferentes tipos de vulnerabilidades web. Por cada

vulnerabilidad se explicar en qu consiste, un ejemplo terico o prctico de cmo se
podra explotar y qu formas hay para evitar y protegernos de dicha vulnerabilidad.
Estas vulnerabilidades son: Authentication bypass, fuerza bruta, Cross Site Request
Forgery (CSRF), ejecucin maliciosa de ficheros local (LFI) y remota (RFI), Cross Site
Scripting (XSS), configuraciones inseguras, referencia directa insegura a objetos,
inyeccin (de comandos y SQL), redirecciones y reenvos, subida de archivos sin
restriccin, gestin de sesiones, almacenamiento criptogrfico inseguro y proteccin
insuficiente en la capa de transporte.
3.2. OWASP
OWASP es un proyecto de cdigo abierto dedicado a determinar y combatir las causas

que hacen que el software sea inseguro. La Fundacin OWASP es un organismo sin
nimo de lucro que apoya y gestiona los proyectos e infraestructura de OWASP.
Los documentos con ms xito de OWASP son OWASP Testing Guide y OWASP Top
10. El primero, que ya va por su versin 4, consiste en una gua prctica y terica para
realizar pentesting a aplicaciones web; el segundo consiste en una recopilacin de las
vulnerabilidades ms frecuentes que nos podemos encontrar en las aplicaciones web,
as como su funcionamiento, impacto y formas de evitarlas.
Las herramientas OWASP ms usadas incluyen el entorno de formacin WebGoat

que veremos ms adelante, las herramientas WebScarab (para pruebas de penetracin)
y OWASP-ZAP (para realizar escaneos de vulnerabilidades en aplicaciones web) y las
utilidades de seguridad para entornos .NET OWASP DotNet.
Nos vamos a centrar en el top 10 OWASP, su objetivo es educar a desarrolladores,

diseadores, arquitectos, gerentes y organizadores sobre las consecuencias de las
vulnerabilidades de seguridad ms importantes en aplicaciones web. Dicho documento
provee de tcnicas bsicas sobre cmo protegerse en estas reas de alto riesgo y
tambin provee orientacin sobre los pasos a seguir.

4
Nos vamos a fijar en los top 10 de los aos 2010 y 2013 (este ltimo es el ms actual) y
veremos cmo han cambiado en estos aos. En los prximos apartados veremos ms a
fondo los diferentes tipos de vulnerabilidades.
Figura 1. Comparacin Top 10 OWASP 2010 y 2013.
La gua adems clasifica estas vulnerabilidades segn la facilidad de explotacin que

tengan, la prevalencia (la cantidad de sitios donde podemos encontrar la
vulnerabilidad), la deteccin (la facilidad de que un atacante encuentre este tipo de
vulnerabilidad) y el impacto que puede provocar en la aplicacin web.
Figura 2. Clasificacin del Top 10 OWASP 2013.

5
Puedes encontrar documentacin de OWASP en la siguiente direccin web:

https://www.owasp.org/index.php/Main_Page
Accede al top 10 de 2013:

https://www.owasp.org/images/5/5f/OWASP_Top_10_-_2013_Final_-_Espaol.pdf
Accede a la Gua de Testing OWASP v4:

https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf
3.3. Plataformas de aprendizaje
Para poder realizar algunos ejemplos y poder practicar las vulnerabilidades que iremos
viendo ser necesario un entorno que simule una aplicacin web real. No es
conveniente hacerlo con sitios web reales ya que podemos causar verdaderos problemas
a los sitios y hacerlo sin consentimiento de los administradores del sitio es ilegal.
Para ello tenemos a nuestra disposicin tres plataformas diseadas especialmente

para el aprendizaje de las vulnerabilidades web. Estos entornos ya contienen
vulnerabilidades a propsito para que podamos explotarlas de la misma forma que lo
hara un atacante real. Poseen diferentes niveles de dificultad, aunque cada plataforma
los gestiona de una forma diferente.
A continuacin explicaremos cada una de las tres plataformas, tanto su instalacin

como caractersticas principales.
1. DVWA
DVWA (Damn Vulnerable Web Application) es un reconocido entorno de

entrenamiento en explotacin de seguridad web, que permite estudiar e investigar
sobre las diferentes temticas involucradas en dicho campo.
Ser la plataforma que utilizaremos para nuestros ejemplos y demostraciones, ya que es

la que presenta la interfaz ms cmoda y no necesita descargar nada extra para su
instalacin.

6
Tiene tres niveles de dificultad:

Bajo (Low). Simula un entorno muy vulnerable, nos permitir hacer casi cualquier
cosa.
Medio (Medium). Simula un entorno ms controlado, sern necesarias diversas
tcnicas de evasin de filtros.
Alto (High). Simula un entorno real seguro, no podremos vulnerarlo.
Las temticas que cubre la plataforma son las siguientes:
Brute Force Command execution
CSRF Insecure CAPTCHA
File Inclusion SQL Injection
Blind SQL Injection Upload
XSS Reflected XSS Stored
Categoras principales de DVWA.
Su interfaz es la siguiente:
Figura 3. Interfaz de DVWA.
Vamos a explicar cmo realizar su instalacin en nuestra mquina Kali Linux, pero se
podra hacer en cualquier sistema operativo. Para realizar la instalacin ser necesario

7
tener un servidor, una base de datos y PHP ya instalado (ya que DVWA est basado en
este lenguaje).
En nuestro caso, en la mquina Kali ya los tenemos, por lo que descargaremos la

plataforma de la pgina oficial http://www.dvwa.co.uk/.
Descomprimiremos el zip, lo moveremos a la carpeta del servidor y le daremos

permisos de ejecucin:
unzip DVWA-1.0.8.zip.
mv DVWA-1.0.8 /var/www/dvwa.
chmod -R 755 /var/www/dvwa.
Ahora iniciaremos el gestor de bases de datos y crearemos la base de datos de la

aplicacin.
service mysql start.
mysql -u root -p (Cuando nos pida contrasea simplemente pulsaremos enter).
create database dvwa;
show databases; (Para comprobar que la hemos creado correctamente).
Exit.
Finalmente iniciaremos el servidor y ya podremos conectarnos a la plataforma:

service apache2 start.
Nos conectaremos a ella poniendo en el navegador 127.0.0.1/dvwa/ o localhost/dvwa/.

El usuario de login ser admin y la contrasea password (ambas sin las comillas).
Hay otra forma de instalar la plataforma en cualquier sistema operativo (Linux,

Windows, Mac) y es usando XAMPP, una aplicacin que incluye un servidor Apache,
una base de datos MySQL y varias libreras para lenguajes como PHP y Perl. La
aplicacin administrar por nosotros el servidor web.
Puedes obtener ms informacin en la siguiente direccin web:

https://www.apachefriends.org/index.html

8
2. Mutillidae
Mutillidae es otra plataforma para poder entrenar los conocimientos de

seguridad orientados a una aplicacin web. Esta plataforma es complementaria
por si quieres practicar con ms ejemplos que los que se trabajarn en la plataforma
DVWA.
Mutillidae contiene varios tipos de vulnerabilidades ms que DVWA y posee dos niveles
de sugerencias o consejos (Tips) para ayudar al usuario a explotarlas. Incluye todas las
vulnerabilidades vistas en el OWASP Top 10 (tanto de 2010 como de 2013).
La plataforma tiene dos modos:

En el modo inseguro (por defecto), las pginas sern vulnerables, al menos a la
vulnerabilidad que indique la pestaa a la que pertenezcan, aunque pueden ser
vulnerables a muchas ms. Tendr dos niveles dentro del modo inseguro.
En el modo seguro, Mutillidae intenta proteger a las pginas con scripts del lado del
servidor, pero seguirn siendo vulnerables y se podr explotar. Adems, las
sugerencias se desactivan en este modo.
El cdigo fuente de las pginas y los scripts ests comentado para permitir al usuario
ver cmo funcionan las defensas y vulnerabilidades.
Figura 4. Interfaz de Mutillidae.
De nuevo nos conectaremos a la plataforma mediante el navegador, en este caso

pondremos 127.0.0.1/mutillidae/ o localhost/mutillidae/. No har falta usuario ni
contrasea.

9
En la siguiente direccin web encontrars, en el apartado Downloads, todas las

versiones de la aplicacin para descargar:
http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-
php-owasp-top-10
El autor de la plataforma tambin ha creado una gran coleccin de vdeo tutoriales de

pentesting de aplicaciones web utilizando Mutillidae.
Puedes ver todos estos vdeos en la siguiente direccin web:

http://www.irongeek.com/i.php?page=videos%2Fweb-application-pen-testing-
tutorials-with-mutillidae
3. WebGoat
WebGoat es una plataforma con aplicaciones web deliberadamente inseguras

desarrollada y mantenida por OWASP para ensear y practicar lecciones
de seguridad web.
La pgina se divide en diferentes lecciones, en la cuales el usuario deber demostrar su

conocimiento del fallo de seguridad explotando una vulnerabilidad real en la aplicacin
web. Por ejemplo, en una de las lecciones el usuario deber utilizar la inyeccin SQL
para robar nmeros de tarjetas de crdito (falsos). La plataforma adems
proporcionar al usuario consejos y el cdigo de cada vulnerabilidad.
WebGoat est escrito en Java y se puede instalar en cualquier mquina que tenga una
mquina virtual de Java, por lo que funciona sobre cualquier sistema operativo (Linux,
Windows, Mac OS X...).
Actualmente hay 30 lecciones de aprendizaje entre las cuales encontramos las

siguientes vulnerabilidades:
o Cross Site Scripting (XSS).

o Gestin de acceso.
o Seguridad de hilos.
o Manipulacin de campos y parmetros.
o Sesiones dbiles de cookies.

10
o Inyeccin SQL (String, Numeric, blind).

o Peligros de los comentarios HTML.
La plataforma adems incluye informacin acerca de las cookies y los parmetros que
se envan y gestionan.
Figura 5. Interfaz de WebGoat.
La instalacin ser sencilla en cualquier tipo de plataforma, el nico requisito ser

tener Java 1.6 o superior. Las ltimas distribuciones de Kali Linux ya lo llevan
incorporado, pero para asegurarnos comprobaremos la versin en la consola de
comandos con java version.
Si no tenemos 1.6 o superior lo podremos descargar de la pgina oficial de Oracle:

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-
1880260.html
Puedes descargar WebGoat desde la siguiente direccin web:

https://webgoat.atlassian.net/builds/browse/WEB-
WGM/latestSuccessful/artifact/shared/WebGoat-Embedded-Tomcat/WebGoat-6.0.1-
war-exec.jar
Una vez descargado ejecutaremos el siguiente comando cada vez que queramos utilizar
la plataforma, pues no necesita instalacin ni ejecutar ningn servidor o base de datos
extra, ya lo hace todo el archivo jar: java -jar WebGoat-6.0.1-war-exec.jar.

11
Cuando aparezca en la consola el siguiente mensaje ya podremos acceder a la

plataforma a travs del navegador con la URL http://localhost:8080/WebGoat.
Figura 6. Plataforma WebGoat lista para funcionar.
Es importante recordar que no debemos cerrar la consola en la que hayamos ejecutado

el comando anterior, porque entonces dejar de funcionar la plataforma.
3.4. Herramientas
Antes de comenzar a ver los diferentes tipos de vulnerabilidades web vamos a ver ms a
fondo algunas herramientas diseadas especialmente para el anlisis y explotacin de
aplicaciones y servicios web. Estas herramientas facilitarn enormemente la bsqueda
de vulnerabilidades y la automatizacin de la explotacin.
En el prximo apartado de tipos de vulnerabilidades web utilizaremos algunas de estas

herramientas y alguna otra ms, como Crunch, pero se deja como tarea para el alumno
el investigar ms sobre ellas. Todas las herramientas que vamos a ver estn por defecto
en Kali Linux.
1. BurpSuite
BurpSuite es una suite de herramientas de las ms utilizadas a la hora de realizar

un pentesting a una aplicacin web por la gran variedad de herramientas que contiene.
Forma parte del Top 10 de aplicaciones de Kali.
Dispondremos de la versin gratuita en nuestra mquina Kali, que se diferencia de la

versin de pago solamente en que carece de un par de funcionalidades.
Figura 7. Herramientas de BurpSuite.
La primera herramienta es el Proxy, nos proporciona un servidor proxy que nos

permite capturar y manipular el trfico que pase a travs de l. Nos mostrar todos los

12
parmetros separando cabecera y datos y normalmente ser capaz de marcar en color

rojo lo que crea que son parmetros modificables, facilitando la tarea al usuario.
Al modificar parmetros podremos realizar multitud de funciones como: aumentar el

tamao mximo permitido a la hora de subir archivos, introducir ms texto en un
campo del permitido, modificar la cookie de sesin
Para usarlo ser necesario establecer en el navegador que vamos a utilizar un proxy, en
este caso lo vamos a explicar para Iceweasel (Firefox) el navegador por defecto en Kali.
En preferencias iremos a Advanced > Network > Settings.
Figura 8. Preferencias de Iceweasel.
Despus seleccionaremos una configuracin proxy manualmente, por la direccin

127.0.0.1 y el puerto 8080 (en el caso de que queramos utilizarlo con WebGoat ser
necesario cambiar el puerto al 8081, por ejemplo, ya que la plataforma corre en el
mismo puerto).
Figura 9. Ajustes de conexin de Iceweasel.
Adems quitaremos que no se pueda usar un proxy en localhost (puesto por defecto).

13
Por defecto BurpSuite utiliza el puerto 8080, pero si lo queremos modificar podemos ir
a Proxy > Options y ah lo cambiaremos. Podemos ver un ejemplo de captura a
WebGoat con este proxy:
Figura 10. Captura de WebGoat con el proxy de BurpSuite.
Nota: no olvidar desactivar el proxy en las opciones del navegador al cerrar BurpSuite,
ya que no funcionar, porque todas las peticiones las mandar al puerto proxy y no
habr ninguna aplicacin para reenviarlas.
La siguiente herramienta, Spider, es una herramienta que puede enumerar y

realizar un mapa del sitio web y de las diferentes pginas a las que enlaza,
parmetros y objetos que tiene Para ello examina las cookies e inicia conexiones
a la aplicacin web a las pginas que encuentre.
Para utilizarlo elegiremos una captura hecha con el proxy y con clic derecho o pulsando
Action, seleccionaremos Send to Spider.
Figura 11. Spider en funcionamiento.

14
Figura 12. Resultado de Spider en WebGoat.
La siguiente herramienta, el Scanner, es especfica para la versin de pago, por lo que

no nos interesa. Es capaz de realizar un escaneo de una aplicacin web en busca
de vulnerabilidades.
Otra de las herramientas y una de las ms potentes de la suite es Intruder, con la que
podremos realizar ataques sobre aplicaciones web automatizados. Nos
permitir generar peticiones HTTP maliciosas y detectar y explotar vulnerabilidades
como inyeccin SQL, XSS, manipulacin de parmetros o ataques por fuerza bruta.
Esta herramienta nos permitir seleccionar diferentes partes de las peticiones y

convertirlas en parmetros, para despus automatizar peticiones modificando estos
parmetros mediante listas de palabras. La versin gratuita tendr ciertas limitaciones
a la hora de utilizar listas en archivos de texto.
Figura 13. Interfaz del Intruder.

15
En el prximo captulo de tipos de vulnerabilidades web utilizaremos esta herramienta

y se ver ms detalladamente su funcionamiento.
La siguiente herramienta, el Repeater, ser muy simple. Nos permitir coger una
peticin realizada y reenviarla tantas veces queramos modificando manualmente los
parmetros.
Figura 14. Interfaz del Repeater.
Las cuatro herramientas restantes tienen funciones ms especficas y no las

utilizaremos, pero se describir brevemente su utilidad:
El Sequencer se utiliza para comprobar la aleatoriedad de los tokens de sesin
generados por la aplicacin web.
El Decoder se utiliza para codificar una peticin o URL a diferentes formatos como
Base64, URL o incluso convertirlos en hashes MD5 o SHA-1.
El Comparer se utiliza para comparar entre dos conjuntos de datos, puede ser
entre peticiones o entre respuestas, palabra por palabra o bit a bit
Finalmente el Extender nos permitir aadir funcionalidades y plugins extra a
BurpSuite.
2. OWASP-ZAP
OWASP Zed Attack Proxy u OWASP-ZAP es una suite de herramientas creada y

mantenida por el proyecto OWASP. Est escrita en Java y es multiplataforma
(incluyendo Linux, Windows y Mac OS X).

16
Figura 15. Interfaz de OWASP-ZAP.
Es una suite de herramientas para la bsqueda y explotacin de vulnerabilidades web

muy similar a BurpSuite, pero tiene todas sus funcionalidades disponibles ya que es
software libre.
Las principales herramientas con las que cuenta son:

Un proxy de intercepcin que, al igual que en BurpSuite, nos permite capturar y
modificar las peticiones HTTP realizadas y las respuestas por parte del servidor.
Para su funcionamiento ser necesario establecer el proxy manualmente como ya
hemos visto.
El puerto por defecto ser de nuevo el 8080. Aunque no tengamos activa la captura
de peticiones y respuestas, todos los sitios web que visitemos mientras utilicemos el
proxy quedarn guardadas en el mapa de sitios de OWASP-ZAP.
Enviar peticin o respuesta
Capturar peticiones
y/o respuestas
Proxy de OWASP-ZAP.

17
Un escner de vulnerabilidades. Con esta herramienta podemos realizar un

escaneo de uno o varios sitios web, ya sea los que tengamos guardados por la
herramienta en la parte de sitios o porque se haga un escaneo total de un sitio.
Podemos ver un ejemplo de esta herramienta en la plataforma DVWA, en la pestaa
de XSS Reflected. Para la demostracin pondremos la seguridad de la pgina en low.
En primer lugar establecemos manualmente el proxy por el puerto 8080 y visitamos

la pgina. Aparecer un cuadro de texto en el que podremos escribir:
Figura 16. XSS Reflected en DVWA.
Podremos ver que en OWASP-ZAP nos ha aparecido el sitio en la pestaa de sitios a la

izquierda. Para realizar el escaneo daremos clic derecho y seleccionaremos Atacar >
Active Scan single URL.
Figura 17. Realizar un escaneo sobre un sitio web.
El escaneo aparecer en la pestaa de Escaneo Activo y cuando encuentre algo

aparecer en la pestaa de Alertas. En este caso ha encontrado una vulnerabilidad de
XSS y lo notifica colocando una banderita roja delante del sitio.

18
Figura 18. Resultado del escaneo.
En el reporte nos aparece el cdigo malicioso que podemos introducir para comprobar
el resultado de escaneo:
Figura 19. Probamos introducir en el cuadro de texto el cdigo generado.
Un spider o araa, que intenta indexar y capturar las URL de una pgina
para hacer un mapa completo del sitio web. Una forma que tiene de hacerlo
es ver el cdigo HTML y buscar todas las direcciones del mismo dominio para
redirigir y repetir. Tiene dos tipos de spider, uno tradicional y otro para sitios web
AJAX. Para utilizarlo simplemente daremos clic derecho en un sitio guardado en la
pestaa de sitios y seleccionaremos Atacar > Spider tipo, donde tipo podr ser
el sitio entero o una URL especfica.
Un fuzzer, capaz de realizar funciones de ataque por fuerza bruta,

inyecciones SQL, inyecciones de cdigo XSS Realiza peticiones dando
diferentes valores a un parmetro que seleccionemos y a diferencia de BurpSuite
solo permite seleccionar un parmetro. Para utilizarlo tendremos que seleccionar un
trozo de texto en una peticin (que ser nuestro parmetro), clic derecho, Fuzz y
seleccionaremos el tipo de fuzzer.

19
3. SQLMap
SQLMap es una herramienta que nos permite descubrir vulnerabilidades de

inyeccin de SQL y explotarlas en busca de informacin de las bases de
datos. Nos permitir seleccionar una URL como objetivo o los resultados de un Google
Dork (una bsqueda en Google especfica cuyos resultados son pginas vulnerables o
potencialmente vulnerables).
Para utilizar la herramienta utilizaremos la consola de comandos. Para comprobar si

una pgina es vulnerable pondremos:
sqlmap --url="http://www.paginaweb.com/injeccion?=id=1"
Para obtener las diferentes bases de datos que tenga:
sqlmap --url="http://www.paginaweb.com/injeccion?=id=1" --dbs
Para obtener las tablas de una base de datos:
sqlmap --url="http://www.paginaweb.com/injeccion?=id=1" --tables -D

nombre_base_datos
Para obtener los datos de una tabla:
sqlmap --url="http://www.paginaweb.com/injeccion?=id=1" --dump -D

nombre_base_datos -T nombre_tabla
En el apartado de tipos de vulnerabilidades web, cuando se vea inyeccin SQL se ver

un ejemplo prctico del funcionamiento de esta herramienta.
Puedes acceder a ms informacin y ejemplos en la siguiente direccin:

https://github.com/sqlmapproject/sqlmap/wiki/Usage

20
4. Hydra
Hydra es una herramienta de ataques de fuerza bruta multiprotocolo, es decir,

nos permite intentar autenticarnos en diferentes servicios a travs de mltiples
protocolos como HTTP, FTP, IMAP A diferencia de otras herramientas de fuerza
bruta sin conexin, Hydra realizar este tipo de ataque a servicios y aplicaciones web.
Los ataques por fuerza bruta intentan adivinar las credenciales de autenticacin para
ganar acceso al sistema. Es una manera simple y segura de conseguir un resultado, pero
tiene dos grandes desventajas:
El tiempo que puede tardar en probar todas las combinaciones posibles de usuario y
contrasea.
El ruido que causa, pues genera mucho trfico (pudiendo provocar denegaciones de
servicio con estas herramientas de ataque por fuerza bruta).
Para utilizar la herramienta lo haremos por consola. Por ejemplo, si queremos realizar
un ataque por fuerza bruta para obtener las credenciales para conectarnos por SSH a
una mquina con la IP 192.168.1.30 utilizando una lista para usuarios y otra lista para
contraseas:
hydra -L users.txt -P passwords.txt 192.168.1.30 ssh
Figura 20. Uso de Hydra para conectarnos a una mquina por ssh.
5. Tamper Data
Tamper Data no es una aplicacin como las anteriores que hemos visto, sino que es un
plugin para el navegador (en concreto para Firefox y derivados), pero es una
herramienta muy til, sencilla y rpida.
Cuando hablamos de BurpSuite vimos que traa una herramienta de Proxy, pues
Tamper Data realiza esa misma funcin, pero al ser un plugin del navegador nos
permite no tener que modificar las conexiones para establecer manualmente un proxy.

21
Cuando solo queramos trabajar modificando algunos parmetros o comprobando las

cabeceras, ser ms sencillo utilizar este plugin que otras herramientas. Nos permitir
modificar todas las peticiones, abortarlas y algunas funciones extra como falsificar el
User-Agent del navegador o inyectar parmetros SQL o XSS en la peticin.
Figura 21.Interfaz de Tamper Data.
3.5. Tipos de vulnerabilidades web
1. Authentication Bypass
Muchas pginas web requieren algn tipo de autenticacin para acceder a zonas
restringidas o informacin privada, normalmente con un nombre de usuario y
contrasea. Cuando una pgina web permite la introduccin de un usuario o
contrasea lo hace mediante peticiones GET o POST. Para realizar estas peticiones se
deben rellenar ciertos campos donde introducir las credenciales.
Figura 22. Campos para credenciales.
Cuando se genera la peticin, el servidor comprueba en la base de datos que la tupla

existe, es decir, que el nombre est asociado a la contrasea (guardada en formato
hash). Dependiendo de si la tupla existe o no, podr redirigirnos a una pgina
restringida o mandarnos de nuevo a que nos autentiquemos.

22
A causa de malas configuraciones podemos encontrar diferentes mtodos para

saltarnos esta autentificacin y acceder a las zonas privadas sin conocer usuario o
contrasea. Estas son:
URLs mal restringidas. Un error muy bsico que comete un gran nmero de
desarrolladores es crear un mecanismo de autentificacin para un servicio web,
pidiendo usuario y contrasea en una pgina de login y, posteriormente, dar acceso
al resto de pginas del servidor sin realizar otra comprobacin.
El problema con esto reside en que si obtenemos una URL de la zona privada
podramos acceder a ella sin autenticarnos, ya que no comprobar si lo hemos hecho
previamente.
Un ejemplo puede darse en las URLs de un banco. Tenemos una cuenta en un banco
y nos conectamos a su pgina web para consultar nuestro saldo y realizar
transacciones. Nos pide usuario y contrasea para acceder a nuestra cuenta y vemos
que la URL es: https://www.mibanco.es/user/getAccount. Pero si las URL no
estuvieran bien configuradas podramos acceder a otras zonas de la pgina web que
deberan ser privadas cambiando /user/ por otra cosa, como /admin/, /manager/,
/administrator/
Este tipo de fallos se puede evitar configurando correctamente estas URL y

realizando diversos tipos de comprobaciones:
o Acceso restringido solo a usuarios autorizados.
o Gestionar los permisos basndose en usuarios o grupos.
o Bloquear las peticiones a pginas no autorizadas como ficheros de configuracin,
logs, cdigo fuente
o Verificar el acceso en cada peticin.
o Proteger cada URL de la aplicacin por un filtro externo (Java EE web.xml) o
mediante la comprobacin interna en el cdigo (mtodo isAuthorizedForURL()
de ESAPI).
o Verificar que la configuracin del servidor deniega peticiones de tipos de ficheros
no autorizados por defecto.
Cambiar parmetros en la URL. Otro error muy grave es comprobar el estado

de una sesin con un parmetro que se imprime en las URL. Por ejemplo, un
servidor da acceso a pginas restringidas comprobando que el usuario se ha

23
conectado mediante el parmetro auth=1 (autenticado) o auth=0 (no

autenticado) y lo muestra en la URL de esta manera:
http://www.paginaweb.com/areaadmin.asp?auth=0
Podramos simplemente modificar el parmetro final a auth=1 para conseguir

acceso total a esta pgina sin necesidad de conocer nombres de usuario y
contraseas. Para evitar este fallo es aconsejable mostrar el mnimo de informacin
posible en las URL y realizar las verificaciones del punto anterior.
Ofuscar las URL. Algunos servidores web tienen listas de pginas que estn
restringidas y que necesitan de autentificacin para acceder a ellas. Pero podra
haber URLs que no estn en la lista de pginas restringidas que apunten a dichas
pginas.
Por ejemplo puede ser la pgina restringida:

http://www.mipaginaweb.com/admin/configuration/. Si aadimos algn smbolo
como /, ?, % o ~ podramos hacer que la URL apunte a la misma pgina, pero
cambiando el nombre de la forma:
http://www.mipaginaweb.com/admin/configuration//
Si la configuracin no es correcta y el servidor comprueba la lista de pginas

restringidas literalmente sin parsear las URLs, no nos pedir autenticacin. Por ello
es conveniente utilizar mtodos que, antes de devolver el contenido al usuario,
comprueben las URLs y eviten los smbolos, codificando estos en formato
hexadecimal de la forma %25.
SQL injection. El ltimo mtodo para saltarse la autenticacin consiste en

aprovecharnos de los errores al realizar la comprobacin del usuario y la contrasea
en la base de datos. Podremos hacer una inyeccin en la peticin SQL a la base de
datos para saltarnos el proceso de autenticacin. Tenemos un ejemplo en la pgina
de la plataforma DVWA (ya explicada anteriormente):

24
El ejemplo lo encontramos en el nivel low de la pestaa de fuerza bruta, si nos

fijamos en su cdigo fuente vemos:
Figura 23. Cdigo fuente de la pestaa de fuerza bruta (low)
Podemos ver que no realiza ninguna comprobacin de seguridad en la entrada de

texto del usuario y la contrasea, por ello podremos saltarnos la autentificacin
conociendo un usuario (o buscndolo por fuerza bruta, que se explicar en el
prximo apartado). En este ejemplo usaremos el smbolo # que se utiliza para crear
una tabla temporal en la base de datos.
Introduciremos en usuario: admin#. El usuario admin es el que sabemos que estar

en la base de datos.
Figura 24. Texto introducido en el campo usuario.
Esto pasar a la consulta de la siguiente manera:
"SELECT * FROM `users` WHERE user=admin# AND password=;"

25
La consulta solo analizar hasta el usuario, ya que para el resto crear una tabla
temporal que dar un error, aunque esto no nos afectar. Como el usuario existe y
solo hay una entrada en la base de datos, nos identificar como este usuario y
podremos saltarnos la autentificacin sin necesidad de introducir contrasea.
Figura 25. Acceso a la zona de admin.
La forma ms fcil para evitar estos fallos es utilizar funciones que comprueben los
parmetros antes de pasrselos a las consultas, como en los niveles medio y alto de
DVWA de fuerza bruta.
2. Fuerza bruta
Qu ocurre si el servidor comprueba correctamente las entradas de texto del usuario?

Podemos ver en los niveles medio y difcil como en el cdigo fuente realiza
comprobaciones para evitar las comillas ( ) o los slashes ( \ ).
La nica forma que nos queda ser comprobar todas las posibles combinaciones
de usuario contrasea. Normalmente esta es una tarea muy tediosa, por lo que se
recurren a diccionarios (archivos de texto con gran cantidad de palabras que se suelen
utilizar como usuario o contrasea). A este tipo de ataque se le llama de fuerza bruta.
Para ver un ejemplo nos fijamos de nuevo en la pgina DVWA, en la pestaa de Brute
Force. En este caso usaremos la dificultad medium.
Vamos a utilizar la tcnica de fuerza bruta para poder obtener el nombre de usuario y la
contrasea. Para ello utilizaremos la herramienta BurpSuite y su pestaa de Intruder.
Pasos:
En primer lugar pondremos el navegador en modo proxy por el puerto 8080 como
ya se ha explicado.

26
En la pestaa de Proxy nos fijaremos que en un botn ponga Intercept is on y

realizaremos una peticin en la pgina de DVWA con un nombre de usuario y
contrasea cualquiera para poder capturar el mensaje HTTP enviado y modificarlo
posteriormente.
Pulsaremos el botn Action y Send to Intruder para mandar el mensaje a la pestaa

Intruder.
Figura 26. Enviar el mensaje capturado al Intruder.
En la pestaa Intruder seleccionaremos el tipo de ataque cluster bomb (para poder

modificar varias variables). Y seleccionaremos en el mensaje lo que queremos que
sean las variables a modificar; primero pulsaremos clear para quitar todas las que
vienen por defecto y luego pulsaremos add para seleccionarlas manualmente.
Figura 27. Pestaa Intruder.
En la subpestaa de Payloads podremos seleccionar las diferentes variables (en este

caso payload 1 ser el usuario y el 2 la contrasea). Podremos crear una lista
nosotros insertando valores en la parte de Payload Options o cargar una lista de
palabras de un archivo txt.
En Kali podemos encontrar algunas listas de palabras en el directorio:

/usr/share/wfuzz/wordlist/general

27
Figuras 28 y 29. Asignar listas de palabras a los payloads.
En este caso se ha usado una pequea lista con combinaciones que se conoce de
antemano que funcionarn, para ahorrar tiempo, pero en un entorno real ser
necesario probar uno o varios diccionarios completos.
En la pestaa de Options estableceremos que nos indique si ha coincidido con un

patrn (en este caso para conexin incorrecta).
Figura 30. Campo para marcar mensajes correctos o incorrectos.
Pulsaremos Start Intruder para comenzar el ataque por fuerza bruta.
Figura 31. Comenzar el ataque.

28
Finalmente obtendremos los resultados de las combinaciones de usuario y

contrasea encontradas.
Figura 32. Resultados obtenidos, a la derecha estn marcados los mensajes que coinciden con el patrn
anterior
Hay formas de dificultar o evitar este tipo de ataques. Algunas de ellas

son:
o Establecer retrasos a las peticiones realizadas cuando sean incorrectas (como

hace el cdigo de DVWA en el nivel alto de fuerza bruta). Aunque un atacante lo
podra contrarrestar realizando muchas peticiones en paralelo.
o Poner lmite de intentos para bloquear alguna IP en particular o para bloquear a
algn usuario que haya introducido mal su contrasea en varias ocasiones.
o Usar un segundo factor de autenticacin, por si un atacante obtiene las
credenciales por fuerza bruta, que necesite la otra forma de autenticacin para
poder acceder.
Nota: a veces para mejorar la efectividad de los ataques de fuerza bruta por diccionario,
es conveniente crear nuestro propio diccionario. Para ello nosotros usaremos la
herramienta Crunch ya incluida en Kali Linux.
Esta herramienta nos permite utilizar patrones para generar grandes listas de palabras
que podremos utilizar como diccionarios. Nos permite elegir la longitud que queremos
que tengan las palabras generadas (mnima y mxima). Para ver todas las opciones de
esta herramienta escribiremos en consola:
crunch --help

29
Si por ejemplo conocemos que las contraseas de alguna organizacin se generan con 3
letras y 4 nmeros podremos generar un diccionario con todas las combinaciones
posibles para poder usar luego herramientas como Hydra o BurpSuite para atacar por
fuerza bruta.
Figura 33. Herramienta Crunch.
3. Cross Site Request Forgery (CSRF)
Un ataque Cross Site Request Forgery o CSRF consiste en forzar a la vctima a

realizar una peticin HTTP a una aplicacin web vulnerable a la que ya se
autentic, aprovechando la cookie de la sesin y cualquier otra informacin para
volver a conectarse y poder realizar acciones en nombre de la vctima.
Esta vulnerabilidad se aprovecha de la confianza que tiene un sitio web en el

navegador, haciendo que este realice una operacin hostil que beneficia al atacante.
CSRF es tan peligroso como la aplicacin web que se ataque, si fuera un banco, un
atacante podra hacer transferencias desde la cuenta de la vctima, cerrar una cuenta
bancaria, etc.
Una aplicacin web ser vulnerable a CSRF si:

No verifica de nuevo la autenticacin antes de realizar la operacin.
La autenticacin por defecto permite realizar operaciones.
Se autorizan operaciones basndose nicamente en las credenciales que se
suministran automticamente por el navegador como cookies de sesin, token
Kerberos, autorizacin clsica, certificado SSL
El gran problema con este tipo de vulnerabilidades es que es muy difcil seguir la pista
hasta el atacante, ya que la IP que realiza la peticin a la aplicacin web vulnerable es la
de la vctima (como si fuera una operacin lcita).

30
Un ejemplo de un ataque CSRF es:

Un atacante introduce un script con una URL maliciosa en su web que hace
automticamente Likes en Facebook y lo oculta como si fuera una imagen. El script
puede ser del formato:
<img src="https://www.facebook.com/pages/PaginaParaLikes/?=like">
La vctima que tiene abierta una sesin en Facebook visita la pgina web del
atacante, al hacerlo descarga la imagen y el navegador ejecuta el cdigo oculto.
Si la sesin de la vctima no ha caducado, Facebook tomar la peticin como legtima
(ya que la cookie de sesin no ha caducado, el navegador y la IP son los de la vctima,
etc.) y realizar la accin del atacante sin el conocimiento de la vctima.
Deben cumplirse varias condiciones para que pueda darse a cabo este tipo de ataque:
El atacante debe elegir una aplicacin web que no compruebe el campo de la

cabecera de referer, que indica de dnde procede el enlace a esa pgina, o elegir una
vctima con un navegador o plugin que permita falsificar ese campo de referer. Un
ejemplo del funcionamiento de este campo es:
La pgina www.pagina1.es tiene un enlace a la pgina www.pagina2.com, cuando

alguien haga clic en el enlace se crear una peticin a la segunda pgina en la que el
campo referer tendr www.pagina1.es.
Esta medida, por ejemplo, se usa para evitar acceder a pginas de forma directa, es
decir, sin pasar por pginas de registro.
El atacante debe encontrar alguna forma (HTML) o URL que realice la accin que
desee (como hacer likes, transferir dinero o cambiar una contrasea).
El atacante debe determinar el valor correcto de los parmetros de la forma o URL,

si cualquiera de ellos requiere valores secretos de la autenticacin o tiene valores que
el atacante no puede adivinar, el ataque fallar.
Si un atacante quiere hacer una transferencia desde la cuenta de la vctima podra

usar una URL como:
http://bank.ejemplo.com/withdraw?account=Victima&amount=10000&for=Atacante

31
El atacante deber conocer el valor Victima (que podra ser un nombre, una cuenta o
un identificador de cliente) para poder realizar la operacin.
El atacante debe asegurarse que la vctima accede a la pgina con el cdigo malicioso
cuando tiene una sesin abierta en el sitio objetivo.
Podemos ver un ejemplo de este tipo de ataque de nuevo en la plataforma DVWA, en la

pestaa de CSRF. Consiste en cambiar la contrasea de la pgina de inicio de la vctima
(por defecto password) mediante un ataque CSRF.
Nos fijaremos en el nivel bajo y en el intermedio. En ninguno de ellos la pgina pide

que introduzcamos la contrasea antigua para poder cambiarla, solo introducir la
nueva contrasea y confirmarla.
El nivel intermedio adems comprueba que en el campo referer de la peticin HTTP

contenga la cadena 127.0.0.1, para simular que solo puede realizarse la operacin
desde una pgina web especfica. Igualmente se podra saltar, ya que solo comprueba
que la cadena est, no la posicin, o se podra intentar spoofear (falsificar) este campo.
Para ambos niveles la URL que aparece cuando cambiamos la contrasea es:
127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=pass&password_conf=pass&Ch
ange=Change#
Siendo las palabras en negrita la nueva contrasea y la confirmacin.
Para el ejemplo, primero con el nivel bajo, crearemos una pequea pgina web con una
imagen que referencie a la URL maliciosa y la guardaremos en la carpeta
/var/www/falso.
Figura 34. Cdigo HTML de la web falsa.
Accederemos a la pgina desde la direccin IP privada del ordenador (para no usar la

direccin 127.0.0.1).

32
Figura 35. Pgina web falsa.
Si nos conectamos ahora a la plataforma DVWA, veremos como la contrasea ha

cambiado.
El segundo ejemplo, con el nivel intermedio, ser similar. En este caso crearemos una
pgina con un enlace que nos redireccionar a la pgina de DVWA y cambiar la
contrasea.
Figura 36. Cdigo HTML de la pgina falsa 2.
De nuevo accederemos desde la IP privada del ordenador.
Figura 37. Pgina web falsa 2.
El pulsar en el enlace debera aparecer la confirmacin de que la contrasea ha sido

cambiada, pero no es as. Esto ocurre porque no se cumple que en el campo de referer
est la cadena 127.0.0.1, como requiere el cdigo de este nivel. Para solucionarlo
utilizaremos un plugin para el navegador para poder modificar las cabeceras de los
mensajes, Tamper Data.
Abrimos el plugin, le damos a comenzar la modificacin y hacemos clic en el enlace

malicioso. Podremos ver como en el campo referer est la direccin de la pgina
maliciosa, as que lo cambiaremos por http://127.0.0.1.

33
Figura 38. Campo referer en Tamper Data.
Finalmente podremos cambiar la contrasea (en este caso a enlace).
Figura 39. Confirmacin de cambio de contrasea.
4. Ejecucin maliciosa de ficheros
Este tipo de vulnerabilidad ocurre nicamente en pginas dinmicas en PHP que

permiten especificar un fichero o una ruta a un fichero, ya sea interno a la
aplicacin (LFI) o externo (RFI), mediante parmetros mal validados en la URL.
En el cdigo fuente de este tipo de pginas encontramos funciones como include,

include_once, require o require_once, que son utilizadas para incluir en una misma
pgina ficheros o cdigo fuente de otros servicios web.
Esta vulnerabilidad tiene un gran riesgo, ya que puede permitir a un atacante:

Introducir cdigo ejecutable en una aplicacin web.
Subir archivos maliciosos al servidor.
Acceder a datos privados del servidor como logs, contraseas, informacin de
sesin
Actualmente ya no se encuentra en el Top 10 de OWASP pero siguen existiendo muchas

pginas con esta vulnerabilidad. Para descubrir estas pginas vulnerables debemos
fijarnos en las URL. Aquellas que tengan el formato:
http://www.pagina_vulnerable.com/index.php?page=plantilla.html

34
En la plataforma DVWA tenemos de nuevo una seccin vulnerable a este fallo, en la

pestaa File Inclusion. Nos encontraremos con la siguiente URL:
Figura 40. URL de la pestaa vulnerable.
Podemos comprobar que si modificamos el parmetro page por /etc/group el

servidor nos volcar en la pgina web el fichero de grupos de este, por lo que la pgina
ser vulnerable a una inclusin local.
Figura 41. Volcado de /etc/group.
Para comprobar tambin si la pgina es vulnerable a una inclusin remota tendremos

que probar insertar una un enlace a una pgina web como http://www.google.es.
Figura 42. Inclusin de la pgina www.google.es.

Se puede ver que se ha incrustado el cdigo de la pgina www.google.es en la pgina de
DVWA. Esto indicar que tambin ser vulnerable a una inclusin remota.

35
Nota: en muchos casos no funcionar, ya que servidores como Apache, por defecto,
tienen un parmetro que evita que se pueda realizar esta llamada a otras pginas web.
Para desactivarlo (en el caso de Kali Linux) deberemos ir al fichero:
/etc/php5/apache2/php.ini
Buscar y poner a On la opcin:

allow_url_include
Reiniciaremos el servicio apache2 y ahora nos debera funcionar correctamente.
En caso de no usar Kali Linux y Apache2 como servidor, deberemos buscar el archivo
php.ini del que usemos y modificar el mismo parmetro.
Nuestro objetivo ser ejecutar una webshell en la pgina vulnerable, as que crearemos
una (o la descargaremos). En nuestro caso hemos copiado el cdigo fuente de la
webshell desde pastebin.com y hemos creado el archivo c99.txt en la carpeta falsa de
nuestro servidor (para simular una pgina web ajena al servidor).
http://pastebin.com/JK2AaELL
A continuacin se explicarn los dos tipos de inclusin de ficheros que hay: remota y
local.
Remote File Inclusion (RFI)
Consiste en llamar desde la pgina web a un fichero que est situado en otro
servidor. El fichero al que queramos llamar no debe acabar en .php, ya que este tipo
de fichero se ejecuta en el servidor en el que est; por ello lo hemos llamado c99.txt.

36
En el nivel bajo de DVWA realizamos la peticin a travs de la URL y obtenemos:
Figura 43. Webshell por RFI.
Esta webshell ser solo de lectura, pero podremos obtener mucha informacin del
servidor, as como descargar el cdigo fuente de las pginas.
Local File Inclusion (LFI)
En este caso consiste en llamar desde la pgina web a un fichero local, es decir, que
ya est en el servidor (en cualquier lugar de este) y ejecutarlo. Por ejemplo si ya
hemos conseguido subir una webshell al servidor por algn mtodo, podremos
llamarlo utilizando su ruta absoluta o relativa.
Podemos ver un ejemplo con el nivel medio de DVWA. En este nivel la pgina
comprueba antes de hacer el include(), pues no permite la introduccin de http o
https para poder hacer una inclusin remota (aunque podramos llamar a un
archivo de un servidor ftp, ya que no lo bloquea).
Figura 44. Webshell por LFI.

37
En este caso hemos llamado directamente al archivo de la webshell c99.php que

tenamos en una carpeta local.
Tambin hay otra forma para realizar esta inclusin local sin necesidad de tener el
archivo de la webshell cargado en la mquina del servidor. Para ello usaremos el
esquema URL data (disponible a partir de PHP 5.2).
Un ejemplo del funcionamiento es: ?page=data:, <?php echo "Prueba de data"; ?>
Figura 45. Prueba del esquema data.
Nosotros lo que queremos es ejecutar comandos como si fuera una shell, as que
llamaremos a una de forma local con la llamada system().
?page=data:, <?php system($_GET['cmd']); ?>&cmd=ls
Figura 46. Llamada a una shell con LFI.
De nuevo esta shell que obtenemos solo tendr permisos de lectura.
Para evitar estas vulnerabilidades:

No se debe incluir rutas a ficheros en la URL.
Si se incluye la ruta, es necesario tener una lista blanca de ficheros, como el nivel
alto de la plataforma DVWA, que solo permite include.php.
Tener especial cuidado con los formularios que permitan a los usuarios subir
ficheros a la aplicacin:
o Almacenar los ficheros en una ruta distinta de la raz.

38
o Validar la ruta y la extensin del fichero.

o Implementar un sistema de Sandbox o chroot que limite el acceso.
5. Cross Site Scripting (XSS)
Este tipo de vulnerabilidad web consiste en la ejecucin de cdigo en algn

lenguaje de script (JavaScript normalmente) en el navegador de la vctima
cuando esta visite alguna aplicacin web vulnerable.
Podemos encontrar esta vulnerabilidad en aplicaciones web disponibles en Internet, en

aplicaciones locales e incluso en el navegador en s, pues ocurre cuando una aplicacin
no valida la entrada de datos del usuario correctamente o no sanea la salida
adecuadamente, permitiendo que se introduzca cdigo malicioso.
Un atacante puede realizar peligrosas acciones con XSS como:

Robar informacin delicada.
Secuestrar sesiones del usuario.
Defacement de pginas web, es decir, modificar de manera intencionada una pgina
web cuando se haya obtenido algn tipo de acceso a ella, bien por algn error de
programacin de la pgina, por algn bug en el propio servidor o por una mala
administracin de este.
Comprometer el navegador e introducir malware en la mquina vctima.
Este tipo de vulnerabilidad se suele encontrar en sitios donde se permita introducir

contenido (campos de texto, libros de visitas). Se suele esconder el vector de ataque
en tags HTML como iframes o imgenes que permitan ocultar el contenido al usuario y
adems se puede codificar (en formato UNICODE) para que no sea tan sospechoso.
Existes varios tipos de XSS:

Reflejado (No persistente). Los ataques llegan a la vctima a travs de una URL
maliciosa con los parmetros directamente modificados (por algn enlace en otra
pgina, email).
Almacenado (Persistente). El cdigo se almacena en un servidor de manera
permanente (en una base de datos, foro, libro de visitas) y cuando un usuario
acceda a la pgina vulnerable se ejecutar el cdigo malicioso.

39
Inyeccin DOM. En este tipo de ataques el cdigo inyectado manipula el cdigo

JavaScript del sitio Web y sus variables son manipuladas, en lugar de los elementos
HTML.
Se puede ver que el segundo tipo de XSS es muy peligroso, ya que, si algn sitio web
que reciba millones de visitas al da es vulnerable a un XSS almacenado se podran
comprometer todas las mquinas para cualquier fin: robo de datos, botnets, etc.
XSS Reflejado
Volvemos a fijarnos en la plataforma DVWA, en la pestaa XSS Reflected.
Figura 47. Pestaa de XSS Relejado.
En el nivel fcil vemos que no realiza comprobacin alguna del texto que
introduzcamos.
Figura 48. Cdigo nivel fcil.
Entonces podremos introducir cdigo JavaScript en la pgina, como una alerta:
?name=</pre><script>javascript:alert("XSS!!");</script>

40
Figura 49.Alerta por XSS.

Tambin podremos realizar la insercin de imgenes o de formas de HTML.
</pre><img src=http://www.fasebonus.net/wp-content/uploads/2013/02/hacker-02.jpg>
Figura 50. Imagen insertada por XSS.
En el nivel medio encontramos que el cdigo no permite que utilicemos la cadena

<script> (cuando encuentra esta cadena la quita directamente), por lo que
supuestamente no dejara que ejecutramos cdigo en el cliente.
Figura 51. Cdigo del nivel medio.
Existen muchas tcnicas para saltarnos este tipo de controles mediante listas negras de
palabras o expresiones. Un par de ejemplos pueden ser:
Usar maysculas:
?name=<SCRIPT>javascript:alert("XSS!!")</script>

41
Aprovecharnos del reemplazo de la cadena <script>:
?name=<scrip<script>t>javascript:alert("XSS!!")</script>
Hay muchas ms formas de evadir estos filtros, como otras combinaciones o codificar
las URL.
Podemos encontrar ejemplos en las siguientes direcciones web:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
http://ha.ckers.org/xsscalc.html
XSS Almacenado
En este caso nos fijaremos en la pestaa de XSS Stored.
Figura 52. Libro de firmas en la pestaa de XSS almacenado.
Nos encontramos con un libro de visitas en el cual podemos introducir texto en dos
campos. Si nos fijamos y comenzamos a poner caracteres en ellos veremos que el
primero solo acepta 10 y el segundo 50.
Podemos introducir de nuevo el cdigo que queramos, ya sea para generar una alerta,
inyectar una foto, redirigir a otra pgina pero a diferencia del caso anterior, se
quedar guardado y siempre que carguemos la pgina el cdigo se ejecutar.
Para el ejemplo vamos a ver el nivel bajo e intentaremos hacer que la pgina nos
redireccione a otra que queramos, es decir, que siempre que accedamos a la pestaa
XSS Stored nos redireccionar a otra pgina. Para ello usaremos:
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.google.es">

42
El nmero indica el tiempo que tardar en refrescar la pgina y la URL a qu pgina

deber redireccionar.
Cuando queramos insertar el cdigo en el mensaje veremos que no entra todo, por lo
que deberemos usar Tamper Data.
Figura 53. Tamper Data para hacer un ataque de XSS almacenado.
Cuando aceptemos el envo de la peticin nos enviar a la pgina de Google, al igual

que cuando pulsemos la pestaa de XSS Stored.
Nota: para eliminar las entradas del libro de visitas que hayamos creado ser necesario
resetear la base de datos de la pgina.
Para ello iremos a la pestaa Setup y pulsaremos en Create/Reset Database.
En el nivel intermedio el campo de mensaje no permitir la introduccin de smbolos

HTML como < o > por lo que no podremos utilizarlo, pero el campo de nombre si
permitir. Podremos hacer lo mismo que hemos hecho en el ejemplo del nivel fcil pero
usando el otro campo, incluyendo el uso de Tamper Data, ya que este campo de nombre
solo permitir 10 caracteres.
Hay varias formas de evitar las vulnerabilidades de XSS:
Eliminar los fallos o evitar incluir aplicaciones propensas a XSS.
Filtrar las salidas convirtiendo el texto o datos que podran contener scripts
maliciosos a un formato codificado:
o < y > -> < y >
o ( y ) -> ( y )
o # y & -> # y &

43
Utilizar validacin de entrada mediante una lista blanca y no una lista negra.
Podemos ver que usando una lista negra, en el ejemplo de XSS Reflejado filtrando
por <script>, somos capaces de saltrnoslo.
Para grandes cantidades de informacin que procede de usuarios se puede utilizar la

API AntiSamy de OWASP que permite sanear las entradas:
https://www.owasp.org/index.php/AntiSamy.
6. Referencia directa insegura a objetos
Este tipo de vulnerabilidad sucede cuando un desarrollador deja referencias a

objetos implementados de manera interna en un URL o como un
parmetro en un formulario.
Estos objetos pueden ser:

Un fichero o directorio.
Una URL.
Una clave de base de datos.
Otros objetos de una base de datos, como por ejemplo el nombre de una tabla.
Si una aplicacin web no ha implementado correctamente la gestin de sesin o una

autentificacin segura se podr cambiar el valor de estos parmetros y objetos,
permitiendo a los atacantes referenciar objetos para los que no tengan
autorizacin y manipular informacin restringida.
Podemos ver un sencillo ejemplo:
Tenemos una cuenta en la pgina online de un banco y al conectarnos nos aparece una
URL como esta:
http://www.mibanco.com/usuario/cuentas.php?cuenta=1234
Si ahora cambiamos el parmetro cuenta de la URL, por ejemplo por 1235, esta
vulnerabilidad nos permitira acceder a la pgina del banco de la persona que tenga la
cuenta 1235, as como realizar acciones en ella.

44
Otro ejemplo de esta pgina del banco puede ser:
http://www.mibanco.com/descarga.php?dir=nomina&file=123123.pdf
Podramos cambiar el valor de estos parmetros dir y file y acceder a archivos del
servidor.
http://www.mibanco.com/descarga.php?dir=../../../etc&file=passwd
Como se puede ver, no se est haciendo ningn tipo de inyeccin como en el caso de
XSS; simplemente estamos modificando el parmetro a buscar, por lo que filtrar
parmetros y usar listas blancas no servira. Para evitar este tipo de vulnerabilidad
podemos:
Eliminar la referencia al objeto.
Sustituir la referencia por un valor temporal de referencia (1, 2, 3, 4). Aunque
implicara implementar algn mapa de referencia que permita traducir de uno a
otro.
http://aplicacion?fichero=imagen1.jpg -> http://aplicacion?fichero=1
Validar la referencia directa al objeto.

o Verificar que el valor del parmetro est correctamente formado.
o Verificar si el usuario tiene permiso para acceder al parmetro.
o Verificar si el modo de acceso est permitido (lectura/escritura).
7. Configuraciones inseguras
Los fallos de configuracin pueden estar presentes en cualquier nivel de un servicio de

red, incluyendo la plataforma, el servidor web, el servidor de aplicacin, la base de
datos, el cdigo Tanto los desarrolladores como los administradores de sistemas
deben trabajar juntos para asegurarse que todos los niveles se configuran
apropiadamente.
Una mala configuracin puede tener todo tipo de consecuencias: revelar directorios,
datos de conexin, credenciales, informacin de la base de datos, modificar ficheros
Instalacin de puertas traseras debido a la falta de parches.
Explotacin de XSS debido a falta de parches de seguridad.
Acceso no autorizado a cuentas por defecto.

45
Obtener informacin del funcionamiento del sistema privado.
Es importante tener en cuenta si el cdigo fuente de la aplicacin es pblico o privado y

si es el caso, estar atentos a cualquier actualizacin de seguridad que pueda surgir. En
el caso de ser un cdigo fuente privado hay que considerar todos los sitios donde se
almacena este cdigo. Como norma general, que el cdigo sea privado o no, no debera
afectar a la seguridad del sistema.
Al portar un sistema de desarrollo a produccin se deberan cambiar todas las

credenciales por seguridad.
Un par de escenarios de ejemplo pueden ser:

Un servidor web que disponga de una webshell para administrar el sitio que no
disponga de contrasea o utilice una por defecto. Si un atacante descubre su
existencia podra tener control total del sitio web.
Una aplicacin web que cuando surja cualquier error en una pgina porque no ha
podido cargar el contenido, muestre una traza de directorios y del error. Un atacante
podra obtener informacin de esta manera.
Para evitar las configuraciones inseguras es necesario verificar todas las

configuraciones de todas las aplicaciones y servicios, tanto de cara al usuario
(pblicos), como de cara al administrador (privados).
Escaneos automticos para detectar parches, malas configuraciones, uso de cuentas
por defecto, servicios innecesarios.
Guas de hardening.
Estar al da en todas las actualizaciones de seguridad. Tanto para bibliotecas,
aplicaciones, sistema operativo
Analizar las implicaciones de seguridad que traen consigo estos cambios.
Adaptar las aplicaciones para que generen reportes para poder analizarlos
posteriormente.
Verificar la implementacin mediante software de anlisis de vulnerabilidades,
configuracin y parches.

46
El hardening (endurecimiento) es el proceso de asegurar un sistema mediante la

reduccin de vulnerabilidades en el mismo. Esto se logra eliminando software,
servicios y usuarios innecesarios en el sistema, mantenindolo actualizado,
configurndolo correctamente, instalando software de seguridad, realizando
auditoras En conclusin, hacindole la vida ms difcil al atacante reforzando el
sistema.
8. Inyeccin
La inyeccin consiste en manipular las entradas de una aplicacin para mandar texto
de una forma concreta y que los intrpretes de rdenes lo tomen como comandos y los
ejecuten. Los intrpretes ms comunes son SQL, shell del sistema operativo, LDAP,
XPath
La causa ms comn es la falta de saneamiento en la entrada de datos o parmetros, es

muy sencillo de evitar, pero ocurre en un gran nmero de aplicaciones web. Tienen
tambin un impacto muy grave pues:
Permite a un atacante leer una base de datos entera y en algunos casos modificarla
y/o borrarla.
Permite el acceso al esquema de la base de datos y a sus cuentas.
Permite acceso al mismo sistema operativo (si hablamos de un intrprete como una
shell).
La inyeccin est en la primera posicin del Top 10 de OWASP de 2013, pues es la

vulnerabilidad que ms podemos encontrar. Es relativamente fcil explotarla (solo
necesita insertar texto en los intrpretes), no es muy difcil encontrar puntos de
explotacin (usando fuzzers o escneres) y tiene un gran impacto como hemos visto.
Vamos a ver en profundidad dos tipos de inyecciones en particular, las ms usuales, la

inyeccin de comandos en shell y la inyeccin SQL.
Inyeccin de comandos
A veces las pginas web utilizan llamadas a programas en el mismo servidor para
permitir ejecutar al usuario diversas tareas o servicios, como las tpicas pginas que
permiten hacer ping a una direccin IP. Pero, qu ocurre si estas pginas no
comprueban la entrada de texto antes de realizar la llamada?

47
Podemos ver un ejemplo en la plataforma DVWA, en la pestaa de Command

execution. Tanto el nivel bajo como el intermedio sern vulnerables. Consiste en una
aplicacin para hacer ping a una direccin IP mediante la llamada shell_exec() que
ejecuta un programa en la consola del servidor, en este caso ping.
Figura 54. Cdigo de la pestaa Command execution.
El nivel bajo no realiza comprobacin alguna del texto que se introduce por pantalla,
por lo que podramos usar smbolos de consola para ejecutar una sentencia detrs de
otra como ; (Linux) o && (Windows).
Figura 55. Ejemplo de inyeccin de comandos.
En este caso hemos ejecutado ls ../.. para ver el contenido de la carpeta

/var/www/dvwa del servidor.
En el caso del nivel intermedio la pgina cuenta con un par de restricciones que son:
eliminar los ; y && que encuentre en el texto introducido. Pero podremos seguir
ejecutando texto a travs de las tuberas en Linux | o el OR en Windows ||.
Figura 56. Inyeccin de comandos en el nivel intermedio.

48
No solo los servicios que hacen ping pueden ser vulnerables. Cualquier funcin que
realice una llamada a algn programa dentro del servidor del estilo cmd(), shell_exec()
o system() y permita al usuario introducir valores dentro, podra serlo.
Inyeccin SQL
Casi la totalidad de las aplicaciones web en Internet poseen una base de datos, ya sea
para almacenar las credenciales de acceso como para guardar informacin del
contenido de las pginas. Para acceder a estas bases de datos es necesario un lenguaje
especfico para realizar las consultas, as como un intrprete que entienda las consultas
y nos devuelva un resultado. El lenguaje ms comn de todos, en el mbito de
aplicaciones web, es SQL y la base de datos ms comn es MySQL, por eso este tipo de
inyeccin es la ms comn.
Podemos encontrar muchas clasificaciones de tipos de inyeccin SQL, pero nosotros

nos vamos a centrar en una, dependiendo de si la aplicacin web nos devuelve
informacin con los fallos o no.
Nos encontraremos ante una inyeccin clsica si nos muestra estos errores y ante
una inyeccin a ciegas (Blind SQL injection) si solo nos muestra informacin cuando
realizamos una consulta correcta y hay informacin que mostrar (no es lo mismo hacer
correctamente una consulta pero que una tabla o columna no existan, que hacer mal la
consulta directamente).
Para ambos tipos de SQL injection usaremos como ejemplo la plataforma DVWA, en las
pestaas SQL Injection y SQL Injection (Blind), en las que ser vulnerable tanto el nivel
bajo como el nivel medio. En ambas solo dispondremos de un campo de texto.
Comenzaremos con inyeccin SQL clsica. El cdigo fuente de la entrada de texto y la

consulta, del nivel bajo, es:
Figura 57. Cdigo fuente del nivel bajo de inyeccin SQL.
Nosotros podremos cambiar el parmetro id, por lo que podemos realizar varios test
para comprobar la explotacin de la base de datos y averiguar ms cosas sobre ella.

49
Test positivo: or1=1 Siempre ser cierto.

Test negativo: or1=0 Siempre ser falso.
El test positivo nos deber devolver un resultado, mientras que el negativo no debera
devolver nada. Con ello comprobamos si estamos ante un caso de inyeccin clsica o a
ciegas.
Figura 58. Inyeccin SQL siempre positiva.
Podemos averiguar tambin el nmero de columnas de la tabla que obtiene de

respuesta, es decir, el nmero de atributos diferentes que nos va a devolver (esto ser
necesario a la hora de concatenar consultas).
Una columna como mnimo: a ORDER BY 1;#

Dos columnas como mnimo: a ORDER BY 2;#
Podremos ir realizando indefinidas consultas as, hasta encontrar el nmero de

columnas. Cuando sobrepasemos el lmite de columnas nos mostrar un error, en caso
de ir acertando puede o no mostrar informacin (dependiendo del valor que le demos a
id, en estos casos le hemos dado a).
Figura 59. Error al sobrepasar el mximo de columnas.
En este caso podemos ver que la respuesta devuelve un error para 3 columnas, por lo
que tendr 2 (hemos visto en el cdigo fuente que es as, first name y last name).

50
Ahora empezaremos a utilizar consultas concatenadas y para ello utilizaremos la orden

UNION ALL SELECT. UNION ser para concatenar las consultas y que la respuesta de
la segunda consulta se sume a la primera; ALL la usaremos por si hace falta que se
repitan resultados y la consulta inicial tena DISTINCT puesto; y SELECT es el inicio de
la nueva consulta como si fuera normal.
El nico problema a la hora de realizar esta segunda consulta es que el nmero de

columnas de la respuesta debe ser el mismo nmero que en la primera, por ello
necesitamos saber el nmero de columnas con el comando anterior.
Para obtener la versin de la base de datos (podemos ver como se utilizan 2 columnas,
una para la versin y otra siempre con un 1 para que sea correcta la consulta):
a' UNION ALL SELECT 1, @@version;#
Podemos tambin obtener archivos del servidor:
' UNION ALL SELECT load_file('/var/www/dvwa/.htaccess'), '1
Ahora veremos el nivel medio e intentaremos sacar ms informacin, como el nombre

de la base de datos o el nombre de sus atributos. En este caso vemos que la entrada de
texto est un poco ms saneada y no permite utilizar algunos smbolos como las
comillas simples.
Figura 60. Nos da error porque el servidor codifica las comillas dobles.
Para solucionarlo tendremos que introducir un valor vlido en id, es decir, un nmero
entero.

51
Figura 61. Introducimos un valor vlido de ID y luego la inyeccin.
Deberamos repetir los pasos del ejemplo anterior para obtener de nuevo las columnas,
aunque en este caso siguen siendo 2.
El primer paso para obtener toda la informacin de una base de datos ser obtener su
nombre:
0 UNION ALL SELECT null, database();#
Figura 62. Consulta del nombre.
El nombre de la base de datos ser dvwa. Para intentar obtener las tablas de esta
base de datos, probaremos accediendo al esquema por defecto de las tablas de las bases
de datos MySQL information_schema.tables. La consulta sera as:
0 UNION SELECT table_schema, table_name FROM information_schema.tables

WHERE table_schema =dvwa#
Pero obtendremos un error ya que no podemos utilizar las comillas en las consultas por
el saneamiento de la entrada de texto. As que tendremos que obtener el esquema de

52
todas las tablas de la base de datos, en lugar de solo la que nos interesa y buscar
despus la que nos interesa.
0 UNION SELECT table_schema, table_name FROM information_schema.tables#
Figura 63. Buscamos el nombre que nos interesa.
Encontramos que tiene dos tablas: guestbook (que podemos suponer que ser la que
usa como libro de visitas para la pestaa de XSS almacenado) y users (que podemos
suponer que ser donde guarda la informacin de los usuarios).
El siguiente paso ser intentar averiguar el nombre de las columnas (atributos) de la

tabla de usuarios. Para hacerlo tendremos que usar el mtodo de prueba y error.
Usaremos consultas del estilo:
1 or NombrePrueba = z

53
Donde NombrePrueba ser el nombre de la columna que pensamos que puede existir
en la base de datos. Podremos encontrar dos tipos de respuesta por parte de la base de
datos, que exista el nombre o que no:
NO EXISTE EXISTE
Consultas de columnas existentes e inexistentes.
Una vez descubiertas las columnas, realizamos la consulta final para obtener la
informacin que queremos.
0 UNION ALL SELECT user, password from dvwa.users;#
Figura 64. Informacin de usuarios de la base de datos.
Ahora vamos a ver un poco blind SQL injection. El problema que nos ocasiona es que
no podremos ver los errores como hemos hecho con la inyeccin clsica. Aunque
podremos realizar las mismas acciones pero con algunos matices:
Hay que suponer que realizamos correctamente las consultas y cuando no nos
devuelve nada es porque algo a lo que hemos hecho referencia en la consulta no
existe.

54
Podemos hacer consultas de tal manera que devuelva valores booleanos. Si por
ejemplo no nos dice la versin de la base datos podemos preguntar carcter a
carcter.
1 AND 1=0 UNION SELECT null, substring(@@version,1,1)=5#
1 -> Correcto
0 -> Incorrecto
Nos devuelve valores booleanos.
A la hora de descubrir las tablas y las columnas podemos utilizar de nuevo los
esquemas por defecto, pero podemos codificar en hexadecimal los nombres en lugar
de ponerlos entre comillas (tambin lo podemos hacer en las inyecciones clsicas).
dvwa = 0x64767761
Figura 65. Codificamos los nombres de tablas.
Adems podemos concatenar ms columnas de las iniciales usando la expresin

concat().
1 AND 1=0 UNION SELECT null, concat(table_name, 0x0a, column_name) from

information_schema.columns where table_name=0x7573657273
users = 0x7573657273

55
Figura 66. Utilizamos concat().
Las tcnicas para realizar consultas SQL ms importantes (algunas de ellas ya las
hemos estado usando) son:
o UNION query-based. Realizar consultas concatenando con la expresin
UNION (la que hemos estado usando).
o Error-based. Cuando no podemos utilizar tcnicas como UNION se puede
intentar provocar errores y enviarnos el resultado del error.
o Out-of-Band. Similar al anterior pero intentando enviar todo, tanto errores
como resultados.
o Boolean-based. Se realiza una consulta que devuelve un valor booleano,
utilizando expresiones como LENGTH, ASCII o SUBSTRING.
o Time-based. Esta tcnica consiste en enviar una consulta inyectada con la
condicin a true y monitorizar el tiempo que tarda un servidor en responder. Si
hay algn retraso, se puede asumir que el resultado de una consulta condicional
es verdadero.
Como ya hemos visto, disponemos de una herramienta para realizar inyecciones SQL,
tanto clsicas como blind: esta es sqlmap, disponible en Kali Linux. Vamos a hacer una
prueba de nuevo con la plataforma DVWA y esta herramienta para sacar las bases de
datos y las tablas de estas.
sqlmap --url=http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit# --dbs
Al ejecutarlo nos dir que nos ha redirigido a la pgina de login, por lo que tendremos
que utilizar una cookie de la sesin que tengamos abierta.
sqlmap --url=http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#
--cookie=security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6 --dbs

56
Obteniendo en nuestro caso:
Figura 67. Obteniendo las bases de datos con sqlmap.
Finalmente obtendremos las tablas de las bases de datos con:
sqlmap --url=http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#
--cookie=security=medium; PHPSESSID=8k2kj7a9454b18lbojv87jc7d6 --schema
--exclude-sysdbs
Figura 68. Obtenemos las columnas con sqlmap.
Para evitar las vulnerabilidades de inyeccin (tanto las de inyeccin de comandos como
las de SQL) hay algunas recomendaciones:
Evitar utilizar un intrprete, en los casos que sea posible.
Utilizar una interfaz que implemente variables vinculadas (bind).
o Sentencias preparadas.
o Procedimientos almacenados.
o Las variables vinculadas permiten al intrprete distinguir entre cdigo y datos.

57
Codificar todas las entradas antes de que lleguen al intrprete, quitando smbolos
que puedan afectar a una consulta.
Validar todas las entradas que provengan del usuario mediante una lista blanca, es
decir, denegar todo por defecto y definir los casos que s son vlidos.
Depurar los privilegios del usuario con el que se accede a la base de datos.
Solamente permitir la lectura de las tablas necesarias (sobretodo restringir el acceso
a las tablas con los esquemas por defecto que hemos visto).
Desactivar la escritura donde sea posible.
Deshabilitar la conexin remota a la base de datos (o filtrarla mediante IP) para que
un atacante no se pueda conectar remotamente.
9. Redirecciones y reenvos
Muchos sitios web utilizan parmetros de redireccin en sus URL; esto se suele
utilizar para redirigir a un usuario a otra pgina tras realizar una operacin.
Si el parmetro no est correctamente validado, un atacante podra redirigir el

navegador de una vctima a una pgina maliciosa bajo el pretexto de una URL vlida, ya
que el usuario confiar en la pgina al venir de un sitio de confianza. Se podra redirigir
a:
Pginas de phishing como pginas de login falsas.
Pginas de malware (instalacin de toolbars, adware, plugins).
Exploits para el navegador.
En muchos casos se utiliza la ingeniera social para conseguir que la vctima abra el
enlace, ya sea por email, foros, chats
Para un ejemplo podemos suponer un escenario en el que la pgina de PayPal, cada vez
que haces Log out de tu cuenta te reenva de nuevo a la pgina de login de la forma:
https://www.paypal.es?dest=www.paypal.es/login.php
Un atacante podra aprovecharse de esto y enviar un correo hacindose pasar por

PayPal e introduciendo un enlace modificado:
https://www.paypal.es?dest=www.paypalFalso.es/login.php

58
La URL inicial corresponde con la pgina oficial por lo que un usuario descuidado
podra fcilmente caer en el intento de phishing.
Para eliminar esta vulnerabilidad se debe:
Evitar utilizar redirecciones y reenvos en la medida de lo posible.

Si se usa, evitar incluir la redireccin como un parmetro de la URL.
Si es indispensable incluir el parmetro en la URL:
o Validar cada parmetro para asegurar que es una redireccin permitida y
autorizada para el usuario en cuestin, y a un sitio vlido y de confianza.
o Utilizar parmetros locales y mapear estos en el lado del servidor.
Validar la URL despus de que la pgina de destino se haya determinado, para
asegurar que el destino es correcto.
Validar la redireccin mediante un filtro externo como Siteminder.
Comprobar siempre que el usuario tenga permisos para ver tanto la pgina original
como la redirigida. Si no se hace correctamente podra permitir accesos no
autorizados y escalada de privilegios en la pgina.
10. Subida de archivos sin restriccin
Subir archivos representa un riesgo para las aplicaciones. Muchos ataques contra
aplicaciones web consisten en dos fases, la primera es conseguir algn cdigo en el
sistema a atacar y la segunda encontrar una manera de ejecutar ese cdigo. Con la
subida de archivos se ayuda a un atacante a conseguir la primera fase.
Las consecuencias de la subida de archivos sin restriccin pueden ser variadas,

dependiendo de que la aplicacin permita subir archivos y dnde se almacenen, pero el
riesgo es muy alto:
Prdida total del sistema (Denegacin de servicio o robo de informacin).
Sobrecarga de archivos en el sistema o la base de datos.
Defacement.
Almacenamiento de virus para infectar el sistema y a los usuarios de la aplicacin
web.
Hay dos tipos de problemas con la subida de archivos. El primero son los metadatos de
archivos, como el path o el nombre. Estos podran modificarse al realizarse la peticin

59
de envo HTTP con proxys como Tamper Data, pudiendo subir archivos no permitidos
o sobrescribiendo archivos crticos del servidor. El segundo tipo de problema es el
tamao del archivo o su contenido. De nuevo se podra modificar con un proxy
permitiendo la subida de archivos maliciosos.
Podemos ver un ejemplo en la plataforma DVWA en la pestaa de Upload.
Nota: para que pueda funcionar la subida de archivos es necesario dar permisos 777 a la
carpeta /var/www/dvwa/hackable/uploads con chmod.
En el nivel bajo vamos a insertar subir una webshell como la c99, ya que no tiene
proteccin alguna contra ningn tipo de archivo. Pero al intentarlo vemos que no nos
deja, as que vamos a probar utilizar Tamper Data para ver qu ocurre.
Figura 69. Subida errnea de la webshell.
Vemos que tiene un tamao mximo de archivo, as que vamos a probar modificarlo.
Modificamos el tamao mximo con Tamper Data.

60
Ahora si nos dejar subir la webshell y podremos acceder a ella (y con permisos de
escritura!):
Figura 70. Webshell con permisos de lectura y escritura.
En el nivel medio no podremos, aunque codifiquemos el parmetro del tamao, pues el

propio cdigo de la aplicacin comprobar el tamao y no nos dejar subir archivos
grandes. Pero s podremos subir una pequea shell del tipo:
<?php
$cmd=$_GET[cmd];
system($cmd);
?>
Tambin nos dar error, pues la aplicacin comprueba el tipo de archivo que se sube,
permitiendo solo aquellos que sean del tipo image/jpeg.
De nuevo usaremos Tamper Data para intentar modificar este valor.
Cambiamos el valor del tipo de archivo.

61
Finalmente podremos acceder a ella y ejecutar comandos con permisos de lectura,

escritura y ejecucin:
Figura 71. Podemos ejecutar comandos en el servidor.
Para evitar este tipo de vulnerabilidades debemos:

Comprobar las extensiones y utilizar listas blancas para los valores.
Filtrar los archivos por tamao y establecer un lmite de tamao en la carpeta donde
se almacenen los archivos.
Sanear la entrada de caracteres de los archivos subidos, evitando smbolos como ;,
:, >, <, /, \.
Comprobar el nombre de los archivos antes de introducirlos para evitar sobrescribir
otros.
Tener la carpeta que almacene los archivos separada de los archivos crticos del
servidor y que esta tenga el menor nmero de permisos posibles.
Escanear peridicamente los archivos subidos en busca de virus y archivos
potencialmente peligrosos.
11. Gestin de sesiones
En muchos casos las credenciales y tokens de sesin de una aplicacin no estn

correctamente separadas y protegidas, por lo que un atacante podra obtener
contraseas, claves o tokens de autentificacin que les permitan robar la identidad de
otro usuario. Esto es debido a que HTTP y HTTPS no tienen estado y necesitan utilizar
sesiones de usuario para acordarse del estado de la comunicacin (mediante las
cookies).
En cada peticin de sesin se incluye este identificador en forma de cookie para que
puedan mantenerse configuraciones o para no estar constantemente introduciendo el
usuario y contrasea del cliente.

62
Recordamos que en la plataforma DVWA si mirbamos con Tamper Data las peticiones
encontrbamos el identificador de la sesin as como la configuracin de seguridad:
Figura 72. Cookie de la plataforma DVWA.
En muchos casos, este identificador es visible en la red, en el navegador (Live http

Headers), logs dando lugar a que un atacante pueda robar esta informacin en
cualquier punto.
Los fabricantes de frameworks para aplicaciones web, en muchos casos, ya ofrecen un

sistema de gestin de sesiones seguro, usado de manera correcta, ya que crear un
sistema de gestin de sesiones propio puede ser peligroso si no se realiza
correctamente. Pueden ser peligrosos tambin aquellos scripts que permitan a alguien
interferir o modificar la sesin de otro usuario, como formularios de contraseas
(vistos con CSRF), recuperacin de contraseas, preguntas secretas
Una ID de sesin debe ser:

nica por cada usuario y vlida nicamente para una sesin.
Generada por el servidor y enviada al cliente como una variable oculta en una cookie
HTTP.
El usuario debe mandar de vuelta la misma ID en la siguiente peticin para
autentificarse.
Hay dos tcnicas para el robo de sesin:

Session Hijacking. Un atacante espera a que un usuario legtimo de una
aplicacin web establezca una sesin y obtiene el identificador de esta, pudiendo
entonces hacerse pasar por el usuario al utilizar este identificador.
Session Fixation. Un atacante enva explcitamente un identificador de sesin a
una vctima para que establezca la conexin a travs de dicho identificador. A partir
de ah ser igual que la tcnica de Session Hijacking.
Las URL sern similares a:
http://www.ejemplo.com/index...?session_name=sessionid

63
Normalmente un atacante tiene los mismos privilegios que la vctima a la que usurpa la
identidad, pero puede darse casos en los que la vctima tenga ms privilegios y permita
al atacante escalar privilegios o iniciar nuevos vectores de ataque.
Vamos a ver un par de escenarios de ejemplo de robo de sesin:
Session Hijacking. Un usuario establece una sesin en un foro con su usuario y

contrasea y en la URL aparecer su identificador de la forma:
http://www.foro.com?SESSID=1234
El usuario hace clic en algn enlace y le llevar a una pgina maliciosa. En ella, el
administrador de la web podr ver los logs de las peticiones HTTP y ver en el
campo referer de esta, la URL anterior. El atacante entonces podr suplantar la
identidad de la vctima utilizando su mismo identificador.
Session fixation. Un atacante realiza una peticin de login a una aplicacin web y el
sitio web le devuelve un identificador de sesin para que se conecte. En lugar de
introducir sus credenciales, el atacante enva a la vctima a la pgina de login, con el
identificador de sesin que se le dio al atacante, para que esta introduzca sus
credenciales. Una vez la vctima se haya autentificado, un atacante podr
suplantarla, pues posee el mismo identificador.
Figura 73. Ejemplo de session fixation.

Para poder evitar el robo de sesin es necesario:
Utilizar un ID de sesin complejo y aleatorio, que no pueda ser adivinado ni
obtenido por fuerza bruta.

64
Utilizar tcnicas que fomenten la proteccin en la transmisin y almacenaje de la ID

de sesin.
No se debe incluir el identificador de la sesin en la URL, ya que se guarda en la
cach del navegador o en algn proxy intermedio y esto facilita al atacante la labor
de manipularlo.
Utilizar HTTPS en toda la sesin, no solamente en el momento de la autenticacin
para evitar revelar identificadores de sesin. Adems protege la informacin que se
transmite desde o hacia el cliente. Toda la transmisin va cifrada.
El identificador de sesin debe caducar, gestionado por el servidor, y en el lado del
cliente las cookies deben tener una fecha de expiracin.
Se debe regenerar el identificador de la sesin tras una autenticacin correcta o
cuando la cuenta del usuario sufra un cambio de privilegios.
12. Almacenamiento criptogrfico inseguro
En muchas ocasiones las bases de datos de aplicaciones web no guardan la

informacin sensible como contraseas o nmeros de tarjeta de crdito de
forma cifrada. Un atacante podra aprovecharse de la falta de proteccin para
conseguir acceso no autorizado a cuentas, datos, compras online fraudulentas lo que
podra ocasionar una prdida del valor para la compaa, sobretodo prdida de la
confianza del cliente.
Cifrar los datos se ha vuelto relativamente sencillo para los desarrolladores, ya que la
mayora de las plataformas lo integran, pero aun as es comn ver fallos en su
implementacin (o incluso que no se implemente):
Almacenaje inseguro o incorrecto de contraseas, certificados, claves, etc.
Uso de algoritmos inadecuados (dbiles, obsoletos, vulnerables).
Utilizar una semilla insuficientemente aleatoria para vectores de inicializacin.
Intentar desarrollar un sistema de cifrado propio.
Un atacante para romper cifrados dbiles o vulnerables puede usar rainbow tables
(tablas con las posibles combinaciones de contrasea-hash de algn algoritmo de
cifrado dbil, como MD5 o SHA) o pginas que tengan una base de datos de
contraseas rotas como:
http://www.md5decrypter.co.uk

65
Para evitar esta vulnerabilidad es importante tomar una serie de medidas:
Verificar la arquitectura de las aplicaciones:

o Identificar todos los datos sensibles.
o Identificar los puntos donde se guardar la informacin sensible.
o Identificar los posibles riesgos y accesos no autorizados.
o Utilizar el cifrado para paliar los riesgos, no solo cifrar los datos, sino
implementar mecanismos para que los datos cifrados no puedan accederse por
personal no autorizado.
Utilizar mecanismos de cifrado apropiados a las circunstancias: cifrado de ficheros,

de bases de datos, de elementos y estructuras de datos
Utilizar mecanismos de cifrado de manera correcta y verificar su correcta

implementacin:
o Uso de algoritmos estndar y fuertes, implementados en la situacin adecuada.
o Generacin, distribucin y proteccin de las claves de manera apropiada y
segura.
o Realizar cambios de clave de manera peridica.
13. Proteccin insuficiente en la capa de transporte
Es necesario transmitir los datos importantes de una manera segura, ya que la

existencia de sniffers u otras herramientas permitira a un atacante obtener toda la
informacin que se transmite desde y hacia un cliente.
El envo inseguro se suele deber a varios factores:

No identificar correctamente todos los datos importantes.
No identificar todos los sitios a los que se envan datos importantes, ya sea a travs
de la red, a bases de datos secundarias o de desarrollo, comunicaciones internas
(emails, documentos escritos, ftp entre departamentos), empresas asociadas, etc.
No proteger los datos de manera correcta en todos los puntos.
La falta de seguridad en la capa de transporte o la mala configuracin de esta, tiene un

impacto diverso:
Acceso no autorizado o modificacin de la informacin privada (tarjetas de crdito,
datos financieros, credenciales).

66
La informacin extrada se puede utilizar en otros ataques, como el robo de

credenciales. Quin no tiene una misma contrasea y usuario para dos servicios
web diferentes?
ltimamente se estn encontrando muchas vulnerabilidades respecto a la capa de

transporte, principalmente aquellas que se aprovechan de la negociacin del cifrado.
Esta tcnica consiste en hacer un downgrade del tipo de cifrado usado en la capa de
transporte, a cifrados dbiles u obsoletos que sean relativamente fciles de romper. As
un atacante con un sniffer podra obtener todos los datos de una conexin aun estando
esta cifrada.
Se pueden ver los siguientes artculos para saber ms sobre estas tcnicas:
http://www.elladodelmal.com/2015/03/bar-mitzvah-nuevo-ataque-ssltls-te-roba.html
http://www.elladodelmal.com/2015/03/ataques-smack-sobre-tls-skip-tls-freak.html
La principal solucin para evitar este tipo de fallos es utilizar TLS (actualmente la
ltima versin es la 1.2) para transmitir toda la informacin o al menos la informacin
sensible.
Otras medidas importantes son:

Cifrar los mensajes antes de transmitirlos (cifrar el correo, utilizar tneles cifrados
para chats)
Utilizar la firma digital de mensajes antes de transmitirlos para asegurarse de su
integridad.
Utilizar algoritmos estndar y seguros y deshabilitar las implementaciones antiguas
de SSL (para evitar downgrades).
Almacenar y transmitir certificados y claves de manera segura.
Verificar siempre los certificados SSL antes de utilizarlos.

67
Lo + recomendado
Lecciones magistrales
Vulnerabilidades: SQL Inject, XSS y RFI
En esta leccin magistral se van a comentar brevemente las tcnicas de hacking sobre
SQL Injection, XSS y RFI.
La leccin magistral est disponible en el aula virtual.
No dejes de leer
Best Practices for Keeping Your Home Network Secure
El siguiente documento pretende mostrar la forma de securizar una red local para uso
domstico.
El artculo completo est disponible en el aula virtual o en la siguiente direccin web:

https://www.nsa.gov/ia/_files/factsheets/I43V_Slick_Sheets/Slicksheet_BestPractice
sForKeepingYourHomeNetworkSecure.pdf
TEMA 3 Lo + recomendado Universidad Internacional de La Rioja, S. A. (UNIR)

68
SQL Injection
En el siguiente artculo veremos ejemplos de tcnicas de SQL Injection.
El artculo completo est disponible en el aula virtual o en la siguiente direccin web:

http://www.elladodelmal.com/2007/11/tcnicas-avanzadas-en-blind-sql.html
TEMA 3 Lo + recomendado Universidad Internacional de La Rioja, S. A. (UNIR)

69
+ Informacin
A fondo
XSS
En el siguiente artculo se muestran conceptos bsicos y casos prcticos sobre XSS.
El artculo est disponible en el aula virtual o en la siguiente direccin web:

http://www.interbanco.com.gt/uploads/2012/11/cross-si-121115043151-1353018711.pdf
Ldap Injection y Blind Ldap Injection
En este artculo se propone un anlisis de las vulnerabilidades de los servicios del

protocolo LDAP frente a ataques blind sql injection. Adems, se propone el anlisis de
un caso real para destacar los aspectos ms importantes a la hora de securizar
aplicaciones frente a este tipo de ataques.

http://www.imaginar.org/taller/ecollecter/fullpapers/p75-
LDAPInjectionYBlindLDAPInjection.pdf
Gestin de sesiones
En el siguiente artculo se tratan diferentes casos de gestin de sesiones, en concreto de

session fixation.

http://www.um.es/atica/documentos/OWASP_Testing_Guide_v2_spanish.pdf
TEMA 3 + Informacin Universidad Internacional de La Rioja, S. A. (UNIR)

70
Webgrafa
Owasp
Pgina web donde encontramos ms informacin del proyecto Owasp y otros

documentos.
La pgina web est disponible en el aula virtual o en la siguiente direccin:

https://www.owasp.org/index.php/Main_Page
Mutillidae
Pgina web donde encontramos informacin sobre aplicacin Mutillidae.

http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-
php-owasp-top-10

71
Damn Vulnerable Web Application
Pgina web donde encontramos informacin sobre aplicacin DVWA.

http://www.dvwa.co.uk/
Flu-Project: Herramientas de auditora de seguridad
Pgina web donde encontramos informacin sobre las diferentes herramientas de

seguridad que existen.

http://www.flu-project.com/p/herramientas-de-seguridad.html
Acunetix
Aplicacin que escanea sistemas para sacar todas las vulnerabilidades.

http://www.acunetix.com/

72
Bibliografa
Andreu, A. (2006). Professional Pen Testing for Web Applications.Editorial Wrox.

Indiana: Wiley Publishing.
Thompson Martnez, R. (2012). Mitigar inyecciones SQL con tcnicas de minera de

datos. Editorial Acadmica Espaola.

73
Actividades
Realizar un ataque de fuerza bruta a la zona de administracin

de un router
En la siguiente actividad debes descargar la aplicacin Hydra (instalada en Kali), para

la realizacin de ataques de fuerza bruta. Hydra es una herramienta de fuerza bruta que
puede ser usada para los siguientes protocolos TELNET, FTP, HTTP, HTTPS, HTTP-
PROXY, SMB, SMBNT, MS-SQL, MYSQL, REXEC, RSH, RLOGIN, CVS, SNMP, SMTP-
AUTH, SOCKS5, VNC, POP3, IMAP, NNTP, PCNFS, ICQ, SAP/R3, LDAP, PostgreSQL,
Teamspeak, Cisco auth, Cisco enable y Cisco AAA.
Se deben explicar todos los pasos para realizar un ataque de fuerza bruta a un router
genrico.
Extensin mxima: 15 pginas (Georgia 11 e interlineado 1,5).
Realizacin de ataques Command Injection en Mutillidae
En el siguiente ejercicio se utilizar Mutillidae, un proyecto con el que poder aprender y

practicar numerosas tcnicas de hacking.
El objetivo de esta prctica es que consigas realizar ataques de Command Injection o

inyeccin de comandos bajo la plataforma Mutillidae, con el fin de visualizar una lista
de los ficheros contenidos en la plataforma, ver el contenido del fichero index.php, ver
una lista de los servicios de Windows y conseguir detener e iniciar uno de estos
servicios. Para instalar Mutillidae solo hay que seguir los pasos indicados en el
apartado de Plataformas de Aprendizaje.
Es necesario que comentes brevemente todos los pasos seguidos en la realizacin de los
ataques de Command Injection en Mutillidae.
TEMA 3 Actividades Universidad Internacional de La Rioja, S. A. (UNIR)

74
Trabajo: Realizar ataques SQL Injection a WebGoat
En la siguiente actividad debes descargar WebGoat, para realizar ataques utilizando la

tcnica de SQL injection con la aplicacin SQLMap (instalada en Kali).
Para realizar este trabajo debes explicar todos los pasos a seguir para realizar los
ataques SQL Inject con SQLmap.
TEMA 3 Actividades Universidad Internacional de La Rioja, S. A. (UNIR)

75
Test
1. Dentro de las vulnerabilidades en la red podemos encontrar que:

A. XSS es una herramienta para acceder a sistemas operativos.
B. Las tcnicas de inyeccin estn enfocadas principalmente a funciones de
identificacin del usuario.
C. El cdigo de inyeccin SQL es muy parecido al de XSS.
D. Todas las anteriores son incorrectas.
2. Respecto a las vulnerabilidades web basadas en la gestin de sesin indica cul no es

correcta:
A. Se basa en que los protocolos HTTP y HTTPS no pueden guardar el estado de
sesin.
B. El atacante enva explcitamente el identificador de sesin a la vctima en la
tcnica de session fixation.
C. Se fuerza una sesin en el navegador de la vctima para enviar peticiones
maliciosas.
D. Se podra obtener el identificador de sesin gracias al campo referer.
3. Respecto a OWASP indica que afirmacin es correcta:

A. Es una vulnerabilidad que nos permite modificar el valor de los parmetros
que no estn restringidos en la URL.
B. Es un proyecto de cdigo abierto dedicado a determinar y combatir las causas
que hacen que el software sea inseguro.
C. Es una herramienta para detectar aplicaciones vulnerables a inyecciones ASP y
explotarlas.
D. Todas las anteriores son incorrectas.
4. Dentro del Top 10 de vulnerabilidades web encontramos:

A. Referencia Directa Insegura a objetos.
B. Referencia Directa Insegura a websites.
C. Referencia Directa Insegura en inicio de sesiones.
D. Referencia Directa Insegura a operadores de Google Hack.
TEMA 3 Test Universidad Internacional de La Rioja, S. A. (UNIR)

76
5. Qu herramienta nos permite realizar ataques de fuerza bruta a servicios y

aplicaciones web?:
A. BurpSuite.
B. Crunch.
C. Hydra.
D. Tamper Data.
6. El escenario de ataque en el que el listado del contenido de los directorios no est

deshabilitado en el servidor corresponde a:
A. Configuraciones inseguras.
B. Prdida de autentificacin y gestin de sesiones.
C. Redirecciones y reenvos no validados.
D. Secuencia de comandos en sitios cruzados (XSS).
7. El ataque que obliga al navegador de una vctima autentificada a enviar una peticin
HTTP falsificada es una vulnerabilidad que se conoce con el nombre de:
A. XSS reflejado.
B. CSRF.
C. Session Hijacking.
D. Redirecciones y reenvos.
8. Indica que afirmacin es correcta:

A. En la vulnerabilidad de almacenamiento criptogrfico inseguro se puede hacer
un downgrade a los tipos de cifrado.
B. En la vulnerabilidad de proteccin insegura en la capa de transporte se puede
hacer un downgrade a los tipos de cifrado.
C. En la vulnerabilidad de configuraciones inseguras se puede hacer un
downgrade a los tipos de cifrado.
D. En ningn caso se puede hacer un downgrade de los tipos de cifrado.

77
9. Indica qu hara falta inyectar en parmetro1 y parmetro2 en la siguiente

peticin para obtener toda la informacin del usuario admin. (Suponemos que no
realiza comprobacin de caracteres).
SELECT * FROM users WHERE user = parmetro1 AND HASH(parmetro2) =

contrasea;
A. parmetro1 -> admin OR 1 = 1;

parmetro2 -> OR 1 = 1;
B. parmetro1 -> adminOR1=0;
parmetro2 -> adminOR1=1;
C. parmetro1 -> Indiferente
parmetro2 -> adminOR1=1;
D. parmetro1 -> adminOR1=1;
parmetro2 -> Indiferente
10. Dentro de las vulnerabilidades web, cul de las siguientes no existe:

A. RFI.
B. XSS Stored.
C. Reload injection.
D. Session Hijacking.

78

Tema 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tema 3

Uploaded by

Copyright:

Available Formats

Vulnerabilidades web

[3.1] Cmo estudiar este tema?

[3.3] Plataformas de aprendizaje

[3.4] Herramientas para hacking web

[3.5] Tipos de vulnerabilidades

OWASP Plataformas de Herramientas Tipos de

Mutillidae Ejecucin maliciosa de

Subida de archivos sin restriccin

Almacenamiento criptogrfico inseguro

Proteccin insuficiente en la capa de

Universidad Internacional de La Rioja, S. A. (UNIR)

3.1. Cmo estudiar este tema?

En este tercer tema se hablar de las vulnerabilidades web ms importantes, de las

En primer lugar hablaremos de OWASP, un proyecto de cdigo abierto creado para

Despus veremos tres plataformas de aprendizaje: DVWA, Mutillidae y WebGoat.

Luego se vern diferentes herramientas para poder analizar y explotar vulnerabilidades

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

Finalmente, se hablar de los diferentes tipos de vulnerabilidades web. Por cada

OWASP es un proyecto de cdigo abierto dedicado a determinar y combatir las causas

Las herramientas OWASP ms usadas incluyen el entorno de formacin WebGoat

Nos vamos a centrar en el top 10 OWASP, su objetivo es educar a desarrolladores,

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

Figura 1. Comparacin Top 10 OWASP 2010 y 2013.

La gua adems clasifica estas vulnerabilidades segn la facilidad de explotacin que

Figura 2. Clasificacin del Top 10 OWASP 2013.

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

Puedes encontrar documentacin de OWASP en la siguiente direccin web:

Accede al top 10 de 2013:

Accede a la Gua de Testing OWASP v4:

3.3. Plataformas de aprendizaje

Para ello tenemos a nuestra disposicin tres plataformas diseadas especialmente

A continuacin explicaremos cada una de las tres plataformas, tanto su instalacin

DVWA (Damn Vulnerable Web Application) es un reconocido entorno de

Ser la plataforma que utilizaremos para nuestros ejemplos y demostraciones, ya que es

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

Tiene tres niveles de dificultad:

Las temticas que cubre la plataforma son las siguientes:

Brute Force Command execution

CSRF Insecure CAPTCHA

File Inclusion SQL Injection

Blind SQL Injection Upload

XSS Reflected XSS Stored

Categoras principales de DVWA.

Figura 3. Interfaz de DVWA.

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

En nuestro caso, en la mquina Kali ya los tenemos, por lo que descargaremos la

Descomprimiremos el zip, lo moveremos a la carpeta del servidor y le daremos

Ahora iniciaremos el gestor de bases de datos y crearemos la base de datos de la

Finalmente iniciaremos el servidor y ya podremos conectarnos a la plataforma:

Nos conectaremos a ella poniendo en el navegador 127.0.0.1/dvwa/ o localhost/dvwa/.

Hay otra forma de instalar la plataforma en cualquier sistema operativo (Linux,

Puedes obtener ms informacin en la siguiente direccin web:

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

Mutillidae es otra plataforma para poder entrenar los conocimientos de

La plataforma tiene dos modos:

Figura 4. Interfaz de Mutillidae.

De nuevo nos conectaremos a la plataforma mediante el navegador, en este caso

TEMA 3 Ideas clave Universidad Internacional de La Rioja, S. A. (UNIR)

En la siguiente direccin web encontrars, en el apartado Downloads, todas las

El autor de la plataforma tambin ha creado una gran coleccin de vdeo tutoriales de

Puedes ver todos estos vdeos en la siguiente direccin web:

WebGoat es una plataforma con aplicaciones web deliberadamente inseguras

La pgina se divide en diferentes lecciones, en la cuales el usuario deber demostrar su