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 , 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=alert(/Ejemplo XSS UTALCA 2014-

2/)

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)|)/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 Set-

Cookie 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:

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.