BREACH ataque vs filtrado entrada de usuario reflejada

5

Estoy a cargo de la seguridad aplicativa de nuestra aplicación y me gustaría probar nuestra exposición al ataque BREACH.

Nuestra aplicación web basada en django refleja la entrada de usuario filtrada y sirve un token CSRF.

De la forma en que lo entiendo, BREACH explota el algoritmo de compresión HTTP del cuerpo de la respuesta (para que nuestra cookie de sesión esté segura en el encabezado HTTP) para encontrar otras instancias de una cadena de entrada de usuario en particular.

¿Pero qué pasa si canary="somethingsomething" se convierte en canary="somethingsomething&quot como entrada de usuario? ¿Es la parte canary tan relevante para la "capacidad de respuesta" de somethingsomething ? Supongo que esto elimina el canario para la detección automática, pero si el resto de la página permanece igual, somethingsomething todavía sería vulnerable, pero más difícil de identificar, especialmente si hay más de un token en la página ...

    
pregunta Maxime Leblanc 12.02.2016 - 17:05
fuente

1 respuesta

1

Si la entrada del usuario se refleja literalmente con cada solicitud, su método probablemente no protege contra el INCUMPLIMIENTO.

La forma más segura de defender django es desactivar la compresión Gzip .

Alternativamente, puedes XOR el token con un valor pseudoaleatorio diferente para cada solicitud .

    
respondido por el Foo Bar 11.04.2016 - 23:05
fuente

Lea otras preguntas en las etiquetas