Actividades WebGoat y Web Securify Informe De Resultados

EL PRESENTE TRABAJO es un reporte de estudio y análisis del trabajo

realizados con las aplicaciones Web Securify y con la aplicación WebGoat

cada una de ellas nos ayuda en propósitos concretos a mejorar nuestros

conocimientos de las vulnerabilidades de los sitios |web y encontrar la

solución de ellos mejorando así la seguridad de nuestras aplicaciones web.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 1

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 2

Informé de actividades con las aplicaciones Web Securify y WebGoat

INTRODUCCIÓN

EL PRESENTE TRABAJO es un reporte de estudio y análisis del trabajo realizados con

las aplicaciones Web Securify y con la aplicación WebGoat cada una de ellas nos ayuda

en propósitos concretos a mejorar nuestros conocimientos de las vulnerabilidades de los

sitios web y encontrar la solución de ellos mejorando así la seguridad de nuestras

aplicaciones web.

Parte 1 Web Securify

Bueno de forma inicial comenzaremos con la aplicación Web Securify. Descripción: En

esta parte realizaremos un escaneo de las posibles vulnerabilidades de 3 sitios web daremos

una breve explicación sobre el tipo de sitio que es, las vulnerabilidades encontradas y la

forma recomendada de solución.

Parte 2 WebGoat

Que es WebGoat, es una aplicación web J2EE deliberadamente insegura, mantenida

|por OWASP y diseñada para enseñar lecciones de seguridad en aplicaciones Web. La

seguridad en aplicaciones web es difícil de aprender y practicar. No mucha gente tiene

aplicaciones Web completas como tiendas electrónicas de libros o bancos en línea que

pueden ser usados para buscar vulnerabilidades. Por lo que La meta principal del proyecto

|WebGoat es simple: Crear un ambiente interactivo de enseñanza para seguridad en

aplicaciones web. En el futuro, el equipo del proyecto espera extender WebGoat para

convertirse en una plataforma para "benchmarking" de seguridad y un "Honeypot" para

sitios web basado en Java. Para esta lección resolveremos 3 laboratorios y explicaremos

como lo realizamos.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 3

Parte 1

Primer Análisis

El primer sito que revisaremos es http://www.animextremist.com/

2

El resultado inicial del escaneo de vulnerabilidades es que

http://www.animextremist.com/ tiene el problema potencial de Cross-site Scripting

(XSS) es un tipo de vulnerabilidad de la seguridad de aplicaciones web que

permite la inyección de código por usuarios de la web malicioso en las páginas

web visitadas por otros usuarios. Una vulnerabilidad XSS explotados pueden ser

utilizados por atacantes para eludir los controles de acceso, robar datos, las

tramas de los paquetes de phishing (Phishing es un término informático que

denomina un tipo de delito encuadrado dentro del ámbito de

las estafas cibernéticas, y que se comete mediante el uso de un tipo de ingeniería

social caracterizado por intentar adquirir información confidencial de forma

fraudulenta (como puede ser una contraseña o información detallada

sobre tarjetas de crédito u otra información bancaria)), y lanzar ataques dirigidos

mediante el navegador que estemos utilizando.

Solución: Desinfecte todos los datos proporcionados por el usuario antes de usarla

como parte de las páginas generadas dinámicamente y datos antes de ser

procesados analizarlos de alguna forma o filtro seguro.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 4

La segunda vulnerabilidad encontrada es más como una recomendación puesto

que hace mención a que la opción Autocompletar siempre debe estar

deshabilitada (autocomplete = "off"), especialmente en las formas que procesan

datos sensibles, tales como formularios con campos de contraseña, ya que un

atacante, si es capaz de acceder a la caché del navegador, puede fácilmente

obtener la información almacenada en caché en texto sin formato.

Solución: Desactivar la función de autocompletar (autocomplete = "off") en los

formularios que pueden contener datos sensibles.

En este análisis comprendí cual importancia tiene los detalles que para un usuario

común se nos hacen tan simples como son el auto complete y la inscripción a una

página de comunidad social en línea

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 5

SEGUNDO ANÁLISIS http://www.enladisco.com

El segundo análisis con Web Securify fue a la página http://www.enladisco.com

Encontramos la vulnerabilidad HTTP Banner Disclosure la cual consiste en que la

aplicación revela su tipo y versión. Esta información puede ser utilizada por

atacantes para hacer una conjetura sobre el entorno de aplicación y cualquier

debilidad hereditaria que puede venir con él.

Solución: Se recomienda para evitar la aplicación de la revelación de su tipo y

versión.

URL: http://www.enladisco.com/

banner: Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5

mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.9

url: http://www.enladisco.com/

banner: X-Powered-By: PHP/5.2.9

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 6

La segunda vulnerabilidad encontrada es mas como una recomendación puesto

que hace mención a que la opción Autocompletar siempre debe estar

deshabilitada (autocomplete = "off"), especialmente en las formas que procesan

datos sensibles, tales como formularios con campos de contraseña, ya que un

atacante, si es capaz de acceder a la caché del navegador, puede fácilmente

obtener la información almacenada en caché en texto sin formato.

