CROSS-SITE REQUEST FORGERY

Un ataque de falsificación de solicitud entre sitios (CSRF) ocurre cuando un atacante puede hacer que el navegador de un objetivo envíe una solicitud HTTP a otro sitio web. Ese sitio web luego realiza una acción como si la solicitud fuera válida y enviada por el objetivo. Tal ataque generalmente se basa en que el destino es previamente autentificado en el sitio web vulnerable donde la acción es enviada y ocurre sin el conocimiento del objetivo. Cuando un ataque CSRF tiene éxito, el atacante puede modificar la información del lado del servidor e incluso puede apoderarse de la cuenta de un usuario. Aquí hay un ejemplo básico, que veremos en breve:

  1. Bob inicia sesión en su sitio web bancario para verificar su saldo.
  2. Cuando termina, Bob revisa su cuenta de correo electrónico en un dominio.
  3. Bob tiene un correo electrónico con un vínculo a un sitio web desconocido y hace clic en enlace para ver a dónde conduce.
  4. Cuando se carga, el sitio desconocido indica al navegador de Bob que cree una solicitud HTTP al sitio web bancario de Bob, solicitando una transferencia de dinero de su cuenta a la del atacante.
  5. El sitio web bancario de Bob recibe la solicitud HTTP iniciada desde el sitio web desconocido (y malicioso). Pero debido a que el sitio web bancario no tiene ninguna protección CSRF, procesa la transferencia.

autentificacion

Los ataques CRSF, como el que acabo de describir, aprovechan las debilidades en el proceso que utilizan los sitios web para autenticar solicitudes. Cuando visitas un sitio web
que requiere que inicie sesión, generalmente con un nombre de usuario y contraseña, ese sitio normalmente te autentificará. El sitio almacenará esa autentificación en su navegador para que no tenga que iniciar sesión cada vez que visite una página nueva
en ese sitio. Puede almacenar la autenticación de dos formas: utilizando el básico protocolo de autenticación o una cookie.
Puede identificar un sitio que utiliza autorización básica cuando las solicitudes HTTP incluyen un encabezado que se ve así:

Autorización: Basic QWxhZGRpbjpPcGVuU2VzYW1l

La cadena de aspecto aleatorio es un nombre de usuario y contraseña codificados en base64 separados por dos puntos. En este caso, QWxhZGRpbjpPcGVuU2VzYW1l decodifica a Aladdin: OpenSesame. No nos enfocaremos sobre la autentificación básica en este post, pero puede utilizar muchas de las técnicas cubiertas aquí para explotar las vulnerabilidades CSRF que utilizan autentificación.
Las cookies son pequeños archivos que los sitios web crean y almacenan en el navegador. Los sitios web utilizan cookies para diversos fines, como almacenar información como las preferencias del usuario o el historial de visitas del usuario a un sitio web.
Las cookies tienen ciertos atributos, que son piezas de información estandarizadas. Esos detalles informan a los navegadores sobre las cookies y cómo tratarlas. Algunos atributos de cookies pueden incluir domain, expires, max-age, secure y
httponly, que aprenderá más adelante en este post. Además de los atributos, las cookies pueden contener un par de nombre/valor, que consta de un identificador y un valor asociado que se pasa a un sitio web (el atributo de dominio de la cookie define el sitio al que pasar esta información). Los navegadores definen la cantidad de cookies que puede establecer un sitio. Pero normalmente los sitios individuales pueden establecer entre 50 y 150 cookies en navegadores comunes, y algunos, según se informa, admiten más de 600. Los navegadores generalmente permiten que los sitios puedan utilizar un máximo de 4 KB por cookie. No existe un estándar para los nombres de las cookies o sus valores: los sitios son libres de elegir sus propios pares de nombre/valor y propósitos.
Por ejemplo, un sitio podría usar una cookie llamada sessionId para recordar que usuario es en lugar de que ingrese su nombre de usuario y contraseña para cada página que visitan o cada acción que realizan. (Recuerde que las solicitudes HTTP son sin estado, como se describe en un post anterior. Sin estado significa que con cada solicitud HTTP, un sitio web no sabe quién es un usuario, por lo que debe volver a autenticar que
usuario para cada solicitud.)

