En este artículo, obtendrá la información requerida de la aplicación para saber qué debe hacer el sitio de ataque para enviar solicitudes válidas al servidor vulnerable. Luego, creará una página que simula las solicitudes legítimas y engaña al usuario para que visite esa página mientras esté autenticada. También hará algunas iteraciones sobre la prueba básica de concepto para que se parezca más a un ataque del mundo real, donde la víctima no lo nota. Tenga en cuenta que el archivo de código para este artículo se puede encontrar en el GitHub del autor.
Necesitará una cuenta de usuario válida en Bodgeit para este artículo. Este artículo usa [email protected]
Como la víctima:
Cómo hacerlo…
Primero, debe analizar la solicitud que desea obligar a la víctima a hacer. Para hacer esto, necesita BURP Suite u otro proxy configurado en el navegador:
Entonces, es un CORREO
solicitud de http: // 192.168.56.11/Bodgeit/contraseña.JSP,
y solo tiene la contraseña y su confirmación en el cuerpo.
CSRF-Cambio-password.html
) con los siguientes contenidos: CSRF-Cambio-password-scripted.html
: Esta vez, el formulario tiene un parámetro de identificación y hay un script en la página que enviará su contenido cuando la página se cargue por completo.
Observe cómo la propiedad objetivo del formulario es el iframe definido justo debajo de ella y que dicho marco tiene altura y ancho del 0%.
Cuando envía una solicitud desde un navegador y ya tiene una cookie que pertenece al dominio de destino almacenado, el navegador adjuntará la cookie a la solicitud antes de que se envíe. Esto es lo que hace que las cookies sean tan convenientes como los identificadores de sesión, pero esta característica de cómo funciona HTTP también es lo que lo hace vulnerable a un ataque como el que viste en este artículo.
Cuando carga una página en el mismo navegador, donde tiene una sesión activa en una aplicación, el navegador adjuntará automáticamente la cookie de sesión a esa solicitud. Esto sucede incluso si se trata de una pestaña o ventana diferente, y esta página realiza una solicitud al dominio donde se inicia la sesión.
Si el servidor no verifica que las solicitudes que recibe realmente se originaron desde la aplicación, permite que un sitio malicioso haga llamadas en nombre de usuarios legítimos y activos que visitan este sitio malicioso mientras están autenticados al dominio de destino.
En una prueba de penetración de la aplicación web, el primer código que usó, el que tiene los dos campos de texto y el Entregar botón, puede ser suficiente para demostrar la presencia de un defecto de seguridad. Sin embargo, las pruebas de penetración de la aplicación pueden ser parte de otro compromiso, como una ingeniería social o ejercicio de equipo rojo. En este caso, se requerirá un esfuerzo adicional para evitar que el usuario de la víctima sospeche que algo está sucediendo.
En este artículo, utilizó JavaScript para automatizar el envío de la solicitud configurando el evento de Onload en la página y ejecutando el método de envío del formulario en la función del controlador de eventos. También usó un iframe oculto para cargar la respuesta del cambio de contraseña, por lo que la víctima nunca ve el mensaje de que su contraseña ha cambiado.
Si le pareció interesante este artículo, puede explorar Libro de cocina de pruebas de penetración web de Kali Linux - Segunda edición para descubrir las vulnerabilidades web más comunes y evitar que se conviertan en una amenaza para la seguridad de su sitio. Libro de cocina de pruebas de penetración web de Kali Linux - Segunda edición Le brinda las habilidades que necesita para cubrir cada etapa de una prueba de penetración, desde la recopilación de información sobre el sistema y la aplicación hasta la identificación de vulnerabilidades a través de pruebas manuales.