* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
**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 desean 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" en la **cuenta de la víctima**.
Para poder aprovechar una vulnerabilidad de CSRF, primero debes **encontrar una acción relevante para abusar** (cambiar la contraseña o el correo electrónico, hacer que la víctima te siga en una red social, darte más privilegios...). La **sesión debe depender solo de cookies o del encabezado de autenticación básica HTTP**, no se puede usar ningún otro encabezado para manejar la sesión. Y por último, no debe haber **parámetros impredecibles** en la solicitud.
* [**Cookies SameSite**](hacking-with-cookies/#samesite): Si la cookie de sesión utiliza esta bandera, es posible que no puedas enviar la cookie desde sitios web arbitrarios.
* [**Compartición de recursos entre orígenes**](cors-bypass.md): Dependiendo del tipo de solicitud HTTP que necesites realizar para abusar de la acción relevante, debes tener en cuenta la **política CORS del sitio víctima**. _Ten en cuenta 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._
* Solicitar la **contraseña** del usuario para autorizar la acción.
* Usar un **token CSRF** en cada sesión. Este token debe enviarse dentro de la solicitud para confirmar la acción. Este token puede estar protegido con CORS.
Tal vez el formulario que deseas aprovechar está preparado para enviar una **solicitud POST con un token CSRF**, pero debes **verificar** si también es **válido** enviar una solicitud **GET** y si al enviar una solicitud GET el **token CSRF sigue siendo validado**.
Algunas aplicaciones validan correctamente el token cuando está presente, pero **omitirán la validación si se omite el token**.\
En esta situación, el atacante puede **eliminar el parámetro completo** que contiene el token (no solo su valor) para eludir la validación y realizar un ataque CSRF.
Algunas aplicaciones **no validan que el token pertenezca a la misma sesión** que el usuario que realiza la solicitud. En su lugar, la aplicación **mantiene un conjunto global de tokens** que ha emitido y acepta cualquier token que aparezca en este conjunto.\
En esta situación, el atacante puede iniciar sesión en la aplicación utilizando su propia cuenta, **obtener un token válido** y luego **proporcionar ese token al usuario víctima** en su ataque CSRF.
Si la solicitud utiliza un **método "extraño"**, verifica si la **funcionalidad de anulación de método** está funcionando.\
Por ejemplo, si se 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 **configuran una cookie CSRF** y **verifican en el backend si el token CSRF enviado es el relacionado con la cookie**.
Cuando se valida la solicitud posterior, 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 configurar su cookie CSRF en la víctima como un CRLF**.
Ten en cuenta que si el **token csrf está relacionado con la cookie de sesión, este ataque no funcionará** porque necesitarás establecerle a la víctima tu sesión, y por lo tanto estarás atacándote a ti mismo.
Según [**esto**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), para **evitar las solicitudes de preflight** utilizando el método **POST**, estos son los valores permitidos para Content-Type:
Sin embargo, ten en cuenta que la **lógica del servidor puede variar** dependiendo del **Content-Type** utilizado, por lo que debes probar los valores mencionados y otros como **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Como ya sabes, no puedes enviar una solicitud POST con el tipo de contenido **`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 comprobar si el backend está utilizando los datos independientemente del tipo de contenido.\
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 **burlar** esta restricción utilizando un archivo flash **SWF**. Para obtener más información, [**lee este artículo**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Si se está utilizando un **token CSRF** como **defensa**, puedes intentar **exfiltrarlo** aprovechando una vulnerabilidad de [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) o una vulnerabilidad de [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
A common method used to submit data to a web server is through a form POST request. This type of request is typically used when submitting sensitive information, such as login credentials or payment details.
Un método común utilizado para enviar datos a un servidor web es a través de una solicitud de envío de formulario (form POST request). Este tipo de solicitud se utiliza generalmente al enviar información sensible, como credenciales de inicio de sesión o detalles de pago.
To make a form POST request, the client sends an HTTP POST request to the server with the form data included in the request body. The server then processes the data and responds accordingly.
Para realizar una solicitud de envío de formulario, el cliente envía una solicitud HTTP POST al servidor con los datos del formulario incluidos en el cuerpo de la solicitud. Luego, el servidor procesa los datos y responde en consecuencia.
### Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into submitting a malicious request. This attack occurs when a malicious website or email tricks the victim's browser into making a request to a target website on which the victim is authenticated.
Cross-Site Request Forgery (CSRF) es un ataque que engaña a la víctima para que envíe una solicitud maliciosa. Este ataque ocurre cuando un sitio web o correo electrónico malicioso engaña al navegador de la víctima para que realice una solicitud a un sitio web objetivo en el que la víctima está autenticada.
The attack takes advantage of the fact that many websites rely solely on session cookies for authentication, without additional security measures. By tricking the victim's browser into making a request, the attacker can perform actions on behalf of the victim without their knowledge or consent.
El ataque aprovecha el hecho de que muchos sitios web se basan únicamente en cookies de sesión para la autenticación, sin medidas de seguridad adicionales. Al engañar al navegador de la víctima para que realice una solicitud, el atacante puede realizar acciones en nombre de la víctima sin su conocimiento o consentimiento.
To prevent CSRF attacks, web applications can implement measures such as using anti-CSRF tokens, checking the Referer header, or implementing the SameSite attribute for cookies. These measures help ensure that requests are only accepted from legitimate sources and not from malicious websites.
Para prevenir ataques CSRF, las aplicaciones web pueden implementar medidas como el uso de tokens anti-CSRF, verificar la cabecera Referer o implementar el atributo SameSite para las cookies. Estas medidas ayudan a garantizar que las solicitudes solo sean aceptadas desde fuentes legítimas y no desde sitios web maliciosos.
### Solicitud de envío de formulario a través de un iframe
One common technique used in Cross-Site Request Forgery (CSRF) attacks is to submit a form through an iframe. This technique allows an attacker to trick a user into unknowingly submitting a form on a targeted website.
To execute this attack, the attacker creates a malicious webpage that contains an iframe pointing to the target website's form submission URL. The attacker then lures the victim into visiting the malicious webpage.
When the victim visits the malicious webpage, the iframe automatically submits the form on the target website, using the victim's authenticated session. Since the victim is already logged in to the target website, the form submission appears legitimate to the server.
This technique can be particularly effective when combined with social engineering tactics, such as sending the victim a link to the malicious webpage via email or a messaging platform.
To protect against this type of attack, web developers should implement measures such as:
- Implementing anti-CSRF tokens: By including a unique token in each form submission, developers can ensure that the form is only submitted from their own website and not from a malicious source.
- Implementing SameSite cookies: By setting the SameSite attribute to "Strict" or "Lax" for cookies, developers can prevent them from being sent in cross-origin requests, thereby mitigating the risk of CSRF attacks.
- Implementing strong authentication and session management: By enforcing strong authentication mechanisms and properly managing user sessions, developers can reduce the risk of unauthorized form submissions.
By understanding and implementing these security measures, web developers can effectively protect their websites against CSRF attacks executed through iframes.
An Ajax POST request is a type of HTTP request that is sent asynchronously from a web page to a server using the Ajax technology. This type of request is commonly used to send data to the server without requiring a page refresh.
Una solicitud POST de Ajax es un tipo de solicitud HTTP que se envía de forma asíncrona desde una página web a un servidor utilizando la tecnología Ajax. Este tipo de solicitud se utiliza comúnmente para enviar datos al servidor sin requerir una actualización de la página.
```javascript
$.ajax({
url: "/endpoint",
type: "POST",
data: {
param1: "value1",
param2: "value2"
},
success: function(response) {
console.log(response);
},
error: function(xhr, status, error) {
console.log(error);
}
});
```
The above code snippet demonstrates an example of an Ajax POST request using jQuery. The `url` parameter specifies the endpoint where the request is sent, the `type` parameter specifies the HTTP method (in this case, POST), and the `data` parameter contains the data to be sent to the server.
El fragmento de código anterior muestra un ejemplo de una solicitud POST de Ajax utilizando jQuery. El parámetro `url` especifica el punto final al que se envía la solicitud, el parámetro `type` especifica el método HTTP (en este caso, POST), y el parámetro `data` contiene los datos que se enviarán al servidor.
The `success` function is called when the request is successful, and the `response` parameter contains the response from the server. The `error` function is called when an error occurs during the request, and the `xhr`, `status`, and `error` parameters provide information about the error.
La función `success` se llama cuando la solicitud es exitosa, y el parámetro `response` contiene la respuesta del servidor. La función `error` se llama cuando ocurre un error durante la solicitud, y los parámetros `xhr`, `status` y `error` proporcionan información sobre el error.
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)
When submitting a form on a website, the data is typically sent using the `application/x-www-form-urlencoded` content type. However, in some cases, the form may require the use of the `multipart/form-data` content type.
Cuando se envía un formulario en un sitio web, los datos se suelen enviar utilizando el tipo de contenido `application/x-www-form-urlencoded`. Sin embargo, en algunos casos, el formulario puede requerir el uso del tipo de contenido `multipart/form-data`.
This content type is commonly used when uploading files or when the form includes binary data. It allows the data to be divided into multiple parts, each with its own content type and headers.
Este tipo de contenido se utiliza comúnmente cuando se cargan archivos o cuando el formulario incluye datos binarios. Permite que los datos se dividan en varias partes, cada una con su propio tipo de contenido y encabezados.
To send a `multipart/form-data` POST request, the request body must be formatted accordingly. Each part of the data should be separated by a boundary, which is a unique string that does not appear in the data itself.
Para enviar una solicitud POST `multipart/form-data`, el cuerpo de la solicitud debe estar formateado correctamente. Cada parte de los datos debe estar separada por un límite, que es una cadena única que no aparece en los propios datos.
Each part consists of a set of headers and the actual data. The headers specify the content type, content disposition, and other relevant information.
Cada parte consta de un conjunto de encabezados y los datos reales. Los encabezados especifican el tipo de contenido, la disposición del contenido y otra información relevante.
Here is an example of a `multipart/form-data` POST request:
Aquí tienes un ejemplo de una solicitud POST `multipart/form-data`:
In this example, the request is sent to `example.com/upload` with a `multipart/form-data` content type. The request body consists of two parts: one for the file upload and another for the name field.
En este ejemplo, la solicitud se envía a `example.com/upload` con un tipo de contenido `multipart/form-data`. El cuerpo de la solicitud consta de dos partes: una para la carga del archivo y otra para el campo de nombre.
In this technique, we will explore how to perform a Cross-Site Request Forgery (CSRF) attack using a multipart/form-data POST request. This technique is commonly used to exploit web applications that do not implement proper CSRF protection.
En esta técnica, exploraremos cómo realizar un ataque de falsificación de solicitud entre sitios (CSRF) utilizando una solicitud POST multipart/form-data. Esta técnica se utiliza comúnmente para explotar aplicaciones web que no implementan una protección adecuada contra CSRF.
#### Overview
The multipart/form-data content type is commonly used for file uploads and form submissions that contain binary data. It allows the client to send multiple parts of data in a single request.
El tipo de contenido multipart/form-data se utiliza comúnmente para cargar archivos y enviar formularios que contienen datos binarios. Permite al cliente enviar varias partes de datos en una sola solicitud.
#### Exploiting CSRF using multipart/form-data
To exploit CSRF using a multipart/form-data POST request, we need to create a form that submits the desired request to the target application. This form should include all the necessary fields and values required by the target application.
Para explotar CSRF utilizando una solicitud POST multipart/form-data, debemos crear un formulario que envíe la solicitud deseada a la aplicación objetivo. Este formulario debe incluir todos los campos y valores necesarios requeridos por la aplicación objetivo.
The key point in this technique is to ensure that the target application accepts requests with the multipart/form-data content type without performing any CSRF validation. This can be achieved by bypassing any CSRF protection mechanisms implemented by the application.
El punto clave en esta técnica es asegurarse de que la aplicación objetivo acepte solicitudes con el tipo de contenido multipart/form-data sin realizar ninguna validación CSRF. Esto se puede lograr al eludir cualquier mecanismo de protección CSRF implementado por la aplicación.
#### Conclusion
Performing a CSRF attack using a multipart/form-data POST request can be an effective way to exploit web applications that lack proper CSRF protection. By understanding how this technique works, you can better defend against such attacks and ensure the security of your web applications.
Realizar un ataque CSRF utilizando una solicitud POST multipart/form-data puede ser una forma efectiva de explotar aplicaciones web que carecen de una protección CSRF adecuada. Al comprender cómo funciona esta técnica, puede defenderse mejor contra tales ataques y garantizar la seguridad de sus aplicaciones web.
When an HTML form is submitted, the browser sends a POST request to the server with the form data. This can be exploited in a Cross-Site Request Forgery (CSRF) attack by tricking a user into submitting a form without their knowledge or consent.
Cuando se envía un formulario HTML, el navegador envía una solicitud POST al servidor con los datos del formulario. Esto puede ser explotado en un ataque de falsificación de solicitud entre sitios (CSRF) al engañar a un usuario para que envíe un formulario sin su conocimiento o consentimiento.
One way to execute a CSRF attack is by embedding a malicious website within an iframe on a legitimate website. When the user visits the legitimate website, the malicious website can automatically submit a form on the legitimate website using JavaScript.
Una forma de ejecutar un ataque CSRF es mediante la inserción de un sitio web malicioso dentro de un iframe en un sitio web legítimo. Cuando el usuario visita el sitio web legítimo, el sitio web malicioso puede enviar automáticamente un formulario en el sitio web legítimo utilizando JavaScript.
To do this, the attacker needs to create a hidden iframe on the malicious website and set its `src` attribute to the URL of the legitimate website's form. The attacker can then use JavaScript to automatically submit the form within the iframe.
Para hacer esto, el atacante necesita crear un iframe oculto en el sitio web malicioso y establecer su atributo `src` en la URL del formulario del sitio web legítimo. Luego, el atacante puede utilizar JavaScript para enviar automáticamente el formulario dentro del iframe.
When the user visits the malicious website, the hidden iframe will load the form from the legitimate website and submit it without the user's knowledge. This allows the attacker to perform actions on behalf of the user, such as changing their password or making unauthorized transactions.
Cuando el usuario visita el sitio web malicioso, el iframe oculto cargará el formulario del sitio web legítimo y lo enviará sin el conocimiento del usuario. Esto permite al atacante realizar acciones en nombre del usuario, como cambiar su contraseña o realizar transacciones no autorizadas.
To protect against CSRF attacks, web developers should implement measures such as using anti-CSRF tokens, checking the `Referer` header, and implementing strict access controls.
Para protegerse contra los ataques CSRF, los desarrolladores web deben implementar medidas como el uso de tokens anti-CSRF, verificar la cabecera `Referer` e implementar controles de acceso estrictos.
En un ataque de falsificación de solicitud entre sitios (CSRF), el objetivo es engañar al usuario para que realice una acción no deseada en un sitio web en el que ya está autenticado. Para llevar a cabo este ataque, es necesario robar el token CSRF del usuario y luego enviar una solicitud POST utilizando ese token.
Aquí hay un ejemplo de cómo se puede realizar este ataque:
1. Obtener el token CSRF: El token CSRF se encuentra generalmente en una cookie o en una etiqueta oculta en el formulario. Utilizando técnicas de ingeniería social o de inyección de código, se puede obtener este token del usuario.
2. Crear una solicitud POST: Una vez que se ha obtenido el token CSRF, se puede utilizar para crear una solicitud POST falsa. Esta solicitud puede contener cualquier acción no deseada, como cambiar la contraseña del usuario o realizar una compra no autorizada.
3. Enviar la solicitud POST: La solicitud POST falsa se envía al servidor web objetivo. Dado que la solicitud contiene el token CSRF válido, el servidor la considerará legítima y realizará la acción solicitada.
Es importante tener en cuenta que este ataque solo es exitoso si el usuario está autenticado en el sitio web objetivo y si el sitio no implementa medidas de protección adecuadas, como la verificación del origen de las solicitudes.
Para protegerse contra los ataques CSRF, los desarrolladores deben implementar medidas como el uso de tokens CSRF aleatorios y únicos, la verificación del origen de las solicitudes y la implementación de políticas de seguridad adecuadas en el servidor web.
### **Robar el token CSRF y enviar una solicitud POST utilizando un iframe, un formulario y Ajax**
El robo de tokens CSRF es una técnica común utilizada en ataques de falsificación de solicitudes entre sitios. Esta técnica aprovecha la confianza que un sitio web tiene en las solicitudes enviadas desde su propio dominio.
Para robar el token CSRF, se puede utilizar un iframe oculto que cargue la página objetivo que contiene el token. Luego, se puede acceder al contenido del iframe y extraer el valor del token.
var csrfFrame = document.getElementById('csrfFrame');
var csrfToken = csrfFrame.contentDocument.querySelector('input[name="csrf_token"]').value;
// Aquí se puede enviar el token a un servidor malicioso o realizar otras acciones
</script>
```
Una vez que se ha robado el token CSRF, se puede utilizar para enviar una solicitud POST falsificada al servidor objetivo. Esto se puede hacer utilizando un formulario oculto que se completa automáticamente con el token robado y se envía mediante JavaScript.
Otra forma de enviar la solicitud POST falsificada es utilizando Ajax. Se puede crear una solicitud Ajax y establecer el valor del token CSRF en el encabezado de la solicitud.
// Aquí se pueden agregar otros encabezados y datos de la solicitud
xhr.send();
```
Estas técnicas permiten a un atacante robar el token CSRF y enviar solicitudes falsificadas en nombre del usuario legítimo. Es importante que los desarrolladores implementen medidas de protección adecuadas, como el uso de tokens CSRF con duración limitada y la validación estricta de las solicitudes recibidas.
### **Robar el token CSRF y enviar una solicitud POST utilizando un iframe y un formulario**
Una técnica común para llevar a cabo un ataque de falsificación de solicitudes entre sitios (CSRF) es robar el token CSRF de un usuario y luego utilizarlo para enviar una solicitud POST maliciosa. Esto se puede lograr mediante el uso de un iframe y un formulario.
1. Primero, es necesario obtener el token CSRF del usuario. Esto se puede hacer mediante ingeniería inversa o mediante la explotación de una vulnerabilidad en la aplicación web.
2. Una vez que se ha obtenido el token CSRF, se puede utilizar un iframe para cargar una página maliciosa en el navegador del usuario. El iframe debe apuntar a la página que se desea atacar.
3. Dentro de la página maliciosa, se debe incluir un formulario que contenga el token CSRF robado y los parámetros necesarios para la solicitud POST maliciosa.
4. Cuando el usuario carga la página maliciosa, el formulario se enviará automáticamente debido al uso del atributo `action` en el formulario. Esto enviará la solicitud POST con el token CSRF robado y los parámetros necesarios.
Es importante tener en cuenta que este tipo de ataque solo funcionará si el usuario tiene una sesión activa en la página objetivo y si la página no implementa medidas de protección adecuadas, como la verificación del origen de la solicitud. Los desarrolladores deben implementar medidas de seguridad, como tokens CSRF aleatorios y verificación del origen de la solicitud, para protegerse contra este tipo de ataques.
En esta técnica de CSRF, el atacante roba el token de autenticación de la víctima y lo envía a través de dos iframes. El objetivo es engañar al navegador de la víctima para que realice una solicitud no deseada en nombre del usuario autenticado.
El proceso se divide en los siguientes pasos:
1. El atacante crea una página web maliciosa que contiene dos iframes. Uno de los iframes se carga con la página de destino que se desea atacar, mientras que el otro se carga con una página controlada por el atacante.
2. Cuando la víctima visita la página maliciosa, el navegador carga los iframes automáticamente.
3. El iframe controlado por el atacante realiza una solicitud GET a la página de destino, aprovechando el token de autenticación almacenado en las cookies de la víctima.
4. La página de destino recibe la solicitud y la procesa como si fuera legítima, ya que incluye el token de autenticación válido.
5. El atacante puede aprovechar esta solicitud para realizar acciones no autorizadas en nombre de la víctima, como cambiar la contraseña, realizar compras o realizar cualquier otra acción permitida por la página de destino.
Es importante destacar que esta técnica solo funciona si la página de destino no implementa medidas de protección contra CSRF, como tokens de solicitud aleatorios o verificación de origen. Por lo tanto, es fundamental que los desarrolladores implementen estas medidas de seguridad para proteger sus aplicaciones web contra este tipo de ataques.
### **POSTRobar token CSRF con Ajax y enviar un post con un formulario**
En esta técnica, aprovechamos una vulnerabilidad de Cross-Site Request Forgery (CSRF) para robar el token CSRF de un usuario y luego enviar una solicitud POST utilizando Ajax y un formulario.
1. Primero, necesitamos obtener el token CSRF del usuario. Esto se puede hacer mediante ingeniería social o mediante la explotación de una vulnerabilidad en el sitio web objetivo.
2. Una vez que tenemos el token CSRF, podemos usar Ajax para enviar una solicitud POST al servidor objetivo. Aquí está el código de ejemplo:
Asegúrate de reemplazar "https://www.example.com/endpoint" con la URL del punto final al que deseas enviar la solicitud POST. Además, reemplaza "<TOKEN_CSRF>" con el token CSRF que has obtenido.
3. También podemos enviar una solicitud POST utilizando un formulario oculto. Aquí está el código de ejemplo:
Al igual que antes, asegúrate de reemplazar "https://www.example.com/endpoint" con la URL del punto final al que deseas enviar la solicitud POST. Además, reemplaza "<TOKEN_CSRF>" con el token CSRF que has obtenido.
Estas técnicas permiten a un atacante enviar solicitudes POST en nombre del usuario sin su conocimiento, lo que puede llevar a acciones no deseadas o maliciosas. Es importante que los desarrolladores implementen medidas de protección adecuadas, como el uso de tokens CSRF y la validación de referencias, para mitigar este tipo de ataques.
Socket.IO es una biblioteca de JavaScript que permite la comunicación bidireccional en tiempo real entre el cliente y el servidor. Aunque Socket.IO proporciona una capa de seguridad incorporada, aún es posible que un atacante aproveche una vulnerabilidad de falsificación de solicitudes entre sitios (CSRF) para realizar acciones no deseadas en nombre del usuario.
#### ¿Qué es CSRF?
La falsificación de solicitudes entre sitios (CSRF) es un tipo de ataque en el que un atacante engaña a un usuario para que realice una acción no deseada en un sitio web en el que el usuario está autenticado. Esto se logra engañando al usuario para que haga clic en un enlace o botón malicioso que realiza una solicitud HTTP en segundo plano sin su conocimiento.
#### CSRF con Socket.IO
Socket.IO utiliza cookies para mantener la sesión del usuario y autenticar las solicitudes entrantes. Sin embargo, las cookies no son suficientes para proteger contra ataques CSRF. Un atacante puede engañar a un usuario para que visite un sitio web malicioso que contiene código JavaScript que realiza solicitudes a un servidor Socket.IO legítimo en nombre del usuario autenticado.
Para protegerse contra ataques CSRF en Socket.IO, se pueden implementar las siguientes medidas:
1.**Verificación de origen**: El servidor Socket.IO debe verificar el origen de cada solicitud entrante para asegurarse de que provenga de un dominio confiable. Esto se puede hacer comparando el encabezado "Origin" de la solicitud con una lista blanca de dominios permitidos.
2.**Token CSRF**: Se puede generar un token CSRF único para cada sesión de usuario y enviarlo al cliente como una cookie o un encabezado personalizado. El cliente debe incluir este token en cada solicitud a Socket.IO y el servidor debe verificar su validez antes de procesar la solicitud.
3.**Referer Header**: El servidor Socket.IO puede verificar el encabezado "Referer" de cada solicitud para asegurarse de que provenga de una página legítima en lugar de un sitio malicioso.
Implementar estas medidas de seguridad puede ayudar a prevenir ataques CSRF en aplicaciones que utilizan Socket.IO. Es importante tener en cuenta que estas medidas deben combinarse con otras prácticas de seguridad, como la validación de entrada y la protección contra XSS, para garantizar una protección completa contra ataques en la aplicación web.
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 el encabezado X-Forwarded-For para intentar evadir un posible bloqueo de IP):
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres que tu **empresa sea anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**merchandising oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Comparte tus trucos de hacking enviando PRs al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
