Actividades

Trabajo: Test de penetración a la aplicación BADSTORE

utilizando un Scanner de vulnerabilidades de aplicaciones web
Introducción

Nos vamos a adentrar a conocer el funcionamiento de la herramienta ZAP, esta aplicación nos
sirve para analizar algún sitio y verificar si se tiene vulnerabilidades dentro de este.

ZAP es una herramienta que lo que hace es atacar un dirección, que es proporcionada por el
usuario y así realizar el ataque y encontrar vulnerabilidades que pueda llegar a tener el
sitio web.

Se guiara a como se realizó un ataque a BADSTORE, en donde se tratará de encontrar

vulnerabilidades y así realizar una auditoría de las mismas, esto para conocer un poco
de lo que puede llegar a hacer ZAP.

Desarrollo

Primeramente, instalaremos virtualbox.

Despues configuramos nuestra maquina virtual que previamente descargamos de la dirección

que se nos fue proporcionada, aquí vamos a decirle a virtualbox que la inicie desde el
CDROM.

Despues se configura la parte de redes, en donde se seleccionara el Adaptador solo-anfitrión.

Seguido de esto vamos a configurar lo que es este adaptador y nos vamor a la parte de
herramientas globales donde se creara una nueva propiedad y se habilitara un servidor
DHCP con las direcciones que fueron propuestas en el documento que se nos facilito.
Despues de que configuramos el servidor se iniciara la BADSTORE, cuando comience lo que
haremos sera poner “ifconfig” para conocer la ip y verificar que concuerde con la ip que
nosotros configuramos anteriormente.

Se verifica que, si es igual la ip, entonces se instala ZAP, que es descargado al igual que
BADSTORE de una dirección que nos fue proporcionada. Después estamos en la
interfaz de ZAP colocaremos “http://192.168.56.110/cgi-bin/badstore.cgi” que es la
dirección de la BADSTORE. Se dará click en Attack y arrojará las vulnerabilidades que
presenta.

Ahora se van a auditar tres de la seis alertas que se han descubierto en zap.

Application Error Disclosire

Conociendo la vulnerabilidad

Esta vulnerabilidad se produce cuando una aplicación no protege de forma adecuada la

información que es confidencial de las partes en las que se supone que se tiene acceso a
esta información en las circunstancias normales. Este tipo de vulnerabilidad no llegan a
ser muy explotables en la mayoria de los casos, pero se pueden llegar a considerar
problemas de seguridad de aplicaciones web, esto permite que los atacantes puedan
recopilar información que puedes ser utilizable más adelante en el ciclo de vida del
ataque, esto para lograr más de lo que se podrian obtener si no se tuviera acceso a dicha
información.

Como se evidencia

La forma en que se pude evidenciar, una de las formas es el acaparamiento de banners o el

reconocimiento activo, esto funciona cuando el atacante envía solicitudes al sistema
que intentan atacar, esto para recopilar más información, si el sistema no llega a estar
 bien configurado se puede perder la información sobre el mismo sistema, ya sea que
versión de servidor es, PHP/ASP.net o la versión Open SSH, etc..

Posible solución

Para asegurarnos de que la aplicación web que estamos desarrollando o se trata de proteger de
este tipo de vulnerabilidad se pueden realizar diferentes pautas para tener bien
protegida la aplicación web, las cuales mencionaremos a continuación:

● Verificar que el servidor no envie encabezados de respuesta que puedan llegar a

revelar información sobre el tipo o versión de la tecnología back-end.
● Asegurar que los puertos que estan abiertos en el servidor no muestren
información sobre sus versiones y compilaciones.
● Tener acceso y autorizaciones que sean adecuados para no permitir el acceso a
atacantes dispuestos a descubrir información de nuestros servidores, los
servicios y aplicaciones web.
● No codificar credenciales como las claves API, direcciones ip ni ningun otra
informacion que sea confidencial. Ni siquiera en forma de comentarios.
● En el código del back.end se debe emplear las validaciones que sean necesarias
para la detección de las excepciones y así lograr evitar las filtraciones de
información.
● Que el servidor este configurado para suprimir cualquier excepción que se
presente y devolver una error de página genérica. (Netsparker)

Cookie No HttpOnly Flag

Conociendo la vulnerabilidad

El atributo HttpOnly se establece en alguna cookie, el valor de la cookie no se llega a leer o

establecer mediante el JavaScript del lado del cliente. Esto hace que muchos de los
ataques del lado del cliente, por ejemplo las secuencias de comandos entre sitios,
lleguen a ser un poco mas complicados de explotar, al impedirles las capturas triviales
del valor de la cookie, todo esto mediante un script insertado.
Posible solución

No hay razones para no establecer el indicador HttpOnly en todas las cookies. Hay momentos
en donde si se requieren scripts legítimos del lado del cliente dentro de la aplicación
para su lectura o para establecer el valor de una cookie, se debe establecer el indicador
HTTPOnly, incluyendo el atributo dentro de la directiva Set-cookie relevante.

Se debe de tener en cuenta las restricciones que se van a imponer por el indicador HttpOnly, se
pueden eludir potencialmente en algunas circunstancias, y se pueden enviar númerosos
ataques graves mediante la inyeccion de scripts del lado del cliente, ademas del robo de
cookies.

El nivel de riesgo de esta vulnerabilidad es bajo, pero aunque sea bajo, hay que tenerla en
cuenta, ya que un ataque de este tipo puede tener mucho alcance. (PortSwigger, 2018)

X-Content-Type-Options Header Missing

Conociendo la vulnerabilidad

Es un encabezado HTTP que es utilizado para realizar justamente eso= el aumentar la

seguridad del sitio web. Ademas se utiliza para proteger contra las vulnerabilidades de
rastreo de MIME. Este tipo de vulnerabilidades ocurre cuando un sitio web permite que
se suba contenido al sitio, sin embargo, el puede llegar a ocultar un tipo de archivo
particular como otra cosa. Esto les puede llegar a ayudar a realizar scripts entre sitios y
así poner en peligro el nuestro.

Este encabezado de seguridad permite prevenir este tipo de ataques al deshabilitar la función
de detección de MIME de los navegadores de Internet Explorer y Chrome por lo que
estos navegadores deben de utilizar el tipo de MIME enviado a través del servidor
origen.

Este encabezado no protege contra todas la vulnerabilidades relacionadas con sniffing. Ya que
se menciono anteriormente, chrome solo llega a respetar este encabezado y ciertas
versiones de IE. Debido a esto si un navegador que no es admitido el acceso a un activo
 que devuelve el encabezado de respuesta particular, por lo tanto no se llega a tener
ningún efecto. (Keycdn, 2016)

Posible Solución

Existen diferentes nomenclaturas para solucionar o evitar este tipo de ataques, cuando se envía
en X-Content-Type-Options en la respuesta se agrega el valor “nosniff”, los navegadores
que llegan a soportar este encabezado, no cargan las hoas de estilos, ni los scripts, cuyo
MYME-type no sea adecuado. La nomenclatura adecuada para es:
X-Content-Type-Options:nosniff. (Noguera, 2015)
Bibliografía
Keycdn. (19 de Agosto de 2016). ​Keycdn.​ Obtenido de
https://www.keycdn.com/support/x-content-type-options/
Netsparker. (s.f.). ​Netsparker.​ Obtenido de
https://www.netsparker.com/blog/web-security/information-disclosure-issues-
attacks/
Noguera, D. (25 de Agosto de 2015). ​WPDoctor​. Obtenido de
https://www.wpdoctor.es/cabecera-x-content-type-options/
PortSwigger. (2018). ​PortSwigger Web Security​. Obtenido de
https://portswigger.net/kb/issues/00500600_cookie-without-httponly-flag-set