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

Django 1.4.11 release notes

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

*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.