--- id: CP-053 slug: csrf-falsificacion-peticiones-entre-sitios lang: es title: "El CSRF: la acción forzada sin que usted lo sepa" description: Un sitio trampa o un mensaje pueden hacer que su navegador actúe en su nombre en un servicio donde ha iniciado sesión. Mecanismo y defensas. canonical_url: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ markdown_url: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «El CSRF: la acción forzada sin que usted lo sepa», Cyberpedia, 2026. https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ it: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # El CSRF: la acción forzada sin que usted lo sepa El CSRF (Cross-Site Request Forgery) es un ataque que obliga a un usuario a ejecutar acciones no deseadas en una aplicación web donde ya está autenticado [1]. El atacante no necesita la contraseña de la víctima: hace actuar a su navegador. Para un empleado, el escenario típico es sencillo. Hay un correo o un sitio bancario abierto en una pestaña. Un enlace recibido por correo electrónico o por mensajería instantánea lleva a otra página, y esa página lanza, en segundo plano, una petición al servicio que sigue con la sesión iniciada [1]. ## En 30 segundos - Dónde ocurre: en la mayoría de los servicios web sin protección anti-CSRF, cuando abre un enlace o una página trampa en el mismo navegador [1]. - Qué quiere el atacante: provocar una acción que cambie algo, como una transferencia o un cambio de contraseña [1]. - El reflejo: cerrar la sesión de un servicio cuando termine de usarlo [2]. - De dónde viene el fallo: de la aplicación, no del usuario [2]. ## Preguntas directas ### ¿El CSRF me roba la contraseña? No, no como tal. El ataque toma prestadas la identidad y los permisos de la víctima para realizar una acción en su lugar [1]. Apunta a las acciones que cambian el estado del servicio, como modificar la dirección de correo o la contraseña, o comprar algo. Obligar a la víctima a consultar datos no beneficia al atacante, porque quien recibe la respuesta es la víctima, no él [1]. ### ¿Por qué el servicio obedece una petición que yo no quise hacer? Porque no sabe distinguirla de una petición legítima. En la mayoría de los sitios, las peticiones del navegador incluyen automáticamente las credenciales asociadas al sitio, como la cookie de sesión [1]. Si el usuario está autenticado, el sitio no tiene forma de separar la petición falsificada de la real [1]. El CWE describe la debilidad así: la aplicación no verifica, o no puede verificar, que una petición haya sido enviada de forma voluntaria por el usuario que la emitió [5]. ### ¿Estoy protegido si el servicio usa HTTPS? No. Según OWASP, HTTPS por sí solo no protege del CSRF, aunque sigue siendo un requisito previo para que las demás medidas sean fiables [1]. ### ¿El problema viene de mí o de la aplicación? De la aplicación. Microsoft lo dice sin rodeos: las vulnerabilidades CSRF son, en esencia, un problema de la aplicación web, no del usuario final [2]. Los gestos del usuario solo limitan la exposición: cerrar la sesión al terminar y borrar con regularidad las cookies del navegador [2]. ## En la piel del atacante El atacante empieza por localizar una petición que modifica algo en un servicio y luego fabrica una dirección o un script que la reproduce con sus propios valores. OWASP pone el ejemplo de un banco ficticio: la petición legítima transfiere 100 dólares a un beneficiario, y el atacante se pone a sí mismo como beneficiario y aumenta el importe [1]. Falta conseguir que la víctima cargue esa petición mientras tiene la sesión iniciada. Se citan dos métodos: un correo no solicitado con contenido HTML, o una trampa colocada en páginas que la víctima probablemente visite mientras usa su servicio en línea [1]. El ataque también puede quedar almacenado en el propio sitio vulnerable, por ejemplo en un campo que acepta HTML. Entonces resulta más probable: la víctima consulta con más gusto una página del sitio que una página cualquiera de Internet, y además ya tiene allí la sesión iniciada [1]. ## Lo que ve en la pantalla A menudo, nada. El enlace trampa puede disfrazarse de enlace corriente, con un texto como «ver mis fotos». También puede adoptar la forma de una falsa imagen de tamaño cero: si aparece en un correo, la víctima no ve nada, pero el navegador envía igualmente la petición, sin ninguna señal visual de que la operación se ha realizado [1]. ```text Ilustración neutralizada, no es una dirección real. Enlace disfrazado: texto mostrado «Ver mis fotos», dirección oculta hxxp://banque[.]exemple[.]invalid/virement?dest=[cuenta del atacante]&montant=[elevado] Variante: imagen invisible en un correo, cargada sin hacer clic. ``` Si el servicio espera una petición de tipo POST, el atacante puede alojar en su sitio un formulario con campos ocultos. La víctima cree que hace otra cosa y pulsa, o bien un script lo envía automáticamente al cargar la página [1]. En ambos casos, la página que se muestra es corriente y la acción se desarrolla en otra parte. ## Bajo el capó El mecanismo se basa en un comportamiento normal de los navegadores. Guardan las cookies emitidas por una aplicación, entre ellas las cookies de sesión de los usuarios autenticados, y envían todas las cookies de un dominio en cada petición, sea cual sea la forma en que esa petición nació en el navegador [2]. Las cookies no son lo único implicado: las autenticaciones de tipo Basic y Digest también son vulnerables, porque el navegador reenvía automáticamente las credenciales hasta el final de la sesión [2]. Según OWASP, varias ideas de defensa no funcionan [1]: - una cookie secreta, ya que todas las cookies se envían con cada petición; - aceptar solo peticiones POST, ya que basta un formulario oculto para falsificar una; - las transacciones en varios pasos, mientras el atacante pueda prever cada paso; - la sola comprobación de la cabecera Referer, porque puede falsificarse y a veces falta por razones de privacidad. Las protecciones recomendadas, en el lado de la aplicación, son las siguientes. - Comprobar primero si el framework ya ofrece una protección CSRF y usarla. Si no, añadir tokens anti-CSRF a todas las peticiones que modifican el estado y validarlos en el servidor [3]. Sin token, el atacante no puede fabricar una petición válida [3]. - Para el software sin estado, usar una cookie de doble envío, preferiblemente firmada [3]. - Establecer el atributo SameSite en las cookies de sesión [3]. Con el valor strict, el navegador no envía la cookie en las peticiones entre sitios, ni siquiera al seguir un enlace corriente. Con lax, la envía al seguir un enlace desde otro sitio, pero la retiene en los métodos expuestos al CSRF, como POST [4]. Con none, no se ofrece ninguna protección [4]. - Controlar el origen con las cabeceras estándar, en particular Sec-Fetch-Site, compatible con todos los grandes navegadores desde marzo de 2023 [3]. - No usar peticiones GET para operaciones que modifican el estado [3]. Estas medidas tienen límites. SameSite=Lax deja pasar las peticiones GET de navegación de nivel superior: un punto de acceso que modifica el estado mediante GET sigue siendo vulnerable [2]. Los navegadores antiguos pueden no aplicar SameSite [2]. Y un fallo XSS puede eludir todas las protecciones anti-CSRF; el gusano Samy, por ejemplo, usó un XMLHttpRequest para obtener el token CSRF y falsificar peticiones [1][3]. El comportamiento por defecto de SameSite varía: en diciembre de 2024, lax era el valor por defecto de Chrome, Edge y Opera, pero de ninguna versión de Firefox ni de Safari, de ahí el consejo de fijarlo de forma explícita [4]. ## Autopsias ### 2008: el exploit de uTorrent OWASP cita, como ejemplo real de ataque CSRF contra una aplicación que funciona mediante peticiones GET, un exploit dirigido a uTorrent que data de 2008. Se utilizó a gran escala para descargar software malicioso [1]. La fuente no dice más: ni el número de víctimas ni el modo de difusión. ### Fallos catalogados por el CWE (identificadores de 2004 a 2009) El CWE-352 ofrece una lista seleccionada de ejemplos observados, que no es exhaustiva [5]. Varios se basan en una simple URL dentro de una etiqueta img: CVE-2004-1703 y CVE-2004-1995 permiten añadir cuentas de usuario, y CVE-2004-1842 obtener privilegios de administrador [5]. Otros afectan a la propia administración: CVE-2009-3520 permite modificar la contraseña del administrador, y CVE-2009-3759 cambiar contraseñas o apagar una máquina virtual desde una interfaz web [5]. ## Fuentes 1. OWASP, «Cross Site Request Forgery (CSRF) | OWASP Foundation». https://community.owasp.org/attacks/csrf (consultado el 3 de noviembre de 2026) 2. Microsoft, «Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core». https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (consultado el 3 de noviembre de 2026) 3. OWASP, «Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (consultado el 3 de noviembre de 2026) 4. OWASP, «SameSite | OWASP Foundation». https://community.owasp.org/SameSite (consultado el 3 de noviembre de 2026) 5. MITRE, «CWE - CWE-352: Cross-Site Request Forgery (5.0)». https://cwe.mitre.org/data/definitions/352.html (consultado el 3 de noviembre de 2026) --- Fuente original: Cyberpedia, la enciclopedia pública de ciberseguridad e IA publicada por Brain. Versión canónica: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ Puede reutilizar este texto libremente bajo la licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), siempre que cite «Brain, Cyberpedia» con un enlace a la dirección anterior.