Como ejemplo, un par de nombre/valor en una cookie podría ser

sessionId = 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

y la cookie podría tener un dominio de <site>.com. En consecuencia, la cookie sessionId será enviado a cada site.com que visita un usuario, como foo.<site>.com, bar.<site>.com,
http://www.<site>.com, y así sucesivamente.
Los atributos de seguridad y de HTTP le indican a los navegadores cuándo y cómo enviar
y leer cookies. Estos atributos no contienen valores; en cambio, actúan como flags que están presentes en la cookie o no. Cuando una cookie contiene el atributo seguro, los navegadores solo enviarán esa cookie cuando visitan sitios HTTPS. Por ejemplo, si visitó http://www.<site&gt;.com / (un Sitio HTTP) con una cookie segura, su navegador no enviaría la cookie a ese sitio. El motivo es proteger su privacidad, porque las conexiones HTTPS están encriptadas y las conexiones HTTP no. El atributo httponly, que será importante cuando aprenda a utilizar XSS entre sitios, le dice al navegador que lea una cookie solo a través de HTTP y solicitudes HTTPS. Por lo tanto, los navegadores no permitirán ningún lenguaje de Scripting como JavaScript, para leer el valor de esa cookie. Cuando secure y httponly no está configurados en las cookies, esas cookies podrían enviarse legítimamente pero leidas maliciosamente. Se puede enviar una cookie sin el atributo seguro a un sitio que no es HTTPS; Del mismo modo, una cookie sin la configuración de httpponly puede ser leída por JavaScript.
Los atributos expires y max-age indican cuándo debe expirar una cookie y el navegador debería destruirlo. El atributo expires simplemente le dice al navegador cuando destruir una cookie. Por ejemplo, una cookie podría establecer el atributo expires en Wed, 18 Dec 2019 12:00:00 UTC. En contraste, el max-age es el número de segundos hasta que la cookie caduca y se formatea como un número entero (max-age = 300). En resumen, si el sitio bancario que visita Bob utiliza cookies, el sitio almacenará su autentificación con el siguiente proceso. Una vez que Bob visita el sitio e inicia sesión, el banco responderá a su solicitud HTTP con una respuesta HTTP, que incluye una cookie que identifica a Bob. A su vez, el navegador de Bob enviará automáticamente esa cookie con todas las demás solicitudes HTTP al sitio web bancario. Después de terminar sus operaciones bancarias, Bob no cierra la sesión cuando deja el sitio web bancario. Tenga en cuenta este importante detalle, porque cuando cierra la sesión un sitio, ese sitio normalmente responderá con una respuesta HTTP que expira su cookie. Como resultado, cuando vuelva a visitar el sitio, deberá iniciar sesión nuevamente. Cuando Bob revisa su correo electrónico y hace clic en el enlace para visitar el sitio desconocido, inadvertidamente está visitando un sitio web malicioso. Ese sitio web está diseñado para realizar un ataque CSRF indicando al navegador de Bob que realice una solicitud a su sitio web bancario. Esta solicitud también enviará cookies desde su navegador.

csrf con solicitudes get

