diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/ref/settings.txt | 11 | ||||
| -rw-r--r-- | docs/releases/1.11.22.txt | 20 |
2 files changed, 27 insertions, 4 deletions
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index 0e856a12f9..6b84d34f77 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -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 diff --git a/docs/releases/1.11.22.txt b/docs/releases/1.11.22.txt index 91d81890df..58ea68146e 100644 --- a/docs/releases/1.11.22.txt +++ b/docs/releases/1.11.22.txt @@ -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``. |