ACTIVIDADES DE LABORATORIO OWASP TOP 10

Antecedentes
Para la realizacin de las actividades del laboratorio OWASP Top 10 se utilizarn distintas
herramientas que permitirn simular pginas web con distintos tipos de vulnerabilidades que
pueden ser explotadas con fines de aprendizaje.

Listado de herramientas
Para identificar las vulnerabilidades que podran ser explotadas por las amenazas listadas en el
OWASP Top 10, se utilizar la herramienta OWASP ZAP (Zed Attack Proxy) la cual permite realizar
anlisis de sitios web en bsqueda de vulnerabilidades, con diversos fines, entre los cuales est el
aprendizaje o securizacin misma del sitio.
Para los primeras dos amenazas a la seguridad de una aplicacin web (SQLi y XSS) se har uso de la
Aplicacin de demostracin de Seguridad de Software la cual es utilizada en el mdulo Seguridad de
Software (CC5315) en la Universidad de Chile.
Posteriormente, continuando con el anlisis, deteccin y mitigacin de amenazas se continuar con
el OWASP Broken Web Applications Project, la cual es una coleccin de aplicaciones web vulnerables
que son distribuidas dentro de una mquina virtual en formato VMware para ser utilizada en el
VMware Player.

Instalacin de herramientas
1. OWASP ZAP
La instalacin de OWASP ZAP requiere descargar el instalador desde la pgina web oficial
del proyecto (https://code.google.com/p/zaproxy/wiki/Downloads?tm=2). Posteriormente
slo es necesario seguir los pasos del asistente de instalacin.
2. Aplicacin de demostracin de Seguridad de Software
En primer lugar se requiere tener instalado Java (1.6 o superior) y Maven (2 o superior).
La instalacin de Maven (en Windows) se realiza descargando el instalador desde la pgina
web oficial (http://maven.apache.org/download.cgi) la opcin apache-maven-3.2.3-bin.zip.
Se descomprime el contenido el cual se compone de la carpeta apache-maven-3.2.3.

A continuacin se han de crear ciertas variables de entorno, las cuales son necesarias para
la utilizacin de Maven. Las variables de entorno se crean en las opciones avanzadas de las
propiedades del sistema.

Accediendo al men de Variables de entorno, se pueden crear las variables que se necesitan

Ah hay que crear una nueva variable de sistema con el nombre M2_HOME y el valor la ruta
en donde se encuentra la carpeta de Apache Maven.
Luego, se ha de editar la variable Path con el valor de la variable ;%M2_HOME%\bin

A modo de troubleshooting sera bueno verificar la instalacin del JDK de Java y que exista
la variable de entorno JAVA_HOME. De no ser as, se ha de crear la variable de entorno con
el nombre JAVA_HOME y el valor de la variable; la ruta en donde se encuentra instalado el
JDK. Normalmente la ruta es C:\Archivos de programa\Java\jdk1.x_x
Se debe comprobar el estado de la instalacin mediante la consola ejecutando mvn -version

El mensaje de respuesta debe ser similar al presentado.

Modo de uso
Los comandos que sern listados a continuacin requieren situarse en el directorio donde
se encuentra el archivo pom.xml
Antes de comenzar a usar la aplicacin se debe crear una base de datos para la aplicacin
web, mediante: mvn install

Finalmente para activar el servidor, slo se debe escribir en la consola: mvn jetty:run
El servidor se activar automticamente y dejar la aplicacin en http://localhost:8080
3. OWASP Broken Web Applications Project
Es una coleccin de aplicaciones web vulnerables que son distribuidas dentro de una
mquina virtual en el formato VMware.
Esta coleccin incluye varios tipos de aplicaciones opensource. Entre las cuales se
encuentran:
- Aplicaciones de Entrenamiento: OWASP WebGoat, OWASP Mutillidae II, OWASP Bricks.
- Aplicaciones Reales Intencionalmente Vulnerables: OWASp Vicnum, Google Gruyere,
BodgeIt.
- Aplicaciones Reales Antiguas: WordPress, Gallery2, Joomla, AWStats.
- Aplicaciones para Probar Herramientas: OWASP ZAP-Wave, WAVSEP, WIVET.
- Pginas para Demostracin / Pequeas Aplicaciones: OWASP CSRFGuard, Mandiant
Strus Forms.
- Aplicaciones OWASP para Demostracin: Owasp AppSensor Demo Aplication.
La mquina virtual puede ser descargada en su ltima versin 1.1.1 desde la pgina oficial
(http://sourceforge.net/projects/owaspbwa/files/). Es un archivo de tamao de 1.3 Gb que
viene comprimido. Una vez descomprimido se debe abrir con la aplicacin VMware Player.

Al iniciar la mquina virtual se presentar informacin relacionada al acceso y credenciales,

a tener en consideracin durante el uso del sistema.

Una vez que se utilizan las credenciales username = root y password = owaspbwa se puede
ingresar al portal web que ofrece la mquina mediante un navegador en la direccin
http://192.168.136.130

Desde ah se pueden utilizar las distintas pginas web que sern auditadas durante el
desarrollo de este laboratorio.

OWASP TOP 10
SQL Injection
Descripcin
Un ataque de inyeccin SQL consiste en la insercin o inyeccin de datos en una consulta SQL
desde un cliente de la aplicacin. En el caso de tener xito en inyeccin SQL podra por ejemplo, leer
datos sensibles de la base de datos, modificar los datos, realizar operaciones de administracin
sobre la misma base de datos tal como reiniciar el DBMS, entre otros. Los ataques de inyeccin SQL
son un tipo de ataque de inyeccin, en los cuales comandos SQL son inyectados en texto para afectar
la correcta realizacin de una consulta SQL predefinida.
Los tipos de ataques de inyeccin SQL se dividen en tres clases:
-

Inband: los datos son extrados usando el mismo canal que es usado para inyectar el cdigo
SQL. Este es el tipo de ataque ms simple, en el que los datos recibidos se muestran en la
propia aplicacin web.
Out-of-band: los datos son extrados usando un canal diferente, como puede ser un correo
electrnico con el resultado de la consulta que es generado y enviado al auditor.
Inferetial: no hay transferencia de datos, pero el auditor puede reconstruir la informacin
enviando peticiones y observando el comportamiento que mantiene el servidor de bases de
datos.

Independiente del tipo de ataque, una inyeccin SQL correcta requiere que el atacante pueda
construir una consulta SQL correcta. Si la aplicacin devuelve un mensaje de error a causa de una
consulta incorrecta, entonces en fcil reconstruir de forma lgica la consulta original y, por lo tanto,
entender cmo realizar una inyeccin correctamente. Sin embargo, si la aplicacin oculta los
mensajes de error, un auditor puede conseguir por medio de ingeniera inversa la lgica de la
consulta original. Este ltimo caso se conoce como inyeccin SQL ciega (Blind SQL Injeccion).
Deteccin de inyeccin SQL
Como primer paso para esta prueba es entender cuando una aplicacin web se conecta a un servidor
de bases de datos para acceder a algn dato. Los ejemplos tpicos de casos en los que una aplicacin
necesita comunicarse con una base de datos incluyen:
-

Formularios de autentificacin: cuando la autentificacin es realizada usando un formulario

web, es probable que las credenciales de un usuario sean comprobadas contra una base de
datos que contenga todos los usuarios y contraseas (hash de contraseas).
Motores de bsqueda: el string enviado por un usuario puede ser usado en una consulta
SQL que recupere todos los registros relevantes en una base de datos.
Webs de comercio electrnico: los productos y sus caractersticas (precio, descripcin,
disponibilidad) son siempre almacenados en una base de datos relacional.

Prueba estndar de inyeccin SQL

Considerando la siguiente consulta:
SELECT * FROM Users WHERE Username='$username$' AND Password='$password$'
Un consulta similar a las que son usadas por una aplicacin web para autenticar un usuario. Si la
consulta devuelve un valor, esto significa que un usuario con esas credenciales existe en la BBDD y
entonces el usuario tiene permisos para iniciar su sesin en el sistema, en caso contrario el acceso
es denegado. Los valores de los campos de entrada son generalmente obtenidos del usuario a travs
de un formulario web. Suponiendo que se insertan los siguientes valores en Username y Password:
$username = 1' OR '1' = '1 y $password = 1' OR '1' = '1.
Resulta la siguiente consulta:
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
Si se supone que los valores de los parmetros son enviados al servidor mediante el mtodo GET, y
si el dominio de la aplicacin web vulnerable es www.example.com, la peticin sera:
http://www.example.com/index.php?username=1'%20or%201'%20=%20'1&password=1'%20or%
20'1'%20=%20'1
La consulta devolver un valor dado que la condicin siempre es verdadera (OR 1=1). Por lo tanto,
este caso el sistema autenticara al usuario sin conocer el Username ni el Password. Cabe mencionar
que en algunos sistemas, el primer registro de la tabla de usuarios es el del administrador. Esto
puede hacer que el usuario devuelto sea el propio administrador en muchos casos.
Actividad prctica de laboratorio
En un navegador donde se est viendo la aplicacin web (http://localhost:8080)

Se debe ingresar a la seccin de Login para as intentar determinar la existencia de alguna

vulnerabilidad que pueda ser explotada mediante inyeccin SQL.

Una opcin es probar lo mencionado en al comienzo de la seccin de inyeccin SQL con la prueba
estndar. De otro modo, se puede utilizar OWASP ZAP como herramienta automtica para la
deteccin de vulnerabilidades.
Uso de la herramienta OWASP ZAP
En primer lugar se debe indicar cul ser la direccin a la cual dirigir las acciones de anlisis de
vulnerabilidades. Dado que se est utilizando la aplicacin web alojada en la direccin
localhost:8080 se agrega tal direccin y se continua con el botn Atacar dado el inicio a la revisin
de vulnerabilidades

Luego del escaneo de la pgina objetivo se encontraron vulnerabilidades crticas asociadas a

inyeccin SQL y secuencia de comandos en sitios cruzados o XSS. En esta etapa slo se habr de
considerar la amenaza de inyeccin SQL.

La herramienta indica que efectivamente la brecha puede ser explotada utilizando la prueba
estndar de inyeccin SQL.

Por lo tanto lo que dado que ya se ha identificado que vulnerabidad es explotable efectivamente
por un ataque de inyeccin SQL corresponde ahora aplicar medidas de mitigacin.
Contramedida/Mitigacin
La contramedida o mitigacin para situaciones como estas segn OWASP corresponde a que en
primer lugar todas las consultas deben ser parametrizadas. Luego, todos los datos dinmicos deben

estar vinculados explcitamente a consultas parametrizadas. Por ltimo, que la concatenacin de

strings nunca debe ser usado para crear SQL dinmico. Especficamente para mitigar lo observado
en la actividad se deben usar sentencias preparadas (prepared statements), estas obligan al
desarrollador a definir en primer lugar todo el cdigo SQL y luego pasar en cada parmetro a la
consulta siguiente. Lo importante es que este estilo de codificacin permite a la base de datos
distinguir entre cdigo y datos, independientemente de lo que la entrada del usuario entrega.
Considerando el siguiente ejemplo:

En este cdigo es posible proporcionar un nombre de usuario con meta-caracteres de SQL que
desestabiliza la consulta, por ejemplo con un nombre de usuario admin' OR '1'='1 y una contrasea
en blanco, generando una sentencia de consulta SQL de esta forma:
SELECT * FROM user WHERE username='admin' OR '1'='1' AND password=' '
Permitiendo iniciar sesin sin proporcionar contrasea dado que la expresin OR siempre es cierta.
La forma de evitarlo usando sentencias preparadas es la siguiente:

En esta actividad se requiere buscar la consulta en el cdigo fuente de la aplicacin web y corregir
la consulta utilizando sentencias preparadas para as evitar un ataque de inyeccin SQL.

Actividades
1. Realizar un ataque de SQL inyeccin en el portal de la aplicacin web objetivo.
2. Aplicar correccin de mitigacin en el cdigo fuente de la aplicacin web.
3. Documentar los resultados.

Cross Site Scripting XSS (Reflejado)

Descripcin
Los ataques de tipo XSS reflejado son tambin conocidos como de tipo 1 o no persistentes, y son los
ataques ms frecuentes de XSS en la actualidad.
Cuando una aplicacin web es vulnerable a este tipo de ataque, entregar datos de entrada no
validados al cliente. El modo ms comn de operacin de este ataque incluye un paso de diseo, en
el cual el atacante crea y comprueba la URI culpable, un paso de ingeniera social, en el cual
convence a sus vctimas de cargar esta URI en sus navegadores, y a la eventual ejecucin del cdigo
malicioso utilizando las credenciales de la vctima.
Comnmente el cdigo del atacante es escrito en Javascript, pero en otros lenguajes de scripting
pueden ser tambin utilizados ActionScripting y VBScript.
Los atacantes tpicamente utilizarn estas vulnerabilidades para instalar keyloggers, robar
credenciales de usuarios, obtener datos del portapapeles y cambiar el contenido de la pgina, como
por ejemplo, enlaces de descargas.
Uno de los aspectos ms importantes sobre las vulnerabilidades XSS es la codificacin de caracteres.
En algunos casos, el servidor web o aplicacin web no pueden filtrar la codificacin de algunos
caracteres, por lo tanto, la aplicacin web puede filtrar <script>, pero no es capaz de filtrar
%3escript%3 el cual simplemente incluye otra codificacin de los tags.
Deteccin de Cross Site Scripting
Para la deteccin de un XSS son necesarios al menos, los siguientes tres pasos:
1. Detectar vectores de entrada. El auditor debe determinar las variables de la aplicacin web
y como ingresarlas en la aplicacin web.
2. Analizar cada vector de entrada para detectar posibles vulnerabilidades. Para detectar una
vulnerabilidad XSS, el auditor utiliza datos especialmente diseados para cada vector de
entrada. Tal entrada es tpicamente no daina, pero puede provocar respuestas desde el
navegador web que manifiestan la vulnerabilidad. Los datos de prueba pueden ser
generados utilizando un fuzzer de aplicacin web o manualmente.
3. Por cada vulnerabilidad reportada en fase previa, el auditor analizar el reporte e intentar
explotarla con un ataque que tenga un impacto realista en la seguridad de la aplicacin web.

Prueba estndar de Cross Site Scripting Reflejado

Por ejemplo, considrese un sitio que contenga un mensaje personalizado como el tratamiento de
una persona, ya sea seor o seora.

Un auditor debe sospechar que cada posible entrada de datos puede resultar en un ataque XSS.
Para analizarlo, se juega con las variables en la URI intentando explotar la vulnerabilidad. Por
ejemplo con el siguiente enlace sucede esto:
http://www.clinicasantamaria.cl/***/***.asp?mensaje=<script>alert(/Ejemplo XSS UTALCA 20142/)<script>

Esto indica que existe una vulnerabilidad XSS y pareciera ser que se puede ejecutar cdigo a gusto
en el navegador de cualquiera si el usuario hace clic en el enlace auditado.
Contramedida/Mitigacin
Actualmente la mayora de las aplicaciones web utiliza sanitizacin para evitar este tipo de
vulnerabilidades. Sin embargo, algunas permanecen vulnerables. Los ataques de cross site scripting
reflejado son prevenidos o bien del lado del servidor utilizando sanitizacin, o con firewall de
aplicaciones web, o del lado del cliente utilizando mecanismos de prevencin que se integran a los
navegadores web como complementos.
Debido a que la mayora de los clientes no actualiza los navegadores, un auditor no puede confiarse
en esto y debe testear por vulnerabilidades asumiendo que los navegadores web no podrn evitar
el ataque.
Una aplicacin web o el servidor web, por ejemplo, el mdulo de Apache mod_rewrite, puede
convertir la URL que coincida con una expresin regular como un procedimiento de sanitizacin. Por
ejemplo la siguiente expresin regular puede ser usada para detectar y bloquear caracteres
alfanumricos dentro de tags o barras inclinadas.
/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i
Como resultado el ataque realizado arriba a la pgina web de la Clnica Santa Mara no funcionara.
En esta actividad se requiere buscar en el cdigo fuente de la pgina web de Fans de las aves chilenas
la vulnerabilidad que puede ser explotada por cross site scripting y corregirla para as evitar un
ataque XSS.

Actividades
1. Realizar un ataque de XSS Reflejado en el portal de la aplicacin web objetivo (Fans de las aves
chilenas).
2. Aplicar correccin de mitigacin en el cdigo fuente de la aplicacin web.
3. Documentar los resultados.

Insecure Direct Object References

Descripcin
Una referencia directa a objetos ocurre cuando un programador expone una referencia hacia un
objeto interno de la aplicacin, tales como un fichero, directorio, registro de base de datos, o una
clave tal como una URL o un parmetro de formulario Web. Un atacante podra manipular este tipo
de referencias en la aplicacin para acceder a otros objetos sin autorizacin, a menos que se aplique
un control de accesos como medida de prevencin.
Por ejemplo, en las aplicaciones bancaras en lnea, es comn que se utilice el nmero de cuenta
como clave primaria. Por consiguiente, se podra tener la tentacin de usar esta clave directamente
como parmetro en la interfaz Web. An en el caso de que el equipo de desarrollo hubiera utilizado
consultas SQL preparadas (parameterized SQL queries) para evitar una inyeccin SQL, podra ser
posible que un atacante modificara este parmetro para ver o cambiar todas las dems cuentas, si
no se verifica tambin que el usuario es el titular de la cuenta bancaria o est autorizado para
acceder a la misma.
Deteccin de Insecure Direct Object References
Para comprobar si una aplicacin es vulnerable a referencias inseguras a objetos es verificar que
todas las referencias a objetos tienen las protecciones apropiadas. Para conseguir esto, se debe
considerar:
1. Para referencias directas a recursos restringidos, la aplicacin necesitara verificar si el
usuario est autorizado a acceder al recurso en concreto que solicita.
2. Si la referencia es una referencia indirecta, la correspondencia con la referencia directa debe
ser limitada a valores autorizados por el usuario en concreto.
En estos casos es necesario un anlisis del cdigo de la aplicacin sirve para verificar rpidamente
si dichas propuestas se implementan con seguridad. Tambin es efectivo realizar comprobaciones
para identificar referencias a objetos directos y si estos son seguros. Normalmente las herramientas
automticas no detectan este tipo de vulnerabilidades porque no son capaces de reconocer cules
necesitan proteccin o cules son seguros o inseguros.
Prueba estndar de Insecure Direct Objetct References
Muchas aplicaciones presentan a los usuarios referencias a objetos internos. Un atacante podra
manipular los parmetros de entrada a la aplicacin cambiando estas referencias, saltndose de
esta manera un control de accesos incorrectamente desarrollado. Con frecuencia, estas referencias
apuntan a sistemas de ficheros y bases de datos, si bien cualquier otro elemento de la aplicacin
podra ser vulnerable por un problema de esta categora.
Por ejemplo, en el caso de que el cdigo utilizara la entrada del usuario para construir nombres de
fichero o rutas de acceso a los mismos, podra ser posible que un atacante saliera del directorio
donde est la aplicacin, y accediera a otros recursos.
Consultar una transaccin A en una aplicacin Web

http://webapplication.com/viewtrans?idt=205683
Consultar una transaccin X y poder ver la informacin asociada slo cambiando el ID de transaccin
http://webapplication.com/viewtrans?idt=205684
Decidir si la transaccin X es un problema de seguridad o no es difcil de comprobar por medio de
anlisis dinmicos de vulnerabilidades.
Actividad de laboratorio
En Mutillidae se debe entrar en la seccin de Source Code Viewer

Utilizando la herramienta Tamper Data (https://addons.mozilla.org/es/firefox/addon/tamper-data)

para modificar las cabeceras HTTP/HTTPS y parmetros POST, realizar modificacin de la cabecera
de la pgina donde se puede ver el cdigo fuente de add-to-your-blog.php a ver el cdigo fuente del
php del generador de password, password-generator.php.

El resultado de la actividad es el siguiente.

Actividad
1. Realizar modificacin de la cabecera HTTP en el parmetro POST para saltar al cdigo PHP
de password-generator.php
2. Listar los controles de mitigacin que aplicara si tuviera a disposicin el cdigo fuente de la
aplicacin web.
3. Documentar los resultados.

Broken Authentication and Sesion Management

Descripcin
La vulnerabilidades relacionada con la prdida de autenticacin y gestin de sesiones son crticas en
la seguridad de las aplicaciones y en especial de las aplicaciones Web, ya que permiten a un atacante
suplantar la informacin de un determinado usuario, pudiendo llegar a obtener una cuenta de
administracin que le permita sabotear los controles de autorizacin y registro de la aplicacin. Esta
situacin podra ocasionar un acceso no autorizado a cualquier tipo de informacin que se
encuentre almacenada en el servidor o los servicios que han sido comprometidos.
Existe una gran cantidad de situaciones en las que se puede encontrar frente a una aplicacin
vulnerable a este tipo de ataque, la mayor parte de las veces se encuentran en la gestin de las
contraseas, la expiracin de sesiones o el proceso de cierre de sesin.
Especficamente para este laboratorio se centrar en lo que son las pruebas de seguridad de
atributos de cookies.
Pruebas de atributos de cookies
Las cookies comnmente son un vector de ataque para los usuarios maliciosos (tpicamente
teniendo como objetivo otros usuarios) y, como tal, la aplicacin siempre debe tomar las medidas
para proteger las cookies. En este laboratorio, se ver como en una aplicacin que no toma las
precauciones necesarias al asignar cookies, compromete la seguridad de las cuentas de los usuarios.
Para entender la importancia de las cookies es imperativo entender para que son usadas
principalmente. El sentido de las cookies principalmente consiste en ser usadas como un
identificador de sesin para la autorizacin/autenticacin o como un contenedor de datos temporal.
As, si un atacante fuera capaz de obtener un identificador de sesin (por ejemplo, al explotar una
vulnerabilidad de cross site scripting o al usar un sniffer en una sesin no cifrada), entonces podra
usar esta cookie para obtener una sesin valida.
Adicionalmente, las cookies son establecidas para mantener un estado a lo largo de peticiones
mltiples. Ya que HTTP no tiene estado, el servidor no puede determinar si una peticin que recibe
es parte de una sesin actual o es el inicio de una nueva sesin sin algn tipo de identificador. Este
identificador es muy comnmente una cookie aunque otros mtodos tambin son posibles. Como
podra imaginarse, hay muchos tipos diferentes de aplicaciones que necesitan mantener el registro
del estado de la sesin a travs de peticiones mltiples. La principal que se viene a la mente es una
tienda en lnea. Por ejemplo, mientras un usuario agrega artculos a un carro de compra, esta
informacin necesita ser retenida en peticiones subsecuentes a la aplicacin. Las cookies son muy
comnmente usadas para esta tarea y son establecidas por la aplicacin usando la directiva SetCookie en la respuesta HTTP de la aplicacin, y usualmente es en un formato nombre=valor (si las
cookies estn habilitadas y si son soportadas, el cual es el caso de todos los navegadores modernos).
Una vez que la aplicacin le ha dicho al navegador usar una cookie en particular, el navegador
enviar esta cookie en cada peticin subsecuente. Una cookie puede contener informacin como
artculos de un carro de compra, los precios de estos artculos, la cantidad de estos artculos,
informacin personal, nombres de usuario, etc. Debido a la naturaleza sensitiva de la informacin

en cookies, tpicamente son codificadas o cifradas en un intento de proteger la informacin que

contienen.
Ahora que se entiende cmo son establecidas las cookies, cuando son establecidas, para que se
usan, porque se usan, y su importancia, queda ver cuales atributos pueden ser establecidos para
una cookie y como probar si son seguros.

secure - Este atributo le dice al navegador que solo enve la cookie si la peticin est siendo
enviada sobre un canal seguro como HTTPS. Esto ayudar a proteger la cookie de ser
enviada en peticiones no cifradas.
HttpOnly - Este atributo es usado para ayudar a evitar ataques como cross-site scripting, ya
que no permite que la cookie sea accedida va un script como JavaScript. Note que no todos
los navegadores soportan esta funcionalidad.
domain - Este atributo es usado para comparar contra el dominio del servidor en el que la
URL est siendo requerida. Si el dominio es el mismo o si es un sub-dominio, entonces el
atributo path ser el siguiente en ser verificado.
path - en adicin al dominio, la ruta de URL puede ser especificada para la cual la cookie es
vlida. Si el dominio y la ruta coinciden, entonces la cookie ser enviada en la peticin.
expires - Este atributo es usado para establecer cookies persistentes, ya que la cookie no
expira hasta que la fecha establecida sea superada. Esta cookie persistente ser usada por
esta sesin del navegador y sesiones subsecuentes hasta que la cookie expire. Una vez que
la fecha de expiracin haya sida superada, el navegador borrar la cookie. Alternativamente,
si este atributo no es establecido, entonces la cookie es solo vlida en la sesin actual del
navegador y ser eliminada cuando la sesin termine.

Control/Mitigacin
Usando un proxy interceptor o un plug-in interceptor para el navegador, se deben capturar todas
las respuestas donde una cookie sea establecida por la aplicacin (usando la directiva Set-cookie) e
inspeccione la cookie en busca de:

Atributo secure - Siempre que una cookie contenga informacin sensitiva o que sea un
identificador de sesin, entonces debe siempre ser enviada usando un canal cifrado. Por
ejemplo, despus de ingresar a una aplicacin y un identificador de sesin es establecido
usando una cookie, verificar si est etiquetada usando la bandera ";secure". Si no es as,
entonces el navegador cree que es seguro enviarla en un canal no cifrado como HTTP.
Atributo HttpOnly - Este atributo debe ser establecido siempre aunque no todos los
navegadores lo soportan. Este atributo ayuda a asegurar la de ser accedida por un script
local as que verifique que la etiqueta ";HttpOnly" haya sido establecida.
Atributo Domain - Verifique que el dominio no haya sido establecido pobremente. Como se
vio anteriormente, debe ser nicamente establecido para el servidor que necesita recibir la
cookie. Por ejemplo si la aplicacin reside en el servidor app.mysite.com, entonces debe ser
establecido a "; domain=app.mysite.com" y NO ";domain=.mysite.com" ya que esto
permitira otros servidores potencialmente vulnerables recibir la cookie.
Atributo path - Verifique que el atributo de ruta, como el atributo de dominio, no haya sido
establecido pobremente. Aunque el atributo de dominio haya sido configurado tan rgido

como sea posible, si la ruta es establecida al directorio raz "/" entonces puede ser
vulnerable a aplicaciones menos seguras en el mismo servidor. Por ejemplo si la aplicacin
reside en /myapp/ entonces verifique que la ruta de las cookies sea establecido a ";
path=/myapp/" y NO "; path=/" o "; path=/myapp". Note que "/" debe ser usada despus
de myapp. Si no es usado, el navegador enviar la cookie a cualquier ruta que coincida con
"myapp" como "myapp-exploited".
Atributo expires - Verifique que, si este atributo es establecido en un tiempo futuro, que no
contenga ninguna informacin sensitiva. Por ejemplo, si una cookie es establecida a ";
expires=Fri, 13-Jun-2010 13:45:29 GMT" y es actualmente Junio 10 de 2008, entonces hay
que inspeccionar la cookie. Si la cookie es un identificador de sesin que es almacenado en
el disco duro del usuario entonces un atacante o usuario local (como un administrador) que
tenga acceso a esta cookie puede acceder a la aplicacin al reenviar este identificador hasta
que la fecha de expiracin haya pasado.

Actividad de laboratorio
En Mutillidae se deber capturar la sesin de administrador mediante modificacin de las cookies
de sesin utilizando alguna herramienta del tipo proxy/plug-in interceptor, se deben capturar todas
las respuestas donde una cookie sea establecida por la aplicacin y capturar ah la sesin de
administrador.

Actividades
1. Realizar la captura de la cuenta de sesin de administrador de la aplicacin Web.
2. Listar los controles de mitigacin que aplicara si tuviera a disposicin el cdigo fuente de la
aplicacin web.
3. Documentar los resultados.

Cross Site Request Forgery

Descripcin
Cross Site Request Forgery (CSRF) trata de forzar a un usuario a ejecutar acciones no deseadas en
una aplicacin web en la cual el usuario ya est autenticado. Con un poco de ayuda de ingeniera
social, por ejemplo enviando un enlace va correo electrnico o chat, un atacante puede forzar a los
usuarios de una aplicacin web a ejecutar acciones a su antojo. Un exploit CSRF que tenga xito
puede comprometer los datos de un usuario final y sus operaciones en el caso de un usuario normal.
Si el usuario objetivo del ataque es la cuenta de administrador, se puede comprometer la aplicacin
web por completo.
La forma en que se lleva a cabo un CSRF depende de los siguientes factores:
1. El comportamiento del navegador web en el manejo de la informacin relacionada con la
sesin como las cookies y la informacin de autentificacin http.
2. Conocimiento de las URLs vlidas de la aplicacin web por parte del atacante.
3. Gestin de la sesin de la aplicacin confiando slo en informacin conocida del navegador.
4. Existencia de etiquetas HTML cuya presencia provoque un acceso inmediato a un recurso
http/https; por ejemplo la etiqueta de imgenes img.
Los puntos 1, 2 y 3 son esenciales para que la vulnerabilidad est presente, mientras el punto 4 es
un complemento y facilita la explotacin actual, pero no es estrictamente necesario.
Punto 1: los navegadores envan automticamente informacin que es usada para identificar una
sesin de usuario. Supngase un sitio hospeda una aplicacin web, y que el usuario de la aplicacin
(que ser la vctima) simplemente se ha autenticado a s mismo en el sitio. En respuesta, el sitio le
enva a la vctima una cookie que identifica las peticiones enviadas pertenecientes a la sesin
autenticada de la vctima. Bsicamente, una vez que el navegador recibe la cookie establecida por
el sitio, la enviar automticamente en las sucesivas peticiones dirigidas a ese sitio web.
Punto 2: si la aplicacin no hace uso de informacin relacionada con la sesin en las URLs, entonces
significa que las URLs de la aplicacin, sus parmetros y valores legtimos podran ser identificados,
ya sea mediante anlisis del cdigo o accediendo a la aplicacin y tomando nota de los formularios
y las URLs incrustadas en el HTML/Javascript.
Punto 3: por conocida por el navegador se refiere a informacin como cookies o informacin de
autenticacin basada en http (Autenticacin Basic: autenticacin no basada en formularios), que es
almacenada por el navegador y posteriormente reenviada en cada peticin dirigida hacia el rea de
la aplicacin que solicita esa autenticacin. El ejemplo que se trata a continuacin corresponde a
una aplicacin que confa por completo en este tipo de informacin para identificar la sesin de un
usuario.
En el ejemplo se referir a una URL accesible mediante GET. Suponiendo que el usuario vctima ya
se ha autentificado, el envo de otra peticin provocar que la cookie sea enviada automticamente
con el usuario.

La peticin GET podra originarse de varias formas diferentes:

-

Por el usuario, quien est utilizando la aplicacin web.

Por el usuario, quien teclea la URL directamente en el navegador.
Por el usuario, quien sigue un enlace (externo a la aplicacin) apuntando a la URL.

La aplicacin no puede distinguir entre estas formas de efectuar la peticin GET. En particular, la
tercera podra ser bastante peligrosa. Existen muchas tcnicas, y vulnerabilidades, que pueden
disfrazar las propiedades reales de un enlace. El enlace se puede incrustar en un mensaje de correo
electrnico, o aparecer en un sitio malicioso a donde se atrae al usuario, por ejemplo, el enlace
puede aparecer en alojado en cualquier otro sitio web o correo electrnico, y apunta a un recurso
de la aplicacin. Si el usuario hace clic sobre el enlace, como ya estaba autenticado previamente en
la aplicacin web, el navegador efectuar una peticin GET a la aplicacin web, acompaada de la
informacin de autentificacin (cookie con el identificador de sesin). Esto dar como resultado la
ejecucin de una operacin vlida en la aplicacin web lo cual no ser algo que el usuario
efectivamente espera o desea que suceda. Como puede ser el robo de sus credenciales de una red
social o correo electrnico.
Utilizando una etiqueta como img, tal como se menciona en el punto 4, incluso no es necesario que
el usuario siga un enlace en particular. Suponiendo que un atacante enva a un usuario un correo
electrnico inducindolo a hacer clic en una URL que lo traslade a una pgina que contenga el HTML:

Lo que har el navegador cuando muestre esta pgina es que intentar mostrar tambin la imagen
con un ancho de valor cero. Esto tendr como resultado una peticin enviada de forma automtica
a la aplicacin web hospedada en el sitio. No es importante que la URL de la imagen no haga
referencia a una imagen real, su mera presencia disparar la peticin especfica en el campo src de
todos modos; esto sucede ya que la descarga de imgenes no est deshabilitada en los navegadores,
la configuracin tpica, ya que desactivar las imgenes mutilara la mayora de las aplicaciones web
afectando su usabilidad.

El problema aqu es una consecuencia de los siguientes factores:

-

Existen etiquetas HTML cuya aparicin en una pgina resulta en la ejecucin automtica de
una peticin http, siendo img una de ellas.
El navegador no tiene forma de decir que el recurso referenciado por img no es actualmente
una imagen y que de hecho no es legtima.
La carga de imagen sucede a pesar de su localizacin, por ejemplo, el formulario y la propia
imagen no tienen por qu estar en el mismo servidor, incluso tampoco en el mismo dominio.
Aunque esta es una caracterstica muy til, se hace muy difcil compartimentar aplicaciones.

Profundizando un poco ms, en un escenario an peor que l ejemplo anterior, podra ser en el cual
un entorno integrado correo/navegador simplemente mostrando un mensaje de correo electrnico
que contenga la imagen, podra resultar en la ejecucin de la peticin a la aplicacin web con la
cookie asociada en el navegador.
Referencia URL a una imagen aparentemente vlida:
<img src=https://[attacker]/picture.gif width=0 height=0>
Donde attacker es una pgina web controlada por el atacante y que utiliza un mecanismo de desvo:
http://[attacker]/picture.gif to http://[thirdparty]/action
Las cookies no son el nico ejemplo involucrado en este tipo de vulnerabilidad. Las aplicaciones web
cuya informacin de sesin es proporcionada enteramente por el navegador tambin son
vulnerables. Esto incluye aplicaciones que slo confan en mecanismos de autentificacin HTTP, ya
que la informacin es conocida por el navegador y se enva automticamente en cada peticin. Esto
no incluye la autenticacin basada en formularios, que ocurre slo una vez y general algn tipo de
informacin relacionada con la sesin.
Deteccin de Cross Site Request Forgery
Para hacer comprobaciones se necesita conocer las URLs correspondientes las reas restringidas
(aquellas que requieren autenticacin). Si se cuenta con credenciales vlidas, se pueden asumir los
dos papeles; el atacante y la vctima. En este caso, se conocen las URLs a comprobar simplemente
por haber navegado por la aplicacin.
De otro modo, si no se cuenta con las credenciales vlidas, se tiene que organizar un ataque real, y
por lo tanto inducir al usuario legtimo que est autenticado a que siga un determinado enlace. Esto
puede suponer un considerable esfuerzo de ingeniera social.
Prueba estndar de Cross Site Request Forgery
Supngase un escenario donde un usuario vctima est autenticado en una aplicacin web de
gestin de firewalls. Para iniciar sesin, un usuario tiene que autenticarse el mismo, posteriormente
la informacin de la sesin se almacena en una cookie.
Suponiendo que la aplicacin web de gestin de firewalls tiene una funcin que permite a un usuario
autenticado borrar una regla especificada por su nmero de posicin, o todas las reglas de la

configuracin si el usuario ingresa '*'. A continuacin se muestra la pgina para efectuar el borrado.
Suponiendo que el formulario, por simplicidad, efecta una peticin GET, que ser de la forma:
https://[target]/fwmgt/delete?rule=1 (para eliminar la regla nmero 1)
https:// [target]/fwmgt/delete?rule=* (para eliminar todas las reglas)

Por lo tanto, si se ingresa el valor '*' y se pulsa el botn Delete, se enviar la siguiente peticin GET:
http://www.company.example/fwmgt/delete?rule=*
Causando el consiguiente borrado de todas las reglas del firewall.

Sin embargo, esta no es la nica forma de tener este escenario. El usuario podra haber obtenido
los mismos resultados enviando manualmente la URL:
https://[target]/fwmgt/delete?rule=*
Otra forma es haciendo clic en un enlace que apunte directamente o mediante un desvo, a la URL
anterior. Como tambin, accediendo a una pgina HTML con la etiqueta img insertada apuntando a
la misma URL.
En todos estos casos, si el usuario est autenticado en la aplicacin de gestin de firewall, la peticin
tendr xito y modificar la configuracin del firewall. Es posible imaginar ataques a aplicaciones
sensibles, que hagan apuestas automticas, transferencias de dinero, cambios en la configuracin
de software crtico, etc. Un punto interesante a considerar es que este tipo de vulnerabilidades se
pueden explotar detrs del firewall; por ejemplo, es suficiente que el enlace atacado sea accesible
por la vctima (no directamente por el atacante). En particular, puede tratarse de un servidor web
de la intranet; por ejemplo, la mquina encargada de la gestin del firewall mencionado antes, que

no es probable que est expuesta a internet. No cuesta nada imaginar un ataque CSRF sobre una
aplicacin que est monitoreando una infraestructura crtica, como puede ser una central elctrica.
Puede sonar poco probable, pero es una posibilidad.
Contramedidas/Mitigacin
Las siguientes contramedidas se dividen en recomendaciones para usuarios y recomendaciones
para desarrolladores.
1. Usuarios: dado que las vulnerabilidades CSRF son ampliamente difundidas, se recomienda
seguir buenas prcticas para mitigar el riesgo que implican. Algunas acciones de mitigacin
son:
- Cerrar la sesin inmediatamente despus de utilizar una aplicacin web.
- No permitir al navegador almacenar usuarios/contraseas, y no permitir a las
pginas web recordar la informacin de login.
- No utilizar el mismo navegador para acceder a aplicaciones web sensibles que para
navegar libremente por Internet; si se quiere hacer las dos cosas en la misma
mquina, se recomienda hacerlo en navegadores diferentes.
Los entornos capaces de mostrar pginas HTML al usuario como correo/navegador, lector
de noticias/navegador plantean riesgos dados ya que la simple visin de un mensaje de
correo o de un grupo de noticias podra conducir a la direccin de un ataque.
2. Desarrolladores: aadir informacin relacionada con la sesin de URL. Lo que hace que el
ataque sea posible es el hecho de que la sesin est nicamente identificada por la cookie,
que es enviada de forma automtica por el navegador. Teniendo otra informacin especfica
de la sesin que est siendo generada a nivel de la URL dificulta al atacante conocer la
estructura de URLs a atacar.
Otras contramedidas, aunque no resuelven la situacin, contribuyen a hacer ms difcil su
explotacin.
Utilizar POST en vez de GET. Mientras que las peticiones POST se podran simular mediante
JavaScript, incrementan la complejidad para montar un ataque. Lo mismo ocurre con las
pginas intermedias de confirmacin (como las pginas donde se pide confirmacin al
usuario: Est usted seguro de que quiere hacer esto?). Un atacante las puede evitar,
aunque tendr que hacer su trabajo un poco ms complejo. Por lo tanto, no conviene
confiar solamente en esas medidas para proteger la aplicacin. Por otro lado, los
mecanismos automticos de cierre de sesin de algn modo mitigan la exposicin a estas
vulnerabilidades, aunque en ltima instancia depende del contexto (un usuario que trabaja
todo el da en una aplicacin de banca vulnerable est obviamente ms expuesto al riesgo
que uno que utiliza la misma aplicacin de forma ocasional).
Otra contramedida es confiar en las cabeceras Referer, y permitir slo aquellas peticiones
que parezcan provenir de URLs vlidas. Aunque las cabeceras Referer se pueden falsificar,
proporcionan una proteccin mnima por ejemplo, inhiben ataques va correo electrnico.

Actividad de laboratorio
En Mutillidae determinar el nivel de fortaleza que tienen los tokens CSRF de sesin de la aplicacin
web; nivel de aleatoriedad, largo, complejidad y nivel de entropa efectiva segn los distintos niveles
de seguridad que ofrece la aplicacin utilizando la herramienta Burp Suite.

Interceptar el trfico utilizando Burp Suite.

Luego capturar la secuencia GET con la entrada al blog.

Capturar tokens para luego analizarlos y as determinar lo solicitado para la actividad.

Actividades
1. Realizar el anlisis requerido sobre tokens CSRF de sesin: nivel de aleatoriedad, largo,
complejidad y nivel de entropa efectiva a partir de distintos niveles de seguridad.
2. Documentar e interpretar los resultados.