Fixed CVE-2019-12781 -- Made HttpRequest always trust SECURE_PROXY_SSL_HEADER if set.

An HTTP request would not be redirected to HTTPS when the
SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings were used if
the proxy connected to Django via HTTPS.

HttpRequest.scheme will now always trust the SECURE_PROXY_SSL_HEADER if
set, rather than falling back to the request scheme when the
SECURE_PROXY_SSL_HEADER did not have the secure value.

Thanks to Gavin Wahl for the report and initial patch suggestion, and
Shai Berger for review.
This commit is contained in:
Carlton Gibson 2019-06-13 10:57:29 +02:00 committed by Mariusz Felisiak
parent 30b3ee9d0b
commit 54d0f5e62f
6 changed files with 85 additions and 9 deletions

View file

@ -2253,10 +2253,13 @@ By default, ``is_secure()`` determines if a request is secure by confirming
that a requested URL uses ``https://``. This method is important for Django's
CSRF protection, and it may be used by your own code or third-party apps.
If your Django app is behind a proxy, though, the proxy may be "swallowing" the
fact that a request is HTTPS, using a non-HTTPS connection between the proxy
and Django. In this case, ``is_secure()`` would always return ``False`` -- even
for requests that were made via HTTPS by the end user.
If your Django app is behind a proxy, though, the proxy may be "swallowing"
whether the original request uses HTTPS or not. If there is a non-HTTPS
connection between the proxy and Django then ``is_secure()`` would always
return ``False`` -- even for requests that were made via HTTPS by the end user.
In contrast, if there is an HTTPS connection between the proxy and Django then
``is_secure()`` would always return ``True`` -- even for requests that were
made originally via HTTP.
In this situation, configure your proxy to set a custom HTTP header that tells
Django whether the request came in via HTTPS, and set