# Cross-site request forgery (CSRF)
## Lab: CSRF vulnerability with no defenses
### Enunciado
Este laboratorio tiene una función para cambiar el correo electrónico que es vulnerable a ataques CSRF.
Para resolverlo, crea un código HTML que haga un ataque CSRF para cambiar la dirección de correo del usuario que vea la página. Después, súbelo a tu servidor de explotación.
Puedes iniciar sesión en tu propia cuenta con estas credenciales:
* Usuario: **wiener**
* Contraseña: **peter**
### Resolución
Nos logueamos. Interceptamos la petición de cambiar el email para mandarla al **Repeater**.
Es el único parámetro que se envía. Vamos al **exploit server** y ahí creamos la plantilla HTML maliciosa.
```
```
Lo mandamos a la víctima y completamos el laboratorio.
## Lab: CSRF where token validation depends on request method
### Enunciado
Este laboratorio bloquea todas las etiquetas HTML excepto las personalizadas (custom tags). Realizar un ataque de cross-site scripting (XSS) que inyecte una etiqueta personalizada y que muestre automáticamente un `alert(document.cookie)`.
### Resolución
Nos logueamos. Vemos el código fuente.
```
```
Como podemos ver tenemos el valor CSRF escondido. Vamos al exploit server para poner el ataque CSRF.
```
```
Vemos que no es como el anterior laboratorio así que cambiamos de POST a GET.
```
```
## Lab: CSRF where token validation depends on token being present
### Enunciado
La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF. Usar tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite.
Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:\
**Usuario**: `wiener`\
**Contraseña**: `peter`
### Resolución
Nos logueamos. Interceptamos la petición si cambiamos el email.
Sí que nos cambia el correo. Por POST si quitamos el CSRF sí cambia entonces no lo valida.
```
```
Mandamos eso a la víctima.
## Lab: CSRF where token is not tied to user session
### Enunciado
La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF. Utiliza tokens para intentar prevenir ataques CSRF, pero no están integrados en el sistema de manejo de sesión del sitio. Usa tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite. Tienes dos cuentas en la aplicación que puedes usar para ayudarte a diseñar tu ataque. Las credenciales son las siguientes:
* wiener:peter
* carlos:montoya
### Resolución
Nos logueamos con los dos. EL CSRF es un campo requerido no lo podemos quitar y si cambiamos el método tampoco nos vale. Interceptamos pero le damos a Drop pero sí que nos copiamos ese token ya que no ha sido usado. Vamos a cambiar el correo de Wiener.
Si cambiamos email y enviamos no nos deja ya que ya ha sido usado.
Usamos el token que copiamos anteriormente y lo enviamos.
Se cambia. Volvemos a hacer lo mimo pero vamos a crear una plantilla en el exploit server con un token que no ha sido usado.
```
```
## Lab: CSRF where token is tied to non-session cookie
### Enunciado
La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF. Utiliza tokens para intentar prevenir ataques CSRF, pero no están completamente integrados en el sistema de manejo de sesión del sitio. Usar tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite. Tienes dos cuentas en la aplicación que puedes usar para ayudarte a diseñar tu ataque. Las credenciales son las siguientes:
* wiener:peter
* carlos:montoya
### Resolución
Nos logueamos. Miramos el código fuente.
Interceptando la petición y lo mandamos a Repeater. Cuando accedo, **me redirige a /login**, lo que cierra la sesión actual **y además establece una nueva cookie de sesión**. Luego, vamos a **iniciar sesión como el usuario carlos**, y **probar a reemplazar la cookie csrfKey y el parámetro csrf con los valores del usuario wiener**.
Nos damos cuenta que solo cambia la cookie de session pero no podemos hacer mucho más así que nos fijamos en el campò de búsqueda.
Vemos un nuevo valor en la cookie por lo que podemos setear un valor que queremos en la cookie.
{% embed url="" %}
{% embed url="" %}
Habiendo leído esas páginas realizamos este paylaod.
Ya hemos seteado una nueva cookie.
```
```
## Lab: CSRF where token is duplicated in cookie
### Enunciado
La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF. Intenta usar la técnica insegura de prevención de CSRF conocida como "double submit".
Usa tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite. Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:
* **Usuario:** `wiener`
* **Contraseña:** `peter`
### Resolución
Nos logueamos para cambiar el email y ver esa petición.
Como puedes ver, **el valor de nuestra cookie CSRF coincide con el valor del parámetro CSRF en el POST**. Esto es lo que se conoce como la defensa **“double submit”** contra ataques CSRF.
Vemos el campo de búsqueda para setear una nueva cookie.
Vemos que al enviar la petición se encuentra una nueva cookie. En el anterior laboratorio vimos que eso permite al atacante añadir una nueva cookie.
```
/?search=anything%0d%0aSet-Cookie:csrfKey=CRLF%3b%20SameSite=None
```
Vamos a enviar a la víctima el siguiente script.
```
CSRF
```
## Lab: SameSite Strict bypass via client-side redirect
### Enunciado
**La función de cambio de correo electrónico de este laboratorio es vulnerable a CSRF.** Para resolver el laboratorio, **realiza un ataque CSRF que cambie la dirección de correo electrónico de la víctima.** Debes usar el **servidor de exploits proporcionado** para alojar tu ataque.
**Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:**
* **Usuario:** `wiener`
* **Contraseña:** `peter`
### Resolución
Nos logueamos.
Vemos que tenemos el atributo SameSite puesto a strict. Al cambiar el email tampoco vemos un CSRF token.
**Restricción Strict:**
Si una cookie se configura con el atributo **SameSite=Strict**, los navegadores **no la incluirán en ninguna solicitud cross-site**.
Puedes **lograr superar esta limitación** si encuentras un **"gadget"** que provoque **una segunda solicitud dentro del mismo sitio**.
Un ejemplo de **gadget** es una **redirección del lado del cliente** que construye dinámicamente el destino de la redirección usando **parámetros de la URL controlados por el atacante**.
Para los navegadores, **estas redirecciones del lado del cliente no son realmente redirecciones**; la solicitud resultante se trata como **una solicitud independiente y ordinaria**.
Lo más importante es que **se considera una solicitud same-site** y, por lo tanto, **incluirá todas las cookies relacionadas con el sitio**, sin importar las restricciones configuradas.
Si puedes manipular este **gadget** para generar **una solicitud secundaria maliciosa**, podrías **bypassear por completo** cualquier restricción de cookie SameSite.
Escribimos un post. Nos damos cuenta que hay un script JS.
Cuando vamos a **/post/comment/confirmation**, se ejecuta este **JavaScript**:
Después de 3 segundos, redirige al usuario a **/post/\**.
**Pero el parámetro GET `postId` está completamente bajo el control del atacante.**
Como **/my-account/change-mail** acepta GET realizamos el siguiente script para enviar a la máquina.
```
CSRF-8
```
## Lab: SameSite Lax bypass via method override
### Enunciado
**La función de cambio de correo electrónico de este laboratorio es vulnerable a CSRF.** Para resolver el laboratorio, **realiza un ataque CSRF que cambie la dirección de correo electrónico de la víctima.** Debes usar el **servidor de exploits proporcionado** para alojar tu ataque.
**Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:**
* **Usuario:** `wiener`
* **Contraseña:** `peter`
> Las restricciones predeterminadas de SameSite difieren entre navegadores. Como la víctima usa **Chrome**, se recomienda **también usar Chrome (o el navegador Chromium incorporado en Burp)** para probar tu exploit.
### Resolución
Nos logueamos.
Vemos que no tenemos el atributo SameSite. En Chrome, **aunque el desarrollador no haya configurado nada, se aplican restricciones SameSite=Lax de forma predeterminada**. Esto significa que la cookie **solo se enviará en solicitudes cross-site que cumplan ciertos criterios específicos**.
Por último, vamos a **examinar el código fuente de la página /my-account**.
Vemos que al cambiar el email no incluye un CSRF token.
Cuando hacemos clic en el botón **“Update email”**, se envía una **solicitud POST** a **/my-account/change-email**, con el parámetro **email**.
Para poder realizar un **ataque CSRF**, necesitamos **analizar más a fondo** cómo funciona la restricción **SameSite=Lax**.
**Restricción SameSite=Lax:**
Los navegadores **enviarán la cookie en solicitudes cross-site**, pero solo si **ambas condiciones se cumplen**:
* La solicitud usa el **método GET**.
* La solicitud proviene de una **navegación de nivel superior** del usuario, como hacer clic en un enlace.
**¿Qué significa esto?**
* Que la cookie **no se incluirá** en solicitudes **POST** de tipo cross-site, por ejemplo.
* Las solicitudes POST suelen usarse para **modificar datos o estado** en el servidor (según las buenas prácticas), por lo que son **un objetivo habitual para ataques CSRF**.
* Además, la cookie **tampoco se enviará** en solicitudes en segundo plano, como las iniciadas por **scripts**, **iframes** o **cargas de imágenes u otros recursos**.
```
CSRF
```
No se permite este método. Ahora bien, **incluso si una solicitud GET ordinaria no está permitida**, algunos frameworks **ofrecen mecanismos para sobrescribir el método especificado en la línea de la solicitud**.
Por ejemplo, **Symfony** admite el parámetro **\_method** en formularios, **que tiene prioridad sobre el método normal para fines de enrutamiento**.
```
CSRF
```
## Lab: SameSite Strict bypass via sibling domain
### Enunciado
**La función de chat en vivo de este laboratorio es vulnerable a secuestro de WebSocket en el lado del cliente (CSWSH, por sus siglas en inglés).**
Para resolver el laboratorio, **inicia sesión en la cuenta de la víctima.**
Para hacerlo, **usa el servidor de exploits proporcionado** para realizar un ataque CSWSH que **exfiltre el historial de chat de la víctima** al servidor predeterminado de **Burp Collaborator**.
El historial de chat **contiene las credenciales de inicio de sesión en texto claro**.
> Si aún no lo has hecho, te recomendamos completar nuestro tema sobre **vulnerabilidades en WebSocket** antes de intentar este laboratorio.
### Resolución
Vemos el script JS.
El chat utiliza **WebSocket** de la siguiente forma:
```javascript
var webSocket = new WebSocket(chatForm.getAttribute("action"));
```
También podemos ver que la función **sendMessage()** llama a **htmlEncode()** para codificar en HTML nuestro input:
```javascript
function htmlEncode(str) {
if (chatForm.getAttribute("encode")) {
return String(str).replace(/['"<>&\r\n\\]/gi, function (c) {
var lookup = {'\\': '\', '\r': '
', '\n': '
', '"': '"', '<': '<', '>': '>', "'": ''', '&': '&'};
return lookup[c];
});
}
return str;
}
```
Como puedes ver, **codifica en HTML muchos caracteres especiales**, por lo que **un XSS basado en el DOM tradicional no sería explotable aquí.**
Si la **solicitud de handshake del WebSocket** es vulnerable a **CSRF**, entonces la página web de un atacante **puede realizar una solicitud cross-site para abrir un WebSocket en el sitio vulnerable**.
Para lograr esto, **voy a crear un formulario HTML** que **envíe automáticamente una solicitud WebSocket a /chat** con el mensaje **READY**, y que **exfiltre el historial de chat de la víctima**.
```
CSRF
```
```
cms-0a1f00e1046478b380b4e48300e500f6.web-security-academy.net
```
Viendo la petición nos damos cuenta que tenemos el atributo SameSite y puesto a strict.
Vemos que se refleja el input usuario.
```
```
Ahora hemos identificado **dos vulnerabilidades**:
* **CSWSH** en el **"Live chat".**
* **XSS reflejado** en la página de inicio de sesión del dominio hermano **cms**.
Como el dominio hermano **cms** forma parte del **mismo sitio**, podemos **usar el XSS reflejado** para lanzar el ataque **CSWSH**, sin que las restricciones **SameSite** del navegador lo bloqueen.
URLcodeamos el siguiente script.
```
```
```
```
Enviamos a la víctima.
```
CSRF
```
Tenemos las credenciales de carlos por lo que nos logueamos.
## Lab: SameSite Lax bypass via cookie refresh
### Enunciado
**La función de cambio de correo electrónico de este laboratorio es vulnerable a CSRF.** Para resolver el laboratorio, **realiza un ataque CSRF que cambie la dirección de correo electrónico de la víctima.** Debes usar el **servidor de exploits proporcionado** para alojar tu ataque.
**El laboratorio admite inicio de sesión basado en OAuth.**\
Puedes iniciar sesión a través de tu cuenta de redes sociales con las siguientes credenciales:
* **Usuario:** `wiener`
* **Contraseña:** `peter`
> Las restricciones predeterminadas de SameSite difieren entre navegadores. Como la víctima usa **Chrome**, se recomienda **también usar Chrome (o el navegador Chromium incorporado en Burp)** para probar tu exploit.
### Resolución
Como se puede observar, **no incluye el atributo SameSite**, así que **Chrome aplica automáticamente la restricción Lax por defecto**.
Normalmente, **las cookies con Lax no se envían en solicitudes POST de sitios cruzados**. Sin embargo, para mantener la compatibilidad con **Single Sign-On (SSO)**, **Chrome permite estas solicitudes POST durante los primeros 120 segundos tras iniciar sesión**.
Esto significa que hay **un margen de dos minutos** en el que el usuario **puede quedar expuesto a ataques cross-site**.
Como puedes ver, **el formulario no tiene un parámetro de token CSRF**, que normalmente ayudaría a prevenir ataques CSRF.
Además, cuando enviamos el formulario, **realiza una solicitud POST a /my-account/change-email**, incluyendo el parámetro **email**.
Con esta información, **podemos crear un payload CSRF** para actualizar la dirección de correo electrónico de la víctima.
Pero antes hay algo importante que debemos tener en cuenta:
**Podemos forzar la actualización de la cookie abriendo una nueva pestaña**, de forma que el navegador **no abandone la página antes de que puedas lanzar el ataque final**.
El pequeño inconveniente de este método es que **los navegadores bloquean las ventanas emergentes a menos que se abran mediante una interacción manual del usuario**.
```
Click anywhere on the page
```
## Lab: CSRF where Referer validation depends on header being present
### Enunciado
**La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF.** Intenta bloquear las solicitudes entre dominios, pero **tiene un mecanismo de respaldo inseguro**.
**Usa tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite.**
**Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:**
* **Usuario:** `wiener`
* **Contraseña:** `peter`
### Resolución
Nos logueamos para ver la petición al cambiar el email.
No hay un CSRF token por lo que realizamos el siguiente ataque.
```
CSRF
```
**Como el encabezado Referer se puede manipular por completo**, en realidad **podemos saltarnos esta verificación**.
Según la documentación de Mozilla, **podemos usar la etiqueta `` para controlar o anular el header Referer**.
```
CSRF
```
## Lab: CSRF with broken Referer validation
### Enunciado
**La funcionalidad de cambio de correo electrónico de este laboratorio es vulnerable a CSRF.** Intenta **detectar y bloquear solicitudes entre dominios**, pero **su mecanismo de detección puede ser evadido**.
**Usa tu servidor de exploits para alojar una página HTML que realice un ataque CSRF y cambie la dirección de correo electrónico del usuario que la visite.**
**Puedes iniciar sesión en tu propia cuenta con las siguientes credenciales:**
* **Usuario:** `wiener`
* **Contraseña:** `peter`
### Resolución
Nos logueamos y vemos la petición de cambiar email.
Vemos que no tenemos CSRF token por lo que realizamos lo siguiente.
```
CSRF
```
Nos sale como el anterior laboratorio pero aún así con la etiqueta meta no lo solucionamos. Vemos la cabecera de Referer.
Nos salta error si enviamos distinta URL por lo que voy a intentar añadir un parámetro GET después de lo que se espera.
Según la documentación de Mozilla, **podemos usar la función de JavaScript `history.pushState()` para manipular la URL mostrada sin recargar la página**.
Hay que tener en cuenta que en muchos navegadores **eliminan la cadena de consulta del Referer por defecto como medida de seguridad**.
Para **evitar esa limitación**, **podemos agregar una nueva etiqueta ``** para **anular ese comportamiento** y asegurarnos de que **la URL completa se incluya en la solicitud**.
```
CSRF
```
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://beafn28.gitbook.io/beafn28/web-security/laboratorios-portswigger/cross-site-request-forgery-csrf.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.