You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per an email conversation with @tkurki, I am posting this issue here as the security aspect of this issue is not so critical that some other flow should be used.
SignalK always prefers using the exact value of the X-Forwarded-For header as the originating IP-address. This has several issues.
The X-Forwarded-For header is poorly standardized, and commonly has several different possible types of values, namely:
A comma-separated list of IP-addresses
A singular IP address
With IPv6 addresses maybe bracketized, and IP-addresses maybe being postfixed by a port number. See the linked Wikipedia article for more info.
The X-Forwarded-For header is not always used. Occasionally, a reverse proxy may create a Forwarded header instead. See RFC 7239 (linked)
A client may spoof either the X-Forwarded-For or the Forwarded header. It is therefore necessary to check whether the originating IP address of the request is a trusted proxy.
Possible solutions for the security issue
Boolean configuration option enabling the usage of X-Forwarded-For or Forwarded
This is by far the simplest solution. It is also relatively common. A configuration option would need to be added that either enables the current behaviour, but defaulting to a safer behaviour, namely just using the source IP address as per the IP header.
List of trusted proxies for only the first hop
This is also a relatively common solution. A list of IP-subnets can be specified. If the source IP address as per the IP header is in the list, then the headers are used, and otherwise the source IP address as per the IP header is used.
Possible solutions for the correctness issues
The first problem is choosing between X-Forwarded-For and Forwarded. A configuration option could be added for this, or one or the other can be preferred. I personally think that if we're going to prefer one header over the other, we should prefer Forwarded as it is well-specified as opposed to X-Forwarded-For.
The second is choosing the correct IP if a list is specified. This is relatively simple. Choose the last IP address in the list.
SignalK always prefers using the exact value of the
X-Forwarded-For
header as the originating IP-address. This has several issues.X-Forwarded-For
header is poorly standardized, and commonly has several different possible types of values, namely:With IPv6 addresses maybe bracketized, and IP-addresses maybe being postfixed by a port number. See the linked Wikipedia article for more info.
X-Forwarded-For
header is not always used. Occasionally, a reverse proxy may create aForwarded
header instead. See RFC 7239 (linked)X-Forwarded-For
or theForwarded
header. It is therefore necessary to check whether the originating IP address of the request is a trusted proxy.Possible solutions for the security issue
Boolean configuration option enabling the usage of
X-Forwarded-For
orForwarded
This is by far the simplest solution. It is also relatively common. A configuration option would need to be added that either enables the current behaviour, but defaulting to a safer behaviour, namely just using the source IP address as per the IP header.
List of trusted proxies for only the first hop
This is also a relatively common solution. A list of IP-subnets can be specified. If the source IP address as per the IP header is in the list, then the headers are used, and otherwise the source IP address as per the IP header is used.
Possible solutions for the correctness issues
The first problem is choosing between
X-Forwarded-For
andForwarded
. A configuration option could be added for this, or one or the other can be preferred. I personally think that if we're going to prefer one header over the other, we should preferForwarded
as it is well-specified as opposed toX-Forwarded-For
.The second is choosing the correct IP if a list is specified. This is relatively simple. Choose the last IP address in the list.
See
Problematic sites:
signalk-server/src/serverroutes.ts
Line 436 in 4489441
signalk-server/src/interfaces/ws.js
Line 363 in 4489441
The text was updated successfully, but these errors were encountered: