# CSRF (Cross Site Request Forgery)
Aprende a hackear AWS desde cero hasta convertirte en un experto conhtARTE (HackTricks AWS Red Team Expert)!
Otras formas de apoyar a HackTricks:
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén [**artículos oficiales de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **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).
Únete al servidor de [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para comunicarte con hackers experimentados y cazadores de recompensas por errores.
**Información sobre Hacking**\
Involúcrate con contenido que explora la emoción y los desafíos del hacking
**Noticias de Hacking en Tiempo Real**\
Mantente al día con el mundo del hacking a través de noticias e información en tiempo real
**Últimos Anuncios**\
Mantente informado sobre los nuevos programas de recompensas por errores y actualizaciones importantes de plataformas
**Únete a nosotros en** [**Discord**](https://discord.com/invite/N3FrSbmwdy) y comienza a colaborar con los mejores hackers hoy mismo!
## Explicación de Cross-Site Request Forgery (CSRF)
**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 explotando sus sesiones autenticadas. El ataque se ejecuta cuando un usuario, que está conectado a la plataforma de la 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.
### Requisitos previos para un Ataque CSRF
Para explotar una vulnerabilidad CSRF, se deben cumplir varias condiciones:
1. **Identificar una Acción Valiosa**: 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. **Gestión de Sesiones**: 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 se pueden manipular con este propósito.
3. **Ausencia de Parámetros Impredecibles**: La solicitud no debe contener parámetros impredecibles, ya que pueden evitar el ataque.
### Verificación Rápida
Podrías **capturar la solicitud en Burp** y verificar las protecciones CSRF y para probar desde el navegador puedes hacer clic en **Copiar como fetch** y verificar la solicitud:
### Defensa Contra CSRF
Se pueden implementar varias contramedidas para protegerse contra los ataques CSRF:
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Este atributo evita que el navegador envíe cookies junto con solicitudes entre sitios. [Más sobre las Cookies SameSite](hacking-with-cookies/#samesite).
* [**Compartición de Recursos entre Orígenes**](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 cómo evadir CORS](cors-bypass.md).
* **Verificación de Usuario**: Solicitar la contraseña del usuario o resolver un captcha puede confirmar la intención del usuario.
* **Comprobación de Encabezados Referrer u Origin**: Validar estos encabezados puede ayudar a garantizar que las solicitudes provengan de fuentes confiables. Sin embargo, la elaboración cuidadosa de URLs puede eludir controles implementados de manera deficiente, como:
* Usar `http://mal.net?orig=http://example.com` (URL termina con la URL de confianza)
* Usar `http://example.com.mal.net` (URL comienza con la URL de confianza)
* **Modificar Nombres de Parámetros**: Alterar los nombres de los parámetros en solicitudes POST o GET puede ayudar a prevenir ataques automatizados.
* **Tokens CSRF**: 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 aplicando CORS.
Comprender e implementar estas defensas es crucial para mantener la seguridad y la integridad de las aplicaciones web.
## Bypass de Defensas
### De POST a GET
Tal vez el formulario que deseas aprovechar está preparado para enviar una **solicitud POST con un token CSRF pero**, debes **verificar** si un **GET** también es **válido** y si al enviar una solicitud GET el **token CSRF sigue siendo validado**.
### Falta de token
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 falta el token. 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.
### El token CSRF no está vinculado a la sesión del usuario
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.
Así es como los atacantes explotan esto:
1. **Autenticarse** utilizando su propia cuenta.
2. **Obtener un token CSRF válido** del pool global.
3. **Utilizar este token** en un ataque CSRF contra una víctima.
Esta vulnerabilidad permite a los atacantes realizar solicitudes no autorizadas en nombre de la víctima, explotando el **mecanismo de validación de token insuficiente** de la aplicación.
### Bypass de Método
Si la solicitud está utilizando un **"método extraño"**, verifica si la **funcionalidad de anulación 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**_
Esto también podría funcionar enviando el **parámetro \_method dentro de una solicitud POST** o utilizando los **encabezados**:
* _X-HTTP-Method_
* _X-HTTP-Method-Override_
* _X-Method-Override_
### Bypass de Token de Encabezado Personalizado
Si la solicitud agrega un **encabezado personalizado** con un **token** a la solicitud como **método de protección CSRF**, entonces:
* Prueba la solicitud sin el **Token Personalizado y también sin el encabezado**.
* Prueba la solicitud con una **longitud exactamente igual pero con un token diferente**.
### El token CSRF se verifica mediante una cookie
Las aplicaciones pueden implementar protección CSRF duplicando el token tanto en una cookie como en un parámetro de solicitud o configurando 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 coincide con el valor de 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, seguido por iniciar el ataque CSRF.
A continuación se muestra un ejemplo de cómo podría estructurarse un ataque:
```html
```
{% hint style="info" %}
Ten en cuenta 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.
{% endhint %}
### Cambio de Content-Type
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 de Content-Type permitidos:
* **`application/x-www-form-urlencoded`**
* **`multipart/form-data`**
* **`text/plain`**
Sin embargo, ten en cuenta que la **lógica de los servidores puede variar** dependiendo del **Content-Type** utilizado, por lo que deberías probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Ejemplo (de [aquí](https://brycec.me/posts/corctf\_2021\_challenges)) de envío de datos JSON como text/plain:
```html
```
### Saltando las Solicitudes de Preflight para Datos JSON
Cuando se intenta enviar datos JSON a través de una solicitud POST, usar `Content-Type: application/json` en un formulario HTML no es directamente posible. De manera similar, utilizar `XMLHttpRequest` para enviar este tipo de contenido inicia una solicitud de preflight. Sin embargo, existen estrategias para potencialmente saltar 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 asegurando que el servidor reconozca el contenido como JSON, puedes enviar los datos con `Content-Type: text/plain; application/json`. Esto no desencadena una solicitud de preflight pero podría ser procesado correctamente por el servidor si está configurado para aceptar `application/json`.
3. **Utilización de Archivo Flash SWF**: Un método menos común pero factible implica usar un archivo flash SWF para evadir tales restricciones. Para una comprensión más profunda de esta técnica, consulta [este post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Saltar la Verificación de Referencia/Origen
**Evitar la cabecera de Referencia**
Las aplicaciones pueden validar la cabecera 'Referer' solo cuando está presente. Para evitar que un navegador envíe esta cabecera, se puede utilizar la siguiente etiqueta meta HTML:
```xml
```
Esto asegura que se omita el encabezado 'Referer', potencialmente evitando las comprobaciones de validación en algunas aplicaciones.
**Bypass de expresiones regulares**
{% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %}
[url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md)
{% endcontent-ref %}
Para establecer el nombre de dominio del servidor en la URL que el Referer va a enviar dentro de los parámetros, puedes hacer lo siguiente:
```html
```
### **Bypass del método HEAD**
La primera parte de [**este informe 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 exclusiva de Oak. En lugar de un controlador específico que maneje las solicitudes HEAD, simplemente **se envían al controlador GET pero la aplicación elimina el cuerpo de respuesta**.
Por lo tanto, si una solicitud GET está siendo limitada, simplemente podrías **enviar una solicitud HEAD que será procesada como una solicitud GET**.
## **Ejemplos de Exploit**
### **Exfiltración de Token CSRF**
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 una vulnerabilidad de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
### **GET utilizando etiquetas HTML**
```xml
404 - Page not found
The URL you are requesting is no longer available
```
Otras etiquetas HTML5 que se pueden usar para enviar automáticamente una solicitud GET son:
```html