1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
=============
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.
|