solución: Desactivar la función de autocompletar (autocomplete = "off") en los

formularios que pueden contener datos sensibles.

url: http://www.enladisco.com/

form:

<form action="./acceso.php" method=post> ...

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 7

Tercer análisis

La tercera página analizada fue http://www.friv.com

El análisis de vulnerabilidades a la página www.FRIV.COM dio como como

resultado lo siguiente

La primer vulnerabilidad fue TRACE Method Enabled lo cual significa que El

método TRACE que se utiliza para depurar conexiones de servidor web y permite

al cliente ver lo que está siendo recibida en el otro extremo de la cadena de

solicitud se encuentra Habilitado de forma predeterminada en algunos servidores

web, por lo que un atacante remoto puede abusar de la funcionalidad de HTTP

TRACE, es decir, Cross-site Scripting (XSS). Por lo general, esta función no puede

ser trivialmente explotados en un escenario real pero aun así sigue siendo de

peligro.

solución: Deshabilitar el método TRACE.

url: http://www.friv.com/

methods: GET,HEAD,POST,OPTIONS,TRACE

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 8

La segunda vulnerabilidad encontrada fue HTTP Banner Disclosure esta

consiste en que La aplicación revela su tipo y versión. Esta información puede ser

utilizada por atacantes para hacer una conjetura sobre el entorno de aplicación y

cualquier debilidad hereditaria que puede venir con él.

Solución: Se recomienda para evitar la aplicación de la revelación de su tipo y la

versión

url: http://www.friv.com/

banner: Server: Apache/2.2.11 (Ubuntu) mod_ssl/2.2.11 OpenSSL/0.9.8g

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 9

Parte 2

Primer Laboratorio Comenzaremos con la lección de Los fallos de la autentificación en la primera fase del laboratorio

debemos calcular la seguridad y el tiempo que tardaría un sniffer en encontrar nuestra contraseña

para ello nos ayudaremos en una página web gratuita llamada

https://www.cnlab.ch/codecheck/check.php . De forma inicial comenzabas abriendo el laboratorio

de fallos en autentificación Fig.1

Fig. 1

Posterior mente introducimos la contraseña en la página de test

https://www.cnlab.ch/codecheck/check.php y esperamos el resultado como lo vemos en la Fig.2 ,

la Fig. 3, Fig. 4.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 10

Posterior-mente repetimos esta tarea con todas las contraseñas.

Éstos son los resultados que obtienemos:

Contraseña = 123456: 0 segundos Contraseña = abzfez: 1394 segundos Contraseña = a9z1ez: 5 horas Contraseña = aB8fEz: 2 días Contraseña = Z8! E? 7: 41 días

Y asi completamos de manera sastifactoria esta leccion. Fig. 5

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 11

Segundo laboratorio

Esta lección llamada descubriendo pistas en el código html, algunas veces los programadores

cometen errores que dejan al descubierto información importante en el código como pueden ser

los id de usuarios y los password como lo vamos a examinar en la presente lección. Fig. 1

Para encontrar las credenciales veremos el código fuente de la página Fig. 2

Posterior mente colocamos las credenciales que encontramos en el código fuente y tratamos de

ingresar en la aplicación como se puede ver en la imagen 3

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 12

Una vez realizado esto la página no dará acceso a su aplicación cumpliendo así con el objetivo de

la práctica como resultado de la misma podemos comentar que logramos entender que tan grave

es mandar o guardar las claves de una aplicación web en su código fuente y que tan fácil es

cometer un ataque desde ahí si no tenemos el cuidado necesario.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 13

Laboratorio 3 En esta práctica vamos a tener que realizarla en dos fases en la primer fase vamos a utilizar una

herramienta extra es un sniffer llamado Wire Shark el cual nos ayudara a capturar los paquetes

donde encontraremos las claves que van en las tramas enviadas.

La imagen de nuestro sniffer es la siguiente.

Seleccionamos LA opción de captura de paquetes y seleccionamos la interfaz que estemos

utilizando es importante seleccionar la correcta ya que cualquier error en la selección de la

interfaz tendrá como consecuencia que no podamos realizar la practica

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 14

Posterior mente esperaremos un lapso aproximado de dos minutos en la capturacion de

paquetes como se muestra en la imagen siguiente.

Una vez realizado esto buscaremos los paquetes que son de nuestro interés que los de

POST-HTML y leeremos lo que nos arroja como se ve en la siguiente imagen.

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 15

Esto nos arroja el usuario y la contraseña que buscábamos solo resta introducirlas en la

aplicación de laboratorio y ábrenos concluido exitosamente la tarea en su primera fase.

Para la segunda fase vamos a cabiar la configuración de los paquetes que se envían para

resolver estas preguntas para ello nos basaremos en el protocolo llamado Transport Layer

Security (TLS) y respondemos las dos preguntas de la siguiente forma

E L A B O R O : I N G . G O N Z A L E Z L I M O N J O S E L U I S

I N G . R O D R Í G U E Z N A B O R M a . A R A C E L I .

Página 16

Así finalizaremos de manera exitosa la lección como lo vemos en la siguiente imagen.