¿Es seguro omitir las comprobaciones CSRF para no navegadores?

Navega tus respuestas
1

Estaba implementando un mecanismo de protección CSRF para mi servidor cuando me di cuenta de que este ataque solo afecta realmente a los navegadores web. Me pregunto: ¿por qué debería molestarme en generar / validar tokens CSRF para clientes que no son navegadores?

La eliminación de dichas comprobaciones no solo simplificaría la implementación de los clientes REST, sino que también mejoraría la escalabilidad.

Estaba pensando en que todos los recursos HTML configuren una cookie browserId que contenga un valor pseudoaleatorio criptográficamente fuerte que identifique al cliente como un navegador. Cualquier llamada a la API REST verificará esta cookie y, si está presente, aplicará la validación CSRF. De lo contrario, los cheques serían omitidos.

El valor de la cookie no es tan importante como su existencia. El servidor no almacena ni valida el valor, pero es útil para vincular tokens CSRF a un navegador específico (esto evita que un atacante pase su token CSRF a una víctima).

Mi pregunta es la siguiente:

  • ¿Es posible diferenciar entre clientes de máquina a máquina (M2M) y de persona a máquina (H2M)? Si es así, ¿cuál es la mejor manera (es razonable el enfoque anterior)?
  • ¿Es seguro diferenciar entre clientes M2M y H2M, incluso si podemos? ¿O esto nos abre a posibles ataques en el futuro?
  • ¿Un atacante puede eliminar las cookies, asumiendo que controlo todos los subdominios y uso HTTPS?
pregunta Gili 27.06.2014 - 06:10
fuente

2 respuestas

-1

Respondiendo a mi propia pregunta.

Sí, creo que es posible y seguro diferenciar entre navegadores y no navegadores con la presencia de cookies si y solo si:

  • El atacante no puede leer los valores de las cookies (garantizado por SOP )
  • Los valores de las cookies son obligatorios (evitando que el atacante realice solicitudes sin ellos).

Propongo dividir la implementación del lado del servidor en dos:

  1. Una API central para clientes RESTful.
  2. Una API de navegador que actúa como un puente para los navegadores.
  • La API principal no implementa ninguna función específica del navegador (por ejemplo, cookies, cheques CSRF).
  • La API del navegador refleja la API central (exportando métodos equivalentes, específicos del navegador, cuando sea necesario).
    • Es una implementación del lado del servidor que ejecuta verificaciones de seguridad específicas del navegador y convierte las características específicas del navegador al formato esperado por la API central (por ejemplo, cookies a valores JSON).
    • Reenvía las solicitudes a la API principal y convierte la respuesta a un formato específico del navegador (creando las cookies según sea necesario).

Un atacante no puede omitir las comprobaciones de seguridad al acceder a la API central porque ignora las cookies. Sin cookies, un atacante no puede llevar a cabo ataques CSRF.

    
respondido por el Gili 27.06.2014 - 20:18
fuente
2

CSRF es para formularios en su mayoría y no se utiliza en absoluto para las API REST. Cuando la API REST se implementa con claves API y nonce, podría decir que estos 2 actúan como su protección de falsificación de solicitud entre sitios.

Además, al diseñar la API REST, por lo general, es mejor evitar cosas como las cookies. Utilice claves de API por usuario, esto también resolverá sus problemas de identificación.

¿Es posible diferenciar entre clientes de máquina a máquina (M2M) y de persona a máquina (H2M)? Si es así, ¿cuál es la mejor manera (es razonable el enfoque anterior)?

Para una API de descanso, NO debería importar si el cliente es una máquina o un humano. Para identificar a los humanos, use la clave API por humano que se debe proporcionar en cada solicitud. No hay tal cosa como máquina o ser humano (es decir, no hay diferencia). Todo el mundo es un cliente para la API.

¿Es seguro diferenciar entre clientes M2M y H2M, incluso si podemos? ¿O esto nos abre a posibles ataques en el futuro?

Respondido arriba (no deberías necesitar hacer esto).

¿Un atacante puede eliminar las cookies, asumiendo que controlo todos los subdominios y uso HTTPS?

Respondido anteriormente (no debe usar cookies para las API REST).

    
respondido por el user43488 27.06.2014 - 09:42
fuente

Lea otras preguntas en las etiquetas

Seguimiento del sitio web de la red doméstica [duplicado] vulnerabilidad de truncamiento de SQL