Skip to content

Swith the rate limiter from using X-Forwarded-For to be using Fly-Client-IP for a fly setup #3227

Description

@sydseter

What can go Wrong?

The current rate-limiting design is easy to evade in common proxy or multi-instance deployments. The rate limiting trusts the left-most X-Forwarded-For value and explicitly skips connection limiting when only remote_ip is available. The counters are kept in the in-memory GenServer. That means spoofed forwarded headers, multiple app nodes, or proxy/header misconfiguration can let an attacker bypass the main abuse-control mechanism. We are more than happy to get suggestions for how to improve the rate-limiting. Currently we are not seeing a lot of issues concerning the misuse of our services in production.

The Fly.io reverse proxy does not strip or rewrite untrusted X-Forwarded-For headers before traffic reaches Phoenix. It is therefor still possible to circumvent the rate-limiter.

What are we going to do about it?

Swith the rate limiter from using X-Forwarded-For to be using Fly-Client-IP for a fly setup. Make the change configurable and use X-Forwarded-For by default. We don't know whether this really will work, but we can test it out.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcopi.owasp.orgelixirPull requests that update elixir code

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions