Protección CSRF en páginas estáticas

Puedo realizar cualquier solicitud a su servidor, con los encabezados y valores que desee. Por lo tanto, un atacante puede enviarle un paquete muy fácilmente con un remitente que haya elegido. Pero, ¿cómo hiciste esto en un ataque CSRF?

CSRF funciona al enviarte a una página web que controlo, y luego esa página redirige tu navegador a la página web para ejecutar el CSRF. Por ejemplo, podría enviarte (a través de esa página de ataque) a https://example.com/usermgmt.php?action=delete&user=1 , lo que podría hacer que elimines inadvertidamente el ID de usuario 1.

Lo que hace su navegador es configurar el encabezado REFERER (cuando se carga usermgmt.php) de donde sea que venga, por ejemplo, http://malicious.tld . Si usermgmt.php verificara el referente, notaría que no proviene del mismo dominio. Por lo tanto, no puede (de forma predeterminada) falsificar referencias para CSRF.

Una captura aquí son cosas como páginas de inicio de sesión. Considera esto: https://example.com/login.php?returnTo=index.php . Un ataque CSRF solo funciona cuando la víctima ya ha iniciado sesión, de lo contrario, el atacante podría cargar la URL por sí mismo. Y si ha iniciado sesión, es probable que la página de inicio de sesión simplemente lo redireccione directamente a la URL de retorno. Ahora, ¿qué sucede si escribe usermgmt.php?action=delete&userid=1 como la URL de retorno? Redirigirá de login.php a usermgmt.php, y el remitente recibido por usermgmt.php será https://example.com/login.php?returnto=x . Parece totalmente legítimo, pero no lo es.

Además, es posible que algunos navegadores no incluyan una referencia por razones de privacidad, lo que luego rompería el sitio web. No sé de ningún navegador que tenga esta opción (¿"característica"?) Sin instalar un complemento especial, pero nunca se sabe.

Entonces, la mejor solución es usar tokens CSRF, y ciertamente lo haría si usted va a hospedar algo para una audiencia más grande, pero si es para un grupo de usuarios cerrado, probablemente esté de acuerdo con la referencia.     

Personalmente, no recomiendo usar el encabezado del Referer para detener los ataques CSRF. Tiene dos problemas:

• Primero, es frágil. Hay una larga historia de ataques en el encabezado del Referer, que involucra (de diversas maneras) exploits en los complementos (por ejemplo, Flash), errores en las API del navegador (por ejemplo, XHR) y redirección. Para ser claros, no estoy diciendo que verificar al Referente necesariamente será inseguro; Solo estoy argumentando que creo que es más frágil y que tendría más confianza en una solución que usa tokens CSRF.

• En segundo lugar, algunos navegadores y firewalls corporativos bloquean el encabezado del Referer por razones de privacidad, lo que significa que se verá obligado a bloquear usuarios legítimos. Por lo tanto, el encabezado del Referer simplemente no es una buena solución.

En lugar de usar el encabezado del Referer, recomendaría que uses tokens CSRF.

Es efectivamente el punto final de tus rieles el que necesita protegerse. Debe diferenciar entre sus páginas estáticas y la página malintencionada de otra persona en Internet.

Estoy de acuerdo en que hacer que el punto final de los rieles verifique la referencia es una forma frágil de autorizar el acceso.

Una posibilidad es que el punto final de los rieles tenga una ruta que no esté protegida por CSRF, y no haga nada, pero permite configurar la cookie de CSRF. Una "forma nula". Todos los sitios estáticos de su dominio pueden golpearlo antes de hacer otras llamadas AJAX.

Presumiblemente, si está utilizando AJAX, está en el mismo dominio, lo que significa que puede ver la cookie. Si ese punto final fuera golpeado desde otro sitio, no obtendrían la cookie porque están en un dominio diferente.