Con el ataque BREACH, ¿el token CSRF basado en sesión sigue siendo seguro?

Navega tus respuestas
4

Esto es algo que no he podido envolver, si BREACH permite filtrar información, ¿tenemos que enmascarar o generar el token CSRF de forma temporal o por solicitud para hacerlo más seguro?

Hasta donde sé, el token CSRF basado en sesión puede protege al usuario de CSRF muy bien . Pero, ¿qué tan preciso es esto en el contexto con respecto a SSL? El problema aquí ya no es si el atacante puede realizar CSRF, sino si tal token de CSRF se puede extraer de HTTPS con la compresión activada, ¿incluso se puede usar para filtrar otra información?

Básicamente, estoy preguntando si esto La pregunta anterior ahora tiene una respuesta diferente.

    
pregunta bitinn 11.10.2013 - 09:07
fuente

2 respuestas

2

Si su sitio es vulnerable a INCUMPLIMIENTO, un atacante puede adivinar cualquier cosa en el cuerpo de la respuesta, un personaje a la vez. El atacante hace varias solicitudes, una por cada respuesta, y puede ver si adivinó correctamente. Por ejemplo, el atacante puede intentar estas conjeturas:

  • csrftoken = a
  • csrftoken = b
  • csrftoken = c
  • etc.

Al cabo de un rato, descubre el primer carácter del token y pasa al siguiente. Como puede ver, hay cientos de solicitudes necesarias para adivinar todo el token CSRF.

Este ataque solo funciona si se devuelve el mismo token CSRF en todas las solicitudes. Si el token difiere entre las solicitudes, el atacante no puede usar varias solicitudes para adivinarlo. Entonces, para protegerse contra el ataque BREACH, el token CSRF debería ser diferente en cada página.

Sin embargo, no es necesario crear un token nuevo para cada solicitud. Simplemente ofuscar el token CSRF es suficiente. Puede cifrar o incluso XOR el token CSRF con un poco de sal que incluya en el formulario, como Django y Rails do. Esto significa que el token es diferente en cada página, pero aún debe verificar un solo valor en el backend.

    
respondido por el Sjoerd 24.11.2016 - 10:23
fuente
1

Para responder a su pregunta: aún es seguro, si no utiliza las señales CSRF-tokens basadas en sesión Y Compresión HTTP (consulte la explicación a continuación)

de breachattack.com / ¿Estoy afectado?

Si tiene un cuerpo de respuesta HTTP que cumple TODOS las siguientes condiciones, podría ser vulnerable:

  • Compresión HTTP Su página recibe la compresión HTTP habilitada (GZIP / DEFLATE)
  • Datos del usuario : su página refleja los datos del usuario a través de una cadena de consulta o parámetros POST
  • Un secreto : la página de su aplicación sirve PII, un token CSRF, datos confidenciales

Mitigaciones / ordenados por efectividad

  1. Deshabilitar la compresión HTTP
  2. Separando secretos de la entrada del usuario
  3. Secretos aleatorios por solicitud
  4. Secretos de máscara (aleatorización efectiva mediante XORing con un secreto aleatorio por solicitud)
  5. Proteger páginas vulnerables con CSRF
  6. Ocultación de longitud (agregando un número aleatorio de bytes a las respuestas)
  7. Limitar la velocidad de las solicitudes
respondido por el that guy from over there 11.10.2013 - 09:55
fuente

Lea otras preguntas en las etiquetas

¿Hay alguna diferencia en la terminología entre las palabras "criptograma" y "texto cifrado"? ¿Qué función desempeñan los cifrados de hash y de bloque en la generación de números aleatorios?