8 de julio de 2015
Django 1.4.21 corrige varios problemas de seguridad en 1.4.20.
En versiones anteriores de Django, los backends de sesión creados un nuevo registro vacío en el almacenamiento de sesión cada vez que se accedía a request.session y había una clave de sesión proporcionada en las cookies del request que no tenía ya un registro de sesión. Esto podría permitir a un atacante crear fácilmente muchos nuevos registros de sesión simplemente enviando solicitudes repetidas con claves de sesión desconocidas, lo que potencialmente llenaría el almacenamiento de sesiones o causaría la expulsión de los registros de sesión de otros usuarios.
Los backends de sesión integrados ahora crean un registro de sesión solo si la sesión se modifica realmente; no se crean registros de sesión vacíos. Por lo tanto, esta posible DoS es ahora posible únicamente si el sitio expone una vista que modifica la sesión a usuarios anónimos.
Como cada backend de sesión integrado se corrigió por separado (en lugar de una corrección en el marco de sesiones centralizado), los mantenedores de backends de sesión terceros deben comprobar si la misma vulnerabilidad está presente en su backend y corregirla si es así.
Algunos de los validadores integrados de Django (EmailValidator, entre otros) no prohibían caracteres de nueva línea (debido al uso de $ en lugar de \Z en las expresiones regulares). Si utilizas valores con nuevas líneas en respuestas HTTP o encabezados de correo electrónico, puedes sufrir ataques de inyección de encabezados. Django no es vulnerable porque HttpResponse y las utilidades para enviar correos electrónicos en django.core.mail prohíben nuevas líneas en los encabezados HTTP y SMTP, respectivamente. Aunque los validadores han sido corregidos en Django, si estás creando respuestas HTTP o mensajes de correo electrónico de otras maneras, es una buena idea asegurarte de que esas funciones también prohíban nuevas líneas. También podrías querer validar que cualquier dato existente en tu aplicación no contenga nuevas líneas inesperadas.
validate_ipv4_address(), validate_slug() y URLValidator y su uso en los campos de formulario correspondientes GenericIPAddresseField, IPAddressField, SlugField y URLField también están afectados.
La función no documentada e internamente inutilizada validate_integer() ahora es más estricta ya que valida utilizando una expresión regular en lugar de simplemente convertir el valor usando int() y comprobar si se levantó una excepción.
may 31, 2026