Add changes notes and new documentation related to operation of trusted proxy feature.

1 files changed, 88 insertions, 0 deletions

diff --git a/docs/release-notes/version-4.9.3.rst b/docs/release-notes/version-4.9.3.rst
index a1baafa..bdfbb51 100644
--- a/docs/release-notes/version-4.9.3.rst
+++ b/docs/release-notes/version-4.9.3.rst
@@ -5,3 +5,91 @@ Version 4.9.3
 Version 4.9.3 of mod_wsgi can be obtained from:
 
   https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.9.3
+
+Bugs Fixed
+----------
+
+* When using ``WSGITrustedProxies`` and ``WSGITrustedProxyHeaders`` in the
+  Apache configuration, or ``--trust-proxy`` and ``--trust-proxy-header``
+  options with ``mod_wsgi-express``, if you trusted the ``X-Client-IP``
+  header and a request was received from an untrusted client, the header
+  was not being correctly removed from the set of headers passed through to
+  the WSGI application.
+
+  This only occurred with the ``X-Client-IP`` header and the same problem was
+  not present if trusting the ``X-Real-IP`` or ``X-Forwarded-For`` headers.
+
+  The purpose of this feature for trusting a front end proxy was in this
+  case for the headers:
+
+    * ``X-Client-IP``
+    * ``X-Real-IP``
+    * ``X-Forwarded-For``
+
+  and was designed to allow the value of ``REMOTE_ADDR`` passed to the WSGI
+  application to be rewritten to the IP address that a trusted proxy said
+  was the real remote address of the client.
+
+  In other words, if a request was received from a proxy the IP address
+  of which was trusted, ``REMOTE_ADDR`` would be set to the value of the
+  single designated header out of those listed above which was to be
+  trusted.
+
+  In the case where the proxy was trusted, in addition to ``REMOTE_ADDR``
+  being rewritten, only the trusted header would be passed through. That is,
+  if ``X-Real-IP`` was the trusted header, then ``HTTP_X_REAL_IP`` would
+  be passed to the WSGI application, but ``HTTP_X_CLIENT_IP`` and
+  ``HTTP_X_FORWARDED_FOR`` would be dropped if corresponding headers had
+  also been supplied. That the header used to rewrite ``REMOTE_ADDR`` was
+  passed through still was only intended for the purpose of documenting
+  where the value of ``REMOTE_ADDR`` came from. A WSGI application when
+  relying on this feature should only ever use the value of ``REMOTE_ADDR``
+  and should ignore the header passed through.
+
+  The behaviour as described was therefore based on a WSGI application
+  not at the same time enabling any WSGI or web framework middleware to
+  try and process any proxy headers a second time and ``REMOTE_ADDR``
+  should be the single source of truth. Albeit the headers which were
+  passed through should have resulted in the same result for ``REMOTE_ADDR``
+  if the proxy headers were processed a second time.
+
+  Now in the case of the client a request was received from not being a
+  trusted proxy, then ``REMOTE_ADDR`` would not be rewritten, and would
+  be left as the IP of the client, and none of the headers listed above
+  were supposed to be passed through.
+
+  That ``REMOTE_ADDR`` is not rewritten is implemented correctly when the
+  client is not a trusted proxy, but of the three headers listed above,
+  ``HTTP_X_CLIENT_ID`` was not being dropped if the corresponding header
+  was supplied.
+
+  If the WSGI application followed best practice and only relied on the
+  value of ``REMOTE_ADDR`` as the source of truth for the remote client
+  address, then that ``HTTP_X_CLIENT_ID`` was not being dropped should
+  pose no security risk. There would however be a problem if a WSGI
+  application was still enabling a WSGI or web framework specific middleware
+  to process the proxy headers a second time even though not required. In this
+  case, the middleware used by the WSGI application may still trust the
+  ``X-Client-IP`` header and rewrite ``REMOTE_ADDR`` allowing a malicious
+  client to pretend to have a different IP address.
+
+  In addition to the WSGI application having redundant checks for the proxy
+  headers, to take advantage of this, a client would also need direct access
+  to the Apache/mod_wsgi server instance.
+
+  In the case that only clients on your private network behind your proxy
+  could access the Apache/mod_wsgi server instance, that would imply any
+  malicious actor already had access to your private network and had access
+  to hosts in that private network or could attach their own device to that
+  private network.
+
+  In the case where your Apache/mod_wsgi server instance could be accessed
+  from the same external networks as a proxy forwarding requests to it, such
+  as may occur if making use of a CDN proxy cache, a client would still need
+  to know the direct address used by the Apache/mod_wsgi server instance.
+
+  Note that only one proxy header for designating the IP of a client should
+  ever be trusted. If you trust more than one, then which will be used if
+  both are present is undefined as it is dependent on the order that Apache
+  processes headers. This hasn't changed and as before to avoid ambiguity you
+  should only trust one of the proxy headers recognised for this purpose.