• Author / Uploaded
• Francisco Flores

• Categories
• Cookie HTTP
• Servidor web
• Localizador Uniforme de Recursos
• Protocolo de Transferencia de Hipertexto
• Red mundial

Citation preview

ACTIVIDADES DE LABORATORIO OWASP TOP 10

Antecedentes Para la realización de las actividades del laboratorio OWASP Top 10 se utilizarán distintas herramientas que permitirán simular páginas web con distintos tipos de vulnerabilidades que pueden ser explotadas con fines de aprendizaje.

Listado de herramientas Para identificar las vulnerabilidades que podrían ser explotadas por las amenazas listadas en el OWASP Top 10, se utilizará la herramienta OWASP ZAP (Zed Attack Proxy) la cual permite realizar análisis de sitios web en búsqueda de vulnerabilidades, con diversos fines, entre los cuales está el aprendizaje o securización misma del sitio. Para los primeras dos amenazas a la seguridad de una aplicación web (SQLi y XSS) se hará uso de la Aplicación de demostración de Seguridad de Software la cual es utilizada en el módulo Seguridad de Software (CC5315) en la Universidad de Chile. Posteriormente, continuando con el análisis, detección y mitigación de amenazas se continuará con el OWASP Broken Web Applications Project, la cual es una colección de aplicaciones web vulnerables que son distribuidas dentro de una máquina virtual en formato VMware para ser utilizada en el VMware Player.

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

A continuación se han de crear ciertas variables de entorno, las cuales son necesarias para la utilización 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 sería bueno verificar la instalación 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 instalación mediante la consola ejecutando mvn -version

El mensaje de respuesta debe ser similar al presentado.

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

Finalmente para activar el servidor, sólo se debe escribir en la consola: mvn jetty:run El servidor se activará automáticamente y dejará la aplicación en http://localhost:8080 3. OWASP Broken Web Applications Project Es una colección de aplicaciones web vulnerables que son distribuidas dentro de una máquina virtual en el formato VMware. Esta colección 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. - Páginas para Demostración / Pequeñas Aplicaciones: OWASP CSRFGuard, Mandiant Strus Forms. - Aplicaciones OWASP para Demostración: Owasp AppSensor Demo Aplication. La máquina virtual puede ser descargada en su última versión 1.1.1 desde la página oficial (http://sourceforge.net/projects/owaspbwa/files/). Es un archivo de tamaño de 1.3 Gb que viene comprimido. Una vez descomprimido se debe abrir con la aplicación VMware Player.

Al iniciar la máquina virtual se presentará información relacionada al acceso y credenciales, a tener en consideración 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 máquina mediante un navegador en la dirección http://192.168.136.130

Desde ahí se pueden utilizar las distintas páginas web que serán auditadas durante el desarrollo de este laboratorio.

OWASP TOP 10 SQL Injection Descripción Un ataque de inyección SQL consiste en la inserción o “inyección” de datos en una consulta SQL desde un cliente de la aplicación. En el caso de tener éxito en inyección SQL podría por ejemplo, leer datos sensibles de la base de datos, modificar los datos, realizar operaciones de administración sobre la misma base de datos tal como reiniciar el DBMS, entre otros. Los ataques de inyección SQL son un tipo de ataque de inyección, en los cuales comandos SQL son inyectados en texto para afectar la correcta realización de una consulta SQL predefinida. Los tipos de ataques de inyección SQL se dividen en tres clases: -

-

Inband: los datos son extraídos usando el mismo canal que es usado para inyectar el código SQL. Este es el tipo de ataque más simple, en el que los datos recibidos se muestran en la propia aplicación web. Out-of-band: los datos son extraídos usando un canal diferente, como puede ser un correo electrónico 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 información enviando peticiones y observando el comportamiento que mantiene el servidor de bases de datos.

Independiente del tipo de ataque, una inyección SQL correcta requiere que el atacante pueda construir una consulta SQL correcta. Si la aplicación devuelve un mensaje de error a causa de una consulta incorrecta, entonces en fácil reconstruir de forma lógica la consulta original y, por lo tanto, entender cómo realizar una inyección correctamente. Sin embargo, si la aplicación oculta los mensajes de error, un auditor puede conseguir por medio de ingeniería inversa la lógica de la consulta original. Este último caso se conoce como inyección SQL ciega (Blind SQL Injeccion). Detección de inyección SQL Como primer paso para esta prueba es entender cuando una aplicación web se conecta a un servidor de bases de datos para acceder a algún dato. Los ejemplos típicos de casos en los que una aplicación necesita comunicarse con una base de datos incluyen: -

-

Formularios de autentificación: cuando la autentificación 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 contraseñas (hash de contraseñas). Motores de búsqueda: 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 electrónico: los productos y sus características (precio, descripción, disponibilidad) son siempre almacenados en una base de datos relacional.

Prueba estándar de inyección SQL Considerando la siguiente consulta: SELECT * FROM Users WHERE Username='$username$' AND Password='$password$' Un consulta similar a las que son usadas por una aplicación 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 sesión en el sistema, en caso contrario el acceso es denegado. Los valores de los campos de entrada son generalmente obtenidos del usuario a través 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 parámetros son enviados al servidor mediante el método GET, y si el dominio de la aplicación web vulnerable es www.example.com, la petición sería: http://www.example.com/index.php?username=1'%20or%20’1'%20=%20'1&password=1'%20or% 20'1'%20=%20'1 La consulta devolverá un valor dado que la condición siempre es verdadera (OR 1=1). Por lo tanto, este caso el sistema autenticaría 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 práctica de laboratorio En un navegador donde se esté viendo la aplicación web (http://localhost:8080)

Se debe ingresar a la sección de Login para así intentar determinar la existencia de alguna vulnerabilidad que pueda ser explotada mediante inyección SQL.

Una opción es probar lo mencionado en al comienzo de la sección de inyección SQL con la prueba estándar. De otro modo, se puede utilizar OWASP ZAP como herramienta automática para la detección de vulnerabilidades. Uso de la herramienta OWASP ZAP En primer lugar se debe indicar cuál será la dirección a la cual dirigir las acciones de análisis de vulnerabilidades. Dado que se está utilizando la aplicación web alojada en la dirección localhost:8080 se agrega tal dirección y se continua con el botón Atacar dado el inicio a la revisión de vulnerabilidades

Luego del escaneo de la página objetivo se encontraron vulnerabilidades críticas asociadas a inyección SQL y secuencia de comandos en sitios cruzados o XSS. En esta etapa sólo se habrá de considerar la amenaza de inyección SQL.

La herramienta indica que efectivamente la brecha puede ser explotada utilizando la prueba estándar de inyección SQL.

Por lo tanto lo que dado que ya se ha identificado que vulnerabidad es explotable efectivamente por un ataque de inyección SQL corresponde ahora aplicar medidas de mitigación. Contramedida/Mitigación La contramedida o mitigación para situaciones como estas según OWASP corresponde a que en primer lugar todas las consultas deben ser parametrizadas. Luego, todos los datos dinámicos deben

estar vinculados explícitamente a consultas parametrizadas. Por último, que la concatenación de strings nunca debe ser usado para crear SQL dinámico. Específicamente 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 código SQL y luego pasar en cada parámetro a la consulta siguiente. Lo importante es que este estilo de codificación permite a la base de datos distinguir entre código y datos, independientemente de lo que la entrada del usuario entrega. Considerando el siguiente ejemplo:

En este código 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 contraseña en blanco, generando una sentencia de consulta SQL de esta forma: SELECT * FROM user WHERE username='admin' OR '1'='1' AND password=' ' Permitiendo iniciar sesión sin proporcionar contraseña dado que la expresión OR siempre es cierta. La forma de evitarlo usando sentencias preparadas es la siguiente:

En esta actividad se requiere buscar la consulta en el código fuente de la aplicación web y corregir la consulta utilizando sentencias preparadas para así evitar un ataque de inyección SQL.

Actividades 1. Realizar un ataque de SQL inyección en el portal de la aplicación web objetivo. 2. Aplicar corrección de mitigación en el código fuente de la aplicación web. 3. Documentar los resultados.

