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 de solicitudes entre sitios (CSRF) es un ataque que obliga al usuario final a ejecutar acciones no
deseadas en una aplicación web en la que está autenticado actualmente. Los ataques CSRF se dirigen
específicamente a las solicitudes que cambian el estado, no al robo de datos, ya que el atacante no tiene forma de
ver la respuesta a la solicitud falsificada. Con un poco de ayuda de ingeniería social (como enviar un enlace por
correo electrónico o chat), un atacante puede engañar a los usuarios de una aplicación web para que ejecuten las
acciones que el atacante elija. Si la víctima es un usuario normal, un ataque CSRF exitoso puede obligar al usuario
a realizar solicitudes de cambio de estado, como transferir fondos, cambiar su dirección de correo electrónico, etc.
Si la víctima es una cuenta administrativa, CSRF puede comprometer toda la aplicación web.

Actividades de seguridad relacionadas

Cómo revisar el código para las vulnerabilidades 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 .

Cómo probar vulnerabilidades de CSRF

Consulte el artículo de la Guía de pruebas de OWASP sobre cómo probar las 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 OWASP (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-Prevention-
Using-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 Guard para agregar protección CSRF a sus 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, 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-
owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/) describe cómo utilizar la funcionalidad nativa
anti-CSRF de OWASP ESAPI (http://www.owasp.org/index.php/Category:OWASP_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 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, 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 One-
Click 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:

<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000"> ¡Ver mis imágenes! </a>

O como una imagen falsa de 0x0:

<img src = "http://bank.com/transfer.do?acct=MARIA&amount=100000" width = "0" height = "0" border = "0">

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:

<form action = "<nowiki> http://bank.com/transfer.do </ nowiki>" method = "POST">

<input type = "hidden" name = "acct" value = "MARIA" />
<input type = "hidden" name = "amount" value = "100000" />
<input type = "submit" value = "Ver mis imágenes" />
</ form>

Este formulario requerirá que el usuario haga clic en el botón de enviar, pero esto también se puede ejecutar
automáticamente usando JavaScript:

<body onload = "document.forms [0] .submit ()">

<formulario ...
Otros métodos HTTP

Las API modernas de aplicaciones web utilizan con frecuencia otros métodos HTTP, como PUT o DELETE.
Supongamos que el banco vulnerable usa PUT que toma un bloque JSON como argumento:

PUT http://bank.com/transfer.do HTTP / 1.1

{"acct": "BOB", "cantidad": 100}

Dichas solicitudes se pueden ejecutar con JavaScript incrustado en una página de exploit:

<script>
función put () {
var x = new XMLHttpRequest ();
x.open ("PUT", "http://bank.com/transfer.do", verdadero);
x.setRequestHeader ("Content-Type", "application / json");
x.send (JSON.stringify ({"acct": "BOB", "cantidad": 100}));
}
</ script>
<body onload = "put ()">

Afortunadamente, esta solicitud no será ejecutada por los navegadores web modernos gracias a las restricciones de
política del mismo origen . Esta restricción está habilitada de manera predeterminada a menos que el sitio web
objetivo abra explícitamente las solicitudes de origen cruzado del origen del atacante (o de todos) utilizando CORS
con el siguiente encabezado:

Access-Control-Allow-Origin: *

Ataques relacionados
Cross-site Scripting (XSS)
Manipulación del historial del sitio cruzado (XSHM)

Controles relacionados
Agregue un nonce por solicitud a la URL y a todos los formularios además de la sesión estándar. Esto
también se conoce como "claves de formulario". Muchos marcos (por ejemplo, Drupal.org 4.7.4+) tienen o
están empezando a incluir este tipo de protección "integrada" en cada formulario, por lo que el programador
no necesita codificar esta protección de forma manual.
Agregue un hash (ID de sesión, nombre de función, secreto del lado del servidor) a todos los formularios.
Para .NET, agregue un identificador de sesión a ViewState con MAC (descrito en detalle en la Hoja de
referencia de prevención de CSRF ).
Verificar el encabezado de referencia en la solicitud HTTP del cliente puede prevenir ataques CSRF.
Asegurar que la solicitud HTTP provenga del sitio original significa que los ataques de otros sitios no
funcionarán. Es muy común ver las comprobaciones de encabezado de referencia utilizadas en el hardware
de red incorporado debido a limitaciones de memoria.
XSS se puede utilizar para eludir simultáneamente las comprobaciones basadas en referencias y token.
Por ejemplo, el gusano Samy (http://en.wikipedia.org/wiki/Samy_%28computer_worm%29) usó un
XHR para obtener el token CSRF para forjar las solicitudes.
"Aunque CSRF es fundamentalmente un problema con la aplicación web, no el usuario, los usuarios pueden
ayudar a proteger sus cuentas en sitios mal diseñados cerrando sesión en el sitio antes de visitar otro, o borrar
las cookies de su navegador al final de cada sesión del navegador". - http://en.wikipedia.org/wiki/Cross-
site_request_forgery#_note-1
Tokenizing

Referencias
Hoja de referencia de prevención de falsificación de solicitudes entre sitios de OWASP (CSRF)

Preguntas frecuentes sobre falsificación de solicitudes entre sitios (CSRF / XSRF)

(http://www.cgisecurity.com/articles/csrf-faq.shtml)

Cita: "Este documento sirve como documento vivo para cuestiones de falsificación de solicitudes entre
sitios. Este documento servirá como un depósito de información de documentos existentes, conversaciones y
publicaciones de listas de correo y se actualizará a medida que se descubra nueva información".

Pruebas para CSRF

 Rol CSRF (también conocido como Session riding) del proyecto OWASP Testing Guide.

Vulnerabilidad de CSRF: un 'gigante dormido' (http://www.darkreading.com/document.asp?

doc_id=107651&WT.svl=news1_2)

Papel general

Protección del cliente frente a la sesión de equitación

(http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf)

Martin Johns y el interesante trabajo y presentación de Justus Winter para la 4ª Conferencia AppSec de
OWASP que describieron las posibles técnicas que los navegadores podrían adoptar para proporcionar
automáticamente protección CSRF - Documento PDF
(http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf)

Guardia OWASP CSRF

J2EE, .NET y PHP Filters que añaden un token de solicitud único a cada formulario y un enlace en la
respuesta HTML para proporcionar cobertura universal contra CSRF en toda su aplicación.

Protector CSRF de OWASP

Método Anti CSRF para mitigar CSRF en aplicaciones web. Actualmente implementado como una
biblioteca PHP y módulo Apache 2.xx

Un hecho muy descuidado sobre la falsificación de solicitudes cruzadas (CSRF)

(http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf)

Aung Khant, http://yehg.net , explicó el peligro y el impacto de CSRF con escenarios de peligro.

Probador de CSRF de OWASP

El OWASP CSRFTester brinda a los desarrolladores la capacidad de probar sus aplicaciones para detectar
fallas CSRF.

Herramienta Pinata-CSRF: herramienta CSRF POC (http://code.google.com/p/pinata-csrf-tool/)

Pinata hace que sea fácil crear páginas de prueba de concepto de CSRF. Ayuda en la evaluación de
vulnerabilidad de aplicaciones.

Obtenido de " https://www.owasp.org/index.php?title=Cross-Site_Request_Forgery_(CSRF)&oldid=238390 "

Categorías : Proyecto ASDR de OWASP Explotación de la autenticación Código malicioso incrustado

Spoofing Ataque

Esta página fue modificada por última vez el 6 de marzo de 2018, a las 15:52.
El contenido está disponible bajo Creative Commons Attribution-ShareAlike a menos que se indique lo
contrario.