Re: [servlet-dev] Path Parameters

[Mark Thomas <markt@xxxxxxxxxx>]

On 17/02/2021 12:16, Greg Wilkins wrote:
> On Wed, 17 Feb 2021 at 12:28, Mark Thomas <markt@xxxxxxxxxx
> <mailto:markt@xxxxxxxxxx>> wrote:
> 
>     On 12/02/2021 17:11, Greg Wilkins wrote:
>     > So this gives us two problems.   Firstly I now cannot find any current
>     > specification of HTTP URL path parameters and how they should be
>     > parsed.   So I think the servlet spec could be relying on the
>     > grandfathered definition from RFC2396.  IS this true?  Does
>     anybody know
>     > of a current specification for them?
> 
>     I'm not aware of anything better than the references you have provided.
> 
> 
> Then I think we need to probably note in future specs we are using an
> obsoleted RFC to define what they are.  I'll ask contacts in IETF if
> there is any process to get path parameters formalized there.

Ack

>     > In Jetty, we already handle ambiguous URIs like/foo/%2e%2e/bar with a
>     > 400 and intend to do the same with /foo/..;/bar and /foo/%2f/bar.  How
>     > do the other container handle such URIs?
> 
>     In Tomcat we process URIs with the following sequence:
>     - separate the query string (if any)
>     - parse the path parameters (we are only interested in jsessionid or
>       equivalent) and remove them from the URI
>     - %nn decode the URI
>     - normalize the URI
>     - map the URI to virtual host, web app, filters, security constraints,
>       servlet etc.
> 
> 
> That is also how Jetty has done it until recently.  Specifically decode
> and then normalize.
> 
> However, that is not compliant with RFC 3986 which says that
> normalization should happen before decoding.

Where does it say that? I just looked through all the references to
normalization and couldn't find it.

>  That is all fine if you
> remember the segment boundaries so that segments like "%2e%2e", "%2f"
> and "..;" would be seen as decoded segments after normalization of "..",
> "/" and "..".

My reading of section 2.2 is that reserved characters should not be %nn
decoded prior to normalization.

> But we don't remember segment boundaries and put them
> all back into a string, so following the RFC of  normalize and then
> decode means that information is thrown away and those segments are now
> ambiguous.
> 
> Our plan is to now to follow the RFC and then 400 any requests that have
> such segments, but have a compliance mode for apps that want to work on
> the raw URI.
> 
> I don't think that is a huge difference to what Tomcat is doing, other
> than for a URI like "/foo/%2e%2e/bar". Jetty will 400 such requests
> unless it is the compliance mode, in which case the path of
> "/foo/../bar" will be passed the application (which will have to have
> it's big boy pants on and look at the raw URI).   I think Tomcat will
> handle that as "/bar"?

For that specific example, yes.

>   Jetty used to do that, but we had problems with
> intermediaries putting constraints on "/foo/*"

Arguably an issue with the intermediary for that specific example but
there are other examples such as "/..;/" where there would be an issue
that wasn't the intermediary's fault.
 
> 
>     Given all of the above when receiving a request of the form
>     "/foo;v=1/bar" there were several ways to handle it:
> 
> 
> No disagreement on the handling of that one. Spec is clear that we strip
> path params and treat it as "/foo/bar".   It is only when the docoded
> segment is ".", ".." or includes "/" that I think there is a problem.  
>  
> 
>     The downside with approach 3 is that when used behind a reverse proxy,
>     and depending on how the reverse proxy does the request mapping, it may
>     be possible to bypass path based security constraints defined in the
>     reverse proxy. If the reverse proxy is using path matching as a security
>     control, URIs containing "/..;/" may bypass that control. The Tomcat
>     provided proxy modules (mod_jk, ISAPI redirector) map requests using the
>     same algorithm as Tomcat to avoid this potential issue.
> 
> 
> Using the same algorithm is key to avoiding security problems.  Given
> that the RFCs are very poor in this area then perhaps the servlet spec
> needs to specify the algorithm we expect to be applied?

I think the Servlet spec is the place to be more explicit about this.
This has been on my radar for a while:

https://github.com/eclipse-ee4j/servlet-api/issues/18

It would be great to get this into servlet.next.

Mark