Re: [PR] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932961663 Alright, I guess I got this wrong then, thanks for your detailed explanations. In case others are wondering about the same issue I found two bugs for reference on prominent software projects that apparently implemented it wrong then: - https://github.com/golang/go/issues/3659 - https://trac.nginx.org/nginx/ticket/727 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
markt-asf commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932891346 Nope, `%2F` is NOT equivalent to `/` in a URI as explained in section 2.2 of RFC 3986. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932841669 Thanks for checking back! The section you are referring to does not really negate my statement however. If I get you right you are talking about this specific thing? > These URIs should be normalized by decoding any percent-encoded octet **that corresponds to an unreserved character** This does not mean that reserved characters can't be decoded or? Maybe we can debate this together to clear my confusion. Let me point out to you the relevant parts of the RFC that I am talking about: **2.4. When to Encode or Decode** > Once produced, a URI is always in its percent-encoded form. That means, a URI should be decoded to properly process it right? > When a URI is dereferenced, the components and subcomponents [...] must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be mistaken for component delimiters. This has been done, my change only affects the path component of the whole scheme. That means the components were already separated and decoding can take place, also for delimiters. Note that decoding unreserved characters can optionally happen anytime earlier: > [...] percent-encoded octets corresponding to characters in the unreserved set, which **can be decoded at any time**. Also check the example from **5.4. Reference Resolution Examples**: A base URI of `http://a/b/c/d;p?q` and a relative path of `g;x=1/../y` should resolve to `http://a/b/c/y`. One more note to parent directories, as they are totally valid and should be normalized as well. Just to clear this up, taken from **3.3. Path**: > The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy [...] to indicate relative position within the hierarchical tree of names. This is similar to their role within some operating systems' file directory structures to indicate the current directory and **parent directory**, respectively. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
markt-asf commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932635647 Nope. Read the RFC again. Specifically 6.2.2.2. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932522774 Could you please elaborate how a URI is not user input and how it can be prevented that a user calls a URI on a web application? I can't follow you. Relative paths are explicitly allowed in URIs, and that includes parent directories as well, see the mentioned RFC that defines URIs and how to handle them. This PR was meant to fix a bug in the path processing of Tomcat because it does not decode slashes in paths and that leads to the stripping of the remainder of the URI after the `;` character. I have also added test cases for this issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
rmaucher commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932491567 URL processing and mapping has to follow a lot of rules from specifications to avoid inconsistencies which would be security issues. So this is one of them. Indeed creative encoding can cause path traversals on the backends. To be honest, a good security practice is to not use user input as paths in your app, rather use some other kind of mapping. So no traversal then. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
rmaucher closed pull request #687: Decode and normalize URIs before processing them URL: https://github.com/apache/tomcat/pull/687 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
