Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**Cross-Site Request Forgery (CSRF)** es un tipo de vulnerabilidad de seguridad que se encuentra en aplicaciones web. Permite a los atacantes realizar acciones en nombre de usuarios desprevenidos al explotar sus sesiones autenticadas. El ataque se ejecuta cuando un usuario, que ha iniciado sesión en la plataforma de una víctima, visita un sitio malicioso. Este sitio luego desencadena solicitudes a la cuenta de la víctima a través de métodos como la ejecución de JavaScript, el envío de formularios o la obtención de imágenes.
1.**Identify a Valuable Action**: El atacante necesita encontrar una acción que valga la pena explotar, como cambiar la contraseña del usuario, el correo electrónico o elevar privilegios.
2.**Session Management**: La sesión del usuario debe ser gestionada únicamente a través de cookies o el encabezado de Autenticación Básica HTTP, ya que otros encabezados no pueden ser manipulados para este propósito.
3.**Absence of Unpredictable Parameters**: La solicitud no debe contener parámetros impredecibles, ya que pueden prevenir el ataque.
Puedes **capturar la solicitud en Burp** y verificar las protecciones CSRF y para probar desde el navegador puedes hacer clic en **Copy as fetch** y verificar la solicitud:
* [**SameSite cookies**](hacking-with-cookies/#samesite): Este atributo evita que el navegador envíe cookies junto con solicitudes de otros sitios. [Más sobre cookies SameSite](hacking-with-cookies/#samesite).
* [**Cross-origin resource sharing**](cors-bypass.md): La política CORS del sitio de la víctima puede influir en la viabilidad del ataque, especialmente si el ataque requiere leer la respuesta del sitio de la víctima. [Aprende sobre el bypass de CORS](cors-bypass.md).
* **User Verification**: Solicitar la contraseña del usuario o resolver un captcha puede confirmar la intención del usuario.
* **Checking Referrer or Origin Headers**: Validar estos encabezados puede ayudar a asegurar que las solicitudes provengan de fuentes confiables. Sin embargo, la elaboración cuidadosa de URLs puede eludir verificaciones mal implementadas, como:
* Usar `http://mal.net?orig=http://example.com` (la URL termina con la URL confiable)
* Usar `http://example.com.mal.net` (la URL comienza con la URL confiable)
* **Modifying Parameter Names**: Alterar los nombres de los parámetros en solicitudes POST o GET puede ayudar a prevenir ataques automatizados.
* **CSRF Tokens**: Incorporar un token CSRF único en cada sesión y requerir este token en solicitudes posteriores puede mitigar significativamente el riesgo de CSRF. La efectividad del token puede mejorarse al hacer cumplir CORS.
Quizás el formulario que deseas 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 todavía se está validando**.
Las aplicaciones pueden implementar un mecanismo para **validar tokens** cuando están presentes. Sin embargo, surge una vulnerabilidad si la validación se omite por completo cuando el token está ausente. Los atacantes pueden explotar esto al **eliminar el parámetro** que lleva el token, no solo su valor. Esto les permite eludir el proceso de validación y llevar a cabo un ataque de Cross-Site Request Forgery (CSRF) de manera efectiva.
Las aplicaciones **que no vinculan los tokens CSRF a las sesiones de usuario** presentan un **riesgo de seguridad** significativo. Estos sistemas verifican los tokens contra un **pool global** en lugar de asegurarse de que cada token esté vinculado a la sesión iniciadora.
Esta vulnerabilidad permite a los atacantes realizar solicitudes no autorizadas en nombre de la víctima, explotando el **mecanismo de validación de tokens inadecuado** de la aplicación.
Si la solicitud está utilizando un "**método raro**", verifica si la **funcionalidad** de **sobrescritura de método** está funcionando. Por ejemplo, si está **usando un método PUT** puedes intentar **usar un método POST** y **enviar**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Las aplicaciones pueden implementar protección CSRF duplicando el token tanto en una cookie como en un parámetro de solicitud o estableciendo una cookie CSRF y verificando si el token enviado en el backend corresponde a la cookie. La aplicación valida las solicitudes comprobando si el token en el parámetro de solicitud se alinea con el valor en la cookie.
Sin embargo, este método es vulnerable a ataques CSRF si el sitio web tiene fallas que permiten a un atacante establecer una cookie CSRF en el navegador de la víctima, como una vulnerabilidad CRLF. El atacante puede explotar esto cargando una imagen engañosa que establece la cookie, seguida de iniciar el ataque CSRF.
Nota que si el **token csrf está relacionado con la cookie de sesión, este ataque no funcionará** porque necesitarás establecer la sesión de la víctima, y por lo tanto estarás atacándote a ti mismo.
De acuerdo a [**esto**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar solicitudes preflight** usando el método **POST**, estos son los valores de Content-Type permitidos:
Sin embargo, ten en cuenta que la **lógica del servidor puede variar** dependiendo del **Content-Type** utilizado, así que deberías probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Al intentar enviar datos JSON a través de una solicitud POST, no es posible utilizar directamente `Content-Type: application/json` en un formulario HTML. De manera similar, utilizar `XMLHttpRequest` para enviar este tipo de contenido inicia una solicitud de preflight. No obstante, existen estrategias para potencialmente eludir esta limitación y verificar si el servidor procesa los datos JSON independientemente del Content-Type:
1.**Usar tipos de contenido alternativos**: Emplear `Content-Type: text/plain` o `Content-Type: application/x-www-form-urlencoded` configurando `enctype="text/plain"` en el formulario. Este enfoque prueba si el backend utiliza los datos independientemente del Content-Type.
2.**Modificar el tipo de contenido**: Para evitar una solicitud de preflight mientras se asegura que el servidor reconozca el contenido como JSON, puede enviar los datos con `Content-Type: text/plain; application/json`. Esto no activa una solicitud de preflight, pero podría ser procesado correctamente por el servidor si está configurado para aceptar `application/json`.
3.**Utilización de archivos SWF Flash**: Un método menos común pero factible implica usar un archivo SWF flash para eludir tales restricciones. Para una comprensión más profunda de esta técnica, consulte [esta publicación](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Las aplicaciones pueden validar el encabezado 'Referer' solo cuando está presente. Para evitar que un navegador envíe este encabezado, se puede utilizar la siguiente etiqueta meta HTML:
La primera parte de [**este CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que [el código fuente de Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un enrutador, está configurado para **manejar solicitudes HEAD como solicitudes GET** sin cuerpo de respuesta, un método común que no es exclusivo de Oak. En lugar de un controlador específico que maneje las solicitudes HEAD, simplemente **se les da al controlador GET, pero la aplicación solo elimina el cuerpo de la respuesta**.
Si se está utilizando un **token CSRF** como **defensa**, podrías intentar **exfiltrarlo** abusando de una vulnerabilidad de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o de una vulnerabilidad de [**Markup Colgante**](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 a un formulario de inicio de sesión utilizando un token CSRF (también está utilizando el encabezado 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 bugs!
Aprende y practica Hacking en AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprende y practica Hacking en GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.