1 de marzo de 2016
Django 1.9.3 soluciona dos problemas de seguridad y varios errores en la versión 1.9.2.
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.
Los textos traducidos son:
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 corrigió una regresión para casos donde ForeignObject.get_extra_descriptor_filter() devolvía un objeto Q (#26153).
Se corrigió la regresión con una búsqueda de tipo __in=qs para un campo ForeignKey con to_field establecido (#26196).
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 corrigió un crash cuando se filtraba por un Decimal en RawQuery (#26219).
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 corrigieron algunas herramientas de depuración de desuso en SimpleTemplateResponse que regresaron en Django 1.9 (#26253).
Se ha corregido BoundField para repermitir slices de subwidgets (#26267).
Se cambió el mensaje de permiso denegado del administrador en la plantilla de inicio para utilizar get_username en lugar de username para apoyar modelos de usuarios personalizados (#26231).
Se corrigió un crash cuando se pasaba un nombre de plantilla inexistente al método load_template() del cargador de plantillas cacheado (#26280).
Se ha evitado que instancias de ContentTypeManager compartan su caché (#26286).
Se revertió una modificación en Django 1.9.2 (#25858) que impidió las relaciones lazy definidas en modelos abstractos ser resueltas según el app_label de su modelo concreto (#26186).
may 31, 2026