La wiki de TempWin

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== Cross-Site Request Forgery (CSRF) ======

Notas del curso [[informatica:seguridad:cursos:hacking_etico_descubriendo_vulnerabilidades_en_aplicaciones_web|Hacking ético: descubriendo vulnerabilidades en aplicaciones web]]

La vulnerabilidad de CSRF, conocida como falsificación de petición en sitios cruzados, consiste en engañar a un usuario legítimo (que esté identificado en la aplicación) para que ejecute peticiones/acciones sin su consentimiento (no sabe que esas peticiones se están realizando desde su usuario).

{{ :informatica:seguridad:cursos:hacking_etico_descubriendo_vulnerabilidades_en_aplicaciones_web:csrf.png |}}
==== Impacto ====

  * Acciones fraudulentas.
  * Acciones involuntarias de usuarios.

==== Formas de explotación ====

  * Ingeniería social
  * Phishing

==== Explotación ====

  * Detectar token Anti-CSRF
  * Realizar prueba de concepto sobre funcionalidad susceptible
  * Burp Professional: GenerateCSRF PoC
  * Escáneres automáticos

En la edición profesional de Burp, hay una opción de crear una prueba de concepto de CSRF:

{{ :informatica:seguridad:cursos:hacking_etico_descubriendo_vulnerabilidades_en_aplicaciones_web:csrf-burp-professional.png |}}

HTML creado:

{{ :informatica:seguridad:cursos:hacking_etico_descubriendo_vulnerabilidades_en_aplicaciones_web:csrf-poc-burp-professional.png |}}

http://bank.com/transfer.do?acct=evilUser&amount=100000

Para probarlo en DWVA, con Burp activado como proyx, nos dirigimos a la sección **CSRF**. Con el nivel de seguridad a //Low//, la petición se hace con ''GET''. Creremos un fichero HTML con un formulario similar al de la aplicación vulnerable:

<code html>
<form action="http://192.168.8.109/vulnerabilities/csrf/?" method="GET">
  <input type="hidden" AUTOCOMPLETE="off" name="password_new" value="hacked"><br />
  <input type="hidden" AUTOCOMPLETE="off" name="password_conf" value="hacked"><br />
  <br />
  <input type="submit" value="iPhone 20 gratis" name="Change">
</form>
</code>

Si eso lo enviamos a un usuario que tenga la sesión iniciada, no verá un formulario si no un botón con el texto //iPhone 20 gratis// que al pulsar estará enviando un nuevo valor para modificar la contraseña.

Si establecemos el nivel //High//, al querer usar nuestra prueba de concepto CSRF, no nos funcionará porque espera un token CSRF que además va cambiando en cada petición al cambiar la contraseña, así que esa información solo la conoce el servidor.

Si aumentamos al nivel //Impossible//, el formulario ya nos pide la contraseña actual.
==== Buenas prácticas ====

  * Implementación de tokens anti-CSRF
  * Cookies de sesión: ''SameSite''. Tiene 3 posibles valores: ''Strict'', ''None'' y ''Lax''
  * Protecciones ante XSS
  * No usar peticiones GET para el envío de información a la aplicación
  * Revisar cabeceras: ''Origin Header'' y ''Referer Header''

Link: https://owasp.org/www-community/attacks/csrf