Cross Site Scripting XSS (Reflejado) Descripción Los ataques de tipo XSS reflejado son también conocidos como de tipo 1 o no persistentes, y son los ataques más frecuentes de XSS en la actualidad. Cuando una aplicación web es vulnerable a este tipo de ataque, entregará datos de entrada no validados al cliente. El modo más común de operación de este ataque incluye un paso de diseño, en el cual el atacante crea y comprueba la URI culpable, un paso de ingeniería social, en el cual convence a sus víctimas de cargar esta URI en sus navegadores, y a la eventual ejecución del código malicioso – utilizando las credenciales de la víctima. Comúnmente el código del atacante es escrito en Javascript, pero en otros lenguajes de scripting pueden ser también utilizados ActionScripting y VBScript. Los atacantes típicamente utilizarán estas vulnerabilidades para instalar keyloggers, robar credenciales de usuarios, obtener datos del portapapeles y cambiar el contenido de la página, como por ejemplo, enlaces de descargas. Uno de los aspectos más importantes sobre las vulnerabilidades XSS es la codificación de caracteres. En algunos casos, el servidor web o aplicación web no pueden filtrar la codificación de algunos caracteres, por lo tanto, la aplicación web puede filtrar “”, pero no es capaz de filtrar %3escript%3 el cual simplemente incluye otra codificación de los tags. Detección de Cross Site Scripting Para la detección de un XSS son necesarios al menos, los siguientes tres pasos: 1. Detectar vectores de entrada. El auditor debe determinar las variables de la aplicación web y como ingresarlas en la aplicación web. 2. Analizar cada vector de entrada para detectar posibles vulnerabilidades. Para detectar una vulnerabilidad XSS, el auditor utiliza datos especialmente diseñados para cada vector de entrada. Tal entrada es típicamente no dañina, pero puede provocar respuestas desde el navegador web que manifiestan la vulnerabilidad. Los datos de prueba pueden ser generados utilizando un fuzzer de aplicación 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 aplicación web.

Prueba estándar de Cross Site Scripting Reflejado Por ejemplo, considérese un sitio que contenga un mensaje personalizado como el tratamiento de una persona, ya sea señor o señora.

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

Esto indica que existe una vulnerabilidad XSS y pareciera ser que se puede ejecutar código a gusto en el navegador de cualquiera si el usuario hace clic en el enlace auditado. Contramedida/Mitigación Actualmente la mayoría de las aplicaciones web utiliza sanitización 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 sanitización, o con firewall de aplicaciones web, o del lado del cliente utilizando mecanismos de prevención que se integran a los navegadores web como complementos. Debido a que la mayoría 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 podrán evitar el ataque. Una aplicación web o el servidor web, por ejemplo, el módulo de Apache mod_rewrite, puede convertir la URL que coincida con una expresión regular como un procedimiento de sanitización. Por ejemplo la siguiente expresión regular puede ser usada para detectar y bloquear caracteres alfanuméricos dentro de tags o barras inclinadas. /((\%3C)|)/i Como resultado el ataque realizado arriba a la página web de la Clínica Santa María no funcionaría. En esta actividad se requiere buscar en el código fuente de la página 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 aplicación web objetivo (Fans de las aves chilenas). 2. Aplicar corrección de mitigación en el código fuente de la aplicación web. 3. Documentar los resultados.

Insecure Direct Object References Descripción Una referencia directa a objetos ocurre cuando un programador expone una referencia hacia un objeto interno de la aplicación, tales como un fichero, directorio, registro de base de datos, o una clave tal como una URL o un parámetro de formulario Web. Un atacante podría manipular este tipo de referencias en la aplicación para acceder a otros objetos sin autorización, a menos que se aplique un control de accesos como medida de prevención. Por ejemplo, en las aplicaciones bancarías en línea, es común que se utilice el número de cuenta como clave primaria. Por consiguiente, se podría tener la tentación de usar esta clave directamente como parámetro en la interfaz Web. Aún en el caso de que el equipo de desarrollo hubiera utilizado consultas SQL preparadas (parameterized SQL queries) para evitar una inyección SQL, podría ser posible que un atacante modificara este parámetro para ver o cambiar todas las demás cuentas, si no se verifica también que el usuario es el titular de la cuenta bancaria o está autorizado para acceder a la misma. Detección de Insecure Direct Object References Para comprobar si una aplicación 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 aplicación necesitaría 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 análisis del código de la aplicación sirve para verificar rápidamente si dichas propuestas se implementan con seguridad. También es efectivo realizar comprobaciones para identificar referencias a objetos directos y si estos son seguros. Normalmente las herramientas automáticas no detectan este tipo de vulnerabilidades porque no son capaces de reconocer cuáles necesitan protección o cuáles son seguros o inseguros. Prueba estándar de Insecure Direct Objetct References Muchas aplicaciones presentan a los usuarios referencias a objetos internos. Un atacante podría manipular los parámetros de entrada a la aplicación cambiando estas referencias, saltándose 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 aplicación podría ser vulnerable por un problema de esta categoría. Por ejemplo, en el caso de que el código utilizara la entrada del usuario para construir nombres de fichero o rutas de acceso a los mismos, podría ser posible que un atacante saliera del directorio donde está la aplicación, y accediera a otros recursos. Consultar una transacción A en una aplicación Web

http://webapplication.com/viewtrans?idt=205683 Consultar una transacción X y poder ver la información asociada sólo cambiando el ID de transacción http://webapplication.com/viewtrans?idt=205684 Decidir si la transacción X es un problema de seguridad o no es difícil de comprobar por medio de análisis dinámicos de vulnerabilidades. Actividad de laboratorio En Mutillidae se debe entrar en la sección 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 parámetros POST, realizar modificación de la cabecera de la página donde se puede ver el código fuente de add-to-your-blog.php a ver el código fuente del php del generador de password, password-generator.php.

El resultado de la actividad es el siguiente.

Actividad 1. Realizar modificación de la cabecera HTTP en el parámetro POST para saltar al código PHP de password-generator.php 2. Listar los controles de mitigación que aplicaría si tuviera a disposición el código fuente de la aplicación web. 3. Documentar los resultados.

Broken Authentication and Sesion Management Descripción La vulnerabilidades relacionada con la pérdida de autenticación y gestión de sesiones son críticas en la seguridad de las aplicaciones y en especial de las aplicaciones Web, ya que permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información 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 aplicación vulnerable a este tipo de ataque, la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Específicamente para este laboratorio se centrará en lo que son las pruebas de seguridad de atributos de cookies. Pruebas de atributos de cookies Las cookies comúnmente son un vector de ataque para los usuarios maliciosos (típicamente teniendo como objetivo otros usuarios) y, como tal, la aplicación siempre debe tomar las medidas para proteger las cookies. En este laboratorio, se verá como en una aplicación 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 sesión para la autorización/autenticación o como un contenedor de datos temporal. Así, si un atacante fuera capaz de obtener un identificador de sesión (por ejemplo, al explotar una vulnerabilidad de cross site scripting o al usar un sniffer en una sesión no cifrada), entonces podría usar esta cookie para obtener una sesión valida. Adicionalmente, las cookies son establecidas para mantener un estado a lo largo de peticiones múltiples. Ya que HTTP no tiene estado, el servidor no puede determinar si una petición que recibe es parte de una sesión actual o es el inicio de una nueva sesión sin algún tipo de identificador. Este identificador es muy comúnmente una cookie aunque otros métodos también son posibles. Como podría imaginarse, hay muchos tipos diferentes de aplicaciones que necesitan mantener el registro del estado de la sesión a través de peticiones múltiples. La principal que se viene a la mente es una tienda en línea. Por ejemplo, mientras un usuario agrega artículos a un carro de compra, esta información necesita ser retenida en peticiones subsecuentes a la aplicación. Las cookies son muy comúnmente usadas para esta tarea y son establecidas por la aplicación usando la directiva SetCookie en la respuesta HTTP de la aplicación, y usualmente es en un formato nombre=valor (si las cookies están habilitadas y si son soportadas, el cual es el caso de todos los navegadores modernos). Una vez que la aplicación le ha dicho al navegador usar una cookie en particular, el navegador enviará esta cookie en cada petición subsecuente. Una cookie puede contener información como artículos de un carro de compra, los precios de estos artículos, la cantidad de estos artículos, información personal, nombres de usuario, etc. Debido a la naturaleza sensitiva de la información

en cookies, típicamente son codificadas o cifradas en un intento de proteger la información que contienen. Ahora que se entiende cómo 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 envíe la cookie si la petición 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 vía 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 adición al dominio, la ruta de URL puede ser especificada para la cual la cookie es válida. Si el dominio y la ruta coinciden, entonces la cookie será enviada en la petición. 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 sesión del navegador y sesiones subsecuentes hasta que la cookie expire. Una vez que la fecha de expiración haya sida superada, el navegador borrará la cookie. Alternativamente, si este atributo no es establecido, entonces la cookie es solo válida en la sesión actual del navegador y será eliminada cuando la sesión termine.

Control/Mitigación 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 aplicación (usando la directiva Set-cookie) e inspeccione la cookie en busca de: 







Atributo secure - Siempre que una cookie contenga información sensitiva o que sea un identificador de sesión, entonces debe siempre ser enviada usando un canal cifrado. Por ejemplo, después de ingresar a una aplicación y un identificador de sesión 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 aplicación reside en el servidor app.mysite.com, entonces debe ser establecido a "; domain=app.mysite.com" y NO ";domain=.mysite.com" ya que esto permitiría 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 rígido



como sea posible, si la ruta es establecida al directorio raíz "/" entonces puede ser vulnerable a aplicaciones menos seguras en el mismo servidor. Por ejemplo si la aplicación 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 después 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 información 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 sesión 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 aplicación al reenviar este identificador hasta que la fecha de expiración haya pasado.

Actividad de laboratorio En Mutillidae se deberá capturar la sesión de administrador mediante modificación de las cookies de sesión utilizando alguna herramienta del tipo proxy/plug-in interceptor, se deben capturar todas las respuestas donde una cookie sea establecida por la aplicación y capturar ahí la sesión de administrador.

Actividades 1. Realizar la captura de la cuenta de sesión de administrador de la aplicación Web. 2. Listar los controles de mitigación que aplicaría si tuviera a disposición el código fuente de la aplicación web. 3. Documentar los resultados.

Cross Site Request Forgery Descripción Cross Site Request Forgery (CSRF) trata de forzar a un usuario a ejecutar acciones no deseadas en una aplicación web en la cual el usuario ya está autenticado. Con un poco de ayuda de ingeniería social, por ejemplo enviando un enlace vía correo electrónico o chat, un atacante puede forzar a los usuarios de una aplicación 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 aplicación 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 información relacionada con la sesión como las cookies y la información de autentificación http. 2. Conocimiento de las URLs válidas de la aplicación web por parte del atacante. 3. Gestión de la sesión de la aplicación confiando sólo en información conocida del navegador. 4. Existencia de etiquetas HTML cuya presencia provoque un acceso inmediato a un recurso http/https; por ejemplo la etiqueta de imágenes 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 explotación actual, pero no es estrictamente necesario. Punto 1: los navegadores envían automáticamente información que es usada para identificar una sesión de usuario. Supóngase un sitio hospeda una aplicación web, y que el usuario de la aplicación (que será la víctima) simplemente se ha autenticado a sí mismo en el sitio. En respuesta, el sitio le envía a la víctima una cookie que identifica las peticiones enviadas pertenecientes a la sesión autenticada de la víctima. Básicamente, una vez que el navegador recibe la cookie establecida por el sitio, la enviará automáticamente en las sucesivas peticiones dirigidas a ese sitio web. Punto 2: si la aplicación no hace uso de información relacionada con la sesión en las URLs, entonces significa que las URLs de la aplicación, sus parámetros y valores legítimos podrían ser identificados, ya sea mediante análisis del código o accediendo a la aplicación y tomando nota de los formularios y las URLs incrustadas en el HTML/Javascript. Punto 3: por “conocida por el navegador” se refiere a información como cookies o información de autenticación basada en http (Autenticación Basic: autenticación no basada en formularios), que es almacenada por el navegador y posteriormente reenviada en cada petición dirigida hacia el área de la aplicación que solicita esa autenticación. El ejemplo que se trata a continuación corresponde a una aplicación que confía por completo en este tipo de información para identificar la sesión de un usuario. En el ejemplo se referirá a una URL accesible mediante GET. Suponiendo que el usuario víctima ya se ha autentificado, el envío de otra petición provocará que la cookie sea enviada automáticamente con el usuario.

