vertx-web icon indicating copy to clipboard operation
vertx-web copied to clipboard

Add list of trusted origin IP's for `Forward` http header

Open onyn opened this issue 2 years ago • 0 comments

We have real ip feature but lack configurable list of IP addresses of trusted origins of Forwarded http header.

I found ticket where problem pretty well described. I totally agree with this comment. However there's interesting situation.

Problem

I have vertx application behind cloudflare proxy (used for mitigating DDOS attacks):

1

Also there's couple of enterprise clients who refuses to send requests via cloudflare for their own policy and security reasons. They wanted direct connection to my infrastructure:

2

And there's problem. I need to know real IP of clients behind cloudflare and also want protect myself from potential tampering of IP address by directly connected users.

My current solution is place nginx reverse proxy in between:

3

Nginx strips any forwarding headers from client and put its own headers.

Involving nginx just for sanitizing couple of http headers is tedious and places unnecessary maintenance burden.

Proposal

Add several options to the HttpServerOptions class:

  1. trustedForwardOrigins - list of individual IP addresses (1.2.3.4, 2001:db8::1) and CIDR networks (1.2.3.4/24, 2001:db8::/32)
  2. forwardHeaders - one of AllowForwardHeaders enum values with addition of new value named CUSTOM_HEADER
  3. customForwardHeader - name of http header where real IP address resides if forwardHeaders has CUSTOM_HEADER value

CUSTOM_HEADER and customForwardHeader are not strictly necessary and needs to be discussed. Cloudflare uses nonstandard CF-Connecting-IP and True-Client-IP in addition to X-Forwarded-* http headers. Eventually cloudflare may implement rfc7239. But there may be other proxy services and software with their own bizarre forwarding headers. For example I personally saw X-Real-IP header in real use.

Algorithm of resolvilng IP:

  1. If trustedForwardOrigins is null or empty, then we trust forwarding headers from everyone.
  2. If request comes from IP that is listed in trustedForwardOrigins, then process forwarding headers.
  3. If request comes from IP that is not listed in trustedForwardOrigins, then forwarding headers totally ignored.

That's how nginx realip module works.

Proposed options may be added to Router interface. But I have seen that the real IP functionality is always configurable at the server-wide level. Not per-route.

onyn avatar Dec 23 '22 21:12 onyn