April 21, 2014
\nDjango 1.6.3 fixes several bugs in 1.6.2, including three security issues,\nand makes one backwards-incompatible change:
\nreverse()Link to this heading#Django’s URL handling is based on a mapping of regex patterns\n(representing the URLs) to callable views, and Django’s own processing\nconsists of matching a requested URL against those patterns to\ndetermine the appropriate view to invoke.
\nDjango also provides a convenience function – reverse() – which performs\nthis process in the opposite direction. The reverse() function takes\ninformation about a view and returns a URL which would invoke that view. Use\nof reverse() is encouraged for application developers, as the output of\nreverse() is always based on the current URL patterns, meaning developers\ndo not need to change other code when making changes to URLs.
One argument signature for reverse() is to pass a dotted Python\npath to the desired view. In this situation, Django will import the\nmodule indicated by that dotted path as part of generating the\nresulting URL. If such a module has import-time side effects, those\nside effects will occur.
Thus it is possible for an attacker to cause unexpected code\nexecution, given the following conditions:
\nOne or more views are present which construct a URL based on user\ninput (commonly, a “next” parameter in a querystring indicating\nwhere to redirect upon successful completion of an action).
One or more modules are known to an attacker to exist on the\nserver’s Python import path, which perform code execution with side\neffects on importing.
To remedy this, reverse() will now only accept and import dotted\npaths based on the view-containing modules listed in the project’s URL\npattern configuration, so as to ensure that only modules\nthe developer intended to be imported in this fashion can or will be imported.
Django includes both a caching framework and a system\nfor preventing cross-site request forgery (CSRF) attacks. The CSRF-protection system is based on a random nonce\nsent to the client in a cookie which must be sent by the client on future\nrequests and, in forms, a hidden value which must be submitted back with the\nform.
\nThe caching framework includes an option to cache responses to\nanonymous (i.e., unauthenticated) clients.
\nWhen the first anonymous request to a given page is by a client which\ndid not have a CSRF cookie, the cache framework will also cache the\nCSRF cookie and serve the same nonce to other anonymous clients who\ndo not have a CSRF cookie. This can allow an attacker to obtain a\nvalid CSRF cookie value and perform attacks which bypass the check for\nthe cookie.
\nTo remedy this, the caching framework will no longer cache such\nresponses. The heuristic for this will be:
\nIf the incoming request did not submit any cookies, and
If the response did send one or more cookies, and
If the Vary: Cookie header is set on the response, then the\nresponse will not be cached.
The MySQL database is known to “typecast” on certain queries; for\nexample, when querying a table which contains string values, but using\na query which filters based on an integer value, MySQL will first\nsilently coerce the strings to integers and return a result based on that.
\nIf a query is performed without first converting values to the\nappropriate type, this can produce unexpected results, similar to what\nwould occur if the query itself had been manipulated.
\nDjango’s model field classes are aware of their own types and most\nsuch classes perform explicit conversion of query arguments to the\ncorrect database-level type before querying. However, three model\nfield classes did not correctly convert their arguments:
\nIPAddressField
These three fields have been updated to convert their arguments to the\ncorrect types before querying.
\nAdditionally, developers of custom model fields are now warned via\ndocumentation to ensure their custom field classes will perform\nappropriate type conversions, and users of the raw() and extra() query methods – which allow the\ndeveloper to supply raw SQL or SQL fragments – will be advised to ensure they\nperform appropriate manual type conversions prior to executing queries.
select_for_update() requires a transactionLink to this heading#Historically, queries that use\nselect_for_update() could be\nexecuted in autocommit mode, outside of a transaction. Before Django\n1.6, Django’s automatic transactions mode allowed this to be used to\nlock records until the next write operation. Django 1.6 introduced\ndatabase-level autocommit; since then, execution in such a context\nvoids the effect of select_for_update(). It is, therefore, assumed\nnow to be an error and raises an exception.
This change was made because such errors can be caused by including an\napp which expects global transactions (e.g. ATOMIC_REQUESTS set to True), or Django’s old autocommit\nbehavior, in a project which runs without them; and further, such\nerrors may manifest as data-corruption bugs.
This change may cause test failures if you use select_for_update()\nin a test class which is a subclass of\nTransactionTestCase rather than\nTestCase.
Content retrieved from the GeoIP library is now properly decoded from its\ndefault iso-8859-1 encoding\n(#21996).
Fixed AttributeError when using\nbulk_create() with ForeignObject\n(#21566).
Fixed crash of QuerySets that use F() + timedelta() when their query\nwas compiled more once\n(#21643).
Prevented custom widget class attribute of\nIntegerField subclasses from being overwritten by the\ncode in their __init__ method\n(#22245).
Improved strip_tags() accuracy (but it still cannot\nguarantee an HTML-safe result, as stated in the documentation).
Fixed a regression in the django.contrib.gis SQL compiler for\nnon-concrete fields (#22250).
Fixed ModelAdmin.preserve_filters when running a site with\na URL prefix (#21795).
Fixed a crash in the find_command management utility when the PATH\nenvironment variable wasn’t set\n(#22256).
Fixed changepassword on Windows\n(#22364).
Avoided shadowing deadlock exceptions on MySQL\n(#22291).
Wrapped database exceptions in _set_autocommit\n(#22321).
Fixed atomicity when closing a database connection or when the database\nserver disconnects (#21239 and #21202)
Fixed regression in prefetch_related that caused the related objects\nquery to include an unnecessary join\n(#21760).
Additionally, Django’s vendored version of six, django.utils.six has been\nupgraded to the latest release (1.6.1).