* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**Sigue a HackenProof**](https://bit.ly/3xrrDrL) **para aprender más sobre errores web3**
🐞 Lee tutoriales de errores web3
🔔 Recibe notificaciones sobre nuevos programas de recompensas por errores
💬 Participa en discusiones comunitarias
## ¿Qué es CSRF?
**Cross-site request forger**y (también conocido como CSRF) es una vulnerabilidad de seguridad web que permite a un atacante **inducir a los usuarios a realizar acciones que no tienen la intención de realizar**.\
Esto se hace **haciendo que un usuario conectado** en la plataforma víctima acceda a un sitio web controlado por el atacante y desde allí **ejecute** código JS malicioso, envíe formularios o recupere "imágenes" en la **cuenta de la víctima**.
### Requisitos
Para poder abusar de una vulnerabilidad CSRF, primero debes **encontrar una acción relevante para abusar** (cambiar la contraseña o el correo electrónico, hacer que la víctima te siga en una red social, darte más privilegios...). La **sesión debe depender solo de cookies o del encabezado de autenticación básica HTTP**, no se puede usar ningún otro encabezado para manejar la sesión. Y finalmente, no debe haber **parámetros impredecibles** en la solicitud.
Varias **contramedidas** podrían estar en su lugar para evitar esta vulnerabilidad.
### **Defensas comunes**
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Si la cookie de sesión está utilizando esta bandera, es posible que no pueda enviar la cookie desde sitios web arbitrarios.
* [**Compartición de recursos de origen cruzado**](cors-bypass.md): Dependiendo del tipo de solicitud HTTP que necesite realizar para abusar de la acción relevante, puede tener en cuenta la **política CORS del sitio víctima**. _Tenga en cuenta que la política CORS no afectará si solo desea enviar una solicitud GET o una solicitud POST desde un formulario y no necesita leer la respuesta._
* Leer los encabezados **Referer** u **Origen**. Si se usa una expresión regular, se puede pasar por alto, por ejemplo, con:
* http://mal.net?orig=http://example.com (termina con la URL)
* http://example.com.mal.net (comienza con la URL)
* **Modificar** el **nombre** de los **parámetros** de la solicitud POST o GET
* Usar un **token CSRF** en cada sesión. Este token debe enviarse dentro de la solicitud para confirmar la acción. Este token podría estar protegido con CORS.
Tal vez el formulario que desea abusar está preparado para enviar una **solicitud POST con un token CSRF pero**, debe **verificar** si un **GET** también es **válido** y si cuando envía una solicitud GET el **token CSRF todavía se está validando**.
Algunas aplicaciones **validan correctamente el token cuando está presente pero omiten la validación si se omite el token**.\
En esta situación, el atacante puede **eliminar todo el parámetro** que contiene el token (no solo su valor) para evitar la validación y realizar un ataque CSRF.
### El token CSRF no está vinculado a la sesión del usuario
Algunas aplicaciones **no validan que el token pertenezca a la misma sesión** que el usuario que realiza la solicitud. En su lugar, la aplicación **mantiene una piscina global de tokens** que ha emitido y acepta cualquier token que aparezca en esta piscina.\
En esta situación, el atacante puede iniciar sesión en la aplicación utilizando su propia cuenta, **obtener un token válido** y luego **proporcionar ese token al usuario víctima** en su ataque CSRF.
### Bypass de método
Si la solicitud está utilizando un **método "extraño"**, verifique si la **funcionalidad de anulación de método** está funcionando.\
Por ejemplo, si está **usando un método PUT**, puede intentar **usar un método POST** y **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Esto también podría funcionar enviando el **parámetro \_method dentro de una solicitud POST** o usando los **encabezados**:
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Bypass de token de encabezado personalizado
Si la solicitud está agregando un **encabezado personalizado** con un **token** a la solicitud como **método de protección CSRF**, entonces:
* Pruebe la solicitud sin el **Token personalizado y también sin el encabezado**.
* Pruebe la solicitud con una **longitud exactamente igual pero con un token diferente**.
### El token CSRF se verifica mediante una cookie
En una variación posterior de la vulnerabilidad anterior, algunas aplicaciones **duplican cada token dentro de una cookie y un parámetro de solicitud**. O **establecen una cookie csrf** y **verifican en el backend si el token csrf enviado es el relacionado con la cookie**.
Cuando se valida la solicitud posterior, la aplicación simplemente verifica que el **token** enviado en el **parámetro de solicitud coincide** con el valor almacenado por la **cookie**.\
En esta situación, el atacante puede nuevamente realizar un ataque CSRF **si el sitio web contiene alguna vulnerabilidad que le permita establecer su cookie CSRF en la víctima como un CRLF**.
En este caso, puede establecer la cookie intentando cargar una imagen falsa y luego lanzar el ataque CSRF como en este ejemplo:
```html
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
Ten en cuenta que si el token csrf está relacionado con la cookie de sesión, este ataque no funcionará porque necesitarás establecer tu sesión como víctima, y por lo tanto estarás atacándote a ti mismo.
Según [**esto**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar las solicitudes previas** utilizando el método **POST**, estos son los valores permitidos para Content-Type:
Sin embargo, ten en cuenta que la **lógica del servidor puede variar** dependiendo del **Content-Type** utilizado, por lo que debes probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Como ya sabes, no puedes enviar una solicitud POST con el tipo de contenido **`application/json`** a través de un formulario HTML, y si intentas hacerlo a través de **`XMLHttpRequest`** se envía primero una solicitud **previa**.\
Sin embargo, podrías intentar enviar los datos JSON utilizando los tipos de contenido **`text/plain` y `application/x-www-form-urlencoded`** solo para comprobar si el backend está utilizando los datos independientemente del tipo de contenido.\
Puedes enviar un formulario utilizando `Content-Type: text/plain` estableciendo **`enctype="text/plain"`**
Si el servidor solo acepta el tipo de contenido "application/json", puedes **enviar el tipo de contenido "text/plain; application/json"** sin activar una solicitud previa.
También podrías intentar **burlar** esta restricción utilizando un archivo **SWF flash**. Para obtener más información, [**lee este post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
[**Sigue a HackenProof**](https://bit.ly/3xrrDrL) **para aprender más sobre errores web3**
🐞 Lee tutoriales sobre errores web3
🔔 Recibe notificaciones sobre nuevos programas de recompensas por errores
💬 Participa en discusiones comunitarias
## **Ejemplos de explotación**
### **Exfiltración de token CSRF**
Si se está utilizando un **token CSRF** como **defensa**, se podría intentar **exfiltrarlo** abusando de una vulnerabilidad [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o una vulnerabilidad de [**markup colgante**](dangling-markup-html-scriptless-injection.md).
La técnica de CSRF también puede ser explotada mediante una petición POST de Ajax. En este caso, el atacante puede crear una página web maliciosa que realice una petición POST de Ajax a una página vulnerable en el sitio web de la víctima. La petición POST de Ajax puede ser enviada automáticamente cuando la página maliciosa se carga en el navegador de la víctima, sin que ésta se dé cuenta.
Para prevenir este tipo de ataques, se puede utilizar un token CSRF en la petición POST de Ajax, de la misma manera que se utiliza en una petición POST normal.
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on");
</script>
<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value¶m2=value2"
})
</script>
```
### solicitud POST multipart/form-data
```javascript
myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
Para llevar a cabo un ataque CSRF, el atacante necesita conocer el token CSRF válido. Si el token CSRF se almacena en una cookie, el atacante puede robarlo utilizando una vulnerabilidad de XSS. Si el token CSRF se almacena en una etiqueta HTML, el atacante puede robarlo utilizando una vulnerabilidad de inyección de código HTML. Una vez que el atacante tiene el token CSRF, puede enviar una solicitud POST al servidor utilizando el token robado.
Para llevar a cabo un ataque CSRF, el atacante necesita conocer el token CSRF válido. Si el token CSRF se almacena en una cookie, el atacante puede robarlo usando un script malicioso. Si el token CSRF se almacena en una etiqueta HTML, el atacante puede robarlo usando un iframe y un formulario.
El atacante puede crear un iframe que apunte a la página de destino y un formulario que envíe una solicitud POST a la página de destino. El formulario debe incluir los parámetros necesarios para realizar la acción deseada en la página de destino, incluido el token CSRF robado.
Cuando el usuario visita la página maliciosa, el iframe se carga automáticamente y envía la solicitud POST a la página de destino, realizando la acción deseada en nombre del usuario sin su conocimiento.
El código se puede utilizar para realizar un ataque de fuerza bruta en un formulario de inicio de sesión utilizando un token CSRF (también utiliza el encabezado X-Forwarded-For para intentar evitar una posible lista negra de direcciones IP):
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).