Fixed #28693 -- Fixed DisallowedHost crash in CsrfViewMiddleware when an HTTPS request has an invalid host. #9268
Conversation
r3m0t
force-pushed
the
28693-csrf-on-400
branch
from
974ec75
to
dabb90e
Compare
docs/releases/1.11.7.txt
Outdated
| @@ -13,3 +13,6 @@ Bugfixes | |||
| argument is a callable that returns ``None`` (:ticket:`28601`). | |||
|
|
|||
| * Fixed the Basque ``DATE_FORMAT`` string (:ticket:`28710`). | |||
|
|
|||
| * Fixed sending status 500 instead of status 400 when an incorrect `Host` | |||
There was a problem hiding this comment.
I'm not sure that it's important to backport the fix. It seems like it would only affect someone who isn't following the deployment advice,
You should also configure the Web server that sits in front of Django to validate the host. It should respond with a static error page or ignore requests for incorrect hosts instead of forwarding the request to Django. This way you’ll avoid spurious errors in your Django logs (or emails if you have error reporting configured that way).
| @override_settings(ALLOWED_HOSTS=['www.example.com']) | ||
| def test_bad_request_bad_host(self): | ||
| """ | ||
| The bad request page loads. |
There was a problem hiding this comment.
if the Host header isn't in ALLOWED_HOSTS.
timgraham
changed the title
r3m0t
force-pushed
the
28693-csrf-on-400
branch
from
dabb90e
to
771b3b8
Compare
|
@timgraham fixed |
|
Did you see and consider my comment, "A test in tests/csrf_tests/tests.py is probably appropriate (or perhaps more appropriate than the one for bad_request) consider that's where the problem is." |
|
No, I will see if that's possible |
r3m0t
force-pushed
the
28693-csrf-on-400
branch
from
771b3b8
to
4714217
Compare
|
@timgraham yep, fixed (for real this time) |
tests/csrf_tests/tests.py
Outdated
| req.META['HTTP_REFERER'] = 'https://www.evil.org/somepage' | ||
| req.META['SERVER_PORT'] = '443' | ||
| resp = requires_csrf_token(token_view)(req) | ||
| self.assertEqual(resp.status_code, 200) |
There was a problem hiding this comment.
I'm not sure I totally understand this test.
Does it actually involve the bad-request page? It doesn't look like it, but the docstring says so.
Why is the status code 200, rather than 400? This looks to me like a request with an HTTP_HOST that doesn't match ALLOWED_HOSTS.
There was a problem hiding this comment.
No, it doesn't. requires_csrf_token(token_view) is a standin for the default 400 handler, but it gives status 200. I will improve the docstring.
r3m0t
force-pushed
the
28693-csrf-on-400
branch
from
4714217
to
ecca433
Compare
timgraham
force-pushed
the
28693-csrf-on-400
branch
5 times, most recently
from
4d4d152
to
631416d
Compare
…st has an invalid host.
timgraham
force-pushed
the
28693-csrf-on-400
branch
from
631416d
to
7ec0fdf
Compare
https://code.djangoproject.com/ticket/28693