1 de noviembre de 2016
Django 1.8.16 resuelve dos problemas de seguridad en 1.8.15.
Cuando se ejecutan pruebas con una base de datos Oracle, Django crea un usuario temporal de la base de datos. En versiones anteriores, si no se especifica manualmente la contraseña en el diccionario de configuración TEST de la base de datos, se utiliza una contraseña hardcoded. Esto podría permitir a un atacante con acceso a la red al servidor de bases de datos que conecte.
Este usuario suele eliminarse después de completar el conjunto de pruebas, pero no cuando se usa la opción manage.py test --keepdb o si el usuario tiene una sesión activa (como la conexión de un atacante).
Un password aleatorio se utiliza ahora para cada ejecución de pruebas.
DEBUG=True¶Las versiones antiguas de Django no validan el encabezado Host contra settings.ALLOWED_HOSTS cuando settings.DEBUG=True. Esto las hace vulnerables a un ataque de reencaminamiento DNS.
Si bien Django no envía un módulo que permite la ejecución de código remoto, esto al menos es un vector de scripting entre sitios, lo cual podría ser bastante grave si los desarrolladores cargan una copia de la base de datos de producción en desarrollo o conectan a algunos servicios de producción para los cuales no hay instancia de desarrollo, por ejemplo. Si un proyecto utiliza un paquete como django-debug-toolbar, entonces el atacante podría ejecutar SQL arbitrario, lo cual podría ser especialmente malo si los desarrolladores se conectan a la base de datos con una cuenta superusuario.
Ahora se valida settings.ALLOWED_HOSTS sin importar DEBUG. Para conveniencia, si ALLOWED_HOSTS está vacío y DEBUG=True, entonces las siguientes variaciones de localhost están permitidas: ['localhost', '127.0.0.1', '::1']. Si tu archivo de configuración local tiene el valor de producción de ALLOWED_HOSTS, debes omitirlo para obtener esos valores por defecto.
may 31, 2026