net/http/httputil: ReverseProxy should not forward unparseable query parameters

[neild]

We generally treat malformed value pairs in URL queries as a soft error, ignoring the invalid pair but accepting others. For example, the following (playground link) accepts the value for the key b even as it rejects the invalid one for a:

u, _ := url.Parse("http://go.dev/?a=%x&b=ok")
v, err := url.ParseQuery(u.RawQuery)
fmt.Println(v, err)
// map[b:[ok]] invalid URL escape "%x"

ReverseProxy should not include unparseable query parameters when forwarding a request, since this is a vector for parameter smuggling. In Go 1.17, we changed URL parsing to reject keys containing a semicolon (https://go.dev/issue/25192). If a Go 1.17 ReverseProxy forwards a request to a backend which treats semicolons as a parameter separator (as Go 1.16 and earlier did), the proxy and backend may disagree on the parameter values of the request.

Thanks to Oxeye for pointing out this issue: https://www.oxeye.io/blog/golang-parameter-smuggling-attack

[gopherbot]

Change https://go.dev/cl/425417 mentions this issue: net/http/httputil: ReverseProxy should not forward unparseable query parameters

[chrisguiney]

Is this going to be present in a 1.19.x release, or strictly a 1.20 change?

Unfortunately it's behavior that I'm currently depending on, so I'll need to find a way to maintain the current behavior. For context, I'm reverse proxying to a server that doesn't use ; as a separator, but does allow them as part of a key or value.

I've accepted that there's apparently no room for discussion on how to handle semicolons. I do hope that there can at least be a way to restore prior behavior. Working around this is going to be difficult given the changeset in https://go.dev/cl/425417

[neild]

Is this going to be present in a 1.19.x release, or strictly a 1.20 change?

We don't even know what the fix for this is yet.

The basic requirement as I see it is that if a proxy Director or Rewrite func parses the query parameters, we must not forward unparsed parameters by default. Given that, what change can we make that has the least impact and preserves the most flexibility?

[chrisguiney]

Ah sorry, I hadn't looked closely enough at the PR to see it wasn't merged yet.

My ideal solution at this point would be to introduce url.QueryParser and url.QueryEncoder interfaces, with default implementations calling url.ParseQuery and Values.Encode respectively (and exposed through package variables url.DefaultQueryParser and url.DefaultQueryEncoder).

From there, updating ReverseProxy with a url.QueryParser field that defaults to url.DefaultQueryParser. The same could be done for the net/http package, and anywhere else urls are parsed in the standard library.

This approach should maintain backwards compatibility, while allowing people with particular needs the ability to supply their own parser/encoder. In the long run, I think this is the way to go -- urls are tricky things that are both ubiquitous and varying interpretations of the RFCs exist throughout the internet.

I also realize that's touching more components than just httputil.ReverseProxy -- and would be a much bigger lift. I'd personally be happy with even just a boolean flag, or context variable to restore previous behavior, or maybe a QueryParser func(s) (Values, error) field

---

quick sketch of the interface described above:

var (
    DefaultQueryParser QueryParser = defaultQueryParser{}
    DefaultQueryEncoder QueryEncoder = defaultQueryParser{}
)

type QueryParser {
    Parse(string) (Values, error)
}

type QueryEncoder {
    Encode(Values) (string, error)
}

type defaultQueryParser struct{}

func (defaultQueryParser) Parse(s string) (Values, error) {
    return ParseQuery(s)
}

func (defaultQueryParser) Encode(v Values) (string, error) {
    return v.Encode(), nil
}

[neild]

Behavior which I think strikes the right balance between security and compatibility:

Clean the outgoing request's req.URL.RawQuery to remove unparseable parameters

• If req.Form != nil after calling ReverseProxy.Director.
• Before calling ReverseProxy.Rewrite.

When using the Director hook, RawQuery is cleaned only if the hook parsed the query parameters. A Director func which doesn't examine query parameters will pass garbage through untouched, but that's okay because it (probably) wasn't making decisions based on it.

When using the Rewrite hook (new in 1.20, intended to be the recommended replacement for Director for all uses), RawQuery gets cleaned by default. (We can't easily conditionalize this on whether the hook parses the form or not, because a design goal of Rewrite is that we give it the outgoing request we intend to send--we don't want to modify that request further after Rewrite returns.) To disable this, you can just restore the old value in Rewrite:

Rewriter: func(r *ProxyRequest) {
  r.Out.URL = r.In.URL // use uncleaned query parameters
}

[gopherbot]

Change https://go.dev/cl/432976 mentions this issue: net/http/httputil: avoid query parameter smuggling

[neild]

This is CVE-2022-2880.

[neild]

@gopherbot please open backport issues

[gopherbot]

Backport issue(s) opened: #55842 (for 1.18), #55843 (for 1.19).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/433695 mentions this issue: [release-branch.go1.18] net/http/httputil: avoid query parameter smuggling

[gopherbot]

Change https://go.dev/cl/433735 mentions this issue: [release-branch.go1.19] net/http/httputil: avoid query parameter smuggling