¿Cómo se defiende CSRF contra solicitudes que pretenden no ser navegadores?

No deberías tener que bloquear solicitudes que no sean del navegador.

¿La razón? Csrf es un ataque a un usuario que utiliza un navegador. Deben estar visitando su sitio al mismo tiempo que un sitio malicioso.

Si no hay navegador, no hay ataque. Así que dejen pasar los navegadores.

Actualización: Después de Comentario de Anders Ahora me doy cuenta de que la pregunta estaba relacionada con los sitios web que ya permiten las solicitudes de cambio de estado basadas en el Agente de usuario. Consulte su respuesta ya que resume la situación muy bien con respecto a esto.

Mi nueva respuesta:

El mejor enfoque no es utilizar un mecanismo de autenticación basado en navegador para funciones sensibles. Para cualquier cosa a la que se acceda desde fuera de un navegador, aplique el acceso utilizando las claves de API enviadas como encabezados dentro de la solicitud. Los sistemas automatizados que utilizan API no deberían usar un nombre de usuario & Para obtener una contraseña y obtener un token de sesión, deben tener una clave segura que se pueda adjuntar con cada solicitud.

De esta manera, no importa lo que sea el agente de usuario: usted identifica los no navegadores por el hecho de que están utilizando una clave API enviada en un encabezado para autenticarse.

Creo que un ejemplo de un ataque CSRF podría ayudar a entender por qué es un ataque basado en navegador y por qué no hay necesidad de detectar si el cliente está usando un navegador o no.

Digamos que usted es usuario de un sitio web www.example.com y es posible eliminar su cuenta si hace clic en un enlace que conduce a www.example.com/delete_account. ¿Qué pasa cuando haces clic en ese enlace? Su navegador generará una solicitud HTTP para ese recurso (/ delete_account) e incluirá todas las cookies de ese sitio en esa solicitud. Por lo tanto, el servidor sabrá que es usted y que desea eliminar su cuenta, según las cookies incluidas, y por lo tanto lo hará.

El problema es que alguien podría crear una página maliciosa e incluir un iframe con el atributo src que apunta a www.example.com/delete_account. Si visita ese sitio malicioso y está conectado a www.example.com, su navegador intentará procesar el iframe enviando una solicitud a www.example.com/delete_account y también incluirá sus cookies en esa solicitud. De esa forma, realmente eliminaría su cuenta en example.com si no hay protección CSRF.

Eso significa que CSRF sucede si, por ejemplo, confía en una acción de los usuarios solo en función de las cookies que envía, y el problema es que los navegadores envían cookies automáticamente. Es por eso que la protección CSRF es importante.

¿Puedo hacer que realice la misma solicitud a www.example.com/delete_account utilizando un navegador que no sea? Eso en realidad no tendría sentido. Podría intentar convencerlo de que copie la solicitud en Burp, y además tendría que copiar y pegar manualmente las cookies en la solicitud ... y en realidad no tiene sentido :) La mejor manera de entenderlo es no pensar cómo La protección funcionaría, pero pensar cómo funcionaría el ataque.

Si te leo bien, estás considerando un escenario en el que el sitio http://completely.not.evil.com tiene una secuencia de comandos como esta:

var req = new XMLHttpRequest();
req.setRequestHeader("User-Agent", "Totally not a browser");
req.open("POST", "http://example.com/delete_account");
req.send();

Este ataque fallará. Todas las demás respuestas dicen cosas válidas sobre CSRF, pero ninguna de ellas menciona la pieza faltante del rompecabezas que explica por qué el atacante no puede engañar al navegador de las víctimas para que envíe una solicitud con un agente de usuario modificado. Y esa pieza es CORS .

La configuración del encabezado User-Agent hará que el navegador realice una solicitud previa al vuelo OPTIONS al servidor para ver si está permitido. A menos que configure específicamente su servidor para permitir esto, que se disparará en el pie, no responderá de manera positiva. El navegador no enviará la solicitud POST que en realidad habría realizado la acción maliciosa.

Entonces, en conclusión, el atacante no puede modificar con éxito el encabezado User-Agent a menos que usted lo permita.

En resumen: no tiene que preocuparse por CSRF y no navegadores.

Para que un ataque CSRF tenga éxito, su sitio web debe recibir una solicitud con todos los encabezados y cookies de un cliente, y no poder saber si su sitio o un tercero realizó la solicitud.

Para un ataque que no sea del navegador, un usuario tendría que adivinar (o poseer) todas las cookies y encabezados que usa su sitio, pasando toda la información de la sesión como si el usuario se estuviera conectando.

No tienes que preocuparte por que el agente de usuario esté enredado porque

CSRF no proviene de un atacante

El atacante no emite las solicitudes falsificadas involucradas en un ataque CSRF. Son emitidos por un navegador usuario legítimo . Ese es el punto central de esto. El pirata informático está secuestrando la sesión legítima del usuario legítimo (es por eso que el ataque a veces se denomina sesión montada ). El atacante simplemente convenció al usuario de enviar la solicitud de alguna manera (por ejemplo, haciendo clic en un enlace o abriendo un correo electrónico cuidadosamente diseñado); no está realmente involucrado en el tráfico o la conexión de red de ninguna manera.

La idea de que el atacante forjaría un encabezado de agente de usuario y enviaría la solicitud no encaja en este escenario en absoluto. Ciertamente, hay otros ataques que pueden ser emitidos directamente por un pirata informático, utilizando una herramienta de pirateo de su elección, pero ninguno de esos ataques es CSRF, por definición .