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

Examine X-Forwarded-Host for additional port information #135

Merged
merged 11 commits into from
Apr 7, 2023

Conversation

boesing
Copy link
Member

@boesing boesing commented Apr 5, 2023

Q A
Bugfix yes

Description

Fixes #111

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
@boesing boesing added the Bug Something isn't working label Apr 5, 2023
@boesing boesing added this to the 2.24.1 milestone Apr 5, 2023
@boesing
Copy link
Member Author

boesing commented Apr 5, 2023

TBH: Not even sure if it makes any sense to pass a port via Host header. When I connect via TCP to port 443 and add port 80 to the Host header, it will still connect to 443 tho...
I wonder if any webserver out there then tries to internally connect to port 80. I hope they won't as this could be a serious security problem when some1 can use a webserver to actually connect to another port internally.

I guess most if not any webserver (besides apache2) do not pass any port via X-Forwarded-Host header but since there are already 2 reports regarding the same bug, I'd say lets fix this.

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
@boesing boesing requested a review from Ocramius April 5, 2023 13:48
…is only ignored when `X-Forwarded-Port` is available

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
@boesing boesing force-pushed the bugfix/x-forwarded-host-contains-port branch from 396866d to 441cd05 Compare April 6, 2023 00:32
This also requires `Uri` to be `psalm-immutable`.

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
…uppressed

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
…aracters

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
Copy link
Member

@weierophinney weierophinney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks... pretty sane. My one concern is how this plays with our fixes for [LP-2022-02](https://getlaminas.org/security/advisory/LP-2022-02}, though what it looks like in here is it is properly considering X-Forwarded-Port as the "source of truth" if both that and X-Forwarded-Host are present.

@TimWolla
Copy link
Contributor

TimWolla commented Apr 6, 2023

though what it looks like in here is it is properly considering X-Forwarded-Port as the "source of truth" if both that and X-Forwarded-Host are present.

@weierophinney From my understanding, the priority is implicitly decided based on the ordering of the headers within the $trustedHeaders list. I find this reasonable, but it should probably be spelled out explicitly that the order of headers matters (if this is the behavior we want to guarantee here).


The current version of the PR looks reasonable to me as well, the port is taken from the xfh header (if available), if both xfh and xfp match, it does the right thing by definition and if they differ, then the user is able to select the priority based on the ordering in the list. (If xfh and xfp differ, the reverse proxy is broken beyond repair, so … who cares).

Please just give me the time to also check the Traefik source code / behavior (see the existing comment thread with boesing), so that the decision can be backed up with some hard evidence in case someone complains in the future.

Copy link
Contributor

@TimWolla TimWolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The proposed behavior looks correct to me. There should likely be a follow-up that makes ->withHost() more strict to prevent it from accepting garbage (such as colons or whitespace). See also this comment in a previous PR of mine: #97 (comment)

Signed-off-by: Maximilian Bösing <2189546+boesing@users.noreply.github.com>
@boesing boesing changed the title Strip port from X-Forwarded-Host Examine X-Forwarded-Host for additional port information Apr 7, 2023
@boesing boesing merged commit a7a7f72 into laminas:2.24.x Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FilterUsingXForwardedHeaders should correctly deal with <host>:<port> pair in X-FORWARDED-HOST header
4 participants