Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 884e113

Browse files
timgrahamtimgraham
committed
[1.10.x] Fixed CVE-2016-9014 -- Validated Host header when DEBUG=True.
This is a security fix.
1 parent 34e1072 commit 884e113

7 files changed

Lines changed: 95 additions & 22 deletions

File tree

‎django/http/request.py‎

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -96,12 +96,13 @@ def get_host(self):
9696
"""Return the HTTP host using the environment or request headers."""
9797
host = self._get_raw_host()
9898

99-
# There is no hostname validation when DEBUG=True
100-
if settings.DEBUG:
101-
return host
99+
# Allow variants of localhost if ALLOWED_HOSTS is empty and DEBUG=True.
100+
allowed_hosts = settings.ALLOWED_HOSTS
101+
if settings.DEBUG and not allowed_hosts:
102+
allowed_hosts = ['localhost', '127.0.0.1', '[::1]']
102103

103104
domain, port = split_domain_port(host)
104-
if domain and validate_host(domain, settings.ALLOWED_HOSTS):
105+
if domain and validate_host(domain, allowed_hosts):
105106
return host
106107
else:
107108
msg = "Invalid HTTP_HOST header: %r." % host

‎docs/ref/settings.txt‎

Lines changed: 8 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -90,14 +90,19 @@ If the ``Host`` header (or ``X-Forwarded-Host`` if
9090
list, the :meth:`django.http.HttpRequest.get_host()` method will raise
9191
:exc:`~django.core.exceptions.SuspiciousOperation`.
9292

93-
When :setting:`DEBUG` is ``True`` or when running tests, host validation is
94-
disabled; any host will be accepted. Thus it's usually only necessary to set it
95-
in production.
93+
When :setting:`DEBUG` is ``True`` and ``ALLOWED_HOSTS`` is empty, the host
94+
is validated against ``['localhost', '127.0.0.1', '[::1]']``.
9695

9796
This validation only applies via :meth:`~django.http.HttpRequest.get_host()`;
9897
if your code accesses the ``Host`` header directly from ``request.META`` you
9998
are bypassing this security protection.
10099

100+
.. versionchanged:: 1.10.3
101+
102+
In older versions, ``ALLOWED_HOSTS`` wasn't checked if ``DEBUG=True``.
103+
This was also changed in Django 1.9.11 and 1.8.16 to prevent a
104+
DNS rebinding attack.
105+
101106
.. setting:: APPEND_SLASH
102107

103108
``APPEND_SLASH``

‎docs/releases/1.10.3.txt‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,28 @@ the ``manage.py test --keepdb`` option or if the user has an active session
2020

2121
A randomly generated password is now used for each test run.
2222

23+
DNS rebinding vulnerability when ``DEBUG=True``
24+
===============================================
25+
26+
Older versions of Django don't validate the ``Host`` header against
27+
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
28+
vulnerable to a `DNS rebinding attack
29+
<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
30+
31+
While Django doesn't ship a module that allows remote code execution, this is
32+
at least a cross-site scripting vector, which could be quite serious if
33+
developers load a copy of the production database in development or connect to
34+
some production services for which there's no development instance, for
35+
example. If a project uses a package like the ``django-debug-toolbar``, then
36+
the attacker could execute arbitrary SQL, which could be especially bad if the
37+
developers connect to the database with a superuser account.
38+
39+
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
40+
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
41+
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
42+
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
43+
now omit it to get those fallback values.
44+
2345
Bugfixes
2446
========
2547

‎docs/releases/1.8.16.txt‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,3 +19,25 @@ the ``manage.py test --keepdb`` option or if the user has an active session
1919
(such as an attacker's connection).
2020

2121
A randomly generated password is now used for each test run.
22+
23+
DNS rebinding vulnerability when ``DEBUG=True``
24+
===============================================
25+
26+
Older versions of Django don't validate the ``Host`` header against
27+
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
28+
vulnerable to a `DNS rebinding attack
29+
<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
30+
31+
While Django doesn't ship a module that allows remote code execution, this is
32+
at least a cross-site scripting vector, which could be quite serious if
33+
developers load a copy of the production database in development or connect to
34+
some production services for which there's no development instance, for
35+
example. If a project uses a package like the ``django-debug-toolbar``, then
36+
the attacker could execute arbitrary SQL, which could be especially bad if the
37+
developers connect to the database with a superuser account.
38+
39+
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
40+
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
41+
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
42+
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
43+
now omit it to get those fallback values.

‎docs/releases/1.9.11.txt‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,3 +19,25 @@ the ``manage.py test --keepdb`` option or if the user has an active session
1919
(such as an attacker's connection).
2020

2121
A randomly generated password is now used for each test run.
22+
23+
DNS rebinding vulnerability when ``DEBUG=True``
24+
===============================================
25+
26+
Older versions of Django don't validate the ``Host`` header against
27+
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
28+
vulnerable to a `DNS rebinding attack
29+
<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
30+
31+
While Django doesn't ship a module that allows remote code execution, this is
32+
at least a cross-site scripting vector, which could be quite serious if
33+
developers load a copy of the production database in development or connect to
34+
some production services for which there's no development instance, for
35+
example. If a project uses a package like the ``django-debug-toolbar``, then
36+
the attacker could execute arbitrary SQL, which could be especially bad if the
37+
developers connect to the database with a superuser account.
38+
39+
``settings.ALLOWED_HOSTS`` is now validated regardless of ``DEBUG``. For
40+
convenience, if ``ALLOWED_HOSTS`` is empty and ``DEBUG=True``, the following
41+
variations of localhost are allowed ``['localhost', '127.0.0.1', '::1']``. If
42+
your local settings file has your production ``ALLOWED_HOSTS`` value, you must
43+
now omit it to get those fallback values.

‎tests/csrf_tests/tests.py‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -377,7 +377,7 @@ def test_bare_secret_accepted_and_replaced(self):
377377
self.assertEqual(len(csrf_cookie.value), CSRF_TOKEN_LENGTH)
378378
self._check_token_present(resp, csrf_id=csrf_cookie.value)
379379

380-
@override_settings(DEBUG=True)
380+
@override_settings(DEBUG=True, ALLOWED_HOSTS=['www.example.com'])
381381
def test_https_bad_referer(self):
382382
"""
383383
Test that a POST HTTPS request with a bad referer is rejected

‎tests/requests/tests.py‎

Lines changed: 15 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -756,21 +756,22 @@ def test_get_port_with_x_forwarded_port(self):
756756
self.assertEqual(request.get_port(), '8080')
757757

758758
@override_settings(DEBUG=True, ALLOWED_HOSTS=[])
759-
def test_host_validation_disabled_in_debug_mode(self):
760-
"""If ALLOWED_HOSTS is empty and DEBUG is True, all hosts pass."""
761-
request = HttpRequest()
762-
request.META = {
763-
'HTTP_HOST': 'example.com',
764-
}
765-
self.assertEqual(request.get_host(), 'example.com')
759+
def test_host_validation_in_debug_mode(self):
760+
"""
761+
If ALLOWED_HOSTS is empty and DEBUG is True, variants of localhost are
762+
allowed.
763+
"""
764+
valid_hosts = ['localhost', '127.0.0.1', '[::1]']
765+
for host in valid_hosts:
766+
request = HttpRequest()
767+
request.META = {'HTTP_HOST': host}
768+
self.assertEqual(request.get_host(), host)
766769

767-
# Invalid hostnames would normally raise a SuspiciousOperation,
768-
# but we have DEBUG=True, so this check is disabled.
769-
request = HttpRequest()
770-
request.META = {
771-
'HTTP_HOST': "invalid_hostname.com",
772-
}
773-
self.assertEqual(request.get_host(), "invalid_hostname.com")
770+
# Other hostnames raise a SuspiciousOperation.
771+
with self.assertRaises(SuspiciousOperation):
772+
request = HttpRequest()
773+
request.META = {'HTTP_HOST': 'example.com'}
774+
request.get_host()
774775

775776
@override_settings(ALLOWED_HOSTS=[])
776777
def test_get_host_suggestion_of_allowed_host(self):

0 commit comments

Comments
 (0)