¿Cómo mantener una verificación de origen / referencia para que la prevención CSRF no bloquee las URL que se escriben?

2

Estoy intentando configurar la prevención de CSRF al verificar los encabezados Origin y Referer, y también bloquear cualquier acción si no se establece ninguna.

Sin embargo, si la URL simplemente se escribe o se pega en el navegador, dicha comprobación provocará el bloqueo de la acción, ya que no se establecerán los encabezados de Origen y de Referencia.

Pensé que tal vez asegurarme de que HTTP_HOST es igual a SERVER_NAME, pero parece que eso puede debilitar la comprobación.

¿Cuál es la mejor manera de tener una verificación segura de origen / referencia y, sin embargo, dejar que las URL ingresadas pasen la verificación?

    
pregunta lindon 30.05.2017 - 01:53
fuente

3 respuestas

6

Si sigue la práctica recomendada a menudo citada de no mutar los datos u otro estado de la aplicación en las solicitudes de obtención de HTTP, la verificación de referencia en la solicitud de obtención se convierte en un problema. Solo puede usar la verificación de referencia en todas sus publicaciones HTTP (u otros métodos si los está usando).

La explotación de CSRF es esencialmente ciega (salvo las configuraciones erróneas de CORS masivas), por lo que siempre que las solicitudes Get solo devuelvan datos / JSON / HTML / etc. y no cambies nada, estás bien si no aplicas el anti-CSRF en ellos. Simplemente no son sensibles a este tipo de ataque.

Las publicaciones (Puts, etc.) probablemente solo provendrán de una aplicación conocida, por lo tanto, deben tener la referencia correcta a menos que estén siendo eliminadas por un proxy o algún otro software o dispositivo "en el medio".

    
respondido por el user18519 30.05.2017 - 02:17
fuente
2
  

¿Cuál es la mejor manera de tener una verificación segura de origen / referencia y, sin embargo, dejar que las URL ingresadas pasen la verificación?

Si está permitiendo que las URL ingresadas pasen la verificación, inevitablemente está creando una vulnerabilidad CSRF (obviamente, asumiendo que las URL escritas no usan tokens CSRF y causan cambios de estado sensibles a la seguridad).

Es decir, un sitio malintencionado puede omitir fácilmente al remitente y no tiene que enviar un encabezado Origin . Esto hace que una solicitud de origen cruzado sea indistinguible de una URL escrita. Una forma fácil de quitar la referencia de las solicitudes de origen cruzado es agregar un encabezado meta:

<meta name="referrer" content="no-referrer">
<a href="https://yoursite.example/delete_my_account">Click me</a>

En ese ejemplo, su navegador no puede saber si el usuario hizo clic en el enlace o escribió manualmente la URL.

    
respondido por el Arminius 30.05.2017 - 01:58
fuente
-1

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:

  1. Verifique los encabezados de origen y referencia
  2. 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.

    
fuente

Lea otras preguntas en las etiquetas