19 de febrero de 2013
Django 1.3.6 resuelve cuatro problemas de seguridad presentes en versiones anteriores de Django dentro de la serie 1.3.
Este es el sexto lanzamiento de corrección de errores y seguridad en la serie Django 1.3.
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.3.6 agrega una nueva configuración, ALLOWED_HOSTS, que debe contener 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.3.6 es [“*”] (que coincide con cualquier host), por compatibilidad hacia atrás, pero fuertemente recomendamos a todos los sitios que 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 parser de XML en la biblioteca estándar de Python es vulnerable a varios ataques mediante entidades externas y expansión de entidades. Django utiliza este parser para deserializar fijaciones de base de datos formateadas en XML. El deserializador de fijaciones no está destinado al uso con datos no confiables, pero para errar del lado de la seguridad en Django 1.3.6 el deserializador de XML se niega a parsear un documento XML con una DTD (definición de DOCTYPE), 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.3.6, todos los conjuntos de formas tienen un número máximo estrictamente impuesto de formas (1000 por defecto, aunque se puede establecer más alto mediante el argumento max_num de la fábrica de formset).
En versiones anteriores de Django, un usuario administrador sin permiso de cambio en un modelo aún podía ver la representación Unicode de instancias a través de su registro de historial administrativo. Django 1.3.6 ahora limita la vista del registro de historial administrativo para un objeto a usuarios con permiso de cambio para ese modelo.
may 31, 2026