La forma en que el sitio malicioso explota el sitio bancario de Bob depende de si el banco acepta transferencias a través de solicitudes GET o POST. Si el sitio bancario de Bob acepta transferencias a través de solicitudes GET, el sitio malicioso enviará la solicitud HTTP con un formulario oculto o con una etiqueta <img> . Los métodos GET y POST se basan en HTML para que los navegadores envíen la solicitud HTTP requerida, y ambos métodos pueden usar la técnica del formulario oculto, pero solo el método GET puede usar la técnica de etiqueta <img> . En esta sección, veremos cómo el ataque funciona con la técnica de etiqueta <img> cuando se usa GET, y veremos la técnica de formulario oculto en la siguiente sección, “CSRF con solicitudes POST“.
El atacante debe incluir las cookies de Bob en cualquier transferencia de solicitud HTTP
al sitio web bancario de Bob. Pero como el atacante no tiene forma de leer las cookies de Bob, el atacante no puede simplemente crear una solicitud HTTP y enviarselo al sitio bancario. En su lugar, el atacante puede usar la etiqueta <img> para crear una solicitud GET que también incluya las cookies de Bob. Una etiqueta <img> renderiza imágenes en una página web e incluye un atributo src, que dice a los navegadores donde localizar archivos de imagen. Cuando un navegador muestra una etiqueta <img>, hará una solicitud GET al atributo src en la etiqueta e incluirá cualquier cookie existente en esa solicitud. Digamos que el sitio malicioso usa una URL como la siguiente que transfiere 500$ de Bob a Joe:

https://www.bank.com/transfer?from=bob&to=joe&amount=500

Entonces, la etiqueta <img> maliciosa usaría esta URL como su valor de origen, como
en la siguiente etiqueta:

<img src="https://www.bank.com/transfer?from=bob&to=joe&amount=500">

Como resultado, cuando Bob visita el sitio propiedad del atacante, incluye la etiqueta <img> en su respuesta HTTP, y el navegador luego realiza una solicitud GET al banco. El navegador envía las cookies de autenticación de Bob para obtener lo que cree que debería ser una imagen. Pero, de hecho, el banco recibe la peticion, procesa la URL en el atributo src de la etiqueta y crea la solicitud de transferencia. Para evitar esta vulnerabilidad, los desarrolladores nunca deben usar la solicitud GET para realizar cualquier solicitud de modificación de datos de back-end, como la transferencia de dinero. Pero cualquier solicitud que sea de solo lectura debería ser segura. Muchos frameworks web comunes utilizados para crear sitios web, como Ruby on Rails o Django esperan que los desarrolladores siguan este principio y, por lo tanto, agregarán automáticamente protecciones CSRF a las solicitudes POST, pero no a las solicitudes GET.

csrf con solicitudes post

Si el banco realiza transferencias con solicitudes POST, deberá utilizar un enfoque diferente para crear un ataque CSRF. Un atacante quizas no pudo usar una etiqueta <img>, porque una etiqueta <img> no puede invocar una solicitud POST. En cambio, la estrategia del atacante dependerá del contenido de la solicitud POST. La situación más simple implica una solicitud POST con el type-content:application/x-www-form-urlencoded o text/plain. El tipo de contenido es un encabezado que los navegadores pueden incluir al enviar solicitudes HTTP. El encabezado le dice al destinatario cómo se codifica el cuerpo de la solicitud HTTP. Aquí está un ejemplo de una solicitud de tipo content-type sin formato:

POST / HTTP/1.1
Host: www.google.ca
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Content-Length: 5
Content-Type: text/plain;charset=UTF-8
DNT: 1
Connection: close
hello

El content-type y su tipo aparece junto con la codificación de caracteres de la solicitud. El tipo de contenido es importante porque los navegadores tratan los tipos de manera diferente (lo que abordaré en un segundo). En esta situación, es posible que un sitio malintencionado cree un formulario HTML y se lo envíe silenciosamente al sitio vulnerable sin el conocimiento del objetivo. El formulario puede enviar una solicitud POST o GET a una URL y incluso puede enviar valores de parámetros. A continuación se muestra un ejemplo de algunos códigos en el sitio web al que el enlace malicioso dirigiría a Bob:

Aquí, estamos realizando una solicitud HTTP POST (2) al banco de Bob con un formulario
(que se indica mediante el atributo action en la etiqueta <form>). Ya que el atacante no quiere que Bob vea el formulario, cada uno de los elementos <input> se les da el tipo ‘hidden‘, lo que los hace invisibles en la página web. Como paso final, el atacante incluye algo de JavaScript dentro de una etiqueta <script> para enviar automáticamente el formulario cuando se carga la página (4). JavaScript hace esto llamando al método getElementByID () en el documento HTML con el ID del formulario (“csrf-form“) que configuramos en la segunda línea (2) como argumento. Al igual que con una solicitud GET, una vez que se envía el formulario, el navegador realiza la solicitud HTTP POST para enviar las cookies de Bob al sitio del banco, que invoca una transferencia. Debido a que las solicitudes POST envían una respuesta HTTP al navegador, el atacante oculta la respuesta en un iFrame usando el atributo display: none (1). Como resultado, Bob no lo ve y no se da cuenta de lo que ha sucedido. En otros escenarios, un sitio puede esperar que la solicitud POST se envíe con el content-type:application/json en su lugar. En algunos casos, una solicitud que es un tipo application/json tendrá un token CSRF. Este token es un valor que se envía con la solicitud HTTP para que el sitio legítimo pueda validar que la solicitud se originó en sí mismo, no en otro, sitio malicioso. A veces, el cuerpo HTTP de la solicitud POST incluye el token, pero en otras ocasiones la solicitud POST tiene un encabezado personalizado con un nombre como X-CSRF-TOKEN. Cuando un navegador envía una solicitud POST de una aplicación/json a un sitio, enviará una solicitud OPTIONS antes de la solicitud POST. El sitio luego devuelve una respuesta a la llamada OPTIONS indicando qué tipos de verbos HTTP acepta y de qué origen confía. Esto se conoce como
OPCIONES de verificación de previa llamada. El navegador lee esta respuesta y luego hace la solicitud HTTP apropiada, que en nuestro ejemplo bancario sería una solicitud de transferencia tipo POST. Si se implementa correctamente, la llamada OPTIONS de la verificación previa protege contra algunas vulnerabilidades de CSRF: los sitios maliciosos no aparecerán como sitios de confianza por el servidor, y los navegadores solo permitirán que sitios web específicos (conocidos como sitios web incluidos en la white list) lean la respuesta OPTIONS. Como resultado, debido a que el sitio malicioso no puede leer la respuesta OPTIONS, los navegadores no enviarán la solicitud POST maliciosa. El conjunto de reglas que definen cuándo y cómo los sitios web pueden leer las respuestas entre sí se denomina intercambio de recursos de origen cruzado (CORS). CORS restringe el acceso a recursos, incluido el acceso de respuesta JSON, desde un dominio fuera de ese que sirvió el archivo o está permitido por el sitio que se está probando. En otras palabras,
cuando los desarrolladores usan CORS para proteger un sitio, no puede enviar una solicitud json para llamar a la aplicación que se está probando, ni leer la respuesta ni
realizar otras llamadas a menos que el sitio que se está probando lo permita. En algunas situaciones puede omitir estas protecciones cambiando el content-type a application/x-www-form-urlencoded, multipart/form-data o text/plain. Los navegadores no envian llamadas OPTIONS de verificación previa para ninguno de estos tres tipos de contenido cuando hacen una solicitud POST, por lo que una solicitud CSRF podría funcionar. Si no es así, mire en el header el Access-Control-Allow-Origin en las respuestas HTTP del servidor para comprobar que el servidor no confía en orígenes arbitrarios. Si ese encabezado de respuesta cambia cuando las solicitudes se envían desde orígenes arbitrarios, el sitio puede tener problemas mayores porque permite que cualquier origen lea las respuestas de su servidor. Esto permite las vulnerabilidades CSRF, pero también puede permitir a atacantes malintencionados leer los datos confidenciales devueltos en las respuestas HTTP del servidor.

defensas contra los ataques csrf

Puede mitigar las vulnerabilidades de CSRF de varias formas. Una de la forma más popular de protección contra ataques CSRF es el token CSRF. Los sitios protegidos requieren el token CSRF cuando se envían solicitudes que potencialmente podría alterar los datos (es decir, solicitudes POST). En tal situación, una aplicación web (como el banco de Bob) generaría un token con dos partes: una que Bob recibiría y otro que retendría la aplicación. Cuando Bob intenta realizar solicitudes de transferencia, tendría que enviar su token, que luego el banco validaría con su lado del token. El diseño de estos tokens los hace imposibles de adivinar y solo accesibles para el usuario al que están asignados (como Bob). Además, no siempre se nombran de forma obvia, pero algunos ejemplos potenciales de nombres incluyen X-CSRF-TOKEN, lia-token, rt, o form-id. Los tokens se pueden incluir en los encabezados de solicitud HTTP, en un cuerpo POST, o como un campo oculto, como en el siguiente ejemplo:

En este ejemplo, el sitio podría obtener el token CSRF de una cookie, un script incrustado en el sitio web, o como parte del contenido entregado desde el sitio. Independientemente del método, solo el navegador web del objetivo conoce y puede leer el valor. Ya que el atacante no pudo enviar el token, no podrían enviar correctamente una solicitud POST y
no podría llevar a cabo un ataque CSRF. Sin embargo, solo porque un sitio utiliza tokens CSRF no significa que sea un callejón sin salida cuando estás buscando vulnerabilidades para explotar. Intente eliminar el token, cambiar su valor y así sucesivamente para confirmar que el token se ha implementado correctamente.
La otra forma en que los sitios se protegen a sí mismos es mediante CORS; sin embargo,
esto no es infalible porque se basa en la seguridad del navegador y garantiza configuraciones CORS adecuadas para determinar cuándo los sitios de terceros pueden
acceder a las respuestas. Los atacantes a veces pueden eludir CORS cambiando el
tipo de contenido de application/json a application / x-www-form-urlencoded o mediante el uso de una solicitud GET en lugar de una solicitud POST debido a configuraciones incorrectas en el lado del servidor. La razón por la que funciona el bypass es que los navegadores enviaran automáticamente una solicitud HTTP OPTIONS cuando el tipo de contenido sea application/json, pero no enviará automáticamente una solicitud HTTP OPTIONS si es una solicitud GET o el tipo de contenido es application/x-www-form urlencoded.
Por último, hay dos estrategias de mitigación de CSRF adicionales y menos comunes. Primero, el sitio puede verificar el valor del encabezado Origin o Referer enviado con una solicitud HTTP y asegúrarse de que contiene el valor esperado.
Por ejemplo, en algunos casos, Twitter verificará el encabezado Origin y, si no esta incluido, consulte el encabezado Referer. Esto funciona porque los navegadores controlan
estos encabezados y los atacantes no pueden configurarlos ni cambiarlos de forma remota (obviamente, esto excluye la explotación de una vulnerabilidad en los navegadores o complementos del navegador que podría permitir que un atacante controle cualquiera de los encabezados). En segundo lugar, los navegadores ahora comenzaron a implementar el soporte para un nuevo atributo de cookie llamado samesite. Este atributo se puede establecer como strict o lax. Cuando se establece como strict, el navegador no enviará la cookie con ninguna solicitud HTTP que no se origine en el sitio. Esto incluye incluso solicitudes HTTP GET simples. Por ejemplo, si te registras en Amazon y utilizas cookies strict samesite, el navegador no enviaría sus cookies si estuviera siguiendo un enlace de otro sitio. Además, Amazon no lo reconocerá como conectado hasta que visite otra página web de Amazon y las cookies sean enviadas. Por el contrario, establecer el atributo samesite como lax indica a los navegadores que envíen cookies con solicitudes GET iniciales. Esto apoya el principio de diseño que las solicitudes GET nunca deben alterar los datos del lado del servidor. En este caso, si inicia sesión en Amazon y utilizas cookies samesite lax, el navegador enviaría sus cookies y Amazon le reconocera como conectado si ha sido redirigido allí de otro sitio.

shopify twitter disconnect

