Denegaciones de servicio y cross-site scripting en Django

La primera de las vulnerabilidades, identificada por el CVE-2012-3442 permitiría un ataque de tipo Cross-site Scripting. Django permite la redirección de una página a otra, por ejemplo, cuando un usuario se identifica en el sistema (login) o cierra la sesión (logout), Django lo redirige a una nueva página. Este sistema se llama ‘POST-redirect-GET‘. La página destino debe cumplir unos requisitos básicos que establece Django, como por ejemplo, que esté en el mismo dominio, pero no realiza prueba alguna sobre el tipo de caracteres que contiene. Así que un atacante podría manipular el campo ‘data‘ e incluir código JavaScript malicioso. 

    

Para solventar el error se ha creado una “lista blanca” de redirecciones en la clase de respuesta ‘Django.http.HttpResponseRedirectBase‘, de la cuál heredan ‘HttpResponseRedirect‘ y ‘HttpResponsePermanentRedirect‘.

   

La vulnerabilidad identificada con CVE-2012-3443 se trata de un error al subir una imagen al servidor. Django proporciona la clase ‘Django.forms.ImageField‘ para subir imágenes al servidor, que realiza algunas validaciones. Cuando se sube una imagen comprimida, Django la descomprime (ya en el lado del servidor) para hacer estas comprobaciones básicas, cargando toda la imagen descomprimida en memoria. Si la imagen es de un tamaño excesivamente grande, puede llegar a utilizar gran parte de la memoria, causando una denegación del servicio.

     

Para mitigar los efectos, en la nueva versión se utiliza el verificador de imágenes de PIL (Python Imaging Library), que realiza comprobaciones básicas sin descomprimir ni cargar la imagen entera en memoria.

    

La última vulnerabilidad (CVE-2012-3444) también consiste en una denegación de servicio, pero esta vez en la función ‘get_image_dimensions‘ que se encarga de obtener las dimensiones de una imagen. La manera de trabajar de esta función es cargar bloques de 1024 bytes desde el inicio de la imagen y hacer uso de la biblioteca PIL, que se encarga de determinar las dimensiones. Si el tamaño de datos es insuficiente para realizar los cálculos, Django carga los siguientes 1024 bytes y se los sigue pasando a PIL hasta que este devuelve las dimensiones. Este sistema es útil cuando en la cabecera de las imágenes hay suficientes datos para calcular las dimensiones, pero no es tan útil en formatos ‘RAW‘ o ‘TIFF‘, los cuales hay que cargar completamente para determinar su tamaño. 

    

En estos casos (y con imágenes de gran tamaño) habría que cargar muchos bloques de 1024 bytes del disco (con los accesos que ello conlleva), lo que derivaría en un consumo excesivo de CPU y causaría una denegación de servicio.

     

En las nuevas versiones el algoritmo para determinar las dimensiones ha cambiado: de cargar siempre un bloque fijo de 1024 bytes, ahora realiza lecturas de 1024 bytes * 2número de lecturas. En la primera leería 1024, en la segunda 2048, en la tercera 4096, y así sucesivamente, reduciendo el número de lecturas para ficheros TIFF muy grandes.