3 ms·

... and only if the proxy attempted to interpret the query parameters. If they just route based on path, and do not modify the query at all, and do not try to u

... and only if the proxy attempted to interpret the query parameters. If they just route based on path, and do not modify the query at all, and do not try to use a query parameter as a cache key, then there's no problem. This is really about caching proxies. If the proxy attempts to cache based on some attributes of the request, then it has a lot of request normalizing it needs to do. Some more examples of things that some languages (in this case Go) may parse differently than some web proxies: https://github.com/golang/go/issues/25192#issuecomment-806252940 https://github.com/golang/go/issues/25192#issuecomment-80625... And a more overall argument that putting this "vulnerability" on the language library (in Python and Go) does not make the most sense: https://github.com/golang/go/issues/25192#issuecomment-796858310 https://github.com/golang/go/issues/25192#issuecomment-79685...

Too 5y ago
Exactly. This is only a vulnerability if you send the same raw url to two different systems and base your security on expecting them to treat it identical, to the point of being bug-for-bug compatible. As we’ve seen with multiple other vulnerabilities this can be very fragile. Especially when the complexity of the protocol grows, the recent saml signature mixups being a good example of such https://news.ycombinator.com/item?id=28064835 https://news.ycombinator.com/item?id=28064835 If your auth/proxy parses some parameters used by both the proxy and the app it should forward what it parsed, not the original unparsed data. Only exception is a cache or a best-effort-firewall, but then it’s no longer a vulnerability, just an ordinary bug.