Django

Latest version: v5.0.3

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

Scan your dependencies

Page 39 of 52

1.7.9

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

*July 8, 2015*

Django 1.7.9 fixes several security issues and bugs in 1.7.8.

Denial-of-service possibility by filling session store
======================================================

In previous versions of Django, the session backends created a new empty record
in the session storage anytime ``request.session`` was accessed and there was a
session key provided in the request cookies that didn't already have a session
record. This could allow an attacker to easily create many new session records
simply by sending repeated requests with unknown session keys, potentially
filling up the session store or causing other users' session records to be
evicted.

The built-in session backends now create a session record only if the session
is actually modified; empty session records are not created. Thus this
potential DoS is now only possible if the site chooses to expose a
session-modifying view to anonymous users.

As each built-in session backend was fixed separately (rather than a fix in the
core sessions framework), maintainers of third-party session backends should
check whether the same vulnerability is present in their backend and correct
it if so.

Header injection possibility since validators accept newlines in input
======================================================================

Some of Django's built-in validators
(:class:`~django.core.validators.EmailValidator`, most seriously) didn't
prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in the
regular expressions). If you use values with newlines in HTTP response or email
headers, you can suffer from header injection attacks. Django itself isn't
vulnerable because :class:`~django.http.HttpResponse` and the mail sending
utilities in :mod:`django.core.mail` prohibit newlines in HTTP and SMTP
headers, respectively. While the validators have been fixed in Django, if
you're creating HTTP responses or email messages in other ways, it's a good
idea to ensure that those methods prohibit newlines as well. You might also
want to validate that any existing data in your application doesn't contain
unexpected newlines.

:func:`~django.core.validators.validate_ipv4_address`,
:func:`~django.core.validators.validate_slug`, and
:class:`~django.core.validators.URLValidator` are also affected, however, as
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
and ``URLField`` form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are using
these validators outside of the form fields.

The undocumented, internally unused ``validate_integer()`` function is now
stricter as it validates using a regular expression instead of simply casting
the value using ``int()`` and checking if an exception was raised.

Bugfixes
========

* Prevented the loss of ``null``/``not null`` column properties during field
renaming of MySQL databases (:ticket:`24817`).

* Fixed ``SimpleTestCase.assertRaisesMessage()`` on Python 2.7.10
(:ticket:`24903`).


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

1.7.8

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

*May 1, 2015*

Django 1.7.8 fixes:

* Database introspection with SQLite 3.8.9 (released April 8, 2015)
(:ticket:`24637`).

* A database table name quoting regression in 1.7.2 (:ticket:`24605`).

* The loss of ``null``/``not null`` column properties during field alteration
of MySQL databases (:ticket:`24595`).


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

1.7.7

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

*March 18, 2015*

Django 1.7.7 fixes several bugs and security issues in 1.7.6.

Denial-of-service possibility with ``strip_tags()``
===================================================

Last year :func:`~django.utils.html.strip_tags` was changed to work
iteratively. The problem is that the size of the input it's processing can
increase on each iteration which results in an infinite loop in
``strip_tags()``. This issue only affects versions of Python that haven't
received :bpo:`a bugfix in HTMLParser <20288>`; namely Python < 2.7.7 and
3.3.5. Some operating system vendors have also backported the fix for the
Python bug into their packages of earlier versions.

To remedy this issue, ``strip_tags()`` will now return the original input if
it detects the length of the string it's processing increases. Remember that
absolutely NO guarantee is provided about the results of ``strip_tags()`` being
HTML safe. So NEVER mark safe the result of a ``strip_tags()`` call without
escaping it first, for example with :func:`~django.utils.html.escape`.

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

Django relies on user input in some cases (e.g.
``django.contrib.auth.views.login()`` 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()``) accepted URLs with
leading control characters and so considered URLs like ``\x08javascript:...``
safe. This issue doesn't affect Django currently, since we only put this URL
into the ``Location`` response header and browsers seem to ignore JavaScript
there. Browsers we tested also treat URLs prefixed with control characters such
as ``%08//example.com`` as relative paths so redirection to an unsafe target
isn't a problem either.

However, if a developer relies on ``is_safe_url()`` to
provide safe redirect targets and puts such a URL into a link, they could
suffer from an XSS attack as some browsers such as Google Chrome ignore control
characters at the start of a URL in an anchor ``href``.

Bugfixes
========

* Fixed renaming of classes in migrations where renaming a subclass would
cause incorrect state to be recorded for objects that referenced the
superclass (:ticket:`24354`).

* Stopped writing migration files in dry run mode when merging migration
conflicts. When ``makemigrations --merge`` is called with ``verbosity=3`` the
migration file is written to ``stdout`` (:ticket:`24427`).


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

1.7.6

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

*March 9, 2015*

Django 1.7.6 fixes a security issue and several bugs in 1.7.5.

Mitigated an XSS attack via properties in ``ModelAdmin.readonly_fields``
========================================================================

The :attr:`ModelAdmin.readonly_fields
<django.contrib.admin.ModelAdmin.readonly_fields>` attribute in the Django
admin allows displaying model fields and model attributes. While the former
were correctly escaped, the latter were not. Thus untrusted content could be
injected into the admin, presenting an exploitation vector for XSS attacks.

In this vulnerability, every model attribute used in ``readonly_fields`` that
is not an actual model field (e.g. a :class:`property`) will **fail to be
escaped** even if that attribute is not marked as safe. In this release,
autoescaping is now correctly applied.

Bugfixes
========

* Fixed crash when coercing ``ManyRelatedManager`` to a string
(:ticket:`24352`).

* Fixed a bug that prevented migrations from adding a foreign key constraint
when converting an existing field to a foreign key (:ticket:`24447`).


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

1.7.5

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

*February 25, 2015*

Django 1.7.5 fixes several bugs in 1.7.4.

Bugfixes
========

* Reverted a fix that prevented a migration crash when unapplying
``contrib.contenttypes``’s or ``contrib.auth``’s first migration
(:ticket:`24075`) due to severe impact on the test performance
(:ticket:`24251`) and problems in multi-database setups (:ticket:`24298`).

* Fixed a regression that prevented custom fields inheriting from
``ManyToManyField`` from being recognized in migrations (:ticket:`24236`).

* Fixed crash in ``contrib.sites`` migrations when a default database isn't
used (:ticket:`24332`).

* Added the ability to set the isolation level on PostgreSQL with psycopg2 ≥
2.4.2 (:ticket:`24318`). It was advertised as a new feature in Django 1.6
but it didn't work in practice.

* Formats for the Azerbaijani locale (``az``) have been added.


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

1.7.4

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

*January 27, 2015*

Django 1.7.4 fixes several bugs in 1.7.3.

Bugfixes
========

* Fixed a migration crash when unapplying ``contrib.contenttypes``’s or
``contrib.auth``’s first migration (:ticket:`24075`).

* Made the migration's ``RenameModel`` operation rename ``ManyToManyField``
tables (:ticket:`24135`).

* Fixed a migration crash on MySQL when migrating from a ``OneToOneField`` to a
``ForeignKey`` (:ticket:`24163`).

* Prevented the ``static.serve`` view from producing ``ResourceWarning``\s in
certain circumstances (security fix regression, :ticket:`24193`).

* Fixed schema check for ManyToManyField to look for internal type instead
of checking class instance, so you can write custom m2m-like fields with the
same behavior. (:ticket:`24104`).


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

Page 39 of 52

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.