Hola amigos, hoy les mostraré los pasos para detectar una vulnerabilidad que encontré en Web Application Security Tests en mi proyecto llamado Saka Reflected XSS (Referer) y explotar esta vulnerabilidad.

¿Qué es XSS?

Puede encontrar información detallada sobre la vulnerabilidad XSS en el siguiente artículo.

Ejecutar la aplicación

Estibador

docker pull erdemstar/saka:reflected-xss-referer
docker run -d -p 80:80 erdemstar/saka:reflected-xss-referer

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-referer
- mouse click on reflected-xss-input.sln
- devenv reflected-xss-input.sln (CMD)

Cuando abrimos la aplicación por primera vez, una página como la siguiente nos da la bienvenida. Al presionar el botón Ataque en la página, se nos dirige a la parte que probaremos.

Cuando llegamos a la página de Ataque, los campos de nombre y mensaje están disponibles. Cuando se completan estos campos y se envía la solicitud, se entiende que no hay ningún cambio en la página.

Dado que no hay cambios en el lado de la interfaz de usuario, verifiquemos la solicitud GET y POST y echemos un vistazo más de cerca.

Se ha entendido que la Solicitud GET se usa para obtener la página de Ataque directamente sin recibir ningún dato del usuario.

Aunque se piensa que POST Request se usa para enviar el nombre y la información del mensaje que tomó del usuario, cuando se revisa la parte del cuerpo, se ve que no tiene tal propósito, solo envía un campo llamado referer al back-end

La solicitud POST enviada a la aplicación se crea cuando se hace clic en el botón del formulario en el lado de la interfaz de usuario. Para echar un vistazo más de cerca, se debe examinar la respuesta con la solicitud GET.

Cuando se examina la etiqueta <form> de la respuesta obtenida con la solicitud GET, se ve que las partes del nombre y del mensaje están vacías y se ha detectado la existencia de una entrada denominada referer y el valor asignado a la misma.

Se ha entendido que la razón por la que el elemento de entrada no es visible desde la interfaz de usuario se debe a la configuración de type=hidden .

Mire la solicitud GET, se puede verificar si el "http://localhost/El valor asignado al remitente en la respuesta proviene de la solicitud de la siguiente manera.

Mirando un poco más de cerca el campo Referer en la solicitud GET, la presencia del reflejo de entrada se detecta al mirar la respuesta.

Se ha observado que no se obtiene el mismo resultado con la Solicitud POST, que es similar a la solicitud realizada en la Solicitud GET.

notas mentales

• La aplicación no utiliza la información de nombre y mensaje recibida del usuario a través del formulario.
• Cuando se envía una solicitud al punto final /Home/Attack con GET, los datos en el campo Remitente del encabezado de la solicitud relevante también se reflejan en la entrada del remitente en la respuesta.

Después de obtener suficiente información sobre la aplicación, agregamos algunos caracteres para que el navegador los interprete al valor del Referer que enviaremos para explotar la vulnerabilidad XSS.

Cuando verificamos el contenido de la respuesta entrante, se entiende que la aplicación refleja el valor del Recomendador recibido de nosotros sin ningún control de seguridad.

Después de haber obtenido tanta información sobre el comportamiento de la aplicación, cuando enviamos una solicitud como la siguiente al campo Referer , realizamos el escenario Reflected XSS en la aplicación.

Gracias por leer mi artículo, espero que te haya sido útil. A continuación te dejo los enlaces de mis otros conceptos que te pueden ser de utilidad.

Haga clic aquí para ver mis otros artículos sobre vulnerabilidades web. Enlace