-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Path normalization controls #6589
Comments
Bumping priority, since today we still have normalization disabled by default. |
Once we have this, we should ensure that normalization occurs by default. |
Looking at this along with #6588 |
Work on finding a library for normalisation progessed on #6588 seems tied to the solution for this. Will monitor and action pending outcome of same. |
@twghu related but not dependent, I think we can add in the controls with the existing |
Hi @htuch , I'm using Istio and I'm having an issue related with path traversal. The Envoy version is 1.12. Istio brings the normalize path configuration enabled by default, as we can see here. Even with that configuration enabled, I still can navigate through the url path, for instance:
According with this link, Envoy already has fixed that. I've checked out the |
@jonnysgomes normalized Without normalization, With normalization, |
Implementation: Requirements:
Changes:
|
This seems like a good design to me. @PiotrSikora @mattklein123 thoughts? You'll need to be careful about dumping |
Sorry I'm having a hard time wrapping my head around ^ without seeing it in context with the existing config. Can you potentially do a config/docs only PR and we can discuss the proposal there? |
Hey @mattklein123 See #11111 |
Is this only about path? Or would something like #14491 fall in scope? Essentially allowing the original Host header (with port) to be forwarded while routing without the port internally. The current behavior forwards the modified host header, much like the path normalization |
Another similar question as above: Is header case normalization in scope? I can open a new issue if its both desired and out of scope. istio/istio#30579 for reference |
I think #8463 is tracking this one @howardjohn. |
For observability, if we split this path we may want to default log the original path (that contains the most information, normalized paths can be recovered from the original). We should add formatters like |
Yes, I think original path should be default as anyone doing audit logging will want to see that. |
I was considering this upstream as well. While there is always a risk passing on an unsanitized, unnormalized URI, there might be security applications which want to know the original URI. It would make sense to be able to pass these as an x-original-uri header field (with appropriate header value quoting and escaping, obviously.) |
The fix for CVE-2019-9900, provided a coarse grained ability to opt-in/out of path normalization. That is, you could either normalize, in which case both normalization was used for matching and transforming the path to the upstream, or not normalize.
Ideally we provide finer grained controls similar to Nginx, where users can opt to normalize for match independent of transforming the path to the upstream.
CC @PiotrSikora
Action item for CVE-2019-9901
The text was updated successfully, but these errors were encountered: