mirror of
https://github.com/django/django.git
synced 2025-10-31 09:41:08 +00:00
Fixed CVE-2016-9014 -- Validated Host header when DEBUG=True.
This is a security fix.
This commit is contained in:
@@ -20,6 +20,28 @@ the ``manage.py test --keepdb`` option or if the user has an active session
|
||||
|
||||
A randomly generated password is now used for each test run.
|
||||
|
||||
DNS rebinding vulnerability when ``DEBUG=True``
|
||||
===============================================
|
||||
|
||||
Older versions of Django don't validate the ``Host`` header against
|
||||
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
|
||||
vulnerable to a `DNS rebinding attack
|
||||
<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
|
||||
|
||||
While Django doesn't ship a module that allows remote code execution, this is
|
||||
at least a cross-site scripting vector, which could be quite serious if
|
||||
developers load a copy of the production database in development or connect to
|
||||
some production services for which there's no development instance, for
|
||||
example. If a project uses a package like the ``django-debug-toolbar``, then
|
||||
the attacker could execute arbitrary SQL, which could be especially bad if the
|
||||
developers connect to the database with a superuser account.
|
||||
|
||||
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
|
||||
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
|
||||
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
|
||||
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
|
||||
now omit it to get those fallback values.
|
||||
|
||||
Bugfixes
|
||||
========
|
||||
|
||||
|
||||
Reference in New Issue
Block a user