La petición GET podría originarse de varias formas diferentes: -

Por el usuario, quien está utilizando la aplicación web. Por el usuario, quien teclea la URL directamente en el navegador. Por el usuario, quien sigue un enlace (externo a la aplicación) apuntando a la URL.

La aplicación no puede distinguir entre estas formas de efectuar la petición GET. En particular, la tercera podría ser bastante peligrosa. Existen muchas técnicas, y vulnerabilidades, que pueden disfrazar las propiedades reales de un enlace. El enlace se puede incrustar en un mensaje de correo electrónico, 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 electrónico, y apunta a un recurso de la aplicación. Si el usuario hace clic sobre el enlace, como ya estaba autenticado previamente en la aplicación web, el navegador efectuará una petición GET a la aplicación web, acompañada de la información de autentificación (cookie con el identificador de sesión). Esto dará como resultado la ejecución de una operación válida en la aplicación 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 electrónico. 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 envía a un usuario un correo electrónico induciéndolo a hacer clic en una URL que lo traslade a una página que contenga el HTML:

Lo que hará el navegador cuando muestre esta página es que intentará mostrar también la imagen con un ancho de valor cero. Esto tendrá como resultado una petición enviada de forma automática a la aplicación 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 petición específica en el campo src de todos modos; esto sucede ya que la descarga de imágenes no está deshabilitada en los navegadores, la configuración típica, ya que desactivar las imágenes mutilaría la mayoría de las aplicaciones web afectando su usabilidad.

El problema aquí es una consecuencia de los siguientes factores: -

Existen etiquetas HTML cuya aparición en una página resulta en la ejecución automática de una petición 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 legítima. La carga de imagen sucede a pesar de su localización, 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 característica muy útil, se hace muy difícil compartimentar aplicaciones.

Profundizando un poco más, en un escenario aún peor que él ejemplo anterior, podría ser en el cual un entorno integrado correo/navegador simplemente mostrando un mensaje de correo electrónico que contenga la imagen, podría resultar en la ejecución de la petición a la aplicación web con la cookie asociada en el navegador. Referencia URL a una imagen aparentemente válida:

Donde attacker es una página web controlada por el atacante y que utiliza un mecanismo de desvío: 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 información de sesión es proporcionada enteramente por el navegador también son vulnerables. Esto incluye aplicaciones que sólo confían en mecanismos de autentificación HTTP, ya que la información es conocida por el navegador y se envía automáticamente en cada petición. Esto no incluye la autenticación basada en formularios, que ocurre sólo una vez y general algún tipo de información relacionada con la sesión. Detección de Cross Site Request Forgery Para hacer comprobaciones se necesita conocer las URLs correspondientes las áreas restringidas (aquellas que requieren autenticación). Si se cuenta con credenciales válidas, se pueden asumir los dos papeles; el atacante y la víctima. En este caso, se conocen las URLs a comprobar simplemente por haber navegado por la aplicación. De otro modo, si no se cuenta con las credenciales válidas, se tiene que organizar un ataque real, y por lo tanto inducir al usuario legítimo que esté autenticado a que siga un determinado enlace. Esto puede suponer un considerable esfuerzo de ingeniería social. Prueba estándar de Cross Site Request Forgery Supóngase un escenario donde un usuario víctima está autenticado en una aplicación web de gestión de firewalls. Para iniciar sesión, un usuario tiene que autenticarse el mismo, posteriormente la información de la sesión se almacena en una cookie. Suponiendo que la aplicación web de gestión de firewalls tiene una función que permite a un usuario autenticado borrar una regla especificada por su número de posición, o todas las reglas de la

