IP address extraction using HTTP header requires additional care. Otherwise attackers might have a chance to deceive wrong ip address.

I fixed this problem.

See also: #855

I wrote detailed doc in labstack/echox#134, tl; dr:

• Don't use HTTP header unless it's reported by trustable client
• For XFF header, use rightmost untrustable value, not the leftmost value.
• When proxing, don't relay incoming X-Real-IP unless it's reported by trustable client

Especially about XFF header parsing, see implementations from other players:

• Rails:
  • doc: https://api.rubyonrails.org/classes/ActionDispatch/RemoteIp.html
  • src: https://github.com/rails/rails/blob/v6.0.2.1/actionpack/lib/action_dispatch/middleware/remote_ip.rb
• Express.js:
  • doc: https://expressjs.com/en/guide/behind-proxies.html
  • src: https://github.com/jshttp/proxy-addr/blob/v2.0.5/index.js
• Werkzeug (used by Flask)
  • src: https://github.com/pallets/werkzeug/blob/1.0.0/src/werkzeug/middleware/proxy_fix.py
  • doc: https://werkzeug.palletsprojects.com/en/1.0.x/middleware/proxy_fix/
• Nginx
  • doc: https://nginx.org/en/docs/http/ngx_http_realip_module.html
  • src: https://github.com/nginx/nginx/blob/release-1.17.8/src/http/ngx_http_core_module.c#L2619
• Envoy:
  • src: https://github.com/envoyproxy/envoy/blob/v1.13.0/source/common/http/utility.cc#L353

Another note about XFF header:

• it could be joined by , without whitespace (e.g.: http-party/node-http-proxy)
• multiple header might be set as mentioned in RFC 7230 (see also Go's reverseproxy)