Dataverse: Feature Request: re-enable IP group usage with X-Forwarded-For header

Created on 13 Dec 2019  路  3Comments  路  Source: IQSS/dataverse

This is a successor to #1368 and a follow up to #2826.
Mentioning @pdurbin, @landreev, @djbrooke, @scolapasta, @michbarsinai


Context

When running on Kubernetes, you are most likely not going to use Apache + AJP as your reverse proxy. This will either be nginx or traefik on private clouds, or other ingress controllers like Amazon ALB on public clouds.

Running on Kubernetes, the application server will never be exposed directly in production setups. (If so, this is a bad idea). Thus you have no option to use IP groups at all in these setups. (For a production grade Docker deployment this should be true, too)

Proposed solution

  1. Create a database setting :EnableProxyIPGroups, defaulting to off
  2. Modify DataverseRequest constructor to enable processing X-Forwarded-For header when setting enabled.

    • Maybe add safeguards about trusted proxy addresses (living in the header value)

    • Maybe add safeguards that proxy shall have a RFC1918 address when not specified as trusted IP

  3. Describe setting in docs. Add BIG warning about possible abuse and precautions. Hint to relevant doc pieces of proxies about secured usage. (All ingress controllers I know filter this header on incoming requests unless otherwise configured)

Benefits

Bring back easy groups for advanced setups, otherwise not available. IP groups are very easy to use in many cases.

Possible drawbacks and risks

As outlined in #1368 and #2826, this header is always a security risk. Because of that, it should only be used when you know what you do, have proper documentation etc.

Estimated complexity/size/time

Should be fairly easy to do, low hanging fruit. Safeguards are a bit tricky.

Resources

I would offer a contribution. Usual Code Review / QA process.

Most helpful comment

@lwo and @bikramj might have some opinions on this too.

From my perspective, around 4 years ago when we removed "X-Forwarded-For" I helped contact forks of Dataverse to make sure they understood the security impact, especially if you spoof "localhost" to make yourself a superuser. Here's an example (for those with access) of me contacting at fork: https://help.hmdc.harvard.edu/Ticket/Display.html?id=231692

鈿狅笍 鈿狅笍 鈿狅笍 I'll just say that we should be very, very, very careful. 鈿狅笍 鈿狅笍 鈿狅笍

All 3 comments

@lwo and @bikramj might have some opinions on this too.

From my perspective, around 4 years ago when we removed "X-Forwarded-For" I helped contact forks of Dataverse to make sure they understood the security impact, especially if you spoof "localhost" to make yourself a superuser. Here's an example (for those with access) of me contacting at fork: https://help.hmdc.harvard.edu/Ticket/Display.html?id=231692

鈿狅笍 鈿狅笍 鈿狅笍 I'll just say that we should be very, very, very careful. 鈿狅笍 鈿狅笍 鈿狅笍

We might think about using the more secure way of RFC7239.
See also the "secret" value at https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

Yes, we tried to request the same when we were trying HAProxy to Glassfish direct traffic but had to add apache in between to support IP Groups. Another thing which will stop working without apache is Shibboleth logins.

Was this page helpful?
0 / 5 - 0 ratings