Falsificación de solicitudes entre sitios (CSRF) De OWASP Se trata de un ataque . Para ver todos los ataques, consulte la página Categoría de ataque .
Última revisión (mm / dd / aa): 03/6/2018
Visión de conjunto La Falsificación Falsificación de solicitudes entre sitios (CSRF) es un ataque que obliga al usuario final final a ejecutar acciones no deseadas deseadas en una aplicación web en la que está autenticado actualmente. Los ataques CSRF CSRF se dirigen específ icamente icamente a las las solicitudes que cambian el estado, no al robo de datos, ya que el atacante no tiene forma de ver la la respuesta a la solicitud falsificada. Con un poco de ayuda de ingeniería social (como (como enviar un enlace por corr eo eo electrónico o chat), un atacante puede engañar a los usuarios de una aplicación we b para que ejecuten las acciones acciones que el atacante elija. Si la víctima es un usuario normal, un ataque CSRF exitoso puede exitoso puede obligar al usuario a realizar realizar solicitudes de cambio de estado, como transferir fondos, cambiar su dirección de correo electrónico, etc. Si la víctima la víctima es una cuenta administrativa, CSRF puede comprometer toda la aplicación web. web.
Actividades de seguridad relacionadas relacionadas Cómo revisar revisar el código para las vulnera vulnerabilidades bilidades de CSRF
Consulte el artículo de la Guía de revisión de códigos de OWASP sobre cómo revisar el código para las vulnerabilidades de CSRF CSRF . Cómo probar vulnerabilidades de CSRF
Consulte Con sulte el artículo de la Guía de pruebas de OW OWASP ASP sobre cómo probar las vulnerabilidades vulnerabilidades de CSRF . Cómo prevenir vulnerabilidades CSRF
Consulte la Hoja de información sobre prevención de CSRF para conocer las medidas de prevención. Escuche el Podcast CSRF Top 10 de OW OWASP ASP (http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3) . La mayoría de los marcos tienen soporte CSRF incorporado como Joomla (http://docs.joomla.org/How_to_add_CSRF_anti-spoofing_to_forms) , Spring (http://blog.eyallupu.com/2012/04/csrf-defense-in-spring-mvc-31.html) , Struts (http://web.securityinnovation.com/appsec-weekly/blog/bid/84318/Cross-Site-Request-Forgery-CSRF-PreventionUsing-Struts-2) , Ruby on Rails (http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf) , .NET (http://www.troyhunt.com/2010/11/owasp-top-10-for-net-developers-part-5.html) y otros. Utilice OWASP CSRF CSRF Guard Guard para agregar protección CSRF a sus a sus aplicaciones aplicaciones Java. Puede usar CSRFProtector Project para proteger sus aplicaciones php o cualquier proyecto implementado usando Apache Server. También hay un .Net CSRF Guard en OWASP OWASP,, pero es antiguo y no parece completo. John Melton también tiene una excelente publicación en el blog que (http://www.jtmelton.com/2010/05/16/the(http://www.jtmelton.com/2010/05/16/theowasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/) describe cómo utilizar la funcionalidad nativa anti-CSRF de OW OWASP ASP ESAPI (http://www.owasp.org/index.php/Category:OW (http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API) ASP_Enterprise_Security_API) .
Descripción CSRF es un ataque que engaña a la víctima para que envíe una solicitud maliciosa. Hereda la identidad y los privilegios de la víctima para realizar una función no deseada d eseada en nombre de la víctima. Para la mayoría de los sitios, las solicitudes del navegador incluyen automáticamente las credenciales asociadas con el sitio, como la cookie de sesión del usuario, la dirección IP, IP, las credenciales del dominio de Windows, etc. Por lo tanto, si el usuario está autenticado actualmente en el sitio, el sitio no tendrá forma de distinguir entre la solicitud falsificada enviada por la víctima y una solicitud legítima enviada por la víctima. CSRF ataca la funcionalidad de destino que causa un cambio de estado en el servidor, como cambiar la dirección de correo electrónico o la contraseña de la víctima o comprar algo. Obligar a la víctima a recuperar datos no beneficia a un atacante porque el atacante no recibe la respuesta, la víctima sí. Como tal, los ataques CSRF se
dirigen a las solicitudes que cambian el estado. A veces es posible almacenar el ataque CSRF en el sitio vulnerable en sí. Tales vulnerabilidades se llaman "fallas CSRF almacenadas". Esto se puede lograr simplemente almacenando una etiqueta IMG o IFRAME en un campo que acepta HTML, o mediante un ataque de scripting entre sitios más complejo. Si el ataque puede almacenar un ataque CSRF en el sitio, la gravedad del ataque se amplifica. En particular, la probabilidad aumenta porque es más probable que la víctima vea la página que contiene el ataque que alguna página aleatoria en Internet. La probabilidad también se incrementa porque la víctima ya está autenticada en el sitio. Sinónimos
Los ataques CSRF también son conocidos por varios otros nombres, incluyendo XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery y Hostile Linking. Microsoft se refiere a este tipo de ataque como un ataque OneClick en su proceso de modelado de amenazas y muchos lugares en su documentación en línea. Medidas de prevención que NO funcionan
Usando una cookie secreta Recuerde que todas las cookies, incluso las secretas , se enviarán con cada solicitud. Todos los tokens de autenticación se enviarán independientemente de si el usuario final fue engañado o no para enviar la solicitud. Además, el contenedor de la aplicación simplemente utiliza los identificadores de sesión para asociar la solicitud con un objeto de sesión específico. El identificador de sesión no verifica que el usuario final tenga la intención de enviar la solicitud.
Solo acepta solicitudes POST Las aplicaciones pueden desarrollarse solo para aceptar solicitudes POST para la ejecución de la lógica comercial. La idea errónea es que, como el atacante no puede construir un enlace malicioso, no se puede ejecutar un ataque CSRF. Desafortunadamente, esta lógica es incorrecta. Existen numerosos métodos en los que un atacante puede engañar a una víctima para que envíe una solicitud POST falsificada, como un formulario simple alojado en el sitio web de un atacante con valores ocultos. Esta forma puede ser activada automáticamente por JavaScript o puede ser activada por la víctima que piensa que la forma hará otra cosa. Se han desarrollado varias ideas erróneas para defenderse contra los ataques de CSRF a lo largo del tiempo. Aquí hay algunos que te recomendamos que evites.
Transacciones de varios pasos Las transacciones de varios pasos no son una prevención adecuada de CSRF. Siempre que un atacante pueda predecir o deducir cada paso de la transacción completada, entonces CSRF es posible.
Reescritura de URL Esto podría verse como una técnica de prevención de CSRF útil ya que el atacante no puede adivinar la ID de la sesión de la víctima. Sin embargo, la ID de la sesión del usuario está expuesta en la URL. No recomendamos corregir un defecto de seguridad introduciendo otro.
HTTPS HTTPS por sí mismo no hace nada para defenderse contra CSRF. Sin embargo, HTTPS debe considerarse un requisito previo para que cualquier medida preventiva sea confiable.
Ejemplos ¿Cómo funciona el ataque?
Existen numerosas formas en que un usuario final puede ser engañado para que cargue información o envíe información a una aplicación web. Para ejecutar un ataque, primero debemos entender cómo generar una solicitud maliciosa válida para que se ejecute nuestra víctima. Consideremos el siguiente ejemplo: Alice desea transferir $ 100 a Bob utilizando la aplicación web bank.com que es vulnerable a CSRF. María, una atacante, quiere engañar a Alice para que le envíe el dinero. El ataque comprenderá los siguientes pasos:
1. construir una URL de explotación o script 2. engañando a Alice para que ejecute la acción con ingeniería social Escenario GET
Si la aplicación fue diseñada para usar principalmente solicitudes GET para transferir parámetros y ejecutar acciones, la operación de transferencia de dinero podría reducirse a una solicitud como: OBTENER http://bank.com/transfer.do?acct=BOB&amount=100 HTTP / 1.1
María ahora decide explotar esta vulnerabilidad de la aplicación web usando a Alice como su víctima. Maria primero construye la siguiente URL de explotación que transferirá $ 100,000 de la cuenta de Alice a su cuenta. Toma el URL del comando original y reemplaza el nombre del beneficiario consigo mismo, elevando el monto de la transferencia significativamente al mismo tiempo: http://bank.com/transfer.do?acct=MARIA&amount=100000
El aspecto de ingeniería social del ataque engaña a Alice para que cargue esta URL cuando inicia sesión en la aplicación del banco. Esto generalmente se hace con una de las siguientes técnicas: enviar un correo electrónico no solicitado con contenido HTML plantar una URL de explotación o una secuencia de comandos en páginas que puedan ser visitadas por la víctima mientras también realizan banca en línea La URL de explotación puede disfrazarse como un enlace común, lo que anima a la víctima a hacer clic en él:
¡Ver mis imágenes!
O como una imagen falsa de 0x0:
Si esta etiqueta de imagen se incluyera en el correo electrónico, Alice no vería nada. Sin embargo, el navegador aún enviará la solicitud a bank.com sin ninguna indicación visual de que la transferencia haya tenido lugar. Un ejemplo real de ataque CSRF en una aplicación que utiliza GET fue un exploit uTorrent (https://www.ghacks.net/2008/01/17/dos-vulnerability-in-utorrent-and-bittorrent/) de 2008 que se usó a gran escala para descargar malware. Escenario POST
La única diferencia entre los ataques GET y POST es cómo la víctima está ejecutando el ataque. Supongamos que el banco ahora usa POST y la solicitud vulnerable se ve así: POST http://bank.com/transfer.do HTTP / 1.1 acct = BOB y cantidad = 100
Dicha solicitud no se puede entregar utilizando etiquetas estándar A o IMG, pero se puede entregar utilizando una etiqueta FORM:
