Hola y bienvenido a mi sesión sobre cómo evitar CSRF con Remix. Esta es una charla rápida, así que vamos a pasar por esto de manera bastante rápida. Comencemos hablando de qué es CSRF. Como la mayoría de las explotaciones de seguridad, tiene un acrónimo y significa Cross-Site Request Forgery. Y en este escenario, básicamente el atacante engaña al usuario para que acceda a la URL y luego esta URL realizará una acción utilizando su sesión existente.
Un ejemplo simple, o tal vez el peor ejemplo, es una imagen con una URL y esa URL realiza una acción. Antes de que digas que quieres escribir código como este, he visto esto en aplicaciones que he auditado, y obviamente lo primero que el usuario está haciendo mal aquí es que está utilizando GET para realizar alguna acción. Pero igualmente, este tipo de explotación se puede lograr incluso si se utiliza POST. Y lo hacemos teniendo un iframe con una altura y ancho ocultos, y eso incrusta una URL separada. Y en esa URL tenemos el formulario, el POST a ese endpoint, y tenemos una función onload que lo envía tan pronto como se carga el formulario.
Así que hablemos un poco de Remix. Remix te hace pensar en las acciones en términos de los bloques de construcción de la web, que son los elementos de formulario HTML. Y si has estado construyendo aplicaciones con JavaScript, probablemente hayas estado usando cosas como Fetch o Axios, y en estos escenarios, por supuesto, te protege. A menos que, por supuesto, estés usando access, allow origin, ya sabes, star, y estás permitiendo que las credenciales pasen. Y en ese caso, estás en la misma situación. Así que porque estamos enviando formularios nuevamente a través de datos de formulario multiparte, necesitamos pensar en Cross-Site Request Forgery.
Así que veamos un ejemplo simple de formulario Remix. Aquí tenemos un formulario primitivo con un campo de texto y un botón de enviar. Tenemos algún tipo de cargador para verificar que el usuario tenga una sesión autenticada porque Cross-Site Request Forgery requiere que estén conectados. Ya sabes, estás realizando una acción utilizando su sesión existente que no pretendían hacer. Y por lo tanto, no vamos a entrar en los detalles aquí, pero sí, el cargador se asegura de que el usuario tenga una sesión. Luego tenemos una acción en nuestro componente que hace alguna escritura en la base de datos o similar. Algo que realiza alguna acción que, ya sabes, no se puede revertir. Entonces, ¿cómo evitas Cross-Site Request Forgery con Remix en este escenario? Bueno, lo primero que debes hacer es establecer el mismo atributo de sitio en tus cookies. Puedes establecerlo como lax, lo que significa que el navegador solo enviará las cookies si es una solicitud GET que proviene de otro dominio. O puedes establecerlo como strict, lo que significa que no enviará ninguna cookie para ninguna solicitud que se origine desde otro dominio. Por lo tanto, es posible que debas verificar si estás utilizando algún tipo de flujo de autenticación que redirige a otros sitios para determinar cuál es el más apropiado para tu sitio. Pero desafortunadamente, según OWASP, esto no es suficiente y no debemos reemplazarlo con un token. Y la razón principal de eso es que solo el 93% de los navegadores admiten el atributo de mismo sitio en esta etapa. Casi estamos allí.
Comments