@@ -199,13 +199,14 @@ def _get_scheme(self):

def scheme(self):

if settings.SECURE_PROXY_SSL_HEADER:

try:

header, value = settings.SECURE_PROXY_SSL_HEADER

header, secure_value = settings.SECURE_PROXY_SSL_HEADER

except ValueError:

raise ImproperlyConfigured(

'The SECURE_PROXY_SSL_HEADER setting must be a tuple containing two values.'

)

if self.META.get(header) == value:

return 'https'

header_value = self.META.get(header)

if header_value is not None:

return 'https' if header_value == secure_value else 'http'

return self._get_scheme()

def is_secure(self):

@@ -2189,10 +2189,13 @@ whether a request is secure by looking at whether the requested URL uses

"https://". This is important for Django's CSRF protection, and 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, you'll want to configure your proxy to set a custom HTTP

header that tells Django whether the request came in via HTTPS, and you'll want

@@ -5,3 +5,23 @@ Django 1.11.22 release notes

*July 1, 2019*

Django 1.11.22 fixes a security issue in 1.11.21.

CVE-2019-12781: Incorrect HTTP detection with reverse-proxy connecting via HTTPS

--------------------------------------------------------------------------------

When deployed behind a reverse-proxy connecting to Django via HTTPS,

:attr:`django.http.HttpRequest.scheme` would incorrectly detect client

requests made via HTTP as using HTTPS. This entails incorrect results for

:meth:`~django.http.HttpRequest.is_secure`, and

:meth:`~django.http.HttpRequest.build_absolute_uri`, and that HTTP

requests would not be redirected to HTTPS in accordance with

:setting:`SECURE_SSL_REDIRECT`.

``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it

is configured, and the appropriate header is set on the request, for both HTTP

and HTTPS requests.

If you deploy Django behind a reverse-proxy that forwards HTTP requests, and

that connects to Django via HTTPS, be sure to verify that your application

correctly handles code paths relying on ``scheme``, ``is_secure()``,

``build_absolute_uri()``, and ``SECURE_SSL_REDIRECT``.

@@ -334,6 +334,18 @@ def test_set_with_xheader_right(self):

req.META['HTTP_X_FORWARDED_PROTOCOL'] = 'https'

self.assertIs(req.is_secure(), True)

@override_settings(SECURE_PROXY_SSL_HEADER=('HTTP_X_FORWARDED_PROTOCOL', 'https'))

def test_xheader_preferred_to_underlying_request(self):

class ProxyRequest(HttpRequest):

def _get_scheme(self):

"""Proxy always connecting via HTTPS"""

return 'https'

# Client connects via HTTP.

req = ProxyRequest()

req.META['HTTP_X_FORWARDED_PROTOCOL'] = 'http'

self.assertIs(req.is_secure(), False)

class IsOverriddenTest(SimpleTestCase):

def test_configure(self):