Cuando busque vulnerabilidades potenciales de CSRF, esté atento a la búsqueda de solicitudes GET que modifiquen los datos del lado del servidor. Por ejemplo, un hacker descubrió una vulnerabilidad en una caracteristica de Shopify que integra Twitter en el sitio para permitir a los propietarios de tiendas tuitear sobre sus productos. La función también permitió a los usuarios desconectar una cuenta de Twitter de una tienda conectada. La URL para desconectar una cuenta de Twitter fue la siguiente:

https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect/

Resulta que visitar esta URL enviaría una solicitud GET para desconectar la cuenta, de la siguiente manera:

GET /auth/twitter/disconnect HTTP/1.1
 Host: twitter-commerce.shopifyapps.com
 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0)
 Gecko/20100101 Firefox/43.0
 Accept: text/html, application/xhtml+xml, application/xml
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Referer: https://twitter-commerce.shopifyapps.com/account
 Cookie: _twitter-commerce_session=REDACTED
 Connection: keep-alive

Además, cuando se implementó originalmente el enlace, Shopify no estaba validando la legitimidad de las solicitudes GET enviadas, haciendo que la URL sea vulnerable a CSRF.
El hacker WeSecureApp, que presentó el informe, proporcionó el siguiente documento HTML de prueba de concepto:

Cuando se abre, este documento HTML provocaría que el navegador envie una solicitud HTTP GET a https: // twitter-commerce.shopifyapps.com a través del atributo src de la etiqueta ➊. Si alguien con una cuenta de Twitter está conectada a Shopify visita una página web con esta etiqueta , su cuenta de Twitter quedará desconectada de Shopify.

Cambiar zonas de usuarios en Instacart

Cuando esté mirando la forma de ataque, recuerda considerar los endpoints de la API de un sitio web, así como sus páginas web. Instacart es una aplicación de entrega de comestibles que permite a sus repartidores definir las zonas en las que trabajan. El sitio actualiza estas zonas con una solicitud POST al subdominio de administración de Instacart. Un hacker descubrió que el endpoint de la zona en este subdominio era vulnerable a CSRF. Por ejemplo, puede modificar una zona de destino con el siguiente código:

En este ejemplo, el hacker creó un formulario HTML para enviar una solicitud HTTP POST al endpoint /api/v2/zones ➊. El hacker incluyó dos hidden inputs: una para configurar la nueva zona al código postal 10001 ➋ y una para configurar el parametro override de la API a verdadero ➌ por lo que se reemplazó el valor ZIP actual del usuario con el valor enviado por el hacker. Además, el hacker incluyó un botón de envío para realizar la solicitud POST ➍, a diferencia de el ejemplo de Shopify, que utilizó un envío automático JavaScript. Aunque este ejemplo todavía tiene éxito, el hacker podría mejorar el exploit utilizando las técnicas descritas anteriormente, como usar un iFrame oculto para enviar automáticamente la solicitud en el nombre del objetivo. Esto le demostraría a Instacart cómo un atacante podría usar esta vulnerabilidad.

controlar una cuenta en badoo

Aunque los desarrolladores suelen utilizar tokens CSRF para protegerse contra vulnerabilidades CSRF, en algunos casos, los atacantes pueden robar los tokens, como verá en este error. Si exploras https://www.badoo.com/, verá que utiliza tokens CSRF. Más específicamente, usa un parametro de URL llamado rt, que es único para cada usuario. el hacker Mahmoud Jamal reconoció el parámetro rt y su significado. Él notó que el parámetro se devolvia en casi todas las respuestas JSON. Desafortunadamente, esto no fue útil porque CORS protege a Badoo de los atacantes que leen esas respuestas, ya que están codificados como tipos de contenido application/json. Pero Jamal siguió investigando. Jamal finalmente encontró el archivo JavaScript https://eu1.badoo.com/worker scope/chrome-service-worker.js, que contenía una variable llamada url_stats y estaba
establecida en el siguiente valor:

La variable url_stats almacenaba una URL que contenía el valor rt único como parámetro cuando el navegador del usuario accedia al archivo JavaScript ➊. Aún mejor, para obtener el valor rt del usuario, un atacante solo necesitaría que el objetivo visitara una página web maliciosa que accedería al archivo JavaScript. CORS no bloquea esto porque los navegadores pueden leer e incrustar archivos JavaScript remotos de fuentes externas.
El atacante podría usar el valor rt para vincular cualquier cuenta de medios con la cuenta de Badoo del usuario. Como resultado, el atacante podría invocar solicitudes HTTP POST para modificar la cuenta de destino. Aquí está la página HTML que solía usar Jamal
lograr este exploit:

<html>
<head>
<title>Badoo account take over</title>
➊ <script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.
js?ws=1></script>
</head>
<body>
<script>
➋ function getCSRFcode(str) {
return str.split('=')[2];
}
➌ window.onload = function(){
➍ var csrf_code = getCSRFcode(url_stats);
➎ csrf_url = 'https://eu1.badoo.com/google/verify.phtml?code=4/nprfspM3y
fn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authuser=3&session_state=7cb8
5df679
219ce71044666c7be3e037ff54b560..a810&prompt=none&rt='+ csrf_code;
➏ window.location = csrf_url;
};
</script>
</body>
</html>

Cuando un objetivo carga esta página, la página cargará Badoo
JavaScript haciendo referencia a él como el atributo src en una etiqueta <script> ➊. Una vez cargado el script, la página web llama al Window.onload de la función de JavaScript, que define una función de JavaScript ➌. Los navegadores llaman al controlador de eventos onload cuando se carga una página web; porque la función definida por Jamal es
en el controlador window.onload, su función siempre será llamada
cuando se carga la página. A continuación, Jamal crea una variable csrf_code ➍ y la asignó
el valor de retorno de una función que definió en ➋ llamado getCSRFcode. La función getCSRFcode toma y divide una cadena en una matriz de cadenas en cada carácter ‘=’. Luego devuelve el valor del tercer miembro de la matriz. Cuando la función
analiza la variable url_stats del archivo JavaScript vulnerable de Badoo en ➍, divide la cadena en el siguiente valor de matriz:

https://eu1.badoo.com/chrome-push-stats?ws,1&rt,<rt_param_value>

Luego, la función devuelve el tercer miembro de la matriz, que es el valor rt, y lo asigna a csrf_code.

Una vez que tuvo el token CSRF, Jamal creó la variable csrf_url, que almacena una URL a /google/verify.phtml de Badoo. La página web vincula su propia cuenta de Google a la
cuenta de Badoo del objetivo ➎. Esta página requiere algunos parámetros, que están codificados en la cadena de URL. Sin embargo, tenga en cuenta el parámetro rt final, que no tiene un valor codificado. En su lugar, csrf_code se concatena al final de la cadena de URL para que se transmita como el valor del parámetro rt. Jamal luego realiza una solicitud HTTP invocando window.location ➏ y lo asigna a csrf_url, que redirige el navegador del usuario visitante a la URL en ➎. Esto da como resultado una solicitud GET a Badoo, que valida el parámetro rt y procesa la solicitud para vincular la cuenta de Badoo a la cuenta de Google de Jamal, completando la toma de control de la cuenta.

resumen

Las vulnerabilidades CSRF representan otro vector de ataque que los atacantes pueden ejecutar sin que el objetivo lo sepa o realizar activamente una acción. Encontrar vulnerabilidades CSRF puede requerir algo de ingenio y la voluntad de probar todas las
funcionalidades en un sitio. Generalmente, los frameworks de aplicaciones, como Ruby on Rails, protegen cada vez más los formularios web si el sitio funciona con solicitudes POST; sin embargo, este no es el caso de las solicitudes GET. Por lo tanto, asegúrese de estar atento a cualquier llamada GET HTTP que cambian los datos del usuario del lado del servidor (como desconectar cuentas de Twitter ). Además, aunque no incluí un ejemplo, si
ve que un sitio está enviando un token CSRF con una solicitud POST, puede intentar cambiar el valor del token CSRF o eliminarlo por completo para asegurarse de que el servidor está validando su existencia.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s