Los desarrolladores de Django estamos de enhorabuena ya que el equipo de Django ha securizado varias de sus versiones, las cuales puedes descargar en la web. ( www.djangoproject.com ). En concreto se trataba de dos vulnerabilidades XSS (o cross-site scripting); uno en un widget que usaba la interfaz de administración de Django, y el otro en una función bastante utilizada para validar redirecciones después de mostrar un anuncio o cierre de sesión. Es cierto que éstos temas presentan un riesgo bastante limitado y no tiene por qué afectar a todos los usuarios, el método por el que se accede a dichas vulnerabilidades es de muy fácil ejecución y está bastante extendido por la red; por lo que se recomienda encarecidamente actualizar en cuanto le sea posible a los usuarios. Éstas son las notas expuestas en la web del proyecto, donde el equipo de desarrollo de Django profundiza en las vulnerabilidades.

Cross-site scripting en la interfaz de administración:

La aplicación administrativa Django, django.contrib.admin, proporciona funcionalidad para CRUD (creación, recuperación, actualización y eliminación) en las operaciones para usuarios con privilegios administrativos, incluidas las instalaciones para las interfaces automáticas y en la manipulación de datos. Cuando se muestra el valor de un URLField (un tipo de modelo de campo para el almacenamiento de las direcciones URL) esta interfaz trataba a los valores de los campos tales como datos seguros, impidiendo con ello que se pudiesen asignar etiquetas de 'valor peligroso' en caso de que la dirección almacenada lo fuese. En una implementación Django normal, esto sólo afectará a la interfaz de administración, ya que el trato incorrecto se produce sólo en el formulario de código del widget en django.contrib.admin. Sin embargo, es posible que afecte a otras aplicaciones y el riesgo vaya más allá, si estas hacen uso del mismo formulario de código proporcionado por la interfaz de administración. Para poner solución a este problema, el widget en cuestión (django.contrib.admin.widgets.AdminURLFieldWidget) se ha corregido para que el tratamiento del valor de los campos, se trate de igual forma que cualquier otro valor suministrado por el usuario (como valor inseguro). De esta forma estará sujeto a (viene activado por defecto) la salida de datos de Django, donde se verificará su integridad y valor.

Posibles XSS mediante 'is_safe_url':

Un patrón común en las aplicaciones de Django es que para aceptar una credencial mediante el parámetro de una cadena de consulta, la redirección a la URL se hará al término del procesamiento de dicho valor. Este patrón se utiliza en el código incluido en Django, como por ejemplo el inicio de sesión (django.contrib.auth.views), que acepta un parámetro como para determinar dónde enviar a un usuario después de iniciar correctamente la sesión. Una función de utilidad (django.ituls.hht.is_safe_url () ) se proporciona y usa para validar que esta es la URL de la máquina actual (puede ser me diante URL completa o relativa), a fin de evitar las redirecciones potencialmente peligrosas mediante cadenas de comprobación creadas maliciosamente. 'is_safe_url ()' se pretende para direcciones HTTP y HTTPS, pero debido a la forma en la que se analiza la URL, permitirá redirecciones a otros esquemas, como JavaScript:. Si bien el proyecto Django no tiene conocimiento alguno de ninguna capacidad demostrada para realizar ataques de cross-site scripting mediante este mecanismo, consideramos que esta vulnerabilidad tiene el potencial suficiente como para desencadenar una mejora en la seguridad. Para remediar este problema, 'is_safe_url ()' se ha modificado para reconocer y rechazar correctamente direcciones URL que especifiquen un sistema distinto de HTTP o HTTPS.

Versiones afectadas

Las versiones afectadas por cada una de las vulnerabilidades descritas son: URLField XSS:
  • Django 1.5
  • Django 1.6 (actualmente en fase Beta)
  • Rama principal de desarrollo Django
is_safe_url ():
  • Django 1.4
  • Django 1.5
  • Django 1.6 (actualmente en fase Beta)
  • Rama principal de desarrollo Django

Para conseguir los parches clicar en los enlaces correspondientes:

En la rama principal de desarrollo: master is_safe_url patch ( https://github.com/django/django/commit/ae3535169af804352517b7fea94a42a1c9c4b762 ) master URLField patch ( https://github.com/django/django/commit/cbe6d5568f4f5053ed7228ca3c3d0cce77cf9560 ) Por Django 1.6 rama de lanzamiento: 1.6 patch is_safe_url( https://github.com/django/django/commit/79594b40c087c19fecc72af042c835b11a519b78 ) 1.6 patch URLField( https://github.com/django/django/commit/bfbae15c669beab335400ab51a060e3d7d8e4c7a ) Por Django 1.5 rama de lanzamiento: 1.5 patch is_safe_url( https://github.com/django/django/commit/1a274ccd6bc1afbdac80344c9b6e5810c1162b5f ) 1.5 patch URLField( https://github.com/django/django/commit/90363e388c61874add3f3557ee654a996ec75d78 ) Por Django 1.4 rama de lanzamiento: 1.4 patch is_safe_url( https://github.com/django/django/commit/ec67af0bd609c412b76eaa4cc89968a2a8e5ad6a )

Además de las correcciones, también hemos puesto disponibles para descarga nuevas versiones:

Django 1.6 beta 2 ( descarga Django 1.6b2 | 1.6b2 sumas de comprobación ) https://www.djangoproject.com/m/releases/1.6/Django-1.6b2.tar.gz https://www.djangoproject.com/m/pgp/Django-1.6b2.checksum.txt Django 1.5.2 ( descarga Django 1.5.2 | 1.5.2 sumas de comprobación ) https://www.djangoproject.com/m/releases/1.5/Django-1.5.2.tar.gz https://www.djangoproject.com/m/pgp/Django-1.5.2.checksum.txt Django 1.4.6 ( descarga Django 1.4.6 | 1.4.6 sumas de comprobación ) https://www.djangoproject.com/m/releases/1.4/Django-1.4.6.tar.gz https://www.djangoproject.com/m/pgp/Django-1.4.6.checksum.txt