Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http/httputil: support RFC 7239 Forwarded header in ReverseProxy #30963

Open
AndrewBurian opened this issue Mar 20, 2019 · 2 comments
Open

net/http/httputil: support RFC 7239 Forwarded header in ReverseProxy #30963

AndrewBurian opened this issue Mar 20, 2019 · 2 comments

Comments

@AndrewBurian
Copy link

@AndrewBurian AndrewBurian commented Mar 20, 2019

Revival of #20526 which was frozen due to age

I've been using services that make use of Go's Reverse Proxy, and think there's some substantial improvements in the Forwarded header that were overlooked in the original discussion.

Forwarded includes not just previous client IP, it also has the host and protocol, information that is currently haphazardly implemented in a few other non-standard X headers X-Forwarded-Proto and X-Forwarded-Host most of the time. There's also X-Real-IP competing with X-Forwarded-For, and while much less adopted, is used.

The protocol and host info also tends to not get nicely appended in the other headers as comma separated lists, and instead just clobbered by the most recent. If you're more than one proxy down, the chances of recovering that info is slim to nil, where as Forwarded would be a combined mechanism to ensure its survival.

Forwarded also specifies the format to put IPv6 addresses in, where as this is also somewhat mixed in implementation of X-Forwarded-For and requires a bunch of edge-case decoding.

Considering the RFC provides migration guidelines on how to build a Forwarded header in the presence of an X-Forwarded-For header, I see no reason we couldn't supply both and help push adoption.

I've got code and tests for such a feature on a branch, and would be more than happy to open a PR if there's interest.

@dunglas
Copy link
Contributor

@dunglas dunglas commented Nov 18, 2019

This feature is very needed for https://vulcain.rocks, and I guess for most reverse proxies.

@sporkmonger
Copy link

@sporkmonger sporkmonger commented Jan 21, 2020

If we're considering implementing the Forwarded header, I'd encourage any test suites to cover edge cases, including violations of the specification. In particular, the usage of double quotes, semicolons, commas, and square brackets have the potential to break parsing. For instance, cases like these might result in rather unexpected behavior:

Forwarded: for="
Forwarded: for=";"
Forwarded: for="""
Forwarded: for="";"
Forwarded: for="[
Forwarded: for=","

Keeping in mind that this header can be sent by untrusted sources, these could have undesirable upstream effects like obscuring the real client IP or, depending on implementation details, potentially causing the whole header to be rejected or ignored, giving an attacker the ability to bypass upstream (or possibly in-process) security mechanisms or fraud checks. While I'm in favor of implementing support for this header, I believe it should be done with a test suite that includes adversarial cases.

Also the spec allows for optional port numbers even though they aren't commonly seen, as well as underscore-prefixed obfuscation identifiers in place of both the IP and port, and those should probably have tests too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.