¿Es este un verdadero ataque CSRF?

Question

¿Es este un verdadero ataque CSRF?

#1 de Wadih M. (3 votos)
#2 de shawkyz1 (0 votos)

0

He estado arreglando una aplicación de formularios web de asp.net que tiene una serie de vulnerabilidades que fueron descubiertas por una empresa de pruebas de lápiz externa.

Recientemente he implementado una cookie de envío doble con la biblioteca asp.net AntiForgery. También configurando ViewStateUserKey para usar el sessionId.

Los evaluadores de lápiz proporcionaron una secuencia de comandos CSRF de POC dentro de una página html. Intenta subir un archivo al sitio web. Cuando trato de usarlo, no tiene éxito y los errores de estado de vista no válidos se registran en el servidor web.

Descubrí que los evaluadores de lápiz están usando un inicio de sesión válido para crear el script POC, pero luego usan el mismo inicio de sesión que la víctima objetivo.

¿El script POC no debe crearse a partir de otro inicio de sesión válido? ¿No es eso hacer trampa usando el mismo inicio de sesión para crear el script de ataque y la víctima?

csrf asp.net

pregunta ParleParle 15.12.2017 - 01:24

fuente

2 respuestas

Lea otras preguntas en las etiquetas csrf asp.net

¿Cuándo necesita una empresa contratar a un especialista en seguridad dedicado? [cerrado] Antivirus vs Firewall con Antivirus

score 3 · Answer 1

Sí, es un verdadero ataque CSRF.

Tenga en cuenta que un ataque CSRF está diseñado para ocurrir con un enlace externo forjado enviado a alguien que ya ha iniciado sesión, para que realice una acción en su sesión que no pretendían hacer.

Un ejemplo clásico sería su sitio web bancario, usted ingresaría y alguien le enviaría un correo electrónico externo con un enlace falsificado.

Entonces, recibe ese enlace forjado en su correo electrónico, hace clic en el enlace, abre una nueva pestaña en su navegador, asumiendo que ya ha iniciado sesión, y el comando en la URL se ejecuta directamente en la sesión actual de su banco .

Por ejemplo, la forma de transferir fondos a través de una consulta GET podría ser algo como: https://mybankingwebsite.com/transfer/500/to/attacker-bank-account

Entonces, cualquiera que esté usando su banco y que haya iniciado sesión y haga clic en ese enlace, enviará 500 $ al attacker-bank-account . Pero no fue usted quien quiso hacer ese comando, el enlace provino de otra parte, pero se ejecuta en el contexto de su cuenta bancaria iniciada. Eso es un CSRF.

Facebook también solía ser vulnerable a los ataques CSRF, y a muchos otros sitios. Por ejemplo, un enlace forjado en Facebook podría resultar en que publiques algo en tu muro que nunca pretendiste.

score 0 · Answer 2

Según OWASP ViewStateUsKeyKey es una forma aceptable de evitar el CSRF debido a su unicidad. en el contexto del usuario y la sesión. Además, usar los mismos credenciales de inicio de sesión que los del script PoC no tiene mucho sentido en ese caso. Sugeriría hablar directamente con el auditor y preguntarle cuál fue su intención con este guión.

Además, al depender solo del mecanismo de ViewState no impedirá el CSRF en su aplicación. ¿Qué sucede si está enviando directamente solicitudes AJAX a su back-end? En este caso, es posible que necesite implementar un encabezado personalizado con un token CSRF y verificar y validar este token en el servidor.