configuración si el usuario ingresa '*'. A continuación se muestra la página para efectuar el borrado. Suponiendo que el formulario, por simplicidad, efectúa una petición GET, que será de la forma: https://[target]/fwmgt/delete?rule=1 (para eliminar la regla número 1) https:// [target]/fwmgt/delete?rule=* (para eliminar todas las reglas)

Por lo tanto, si se ingresa el valor '*' y se pulsa el botón Delete, se enviará la siguiente petición 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 podría 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 desvío, a la URL anterior. Como también, accediendo a una página HTML con la etiqueta img insertada apuntando a la misma URL. En todos estos casos, si el usuario está autenticado en la aplicación de gestión de firewall, la petición tendrá éxito y modificará la configuración del firewall. Es posible imaginar ataques a aplicaciones sensibles, que hagan apuestas automáticas, transferencias de dinero, cambios en la configuración de software crítico, etc. Un punto interesante a considerar es que este tipo de vulnerabilidades se pueden explotar detrás del firewall; por ejemplo, es suficiente que el enlace atacado sea accesible por la víctima (no directamente por el atacante). En particular, puede tratarse de un servidor web de la intranet; por ejemplo, la máquina encargada de la gestión del firewall mencionado antes, que

no es probable que esté expuesta a internet. No cuesta nada imaginar un ataque CSRF sobre una aplicación que esté monitoreando una infraestructura crítica, como puede ser una central eléctrica. Puede sonar poco probable, pero es una posibilidad. Contramedidas/Mitigación 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 prácticas para mitigar el riesgo que implican. Algunas acciones de mitigación son: - Cerrar la sesión inmediatamente después de utilizar una aplicación web. - No permitir al navegador almacenar usuarios/contraseñas, y no permitir a las páginas web recordar la información 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 máquina, se recomienda hacerlo en navegadores diferentes. Los entornos capaces de mostrar páginas HTML al usuario como correo/navegador, lector de noticias/navegador plantean riesgos dados ya que la simple visión de un mensaje de correo o de un grupo de noticias podría conducir a la dirección de un ataque. 2. Desarrolladores: añadir información relacionada con la sesión de URL. Lo que hace que el ataque sea posible es el hecho de que la sesión esté únicamente identificada por la cookie, que es enviada de forma automática por el navegador. Teniendo otra información específica de la sesión 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 situación, contribuyen a hacer más difícil su explotación. Utilizar POST en vez de GET. Mientras que las peticiones POST se podrían simular mediante JavaScript, incrementan la complejidad para montar un ataque. Lo mismo ocurre con las páginas intermedias de confirmación (como las páginas donde se pide confirmación al usuario: “¿Está usted seguro de que quiere hacer esto?”). Un atacante las puede evitar, aunque tendrá que hacer su trabajo un poco más complejo. Por lo tanto, no conviene confiar solamente en esas medidas para proteger la aplicación. Por otro lado, los mecanismos automáticos de cierre de sesión de algún modo mitigan la exposición a estas vulnerabilidades, aunque en última instancia depende del contexto (un usuario que trabaja todo el día en una aplicación de banca vulnerable está obviamente más expuesto al riesgo que uno que utiliza la misma aplicación de forma ocasional). Otra contramedida es confiar en las cabeceras Referer, y permitir sólo aquellas peticiones que parezcan provenir de URLs válidas. Aunque las cabeceras Referer se pueden falsificar, proporcionan una protección mínima – por ejemplo, inhiben ataques vía correo electrónico.

Actividad de laboratorio En Mutillidae determinar el nivel de fortaleza que tienen los tokens CSRF de sesión de la aplicación web; nivel de aleatoriedad, largo, complejidad y nivel de entropía efectiva según los distintos niveles de seguridad que ofrece la aplicación utilizando la herramienta Burp Suite.

Interceptar el tráfico 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 análisis requerido sobre tokens CSRF de sesión: nivel de aleatoriedad, largo, complejidad y nivel de entropía efectiva a partir de distintos niveles de seguridad. 2. Documentar e interpretar los resultados.