13 de enero de 2015
Django 1.4.18 soluciona varios problemas de seguridad en la versión 1.4.17, así como una regresión en Python 2.5 en la versión 1.4.17.
Cuando se colocan los encabezados HTTP en el entorno WSGI, se normalizan convirtiendo a mayúsculas, convirtiendo todos los guiones a subrayados y agregando HTTP_ al principio. Por ejemplo, un encabezado X-Auth-User se convertiría en HTTP_X_AUTH_USER en el entorno WSGI (y también en el diccionario de Django request.META).
Desafortunadamente, esto significa que el entorno WSGI no puede distinguir entre encabezados que contienen guiones y encabezados que contienen subrayados: X-Auth-User y X-Auth_User se convierten ambos en HTTP_X_AUTH_USER. Esto significa que si un encabezado se utiliza de manera sensible (por ejemplo, pasando información de autenticación desde un proxy frontal), incluso si el proxy elimina cuidadosamente cualquier valor entrante para X-Auth-User, un atacante puede proporcionar un encabezado X-Auth_User (con subrayado) y evitar esta protección.
Para prevenir tales ataques, tanto Nginx como Apache 2.4+ eliminan por defecto todos los encabezados que contienen subrayados de las solicitudes entrantes. El servidor de desarrollo de Django ahora hace lo mismo. El servidor de desarrollo de Django no se recomienda para uso en producción, pero emular el comportamiento de servidores de producción comunes reduce la superficie de cambios de comportamiento durante la implementación.
Django depende del input del usuario en algunos casos (por ejemplo, django.contrib.auth.views.login() y i18n) para redirigir al usuario a una «URL de éxito». Las comprobaciones de seguridad para estas redirecciones (es decir, django.utils.http.is_safe_url()) no eliminaban el espacio en blanco inicial en la URL probada y como tal consideraban URLs como \njavascript:... seguras. Si un desarrollador confiaba en is_safe_url() para proporcionar objetivos de redirección seguros y ponía una URL así en un enlace, podría sufrir un ataque XSS. Este bug no afecta a Django actualmente, ya que solo colocamos esta URL en el encabezado de respuesta Location y los navegadores parecen ignorar JavaScript allí.
django.views.static.serve¶En versiones antiguas de Django, la vista django.views.static.serve() leía los archivos que servía una línea a la vez. Por lo tanto, un gran archivo sin nuevas líneas resultaría en uso de memoria igual al tamaño del archivo. Un atacante podría explotar esto y lanzar un ataque de denegación de servicio pidiendo simultáneamente muchos grandes archivos. Esta vista ahora lee el archivo en trozos para prevenir el uso de memoria grande.
Sin embargo, tenga en cuenta que esta vista siempre ha llevado una advertencia de que no está hardenizada para uso en producción y debe usarse solo como ayuda de desarrollo. Ahora puede ser un buen momento para auditar su proyecto y servir sus archivos en producción utilizando un servidor frontal real si no lo hace ya.
Para mantener la compatibilidad con Python 2.5, la versión de six vendida por Django, django.utils.six, ha sido actualizada a 1.8.0 que es la última versión que soporta Python 2.5.
may 31, 2026