120 lines
5.0 KiB
Plaintext
120 lines
5.0 KiB
Plaintext
==========================
|
|
Django 1.5.6 release notes
|
|
==========================
|
|
|
|
*April 21, 2014*
|
|
|
|
Django 1.5.6 fixes several bugs in 1.5.5, including three security
|
|
issues.
|
|
|
|
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 --
|
|
:func:`~django.core.urlresolvers.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/contrib/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`
|
|
* :class:`~django.db.models.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.
|
|
|
|
Bugfixes
|
|
========
|
|
|
|
* Fixed :class:`~django.contrib.auth.backends.ModelBackend` raising
|
|
``UnboundLocalError`` if :func:`~django.contrib.auth.get_user_model`
|
|
raised an error (#21439).
|
|
|
|
Additionally, Django's vendored version of six, :mod:`django.utils.six`,
|
|
has been upgraded to the latest release (1.6.1).
|