Creo que vale la pena tomarse el tiempo para preguntar por qué está utilizando una verificación de origen y referencia para habilitar su validación CSRF.
La forma más segura de realizar una comprobación CSRF es mediante el uso de cookies (bueno, la sesión del usuario, en realidad) para almacenar un token que debe regresar con la solicitud final. Las cookies hacen que todo el proceso sea muy simple y mucho menos propenso a errores (para su usuario final). La única vez que realmente debe tener para realizar el origen y la validación CSRF basada en referencia es cuando no es posible almacenar la clave en la sesión del usuario. Sin embargo, si le preocupa que el usuario escriba las URL directamente en el navegador, esto significa que sus usuarios finales operan desde el navegador, lo que significa que tiene acceso específico a las cookies / sesiones. Por lo tanto, sospecho que la respuesta real a su pregunta es ajustar los procedimientos de CSRF para hacer uso de cookies, no de referencia / origen.
Sin embargo, para responder a su pregunta, la respuesta es que no, no puede hacer nada para permitir que los usuarios escriban la URL directamente en el navegador y aún así tengan acceso a cualquier recurso / acción que su configuración de CSRF esté protegiendo. Excepto mediante el uso de cookies, no hay forma de distinguir entre un usuario que escribe una URL directamente y un ataque CSRF malicioso.
Editado para agregar más detalles:
El token CSRF que estoy describiendo se llama token Synchronizer en . La idea es que usted precalifique un secreto, lo almacene en la sesión del usuario (razón por la cual están involucradas las cookies), lo incluya en el formulario que se enviará (pero no lo coloca en una cookie real), y luego verifique que el token CSRF haya creado el formulario y coincida con lo que almacenó en la sesión. La razón por la que funciona es que la acción no está permitida sin el token, y el token no se entrega hasta que el usuario realmente visita el formulario para ejecutar la acción. Para mayor seguridad, también regenera el token para cada envío de formulario. Como resultado, un usuario malintencionado no puede completar silenciosamente una acción en el "fondo" porque todas las acciones solo pueden completarse si el usuario visita la página que contiene el formulario y luego envía el formulario real.
La página a la que hace referencia en OWASP sugiere usar un paradigma de seguridad dual para protegerse contra los ataques CSRF:
- Verifique los encabezados de origen y referencia
- Usa un token CSRF
La aplicación adecuada de la defensa en profundidad dicta tomar todas las medidas de seguridad necesarias, por lo que sugieren el uso de ambos métodos para protegerse contra CSRF. A veces, sin embargo, la realidad requiere un compromiso, por lo que vale la pena mencionar todos los pros y los contras de ambos. Lo más importante, cuando se realiza correctamente, cualquiera de los dos métodos lo protegerá contra todos los vectores de ataque CSRF conocidos actualmente. Por supuesto, aquí es donde entra la defensa en profundidad, ya que contar con seguridad adicional (es decir, implementar ambas medidas de defensa) aumenta potencialmente las posibilidades de mitigar futuros ataques que aún no se han ideado.
A pesar de este hecho, todos los marcos con los que he trabajado utilizan solo la protección de token CSRF fuera de la caja (hasta donde sé). Esto incluye Code Igniter, Laravel, Django y Ruby on Rails. En el caso de Django y Ruby on Rails confío en su documentación para verificar ese hecho (es posible que hayan omitido algunos detalles), pero para el codeigniter y laravel verifiqué el código fuente en sí para asegurarme de que no estaba t equivocado Entonces, en realidad, es común en la web habilitar la protección CSRF utilizando solo tokens CSRF. El hecho de que sea o no una buena idea para usted depende de su nivel de comodidad de equilibrio entre seguridad y facilidad de uso. Sin embargo, ciertamente no es una locura usar solo tokens CSRF para realizar la mitigación de CSRF: muchos sistemas de software populares hacen exactamente eso.
Se me ocurre hacer una pregunta más: ¿por qué su sistema CSRF evita que los usuarios escriban una dirección? Si un usuario simplemente escribe una dirección en su barra de direcciones para visitar su página, eso ejecuta una solicitud HTTP / GET, y las solicitudes GET no deben estar sujetas a la protección CSRF porque el servidor nunca debe tomar medidas en respuesta a una solicitud GET. Entonces, en realidad, también podría haber una solución más fácil para su problema: asegúrese de no tomar medidas en respuesta a una solicitud GET y luego desactive la protección CSRF en todas las solicitudes GET. Luego, los usuarios podrán escribir las URL en un navegador todo lo que deseen.