Django

Latest version: v5.0.3

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

Scan your dependencies

Page 46 of 52

1.4.15

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

*September 2, 2014*

Django 1.4.15 fixes a regression in the 1.4.14 security release.

Bugfixes
========

* Allowed inherited and m2m fields to be referenced in the admin
(:ticket:`22486`)


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

1.4.14

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

*August 20, 2014*

Django 1.4.14 fixes several security issues in 1.4.13.

``reverse()`` could generate URLs pointing to other hosts
=========================================================

In certain situations, URL reversing could generate scheme-relative URLs (URLs
starting with two slashes), which could unexpectedly redirect a user to a
different host. An attacker could exploit this, for example, by redirecting
users to a phishing site designed to ask for user's passwords.

To remedy this, URL reversing now ensures that no URL starts with two slashes
(//), replacing the second slash with its URL encoded counterpart (%2F). This
approach ensures that semantics stay the same, while making the URL relative to
the domain and not to the scheme.

File upload denial-of-service
=============================

Before this release, Django's file upload handing in its default configuration
may degrade to producing a huge number of ``os.stat()`` system calls when a
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.

We've remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
:meth:`Storage.get_available_name()
<django.core.files.storage.Storage.get_available_name>` now appends an
underscore plus a random 7 character alphanumeric string (e.g. ``"_x3a1gho"``),
rather than iterating through an underscore followed by a number (e.g. ``"_1"``,
``"_2"``, etc.).

``RemoteUserMiddleware`` session hijacking
==========================================

When using the :class:`~django.contrib.auth.middleware.RemoteUserMiddleware`
and the ``RemoteUserBackend``, a change to the ``REMOTE_USER`` header between
requests without an intervening logout could result in the prior user's session
being co-opted by the subsequent user. The middleware now logs the user out on
a failed login attempt.

Data leakage via query string manipulation in ``contrib.admin``
===============================================================

In older versions of Django it was possible to reveal any field's data by
modifying the "popup" and "to_field" parameters of the query string on an admin
change form page. For example, requesting a URL like
``/admin/auth/user/?pop=1&t=password`` and viewing the page's HTML allowed
viewing the password hash of each user. While the admin requires users to have
permissions to view the change form pages in the first place, this could leak
data if you rely on users having access to view only certain fields on a model.

To address the issue, an exception will now be raised if a ``to_field`` value
that isn't a related field to a model that has been registered with the admin
is specified.


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

1.4.13

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

*May 14, 2014*

Django 1.4.13 fixes two security issues in 1.4.12.

Caches may incorrectly be allowed to store and serve private data
=================================================================

In certain situations, Django may allow caches to store private data
related to a particular session and then serve that data to requests
with a different session, or no session at all. This can lead to
information disclosure and can be a vector for cache poisoning.

When using Django sessions, Django will set a ``Vary: Cookie`` header to
ensure caches do not serve cached data to requests from other sessions.
However, older versions of Internet Explorer (most likely only Internet
Explorer 6, and Internet Explorer 7 if run on Windows XP or Windows Server
2003) are unable to handle the ``Vary`` header in combination with many content
types. Therefore, Django would remove the header if the request was made by
Internet Explorer.

To remedy this, the special behavior for these older Internet Explorer versions
has been removed, and the ``Vary`` header is no longer stripped from the response.
In addition, modifications to the ``Cache-Control`` header for all Internet Explorer
requests with a ``Content-Disposition`` header have also been removed as they
were found to have similar issues.

Malformed redirect URLs from user input not correctly validated
===============================================================

The validation for redirects did not correctly validate some malformed URLs,
which are accepted by some browsers. This allows a user to be redirected to
an unsafe URL unexpectedly.

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()``) did not correctly validate some malformed
URLs, such as ``http:\\\\\\djangoproject.com``, which are accepted by some
browsers with more liberal URL parsing.

To remedy this, the validation in ``is_safe_url()`` has been tightened to be able
to handle and correctly validate these malformed URLs.


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

1.4.12

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

*April 28, 2014*

Django 1.4.12 fixes a regression in the 1.4.11 security release.

Bugfixes
========

* Restored the ability to ``reverse()`` views created using
:func:`functools.partial()` (:ticket:`22486`).


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

1.4.11

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

*April 21, 2014*

Django 1.4.11 fixes three security issues in 1.4.10. Additionally,
Django's vendored version of six, ``django.utils.six``, has been
upgraded to the latest release (1.6.1).

Unexpected code execution using ``reverse()``
=============================================

Django's URL handling is based on a mapping of regex patterns
(representing the URLs) to callable views, and Django's own processing
consists of matching a requested URL against those patterns to
determine the appropriate view to invoke.

Django also provides a convenience function -- ``reverse()`` -- which performs
this process in the opposite direction. The ``reverse()`` function takes
information about a view and returns a URL which would invoke that view. Use
of ``reverse()`` is encouraged for application developers, as the output of
``reverse()`` is always based on the current URL patterns, meaning developers
do not need to change other code when making changes to URLs.

One argument signature for ``reverse()`` is to pass a dotted Python
path to the desired view. In this situation, Django will import the
module indicated by that dotted path as part of generating the
resulting URL. If such a module has import-time side effects, those
side effects will occur.

Thus it is possible for an attacker to cause unexpected code
execution, given the following conditions:

1. One or more views are present which construct a URL based on user
input (commonly, a "next" parameter in a querystring indicating
where to redirect upon successful completion of an action).

2. One or more modules are known to an attacker to exist on the
server's Python import path, which perform code execution with side
effects on importing.

To remedy this, ``reverse()`` will now only accept and import dotted
paths based on the view-containing modules listed in the project's :doc:`URL
pattern configuration </topics/http/urls>`, so as to ensure that only modules
the developer intended to be imported in this fashion can or will be imported.

Caching of anonymous pages could reveal CSRF token
==================================================

Django includes both a :doc:`caching framework </topics/cache>` and a system
for :doc:`preventing cross-site request forgery (CSRF) attacks
</ref/csrf/>`. The CSRF-protection system is based on a random nonce
sent to the client in a cookie which must be sent by the client on future
requests and, in forms, a hidden value which must be submitted back with the
form.

The caching framework includes an option to cache responses to
anonymous (i.e., unauthenticated) clients.

When the first anonymous request to a given page is by a client which
did not have a CSRF cookie, the cache framework will also cache the
CSRF cookie and serve the same nonce to other anonymous clients who
do not have a CSRF cookie. This can allow an attacker to obtain a
valid CSRF cookie value and perform attacks which bypass the check for
the cookie.

To remedy this, the caching framework will no longer cache such
responses. The heuristic for this will be:

1. If the incoming request did not submit any cookies, and

2. If the response did send one or more cookies, and

3. If the ``Vary: Cookie`` header is set on the response, then the
response will not be cached.

MySQL typecasting
=================

The MySQL database is known to "typecast" on certain queries; for
example, when querying a table which contains string values, but using
a query which filters based on an integer value, MySQL will first
silently coerce the strings to integers and return a result based on that.

If a query is performed without first converting values to the
appropriate type, this can produce unexpected results, similar to what
would occur if the query itself had been manipulated.

Django's model field classes are aware of their own types and most
such classes perform explicit conversion of query arguments to the
correct database-level type before querying. However, three model
field classes did not correctly convert their arguments:

* :class:`~django.db.models.FilePathField`
* :class:`~django.db.models.GenericIPAddressField`
* ``IPAddressField``

These three fields have been updated to convert their arguments to the
correct types before querying.

Additionally, developers of custom model fields are now warned via
documentation to ensure their custom field classes will perform
appropriate type conversions, and users of the :meth:`raw()
<django.db.models.query.QuerySet.raw>` and :meth:`extra()
<django.db.models.query.QuerySet.extra>` query methods -- which allow the
developer to supply raw SQL or SQL fragments -- will be advised to ensure they
perform appropriate manual type conversions prior to executing queries.


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

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.


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

Page 46 of 52

Links

Releases

Has known vulnerabilities

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.