mirror of
https://github.com/django/django.git
synced 2024-11-18 07:26:04 +00:00
89 lines
3.7 KiB
Plaintext
89 lines
3.7 KiB
Plaintext
==========================
|
|
Django 1.4.4 release notes
|
|
==========================
|
|
|
|
*February 19, 2013*
|
|
|
|
Django 1.4.4 fixes four security issues present in previous Django releases in
|
|
the 1.4 series, as well as several other bugs and numerous documentation
|
|
improvements.
|
|
|
|
This is the fourth bugfix/security release in the Django 1.4 series.
|
|
|
|
|
|
Host header poisoning
|
|
---------------------
|
|
|
|
Some parts of Django -- independent of end-user-written applications -- make
|
|
use of full URLs, including domain name, which are generated from the HTTP Host
|
|
header. Django's documentation has for some time contained notes advising users
|
|
on how to configure webservers to ensure that only valid Host headers can reach
|
|
the Django application. However, it has been reported to us that even with the
|
|
recommended webserver configurations there are still techniques available for
|
|
tricking many common webservers into supplying the application with an
|
|
incorrect and possibly malicious Host header.
|
|
|
|
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
|
|
an explicit list of valid host/domain names for this site. A request with a
|
|
Host header not matching an entry in this list will raise
|
|
``SuspiciousOperation`` if ``request.get_host()`` is called. For full details
|
|
see the documentation for the :setting:`ALLOWED_HOSTS` setting.
|
|
|
|
The default value for this setting in Django 1.4.4 is ``['*']`` (matching any
|
|
host), for backwards-compatibility, but we strongly encourage all sites to set
|
|
a more restrictive value.
|
|
|
|
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests.
|
|
|
|
|
|
XML deserialization
|
|
-------------------
|
|
|
|
The XML parser in the Python standard library is vulnerable to a number of
|
|
attacks via external entities and entity expansion. Django uses this parser for
|
|
deserializing XML-formatted database fixtures. This deserializer is not
|
|
intended for use with untrusted data, but in order to err on the side of safety
|
|
in Django 1.4.4 the XML deserializer refuses to parse an XML document with a
|
|
DTD (DOCTYPE definition), which closes off these attack avenues.
|
|
|
|
These issues in the Python standard library are CVE-2013-1664 and
|
|
CVE-2013-1665. More information available `from the Python security team`_.
|
|
|
|
Django's XML serializer does not create documents with a DTD, so this should
|
|
not cause any issues with the typical round-trip from ``dumpdata`` to
|
|
``loaddata``, but if you feed your own XML documents to the ``loaddata``
|
|
management command, you will need to ensure they do not contain a DTD.
|
|
|
|
.. _from the Python security team: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html
|
|
|
|
|
|
Formset memory exhaustion
|
|
-------------------------
|
|
|
|
Previous versions of Django did not validate or limit the form-count data
|
|
provided by the client in a formset's management form, making it possible to
|
|
exhaust a server's available memory by forcing it to create very large numbers
|
|
of forms.
|
|
|
|
In Django 1.4.4, all formsets have a strictly-enforced maximum number of forms
|
|
(1000 by default, though it can be set higher via the ``max_num`` formset
|
|
factory argument).
|
|
|
|
|
|
Admin history view information leakage
|
|
--------------------------------------
|
|
|
|
In previous versions of Django, an admin user without change permission on a
|
|
model could still view the unicode representation of instances via their admin
|
|
history log. Django 1.4.4 now limits the admin history log view for an object
|
|
to users with change permission for that model.
|
|
|
|
|
|
Other bugfixes and changes
|
|
==========================
|
|
|
|
* Prevented transaction state from leaking from one request to the next (#19707).
|
|
* Changed an SQL command syntax to be MySQL 4 compatible (#19702).
|
|
* Added backwards-compatibility with old unsalted MD5 passwords (#18144).
|
|
* Numerous documentation improvements and fixes.
|