Incorrect middleware ordering allows invalid HTTP_HOST header to cause CsrfViewMiddleware failure when using CSRF_USE_SESSIONS.

[Mark Gregson]

I've observed that when using CSRF_USE_SESSIONS = True and with SessionMiddleware correctly placed before CsrfViewMiddleware that a request with an invalid HTTP_HOST header raises an exception and, while preparing a response for this exception, the CsrfViewMiddleware raises an unhandled ImproperlyConfigured exception and an internal server error is returned to the browser.

I expect that an HTTP 400 will be returned to the user for an invalid HTTP_HOST header and that the CsrfViewMiddleware will not raise an exception.

To reproduce, configure the application as above, set up a new hostname (one that is not in ALLOWED_HOSTS) pointing at the Django application (using the hosts file, for example), and then request that hostname.

[Carlton Gibson]

Hi Mark. Do you have an example project you can upload demonstrating this issue? Thanks!

[Mark Gregson]

Hi Carlton. Not one I can easily share. I'll see if I can create a minimal project that reproduces it.

[Mark Gregson]

Patch to create minimal project reproducing the bug

[Mark Gregson]

Okay, I've just attached a minimal working example. I've provided it as a patch to a 'django-admin startproject' site template using Django 1.11.18. You should just be able to do:

1. django-admin startproject mysite
2. cd mysite
3. patch -p1 < min_example.diff

In this example I've configured ALLOWED_HOSTS = ['localhost'] and added '127.0.0.1 dummy' to my /etc/hosts file. Requesting ​http://dummy:8000/ reproduces the ImproperlyConfigured exception.

While producing this example I found that placing CommonMiddleware before SessionMiddleware was also required to reproduce the bug. I'm unsure if this is a configuration error; but I couldn't see anything about ordering of those two middleware classes when I scanned the documentation just now.

Cheers
Mark

[Carlton Gibson]

Hey Mark. Super effort. Thank you. I’ll have a look at the project and get back to you. 👍

[Carlton Gibson]

OK, this is a documentation issue.

Error views are wrapped with @requires_csrf_token, so SessionMiddleware must appear before any middleware that may raise an exception when using CSRF_USE_SESSIONS.

The default project template has this correct, so you have to "opt-in" to this error.

​PR

Thanks for the report and the project to reproduce Mark!

[Mark Gregson]

Thanks Carlton. Appreciate the quick review.

[Tim Graham <timograham@…>]

In 89d39dc:

[2.2.x] Fixed #30091 -- Doc'd middleware ordering requirements with CSRF_USE_SESSIONS.

Backport of bae66e759faee8513da4b11d3fd16b044b415bdb from master.

[Tim Graham <timograham@…>]

In bae66e75:

Fixed #30091 -- Doc'd middleware ordering requirements with CSRF_USE_SESSIONS.