Realizar un ataque de falsificación de solicitud de sitio cruzado

Realizar un ataque de falsificación de solicitud de sitio cruzado
Un ataque CSRF es el que hace que los usuarios autenticados realicen acciones no deseadas en la aplicación web con las que se autentican. Esto se hace a través de un sitio externo que el usuario visita y que desencadena estas acciones.

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.

Prepararse

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:

  1. Inicie sesión en Bodgeit como cualquier usuario y haga clic en el nombre de usuario para ir al perfil.
  2. Hacer un cambio de contraseña. Vea cómo se ve la solicitud en el poder:

    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.

  3. Intente hacer una página HTML muy simple que replique esta solicitud. Crea un archivo (nombre CSRF-Cambio-password.html) con los siguientes contenidos:







  4. Ahora, cargue este archivo en el mismo navegador que su sesión iniciada:
  5. Haga clic en Enviar y se redirigirá a la página de perfil del usuario. Le dirá que la contraseña se actualizó correctamente.
  6. Aunque esto prueba el punto, un sitio externo (o una página HTML local como en este caso) puede ejecutar una solicitud de cambio de contraseña en la aplicación. Todavía es poco probable que un usuario haga clic en el Entregar Puede automatizarlo y ocultar los campos de entrada para que el contenido malicioso esté oculto. Ahora, haga una nueva página basada en la anterior; llámalo CSRF-Cambio-password-scripted.html:


    Una página completamente inofensiva


    Puedes confiar en esta página.
    No te va a pasar nada malo a ti o a tu cuenta de Bodgeit.





    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.

  7. Si carga esta página en el mismo navegador donde se inicia una sesión BODGEIT, enviará automáticamente la solicitud y la página de perfil del usuario se mostrará después de eso. En la siguiente captura de pantalla, el navegador DepuradorEstablecer un punto de interrupción justo antes de que se hiciera la solicitud:
  8. Este último intento se ve mejor desde la perspectiva de un atacante. Solo necesita la víctima para cargar la página y la solicitud se enviará automáticamente, pero luego la víctima verá el Tu contraseña ha sido cambiadamensaje, y eso seguramente aumentará una alerta.
  9. Puede mejorar aún más la página de ataque haciendo que cargue la respuesta en un marco invisible dentro de la misma página. Hay muchas maneras de hacer esto; Una rápida y sucia es establecer un tamaño 0 para el marco. Su archivo se vería así:


    Una página completamente inofensiva


    Puedes confiar en esta página.
    No te va a pasar nada malo a ti o a tu cuenta de Bodgeit.
    Target = "Target_frame">





    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%.

  10. Cargue la nueva página en el navegador donde se inició la sesión. Esta captura de pantalla muestra cómo se ve la página cuando se inspecciona con el navegador Herramientas de desarrollo: Tenga en cuenta que el objeto iframe es solo una línea negra en la página y, en el inspector, puede ver que contiene la página de perfil del usuario de Bodgeit.
  11. Si analiza las comunicaciones de red realizadas por su página CSRF, puede ver que realmente hace solicitudes para cambiar la contraseña de Bodgeit:

Cómo funciona…

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.