February 19, 2013
\nDjango 1.3.6 fixes four security issues present in previous Django releases in\nthe 1.3 series.
\nThis is the sixth bugfix/security release in the Django 1.3 series.
\nSome parts of Django – independent of end-user-written applications – make\nuse of full URLs, including domain name, which are generated from the HTTP Host\nheader. Django’s documentation has for some time contained notes advising users\non how to configure web servers to ensure that only valid Host headers can\nreach the Django application. However, it has been reported to us that even\nwith the recommended web server configurations there are still techniques\navailable for tricking many common web servers into supplying the application\nwith an incorrect and possibly malicious Host header.
\nFor this reason, Django 1.3.6 adds a new setting, ALLOWED_HOSTS, which\nshould contain an explicit list of valid host/domain names for this site. A\nrequest with a Host header not matching an entry in this list will raise\nSuspiciousOperation if request.get_host() is called. For full details\nsee the documentation for the ALLOWED_HOSTS setting.
The default value for this setting in Django 1.3.6 is ['*'] (matching any\nhost), for backwards-compatibility, but we strongly encourage all sites to set\na more restrictive value.
This host validation is disabled when DEBUG is True or when running\ntests.
The XML parser in the Python standard library is vulnerable to a number of\nattacks via external entities and entity expansion. Django uses this parser for\ndeserializing XML-formatted database fixtures. The fixture deserializer is not\nintended for use with untrusted data, but in order to err on the side of safety\nin Django 1.3.6 the XML deserializer refuses to parse an XML document with a\nDTD (DOCTYPE definition), which closes off these attack avenues.
\nThese issues in the Python standard library are CVE-2013-1664 and\nCVE-2013-1665. More information available from the Python security team.
\nDjango’s XML serializer does not create documents with a DTD, so this should\nnot cause any issues with the typical round-trip from dumpdata to\nloaddata, but if you feed your own XML documents to the loaddata\nmanagement command, you will need to ensure they do not contain a DTD.
Previous versions of Django did not validate or limit the form-count data\nprovided by the client in a formset’s management form, making it possible to\nexhaust a server’s available memory by forcing it to create very large numbers\nof forms.
\nIn Django 1.3.6, all formsets have a strictly-enforced maximum number of forms\n(1000 by default, though it can be set higher via the max_num formset\nfactory argument).
In previous versions of Django, an admin user without change permission on a\nmodel could still view the Unicode representation of instances via their admin\nhistory log. Django 1.3.6 now limits the admin history log view for an object\nto users with change permission for that model.
\n