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

Don't override Host when forward-proxying - effectively preserving the transparent proxy approach #678

Closed

Conversation

similark
Copy link
Contributor

@similark similark commented May 19, 2023

Provide a description of what has been changed
This small change solves #331 - when building the forward proxy request, there's no need to override the Host field, which trashes the Host header altogether. The request has the proper value in the URL, making it reach the target svc and still preserving the original Host. This makes it possible to treat the request properly down the road (at the application level)

Checklist

Fixes #331

@similark similark requested a review from a team as a code owner May 19, 2023 10:17
@similark
Copy link
Contributor Author

Opinions, anyone? @JorTurFer

@JorTurFer
Copy link
Member

is this correct @t0rr3sp3dr0 ?

@similark
Copy link
Contributor Author

Just making note that this change is covered in the TestImmediatelySuccessfulProxy test.. meaning the request reaches its target as expected. Only difference is that now the Host header is kept as it was, and not updated. In a running cluster, the target pod will get the request with the actual Host in place, and not service_name.svc.NAMESPACE.....

@t0rr3sp3dr0
Copy link
Contributor

t0rr3sp3dr0 commented May 23, 2023

Yes, it makes sense that we don't override the Host header on incoming requests.

Looking at the entire function, we shouldn't override the Director from httputil.NewSingleHostReverseProxy the way we are doing. We should call the original Director implementation and then make our changes, otherwise we are just using a blank httputil.ReverseProxy and not httputil.NewSingleHostReverseProxy.

@t0rr3sp3dr0
Copy link
Contributor

t0rr3sp3dr0 commented May 23, 2023

I would do something like this:

	superDirector := proxy.Director
	proxy.Director = func(req *http.Request) {
		host := req.URL.Host
		superDirector(req)
		req.URL.Host = host

		// Strip client-provided forwarding headers to prevent IP spoofing.
		req.Header.Del("Forwarded")
		req.Header.Del("X-Forwarded-For")
		req.Header.Del("X-Forwarded-Host")
		req.Header.Del("X-Forwarded-Proto")
	}

For reference:

@similark similark force-pushed the similark/preserve_proxy_host_header branch from 7324e29 to 9c7de79 Compare May 28, 2023 10:30
@similark
Copy link
Contributor Author

similark commented May 28, 2023

@t0rr3sp3dr0 how about this? (I omitted the req.URL.Host blanking here)

@similark similark force-pushed the similark/preserve_proxy_host_header branch from 9c7de79 to 543c124 Compare June 27, 2023 10:12
@similark
Copy link
Contributor Author

Opinions, anyone? @tomkerkhove @JorTurFer @t0rr3sp3dr0
This is kind of a show-stopper for us, as any downstream application can't figure the original request.

@t0rr3sp3dr0
Copy link
Contributor

@similark, I’m ok with the changes, but you need to rebase your branch. The file you patched moved to interceptor/handler/upstream.go.

@t0rr3sp3dr0
Copy link
Contributor

Also, update CHANGELOG.md to reflect this change.

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

Successfully merging this pull request may close these issues.

Proxy redirection to the wrong URL
3 participants