(7) Vulnerabilidades web

Esta es una vista previa del archivo. Inicie sesión para ver el archivo original

Vulnerabilidades web
Índice
3
3
4
5
6
7
8
9
10
10
11
1 | Concepto
2 | Tipos de vulnerabilidades
2.1 | XSS: Cross-Site Scripting
2.2 | Autenticación y gestión de sesiones
2.3 | Referencia directa insegura a objetos
2.4 | CSRF: Cross-Site Request Forgery
2.5 | Inyección
2.6 | Local & Remote File Inclusion
2.7 | Configuraciones inseguras
2.8 | Almacenamiento Criptográfico Inseguro
2.9 | Uso de Proxy (Burp, ZAP…)
Vulnerabilidades web | TELEFÓNICA // 3
Las vulnerabilidades web pueden definirse como un error en la 
programación o gestión de datos. En otros ámbitos también se 
indica que es una debilidad en:
• Una aplicación web hecha a medida.
• La arquitectura.
• En el diseño.
• En la configuración de la aplicación.
• En el propio código como se indica al comenzar el párrafo.
Las vulnerabilidades web tienen especial 
importancia debido al numeroso uso y lo 
extendidas que están en todos los ámbitos. 
A continuación, se irán estudiando los 
principales tipos de vulnerabilidades según 
OWASP. Se puede ver una comparativa del 
top 10 de OWASP entre el del año 2010 y 
2013 en la siguiente imagen:
1. Concepto
2. Tipos de vulnerabilidades
Imagen 109 Comparativa OWASP Top 10 2010-2013
OWASP Top 10-2010 (Previo) OWASP Top 10-2013 (Nuevo)
A1- Inyección
A3- Perdida de Autenticación y Gestión de Sesiones
A2- Secuencia de Comandos en Sitios Cruzados (XSS)
A4- Referencia Directa Insegura a Objetos
A6- Defectuosa Configuración de Seguridad
A7- Almacenamiento Crisptográfico Inseguro - Fusionada A9→
A8- Falla de Restricción de Acceso a URL - Ampliada en →
A5-Falsificación de Peticiones en Sitios Cruzados (CSRF)
<dentro de A6: - Defectuosa Configuración de Seguridad>
A10- Redirecciones y reenvíos no validados
A9- Protección insuficiente en la Capa de Transporte
A1- Inyección
A2- Perdida de Autenticación y Gestión de Sesiones
A3- Secuencia de Comandos en Sitios Cruzados (XSS)
A4- Referencia Directa Insegura a Objetos
A5- Configuración de Seguridad Incorrecta
A6- Exposición de Datos Sensibles
A7- Ausencia de Control de Acceso a las Funciones
A8-Falsificación de Peticiones en Sitios Cruzados (CSRF)
A9- Uso de Componentes con Vulnerabilidades Conocidas
A10- Redirecciones y reenvíos no validados
Fusionada con 2010-A7 en la nueva 2013-A6
Vulnerabilidades web | TELEFÓNICA // 4
Este tipo de ataques es muy común y es conocido como de tipo 
Client-Side, ya que se produce en el navegador del usuario. Un 
atacante consigue introducir un código Javascript en un parámetro 
web, por ejemplo, y consigue a través de un enlace o la visita a un 
sitio web que dicho código sea ejecutado por el navegador de la 
víctima, aprovechando un fallo en la aplicación web. 
Esto sucede cuando la aplicación no valida, ni la entrada ni la salida 
de los datos de la aplicación web. Se puede utilizar para robar 
sesiones o cookies, realizar un deface, …Existen diferentes tipos de 
XSS, los cuales se describen a continuación:
• No persistente o reflejado. Los ataques llegan a la víctima a 
través de, por ejemplo, un enlace. En uno de los parámetros se 
inyecta el código Javascript y cuando la víctima accede al link su 
navegador ejecuta dicho código.
• Persistente. El código Javascript queda almacenado de forma 
persistente en una base de datos, por ejemplo, cuando un 
usuario introduce un comentario en un sistema y éste no valida 
la entrada, puede quedar almacenado en la base de datos el 
código malicioso. Entonces cuando otros usuarios accedan al 
comentario, los navegadores de estos podrán ejecutar el código 
malicioso. Es el XSS más potente.
• DOM. El código inyectado manipula el código Javascript de los 
objetos HTML.
2.1 | XSS: Cross-Site Scripting
Vulnerabilidades web | TELEFÓNICA // 5
En muchos casos las credenciales y tokens de sesión de una aplicación 
no están correctamente separadas ni protegidas. Los atacantes 
pueden obtener contraseñas, claves o tokens de autenticación que 
les permitan robar la identidad a otro usuario. Esto es debido a que el 
protocolo HTTP no tiene estado y necesita utilizar sesiones, cookies, 
para “acordarse” del estado de la comunicación. 
El identificador de sesión se incluye en cada petición. En muchos 
casos es visible en la red, en el navegador, en los logs, ... En muchos 
casos los fabricantes de frameworks de desarrollo de aplicaciones 
web ya ofrecen un sistema de gestión de sesiones que suele ser 
seguro si se utiliza de manera correcta. Crear un sistema de gestión 
de sesiones propio puede ser peligroso.
Un identificador de sesión debe ser:
• Único a cada usuario.
• Válido únicamente para una sesión.
• Generado por el servidor.
• Enviado al cliente como:
 − Una cookie HTTP (http only).
 − Con el flag secure para que solo se envíe por conexiones 
