<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) en github.
Únete al servidor de [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para comunicarte con hackers experimentados y cazadores de recompensas por errores.
**Cross-site request forgery** (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 logra **haciendo que un usuario con sesión iniciada** 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" para la **cuenta de la víctima**.
Para poder abusar de una vulnerabilidad CSRF primero necesitas **encontrar una acción relevante para abusar** (cambiar contraseña o correo electrónico, hacer que la víctima te siga en una red social, darte más privilegios...). La **sesión debe depender únicamente de cookies o del encabezado de Autenticación Básica HTTP**, cualquier otro encabezado no puede ser utilizado para manejar la sesión. Finalmente, **no debería haber parámetros impredecibles** en la solicitud.
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Si la cookie de sesión está utilizando esta bandera, es posible que no puedas enviar la cookie desde sitios web arbitrarios.
* [**Compartición de recursos de origen cruzado**](cors-bypass.md): Dependiendo de qué tipo de solicitud HTTP necesites realizar para abusar de la acción relevante, puedes tener en cuenta la **política CORS del sitio víctima**. _Nota que la política CORS no afectará si solo quieres enviar una solicitud GET o una solicitud POST desde un formulario y no necesitas leer la respuesta._
* Pedir la **contraseña** del usuario para autorizar la acción.
* Resolver un **captcha**
* Leer los encabezados **Referrer** o **Origin**. Si se usa una regex podría ser evitada 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 tiene que ser enviado dentro de la solicitud para confirmar la acción. Este token podría estar protegido con CORS.
Quizás el formulario que quieres abusar está preparado para enviar una **solicitud POST con un token CSRF pero**, deberías **verificar** si un **GET** también es **válido** y si cuando envías una solicitud GET el **token CSRF sigue siendo validado**.
Algunas aplicaciones **validan correctamente el token cuando está presente pero omiten la validación si el token se omite**.\
En esta situación, el atacante puede **eliminar todo el parámetro** que contiene el token (no solo su valor) para evadir la validación y llevar a cabo un ataque CSRF.
Algunas aplicaciones **no validan que el token pertenezca a la misma sesión** que el usuario que está realizando la solicitud. En cambio, la aplicación **mantiene un grupo global de tokens** que ha emitido y acepta cualquier token que aparezca en este grupo.\
En esta situación, el atacante puede iniciar sesión en la aplicación usando su propia cuenta, **obtener un token válido**, y luego **proporcionar ese token al usuario víctima** en su ataque CSRF.
Si la solicitud está utilizando un **método "extraño"**, verifica si la **funcionalidad de sobreescritura de método** está funcionando.\
Por ejemplo, si está **utilizando un método PUT** puedes intentar **usar un método POST** y **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
En una variación adicional 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 subsiguiente, la aplicación simplemente verifica que el **token** enviado en el **parámetro de solicitud coincida** 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**.
Tenga en cuenta que si el **token csrf está relacionado con la cookie de sesión, este ataque no funcionará** porque necesitará establecer en la víctima su sesión, y por lo tanto, se estará atacando a sí mismo.
Según [**esto**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar solicitudes de preflight** utilizando el método **POST**, estos son los valores de Content-Type permitidos:
Sin embargo, tenga en cuenta que la **lógica de los servidores puede variar** dependiendo del **Content-Type** utilizado, por lo que debería probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Como ya sabes, no puedes enviar una solicitud POST con el Content-Type **`application/json`** a través de un formulario HTML, y si intentas hacerlo a través de **`XMLHttpRequest`**, primero se envía una solicitud de **preflight**.\
Sin embargo, podrías intentar enviar los datos JSON utilizando los tipos de contenido \*\*`text/plain` y `application/x-www-form-urlencoded` \*\* solo para verificar si el backend está utilizando los datos independientemente del Content-Type.\
Puedes enviar un formulario utilizando `Content-Type: text/plain` configurando **`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 de preflight.
También podrías intentar **bypass** esta restricción utilizando un **archivo SWF flash**. Para más información [**lee este post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
La primera parte de [**este writeup de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que en el [código fuente de Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un enrutador está configurado para **manejar las solicitudes HEAD como solicitudes GET** sin cuerpo de respuesta - una solución común que no es única de Oak. En lugar de un manejador específico que se ocupe de las solicitudes HEAD, simplemente se **entregan al manejador GET pero la aplicación elimina el cuerpo de la respuesta**.
Si se está utilizando un **token CSRF** como **defensa**, podrías intentar **exfiltrarlo** abusando de una vulnerabilidad [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o una vulnerabilidad de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
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)
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 la cabecera X-Forwarded-For para intentar eludir un posible bloqueo de IP):
¡Únete al servidor de [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para comunicarte con hackers experimentados y cazadores de recompensas por errores!
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos.
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).