19 de febrero de 2013
Django 1.4.4 corrige cuatro problemas de seguridad presentes en versiones anteriores de Django en la serie 1.4, así como varios otros bugs y numerosos mejoras en la documentación.
Esto es el cuarto lanzamiento de corrección de errores/seguridad en la serie Django 1.4.
Algunas partes de Django – independientes de las aplicaciones escritas por los usuarios finales – utilizan URLs completas, incluyendo nombre de dominio, que se generan a partir del encabezado HTTP Host. La documentación de Django ha contenido notas durante algún tiempo para advertir a los usuarios sobre cómo configurar servidores web para asegurarse de que solo cabezerales Host válidos puedan llegar a la aplicación de Django. Sin embargo, nos han informado que incluso con las recomendaciones de configuración de servidor web, todavía existen técnicas disponibles para engañar a muchos servidores web comunes haciéndoles suministrar al aplicativo un encabezado Host incorrecto y potencialmente malicioso.
Por esta razón, Django 1.4.4 agrega una nueva configuración, ALLOWED_HOSTS, que contiene una lista explícita de nombres de host/dominio válidos para este sitio. Una solicitud con un encabezado Host no coincidente con una entrada en esta lista levantará SuspiciousOperation si se llama a request.get_host(). Para obtener detalles completos, consulte la documentación para la configuración ALLOWED_HOSTS.
El valor predeterminado de esta configuración en Django 1.4.4 es ['*'] (coincidiendo con cualquier host), por compatibilidad hacia atrás, pero fuertemente recomendamos que todos los sitios establezcan un valor más restrictivo.
La validación del host se deshabilita cuando DEBUG es True o cuando se están ejecutando pruebas.
El analizador XML de la biblioteca estándar de Python es vulnerable a una serie de ataques mediante entidades externas y expansión de entidades. Django utiliza este analizador para deserializar fijuras de base de datos en formato XML. Este deserializador no se destaca para su uso con datos no confiables, pero para errar en el lado de la seguridad en Django 1.4.4, el deserializador XML rechaza parsear un documento XML con una DTD (definición de tipo de documento), lo que cierra estas vías de ataque.
Estos problemas en la biblioteca estándar de Python son CVE-2013-1664 y CVE-2013-1665. Más información disponible del equipo de seguridad de Python.
La serialización de XML de Django no crea documentos con una DTD, por lo que esto no debería causar ningún problema con el típico round-trip desde dumpdata a loaddata, pero si alimentas tus propios documentos XML al comando de gestión loaddata, debes asegurarte de que no contengan una DTD.
Las versiones anteriores de Django no validaban ni limitaban los datos del recuento de formas proporcionados por el cliente en la forma de gestión de un conjunto de formas, lo que hacía posible agotar la memoria disponible de un servidor obligándolo a crear números muy grandes de formas.
En Django 1.4.4, todos los formularios tienen un número máximo estrictamente impuesto de formas (1000 por defecto, aunque puede establecerse más alto mediante el argumento max_num de la fábrica de formularios).
Los cambios en la versión anterior de Django permitían a un usuario administrador sin permiso de cambio en un modelo ver la representación Unicode de instancias a través de su registro de historial administrativo. La versión 1.4.4 de Django ahora limita la vista del registro de historial administrativo para un objeto a los usuarios con permiso de cambio para ese modelo.
Se evitó que el estado de transacción se filtrara desde una solicitud a otra (#19707).
Se cambió la sintaxis de un comando SQL para ser compatible con MySQL 4 (#19702).
Se agregó compatibilidad hacia atrás con contraseñas MD5 sin sal antiguas (#18144).
Numerosas mejoras y correcciones en la documentación.
may 31, 2026