Django

Latest version: v5.0.4

Safety actively analyzes 618931 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 47 of 52

1.4.10

Not secure
===========================

*November 6, 2013*

Django 1.4.10 fixes a Python-compatibility bug in the 1.4 series.

Python compatibility
====================

Django 1.4.9 inadvertently introduced issues with Python 2.5 compatibility.
Django 1.4.10 restores Python 2.5 compatibility. This was issue 21362 in
Django's Trac.


==========================

1.4.9

Not secure
==========================

*October 23, 2013*

Django 1.4.9 fixes a security-related bug in the 1.4 series and one other
data corruption bug.

Readdressed denial-of-service via password hashers
==================================================

Django 1.4.8 imposes a 4096-byte limit on passwords in order to mitigate a
denial-of-service attack through submission of bogus but extremely large
passwords. In Django 1.4.9, we've reverted this change and instead improved
the speed of our PBKDF2 algorithm by not rehashing the key on every iteration.

Bugfixes
========

* Fixed a data corruption bug with ``datetime_safe.datetime.combine`` (21256).


==========================

1.4.8

Not secure
==========================

*September 14, 2013*

Django 1.4.8 fixes two security issues present in previous Django releases in
the 1.4 series.

Denial-of-service via password hashers
======================================

In previous versions of Django, no limit was imposed on the plaintext
length of a password. This allowed a denial-of-service attack through
submission of bogus but extremely large passwords, tying up server
resources performing the (expensive, and increasingly expensive with
the length of the password) calculation of the corresponding hash.

As of 1.4.8, Django's authentication framework imposes a 4096-byte
limit on passwords and will fail authentication with any submitted
password of greater length.

Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
=========================================================================================================================

The decoration of the ``add_view`` and ``user_change_password`` user admin
views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
did not include :func:`~django.utils.decorators.method_decorator` (required
since the views are methods) resulting in the decorator not being properly
applied. This usage has been fixed and
:func:`~django.views.decorators.debug.sensitive_post_parameters` will now
throw an exception if it's improperly used.


==========================

1.4.7

Not secure
==========================

*September 10, 2013*

Django 1.4.7 fixes one security issue present in previous Django releases in
the 1.4 series.

Directory traversal vulnerability in ``ssi`` template tag
=========================================================

In previous versions of Django it was possible to bypass the
``ALLOWED_INCLUDE_ROOTS`` setting used for security with the ``ssi``
template tag by specifying a relative path that starts with one of the allowed
roots. For example, if ``ALLOWED_INCLUDE_ROOTS = ("/var/www",)`` the following
would be possible:

.. code-block:: html+django

{% ssi "/var/www/../../etc/passwd" %}

In practice this is not a very common problem, as it would require the template
author to put the ``ssi`` file in a user-controlled variable, but it's
possible in principle.


==========================

1.4.6

Not secure
==========================

*August 13, 2013*

Django 1.4.6 fixes one security issue present in previous Django releases in
the 1.4 series, as well as one other bug.

This is the sixth bugfix/security release in the Django 1.4 series.

Mitigated possible XSS attack via user-supplied redirect URLs
=============================================================

Django relies on user input in some cases (e.g.
``django.contrib.auth.views.login()``, ``django.contrib.comments``, and
:doc:`i18n </topics/i18n/index>`) to redirect the user to an "on success" URL.
The security checks for these redirects (namely
``django.utils.http.is_safe_url()``) didn't check if the scheme is ``http(s)``
and as such allowed ``javascript:...`` URLs to be entered. If a developer
relied on ``is_safe_url()`` to provide safe redirect targets and put such a
URL into a link, they could suffer from a XSS attack. This bug doesn't affect
Django currently, since we only put this URL into the ``Location`` response
header and browsers seem to ignore JavaScript there.

Bugfixes
========

* Fixed an obscure bug with the :func:`~django.test.override_settings`
decorator. If you hit an ``AttributeError: 'Settings' object has no attribute
'_original_allowed_hosts'`` exception, it's probably fixed (20636).


==========================

1.4.5

Not secure
==========================

*February 20, 2013*

Django 1.4.5 corrects a packaging problem with yesterday's :doc:`1.4.4 release
</releases/1.4.4>`.

The release contained stray ``.pyc`` files that caused "bad magic number"
errors when running with some versions of Python. This releases corrects this,
and also fixes a bad documentation link in the project template ``settings.py``
file generated by ``manage.py startproject``.


==========================

Page 47 of 52

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.