Comments in line.
Marc Saegesser
> -----Original Message-----
> From: Jason Hunter [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 23, 2001 11:32 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Tomcat 3.2.3 and getPathInfo
>
>
> Marc Saegesser wrote:
> >
> > I just tried this using the SnoopServlet that ships with Tomcat
> using a URL
> > like
> >
> > http://localhost:8080/servlet/SnoopServlet/http://fubar
> >
> > and got
> >
> > /http:/fubar
> >
> > as the path info. Your description makes it look like your
> losing http: in
> > addition to the one of the /s. Is this what your seeing?
>
> Using SnoopServlet I see /http:/fubar just like you. My seeing the
> http: being eaten was due to how the GoTo servlet responded to the
> illegal URL being used. So that's good, it's only the double-slash to
> single-slash issue. It's a hard issue, but a straightforward issue.
I'm glad we're seeing the same thing. The issue can certainly be solved,
after all, its only code. :-)
> > This problem is almost certainly caused the URL normalization
> code that got
> > put into 3.2.3 to fix a serious security hole. This is going to be
> > difficult to resolve. We have to normalize the URL before the servlet
> > container uses it (I think this is even going to be added to the latest
> > servlet specification) or some really bad things can happen with prefix
> > mapping. However, until we've done the prefix mapping we can't
> know what
> > part of the URL refers to a servlet and what part is path info. Getting
> > back the original non-normalized path info is going to be tricky.
>
> I don't recall any EG discussion about normalizing the URL before the
> container sees it. Generally the spec makes contracts on the
> "container" as it interfaces with the servlet and doesn't make any
> statements about a web server might support a plug-in.
This happened recently, Craig would probably have more details. The
specification does discuss the mapping of URLs into servlets and this is
where the problem lies. For example a URL like
http://localhost:8080/examples/sercurity/../security/protected/index.jsp
obviously refers to a resource inside an area protected by a
<security-constraint> but it doesn't match the prefix <url-pattern> of
/jsp/security/protected unless the URL is first normalized. The solution
proposed was to normalize the URL as it entered the container. The value
returned by getRequestURI() and any other method that returns the URI would
*always* return the normalized URI. This solves the security constraint
problems, but it seems it causes problems with path info.
There two choices here. We either don't normalize the path info or we
don't. I think you can make a case for both sides but I'd lean towards
keeping it normalized.
> > This is even worse because we also won't allow the URL to be
> encoded like
> >
> > http://localhost:8080/servlet/SnoopServlet/http:%2F%2Ffubar
> >
> > because we make some rather draconian precautions to ensure that nastily
> > encoded URLs can't obtain access to protected resources (or
> even resources
> > outside the webapp).
>
> Hmm... I wonder if Tomcat has the right to make illegal what HTTP would
> allow?
As I recall, our constraints were basically lifted from the Apache HTTP
server. Our rationale was that it was far better to preclude some odd URLs
than to leave open the possibility that files outside the web application
could be accessed via the container. This was a *really* bad security hole.
>
> > I'll have to give this one some thought. If URL normalization is being
> > added to the specification then there should also some guidance
> on how it
> > relates to path info.
>
> As I understand it, extra path info has to be returned in its simple
> decoded form.
>
> -jh-
