1 de marzo de 2016
Django 1.8.10 resuelve dos problemas de seguridad y varios errores en 1.8.9.
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». La comprobación de seguridad para estas redirecciones (es decir, django.utils.http.is_safe_url()) consideraba algunas URLs con credenciales de autenticación básica como «seguras» cuando no lo deberían.
Por ejemplo, una URL como http://mysite.example.com\@attacker.com se consideraría segura si el host de la solicitud es http://mysite.example.com, pero redirigir a esta URL envía al usuario a attacker.com.
Además, si un desarrollador se basa en is_safe_url() para proporcionar objetivos de redirección seguros y coloca tal URL en una cadena de texto, podría sufrir un ataque XSS.
En cada versión mayor de Django desde 1.6, el número por defecto de iteraciones para el PBKDF2PasswordHasher y sus subclases ha aumentado. Esto mejora la seguridad de la contraseña a medida que aumenta la velocidad del hardware, sin embargo, también crea una diferencia en tiempo entre una solicitud de inicio de sesión para un usuario con una contraseña codificada en un número anterior de iteraciones y una solicitud de inicio de sesión para un usuario inexistente (que ejecuta el factorizador por defecto de hashers desde Django 1.6).
Esto solo afecta a los usuarios que no han iniciado sesión desde que se aumentó el número de iteraciones. La primera vez que un usuario inicia sesión después de un aumento en las iteraciones, su contraseña se actualiza con las nuevas iteraciones y ya no hay una diferencia en tiempo.
El nuevo método BasePasswordHasher.harden_runtime() permite a los hashers puentear la brecha de tiempo entre el factor de trabajo (por ejemplo, iteraciones) proporcionado en contraseñas codificadas existentes y el factor de trabajo por defecto del hasher. Este método se implementa para PBKDF2PasswordHasher y BCryptPasswordHasher. El número de rondas para el último hasher no ha cambiado desde Django 1.4, pero algunos proyectos pueden heredarlo y aumentar el factor de trabajo según sea necesario.
Se emitirá un aviso para cualquier hashers de contraseña de terceros que no implementen un método harden_runtime().
Si tienes diferentes hashes de contraseña en tu base de datos (como hashes SHA1 de usuarios que no han iniciado sesión desde que el hashero por defecto se cambió a PBKDF2 en Django 1.4), la diferencia de tiempo en una solicitud de inicio de sesión para estos usuarios puede ser aún mayor y esta solución no remedia esa diferencia (ni ninguna otra cuando se cambian los hashers). Puede poder actualizar esos hashes para prevenir un ataque de tiempo para ese caso.
Se ha corregido una caída en PostgreSQL que impedía el uso de TIME_ZONE=None y USE_TZ=False (#26177).
Se han agregado comprobaciones del sistema para conflictos de nombres de consulta de relaciones ocultas (#26162).
Se ha hecho que forms.FileField y utils.translation.lazy_number() sean picklables (#26212).
Se ha corregido la serialización de RangeField y ArrayField con valores None (#26215).
Se han repermitido guiones en nombres de dominio de nivel superior de URLs comprobadas por URLValidator para corregir una regresión en Django 1.8 (#26204).
Se ha corregido BoundField para repermitir slices de subwidgets (#26267).
Se ha evitado que instancias de ContentTypeManager compartan su caché (#26286).
may 31, 2026