Este art\u00edculo explora un analiza CSRF, c\u00f3mo funciona y los pasos que puedes dar para prepararte ante uno.<\/p>\n
Echa un vistazo a nuestra gu\u00eda en v\u00eddeo para entenderlo todo sobre los ataques CSRF<\/a>\u00a0<\/strong><\/p>\n Un ataque de falsificaci\u00f3n de petici\u00f3n en sitios cruzados, tambi\u00e9n conocido como ataque CSRF, enga\u00f1a a un usuario autenticado para que realice acciones no deseadas mediante el env\u00edo de peticiones maliciosas sin que se d\u00e9 cuenta.<\/p>\n Normalmente, un ataque CSRF implica solicitudes de cambio de estado porque el atacante no recibe respuesta. Ejemplos de este tipo de solicitudes son borrar un registro, cambiar una contrase\u00f1a<\/a>, comprar un producto o enviar un mensaje. Todas ellas pueden ocurrir sin el conocimiento del usuario.<\/p>\n El atacante malicioso suele utilizar la ingenier\u00eda social para enviar a un usuario desprevenido un enlace a trav\u00e9s del chat o del correo electr\u00f3nico.<\/p>\n Cuando el usuario hace clic en el enlace, ejecuta los comandos que el atacante establece.<\/p>\n Por ejemplo, hacer clic en un enlace puede transferir fondos de la cuenta de un usuario. O puede cambiar la direcci\u00f3n de correo electr\u00f3nico de un usuario impidi\u00e9ndole recuperar el acceso a la cuenta.<\/p>\n Conseguir que el usuario inicie una solicitud de cambio de estado mientras est\u00e1 conectado es el primer paso y el m\u00e1s crucial en un ataque CSRF. Con los ataques CSRF, el atacante pretende que un usuario autenticado env\u00ede sin saberlo una solicitud web maliciosa a un sitio o aplicaci\u00f3n web. Estas peticiones pueden consistir en cookies, par\u00e1metros de URL<\/a> y otros tipos de datos que al usuario le parecen normales.<\/p>\n Para que un ataque CSRF tenga \u00e9xito, deben darse las siguientes condiciones:<\/p>\n El m\u00e9todo m\u00e1s com\u00fan para completar ataques CSRF es utilizar cookies en aplicaciones con una pol\u00edtica de cookies SameSite d\u00e9bil. Los navegadores web incluyen cookies de forma autom\u00e1tica<\/a> y a menudo an\u00f3nima, y guardan las cookies utilizadas por un dominio en cualquier solicitud web que un usuario env\u00ede a ese dominio.<\/p>\n La pol\u00edtica de cookies SameSite define c\u00f3mo trata la cookie el navegador en contextos de navegaci\u00f3n entre sitios. Si se establece en estricto, la cookie no se comparte en contextos de navegaci\u00f3n entre sitios, lo que evita ataques CSRF. El navegador adjunta la cookie en todos los contextos de navegaci\u00f3n entre sitios si se establece como ninguna. Esto hace que la aplicaci\u00f3n sea vulnerable a los ataques CSRF.<\/p>\n Cuando un usuario env\u00eda sin saberlo una solicitud maliciosa a trav\u00e9s de un navegador web, las cookies guardadas hacen que la solicitud parezca leg\u00edtima al servidor. El servidor responde entonces a la solicitud cambiando la cuenta del usuario, cambiando el estado de la sesi\u00f3n o devolviendo los datos solicitados.<\/p>\n Veamos con m\u00e1s detalle dos ejemplos de v\u00edas de ataque CSRF, una con una solicitud GET y otra con una solicitud POST.<\/p>\n En primer lugar, consideremos una solicitud GET<\/a> utilizada por una aplicaci\u00f3n web de banca financiera, en la que el ataque aprovecha una solicitud GET y la entrega de un hiperv\u00ednculo.<\/p>\n Supongamos que la solicitud GET para transferir dinero tiene el siguiente aspecto:<\/p>\n En la petici\u00f3n aut\u00e9ntica anterior, el usuario solicita transferir 1.000 d\u00f3lares a una cuenta en Aunque esta solicitud es expl\u00edcita, sencilla y pr\u00e1ctica, expone al titular de la cuenta a un ataque CSRF. Esto se debe a que la solicitud no requiere detalles que un atacante pueda desconocer. As\u00ed, para iniciar un ataque, un atacante s\u00f3lo necesitar\u00eda alterar los par\u00e1metros de esta solicitud (el importe y el n\u00famero de cuenta) para crear una solicitud falsificada ejecutable.<\/p>\n La petici\u00f3n maliciosa ser\u00eda efectiva en cualquiera de los usuarios del banco mientras tuvieran sesiones en curso gestionadas por cookies.<\/p>\n As\u00ed es como se ver\u00eda la solicitud falsificada para transferir 500 d\u00f3lares a la cuenta de un hacker (aqu\u00ed, el n\u00famero Una vez hecho esto, el atacante debe idear una forma de enga\u00f1ar al usuario para que env\u00ede esta solicitud mientras est\u00e1 conectado a su aplicaci\u00f3n de banca online. Una de las formas de hacerlo es crear un hiperv\u00ednculo inofensivo que llame la atenci\u00f3n del usuario. El enlace puede tener este aspecto:<\/p>\n Dado que el atacante ha encontrado las direcciones de correo electr\u00f3nico correctas<\/a> de sus objetivos, puede enviar esto por correo electr\u00f3nico a muchos clientes del banco. Aquellos que hagan clic en el enlace mientras est\u00e1n conectados, activar\u00edan la petici\u00f3n de enviar al atacante 500 d\u00f3lares desde la cuenta conectada.<\/p>\n Veamos c\u00f3mo la misma instituci\u00f3n financiera experimentar\u00eda un CSRF si s\u00f3lo aceptara peticiones POST<\/a>. En este caso, el env\u00edo de hiperv\u00ednculos utilizado en el ejemplo de solicitud GET no funcionar\u00eda. Por lo tanto, un ataque CSRF con \u00e9xito requerir\u00eda que un atacante creara un formulario HTML. La solicitud aut\u00e9ntica para enviar 1.000 d\u00f3lares por un producto adquirido tendr\u00eda este aspecto:<\/p>\n Esta solicitud POST requiere una cookie para determinar la identidad del usuario, la cantidad que desea enviar y la cuenta a la que desea enviar. Los atacantes pueden alterar esta solicitud para realizar un ataque CSRF.<\/p>\n El atacante s\u00f3lo debe a\u00f1adir una cookie aut\u00e9ntica a una solicitud falsificada para que el servidor procese la transferencia. Pueden hacerlo creando un hiperv\u00ednculo de aspecto inofensivo que lleve al usuario a una p\u00e1gina web desencadenante con el siguiente aspecto:<\/p>\n Ya hemos establecido los par\u00e1metros de importe y cuenta en el formulario anterior. Una vez que un usuario autenticado visita la p\u00e1gina, el navegador a\u00f1ade la cookie de sesi\u00f3n antes de reenviar la solicitud al servidor. El servidor reenv\u00eda entonces 500 d\u00f3lares a la cuenta del hacker.<\/p>\n Existen varios m\u00e9todos para prevenir y mitigar dr\u00e1sticamente los posibles ataques CSRF en tu sitio o aplicaci\u00f3n web, entre ellos:<\/p>\n Un sitio web seguro frente a CSRF asigna a cada sesi\u00f3n un token \u00fanico y lo comparte con el servidor y el navegador<\/a> del cliente. Cada vez que un navegador env\u00eda una solicitud sensible, el servidor espera que contenga el token CSRF asignado. Si contiene un token incorrecto, el servidor lo descarta. El token CSRF no se almacena en las cookies de sesi\u00f3n del navegador del cliente por motivos de seguridad.<\/p>\n Aunque los tokens CSRF son una excelente medida de seguridad, este m\u00e9todo no es 100% a prueba de ataques. Algunas de las vulnerabilidades que acompa\u00f1an a los tokens CSRF son:<\/p>\n Un atacante s\u00f3lo necesita eliminar el token y enviarlo as\u00ed para ejecutar el ataque:<\/p>\n Un atacante puede entrar en una aplicaci\u00f3n utilizando su cuenta para obtener un token, como por ejemplo:<\/p>\n Y como los tokens est\u00e1n agrupados, el atacante puede copiar y utilizar ese mismo token para iniciar sesi\u00f3n en una cuenta de usuario diferente, ya que volver\u00e1 a utilizarlo:<\/p>\n As\u00ed, un atacante puede entrar en una aplicaci\u00f3n utilizando su cuenta y abrir el archivo cookie para ver lo siguiente:<\/p>\n A continuaci\u00f3n, pueden utilizar esta informaci\u00f3n para crear otra cookie y completar el ataque<\/p>\n Otra estrategia para prevenir los ataques CSRF es utilizar el encabezado referrer. En HTTP, los encabezados referrer indican el origen de las peticiones. Suelen utilizarse para realizar an\u00e1lisis<\/a>, optimizaci\u00f3n y registro.<\/p>\n Tambi\u00e9n puedes activar la comprobaci\u00f3n de los encabezados de referencia en el lado del servidor para evitar ataques CSRF. El lado del servidor comprueba el origen de la solicitud y determina el origen de destino de la solicitud. Si coinciden, se permite la solicitud. Si no coinciden, el servidor rechaza la solicitud.<\/p>\n Utilizar cabeceras de referencia es mucho m\u00e1s f\u00e1cil que utilizar tokens porque no requiere la identificaci\u00f3n individual del usuario.<\/p>\n Al igual que los tokens CSRF, los encabezados de referencia tienen algunas vulnerabilidades importantes.<\/p>\n En primer lugar, las cabeceras de referencia no son obligatorias, y algunos sitios enviar\u00e1n solicitudes sin ellas. Si el CSRF no tiene la pol\u00edtica necesaria para gestionar solicitudes sin encabezado, los atacantes pueden utilizar solicitudes sin encabezado para ejecutar ataques de cambio de estado.<\/p>\n Adem\u00e1s, este m\u00e9todo ha perdido eficacia con la reciente introducci\u00f3n de la pol\u00edtica de referencia<\/a>. Esta especificaci\u00f3n evita la filtraci\u00f3n de URL a otros dominios, dando a los usuarios m\u00e1s control sobre la informaci\u00f3n de la cabecera de referencia. Pueden elegir exponer parte de la informaci\u00f3n de la cabecera de referencia o desactivarla a\u00f1adiendo una etiqueta de metadatos en la p\u00e1gina HTML, como se muestra a continuaci\u00f3n:<\/p>\n El c\u00f3digo anterior elimina el encabezado de referencia para todas las peticiones de esta p\u00e1gina. Hacer esto dificulta que las aplicaciones que dependen de las cabeceras de referencia eviten ataques CSRF desde dicha p\u00e1gina.<\/p>\n Adem\u00e1s de utilizar la cabecera referrer y los tokens CSRF, existe una tercera opci\u00f3n mucho m\u00e1s sencilla: elegir un servicio de alojamiento seguro como Kinsta<\/a>\u00a0para tus sitios y aplicaciones web proporciona una barrera mucho m\u00e1s fuerte y segura entre los atacantes y tus usuarios.<\/p>\n Adem\u00e1s de las funciones de seguridad cr\u00edticas, como las copias de seguridad autom\u00e1ticas<\/a>, la autenticaci\u00f3n de dos factores<\/a> y los protocolos SFTP sobre SSH<\/a>, la integraci\u00f3n con Cloudflare de Kinsta<\/a>\u00a0proporciona una protecci\u00f3n de nivel empresarial con protecci\u00f3n basada en IP y cortafuegos.<\/p>\n En concreto, Kinsta cuenta actualmente con unas 60 reglas de cortafuegos personalizadas para ayudar a prevenir ataques maliciosos y hacer frente a vulnerabilidades graves no autenticadas en plugins y temas, incluidas las espec\u00edficas que buscan vulnerabilidades CSRF.<\/p>\n La falsificaci\u00f3n de petici\u00f3n en sitios cruzados (CSRF) es un ataque que enga\u00f1a a usuarios autenticados para que inicien peticiones de cambio de estado de forma no intencionada. Su objetivo es que las aplicaciones que no pueden diferenciar entre solicitudes de cambio de estado v\u00e1lidas y falsificadas.<\/p>\n El CSRF s\u00f3lo puede tener \u00e9xito en aplicaciones que dependen de las cookies de sesi\u00f3n para identificar a los usuarios registrados y que tienen una pol\u00edtica de cookies SameSite d\u00e9bil. Tambi\u00e9n necesitan un servidor que acepte peticiones que no contengan par\u00e1metros desconocidos, como contrase\u00f1as. Los hackers pueden enviar ataques maliciosos utilizando GET o POST.<\/p>\n Aunque el uso de tokens CSRF o la aplicaci\u00f3n de la verificaci\u00f3n del encabezado de referencia pueden evitar algunos ataques CSRF, ambas medidas tienen vulnerabilidades potenciales que pueden hacer que tus medidas preventivas sean in\u00fatiles si no tienes cuidado.<\/p>\n\u00bfQu\u00e9 Es un Ataque CSRF?<\/h2>\n
![\"C\u00f3mo](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
\u00bfC\u00f3mo Funciona un Ataque CSRF?<\/h2>\n
\n
CSRF para una Solicitud GET<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n547895<\/code> como pago por los productos adquiridos.<\/p>\n654585<\/code>). Ten en cuenta que el ejemplo de abajo es una versi\u00f3n muy simplificada de los pasos que hay que seguir en un ataque CSRF para obtener una explicaci\u00f3n.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF para una Solicitud POST<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 Formas de Abatir los Ataques CSRF<\/h2>\n
\n
C\u00f3mo Prevenir los Ataques CSRF Utilizando Tokens CSRF<\/h2>\n
Vulnerabilidades potenciales de los tokens CSRF<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
C\u00f3mo Prevenir los Ataques CSRF con el Encabezado Referrer<\/h2>\n
Vulnerabilidades potenciales del encabezado de referencia<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nC\u00f3mo Protege Kinsta Contra los Ataques CSRF<\/h2>\n
Resumen<\/h2>\n