HTTPS.
• El usuario ha de mandar de vuelta la misma ID en la siguiente 
petición.
El robo de sesión se conoce como Session Hijacking. Cuando un 
atacante tiene la cookie de sesión de otro usuario puede hacerse 
pasar por él, lo cual es altamente peligroso.
2.2 | Autenticación y gestión de sesiones
Vulnerabilidades web | TELEFÓNICA // 6
Esta es una de las vulnerabilidades que más arriba se encuentra 
en el top de OWASP. Está ligada a la autenticación y gestión de 
sesiones y sucede cuando el desarrollador deja referencias a objetos 
implementados de manera interna en una dirección URL o como un 
parámetro en un formulario. Los atacantes pueden manipular estas 
referencias para acceder a otros objetos sin autorización. En otras 
palabras, y para simplificar la explicación, en un sitio web tenemos 
un parámetro llamado “id”, cuando accedemos a nuestra cuenta 
marca “id=55”. Nosotros cambiamos ese identificador por 56, y 
como hay una mala gestión y desarrollo, de repente se acceden a 
los datos del usuario con “id=56”.
Un objeto vulnerable podría ser:
• Un fichero o un directorio.
• Una dirección URL.
• Una clave en base de datos.
• Otros objetos de una base de datos como, por ejemplo, el nombre 
de una tabla.
Para evitar este tipo de vulnerabilidad se debe validar siempre la 
referencia directa al objeto. Verificar que el valor del parámetro 
está correctamente formado y verificar si el usuario tiene permiso 
para acceder al objeto. El control de permisos sobre a qué datos e 
información se puede acceder aquí es fundamental.
2.3 | Referencia directa insegura a objetos
Vulnerabilidades web | TELEFÓNICA // 7
Un ataque CSRF consiste en “obligar” a un usuario ya autenticado 
en un sistema a enviar una petición, con su sesión, al sistema para 
realizar una acción ventajosa para el atacante. Un ejemplo sencillo 
sería el siguiente:
• El usuario “normal” inicia sesión en su red social favorita llamada 
“Facebool”.
• La aplicación web de Facebool es vulnerable a CSRF, es decir, no 
tiene un token anticsrf, el cual se explicará más adelante.
• Un atacante envía a “normal” como el siguiente https://facebool.
XXX/mensajes?id=1034&accion=eliminar_todo
• Si pepito accede a ese enlace, como ya está logado en el sistema 
de Facebool, enviará su cookie y solicitará al sistema la acción 
eliminar todos los mensajes que tenga en su cuenta.
• El sistema de Facebool en ningún momento controla que la acción 
la realice el usuario conscientemente. Esto se puede solucionar 
con los llamados tokens anti-csrf.
La solución para evitar este tipo de ataques es que siempre que 
se vaya a realizar una acción sobre un sistema como, por ejemplo, 
eliminar mensajes, modificar datos, ... el sistema deba darnos un 
token. En el momento que navegamos a la vista de mensajes el 
sistema nos daría un token anti-csrf, el cual debería enviado por 
nuestro navegador cuando realicemos la acción de eliminar, en el 
caso descrito anteriormente. De esta forma, se evita que un atacante 
conozca ese token, el cual debe ser unívoco, grande, complejo, ...
2.4 | CSRF: Cross-Site Request Forgery
Vulnerabilidades web | TELEFÓNICA // 8
La inyección fue la vulnerabilidad más encontrada, además de una 
de las más
críticas, y consiste en manipular las entradas de una 
aplicación para enviar comandos al intérprete de órdenes y que 
éste los ejecute. Lógicamente no es algo sencillo, ya que primero 
se debe detectar dicha vulnerabilidad. Los intérpretes recogen 
cadenas de texto o strings que se pasan a través de parámetros 
web. Por ejemplo, son interpretados por un motor de base de datos 
SQL, el propio sistema operativo, LDAP, XPath, ... La inyección más 
común es la SQL, pero cada día hay más bases de datos NoSQL, las 
cuales empiezan a proporcionar un gran riesgo ante este tipo de 
vulnerabilidades.
La causa más común de esta vulnerabilidad es la falta de 
saneamiento en las entradas, es decir, la validación de las entradas 
y la comprobación de que el parámetro obtenido es seguro. Las 
inyecciones son sencillas de evitar. 
El impacto que tienen es severo, ya que:
• Puede permitir a un atacante leer una base de datos entera y en 
algunos casos modificarla. 
• Puede permitir acceso al esquema de la base de datos, sus 
cuentas y, en algunas ocasiones, al mismo sistema operativo.
Algunas recomendaciones son:
• Evitar utilizar un intérprete en los casos que sea posible. 
• Utilizar una interfaz que implemente variables vinculadas.
 − Sentencias preparadas.
 − Procedimientos almacenados.
 − Las variables vinculadas permiten al intérprete distinguir 
entre código y datos. 
La validación de todas las entradas que provengan de un usuario 
mediante una lista blanca puede ser una buena solución cuando sea 
posible. La idea es denegar todo por defecto y definir los casos en 
que son válidas las entradas. 
La depuración de los privilegios del usuario con el que se accede a 
la base de datos también es importante. Solamente permitir lectura 
de las tablas necesarias. Desactivar escritura dónde sea posible 
y deshabilitar la conexión remota a la base de datos o filtrarla 
mediante dirección IP para que un atacante no pueda conectarse de 
forma remota. 
• http://banco.com/cuentas?auth=687965fdaew87agrde
2.5 | Inyección
http://banco.com/cuentas?auth=687965fdaew87agrde
Vulnerabilidades web | TELEFÓNICA // 9
Estas dos vulnerabilidades son propias de páginas PHP dinámicas 
que permiten enlazar archivos locales o remotos situados en otros 
servidores. Si se echa un vistazo al código fuente de la aplicación 
PHP programada la vulnerabilidad se debe a una mala programación 
o uso de la función include() y require(). Esta vulnerabilidad se da en 
sitios web programados en un lenguaje que permita inclusión de 
ficheros.
La vulnerabilidad es producida por un código semejante a este:
$Page = $_GET[‘page’];
Include($page);
En páginas de este tipo se puede incluir ficheros que estén en 
nuestro servidor: http://victima.com/pagvuln.php?page=http://
[misitio]/miFichero. 
Existen herramientas que permiten explorar un sitio web en 
busca de este tipo de vulnerabilidades, como por ejemplo rpvs. A 
continuación, se puede visualizar una imagen.
Imagen 110 Rpvs
Mediante las webshell o shell PHP se pueden ejecutar comandos en 
una página web. Usando RFI se puede incluir un fichero que ejecute 
comando, tales como listar directorios, obtener y colocar ficheros,... 
El inconveniente es que la mayoría de servidor web en PHP tiene 
deshabilitadas las funciones exec, system o passthru, de modo que 
no se puede ejecutar comandos del sistema operativo. Sin embargo, 
existen funciones como show_source(‘archivo’) que permiten la 
visualización del código fuente de una página. 
A su vez, existen otra serie de funciones que permiten listar el 
contenido de un directorio. El uso de estas funciones no puede 
ser limitado y no depende del sistema operativo sobre el que se 
encuentra instalado el servidor web. 
2.6 | Local & Remote File Inclusion
http://victima.com/pagvuln.php?page=http
Vulnerabilidades web | TELEFÓNICA // 10
Los fallos de configuración pueden estar presentes en cualquier 
punto de una plataforma en Internet o en nuestras redes internas. 
No solo afectan a los equipos de producción, que quizá sea el punto 
más crítico, afectan a cualquier sistema y pueden ser el punto de 
entrada a un robo de información en una organización.
Una mala configuración puede tener todo tipo de consecuencias como, 
por ejemplo, revelar directorios, datos de una conexión a base de datos, 
credenciales de usuarios o, incluso, modificación de datos e información.
Es importante tener en cuenta si el código fuente de una aplicación 
es público o no, y si es el caso estar muy atentos a cualquier 
actualización de seguridad que exista. Independientemente del caso 
en el que nos encontremos, el código fuente sea privado o no, no 
debería afectar a la seguridad del sistema. Al pasar un sistema en 
desarrollo y pre-producción a producción se deberían cambiar todas 
las credenciales.
En muchas aplicaciones, servidores web, instancias de bases de 
datos se almacenan datos sensibles como contraseñas o números 
de tarjeta de crédito. Estos datos son críticos y su almacenamiento 
está sujeto a legislación. Los atacantes pueden aprovechar la falta de 
protección para conseguir acceso no autorizado a cuentas, datos,...
Cifrar los datos es sencillo para los desarrolladores ya que la 
mayoría de frameworks de trabajo proporcionan herramientas y 
librerías que permiten hacerlo. Además, se debe cumplir con las 
leyes actuales, como por ejemplo LOPD. Aun así, es común ver fallos 
de implementación como los siguientes:
• Almacenamiento inseguro o incorrecto de contraseñas, 
certificados, datos sensibles o bajo tratamiento de ley.
• Uso de un algoritmo de cifrado inadecuado.
• Utilización de una semilla insuficientemente aleatoria para los 
vectores de inicialización. Relacionado con el cifrado.
• o Sistemas de cifrado propio. Esto es un error, ya que 
los estándares que se conocen y son robustos están lo 
suficientemente probados como para confiar en ellos. A día de 
hoy se conoce perfectamente que cifrado es robusto y cual no.
2.7 | Configuraciones inseguras
2.8 | Almacenamiento Criptográfico Inseguro
Vulnerabilidades web | TELEFÓNICA // 11
Un proxy es un servidor que hace de 
mediador en las peticiones de recursos 
que efectúa un cliente a un servidor. Esto 
tiene como consecuencia que se tenga 
un control de acceso, registro del tráfico 
generado, prohibición a determinadas 
URL’s, anonimato en las comunicaciones, 
caché web, ...
2.9 | Uso de Proxy (Burp, ZAP…)
Imagen 111 Esquema Proxy - Fuentes: Wikipedia
SCHOOL PC PROXY-
SERVER
INTERNET
FACEBOOK
SERVER
FIREWALL
Allowed session via 
proxi server
Blocked
Facebook
Request
Vulnerabilidades web | TELEFÓNICA // 12
Según la política del proxy podemos encontrar dos tipos de proxys:
• Proxy local: es el propio cliente quien implementa la política de 
proxy, ya que es él el que hace las peticiones, por eso se le suele 
llamar local. Permite controlar el tráfico y establecer diversas 
reglas de filtrado sobre todo para temas de privacidad.
• Proxy de red o proxy externo: es una entidad externa quien 
implemente la política del proxy. Normalmente se utiliza para 
bloquear ciertos contenidos, controlar el tráfico generado, … 
En general, permiten obtener una seria de ventajas como: 
• Control: se pueden limitar los derechos de los clientes, y dar 
permisos únicamente al proxy que es el que hace el trabajo 
efectivo.
• Ahorro: el proxy es el único que utiliza los recursos necesarios. 
• Velocidad: el proxy puede almacenar información (caché) por si 
varios clientes realizan la petición de un mismo recurso. 
• Filtrado: se puede filtrar cierta información denegando acceso a 
determinadas peticiones. 
• Modificación: El proxy puede falsificar cierta información o 
modificarla al vuelo, al estar en medio de la comunicación. 
Además, también se tienen algunas desventajas como son:
• Anonimato: es difícil determinar quién realizó verdaderamente 
la petición de la información.
• Carga: realiza mucha carga de peticiones ya que son diversos 
clientes los que utilizan el mismo proxy.
• Mediación: el proxy al estar en medio de la comunicación puede 
controlar toda la información que viaja entre el origen y destino.
• Incoherencia: el proxy al almacenar información como caché 
puede responder con cierta información poco actualizada. Cada 
vez menos habitual.
Vulnerabilidades web | TELEFÓNICA // 13
Tipos de proxys
Podemos encontrar distintos tipos de proxys según su función 
principal. Entre ellas destacamos las siguientes:
• Proxy Caché: permite almacenar la información solicitada para 
permitir una respuesta rápida a peticiones iguales posteriores.
• Proxy Web: permite proporcionar especial atención a las páginas 
web, mediante el cacheo de información para optimizar tiempos 
de acceso y acelerar la carga de los enlaces. Se utilizan en los 
protocoles web y ftp principalmente.
• Proxies transparentes: este tipo de proxy permite interceptar las 
peticiones y desviarlas hacia el proxy sin que el cliente conozca 
su coexistencia. Se combinan con firewalls.
• Proxy inverso (Reverse Proxy): este tipo de servidor proxy 
permite redirigir todo el tráfico a algún servidor web que permite 
gestionar las peticiones.
• Proxy NAT (Network Address Translation) / Enmascaramiento: 
permite que las peticiones sean redirigidas al proxy mediante NAT 
restringiendo el acceso desde el exterior. Se puede configurar 
desde el propio firewall siendo muy fácil su implementación.
• Proxy abierto: permite las peticiones desde cualquier ordenador 
de una red. Normalmente se utilizan para la redirección de las 
peticiones de los servidores de DNS.
Existen diversas aplicaciones proxy, entre ellas Burp Suite, Paros, 
Vega, WebScarab y Owasp Zap. Todas estas herramientas incluyen 
diversas funcionalidades interesantes.
OWASP ZAP
OWASP Zed Attack Proxy (ZAP) es una herramienta de código libre 
desarrollada en Java dentro del proyecto OWASP (Open Application 
Security Project) utilizada en auditorías de aplicaciones web para 
la búsqueda de vulnerabilidades web. Aunque inicialmente se creó 
como proxy Web HTTP/HTTPS, actualmente posee una serie de 
herramientas automáticas que permiten realizar determinadas 
tareas dentro de un pentesting.
Primeramente, dada su arquitectura de proxy que permite interceptar 
las peticiones HTTP y HTTPS, se tendrá de configurar el navegador 
web para que envíe las peticiones web a ZAP, éste las reenvíe al 
servidor web y pueda obtener las respuestas para enviárselas al 
cliente.
Imagen 112 Configuración Proxy
ZAP, usa el puerto 8080 TCP por defecto para la captura de las 
peticiones, aunque es fácilmente configurable desde la propia 
aplicación.
Vulnerabilidades web | TELEFÓNICA // 14
Una vez configurado el navegador ZAP 
ya está listo para interceptar todas las 
peticiones que se envíen desde el navegador 
y las respuestas del servidor web.
Para empezar, se realizará un Spider a la 
URL que se quiera atacar obteniendo gran 
cantidad de direcciones a analizar al recorrer 
todas las URL del sitio objetivo. A estas 
URL’s se les realizará un análisis en busca 
de vulnerabilidades determinando si se 
tiene algún tipo de riesgo o no, mostrando 
información relativa a dicho riesgo. Es lo que 
llamaríamos un escaneo pasivo.
Imagen 114 Owasp ZAP – Escaneo pasivo
Imagen 113 Owasp ZAP
Vulnerabilidades web | TELEFÓNICA // 15
Una vez efectuado el escaneo pasivo se 
procederá a un escaneo activo, en el que se 
realizará una serie de pruebas o ataques a 
las direcciones encontradas. Los ataques 
típicos que pueden realizarse son SQL 
Injection, XSS Cross Site Scripting, LFI Local 
File Include, RFI Remote File Include, …
 
La forma de trabajar de ZAP es probar este 
tipo de ataques sin concluirlos realmente, 
simulando dichos ataques. Si tiene éxito 
esta simulación se tendrá una vulnerabilidad 
del tipo correspondiente mostrando una 
alerta por cada vulnerabilidad encontrada 
y clasificada (banderitas con colores) según 
su riesgo alto, medio o bajo.
Imagen 116 Owasp ZAP - Alertas vulnerabilidades
Imagen 115 Owasp ZAP - Alertas
Vulnerabilidades web | TELEFÓNICA // 16
ZAP permite generar un informe, tanto 
en HTML como en XML para su posterior 
análisis, en el que podemos comprobar las 
vulnerabilidades obtenidas, mostrando la 
descripción, dirección URL y el ataque tipo 
que se puede ejecutar, así como las posibles 
soluciones.
Imagen 117 Owasp ZAP - Generar informe
Imagen 118 Owasp ZAP - Informe generado