Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <764CA2FF49EC054BA086FC8253A52DD7432BE6@merc09.na.sas.com>
From: Larry Isaacs <Larry.Isaacs@sas.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Cc: servletapi-feedback@eng.sun.com
Subject: RE: Tomcat 3.2.3 and getPathInfo
Date: Fri, 24 Aug 2001 11:14:07 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

In case in matters, RFC 1630 states that:

  PATH

      The rest of the URI follows the colon in a format
      depending on the scheme. The path is interpreted
      in a manner dependent on the protocol being used.
      However, when it contains slashes, these must
      imply a hierarchical structure

I read this as meaning the slashes in "http://fubar" are 
required to be encoded.  Page 9 of RFC 1630 contains
"Example 2", which illustrates this.  Since Tomcat 3.3
and Tomcat 4.0 also disallow "%2F", we all have this issue.

Larry

> -----Original Message-----
> From: Marc Saegesser [mailto:marc.saegesser@apropos.com]
> Sent: Friday, August 24, 2001 9:24 AM
> To: tomcat-dev@jakarta.apache.org
> Cc: servletapi-feedback@eng.sun.com
> Subject: RE: Tomcat 3.2.3 and getPathInfo
> 
> 
> Comments in line.
> 
> 
> Marc Saegesser
> 
> > -----Original Message-----
> > From: Jason Hunter [mailto:jhunter@acm.org]
> > Sent: Thursday, August 23, 2001 11:32 PM
> > To: tomcat-dev@jakarta.apache.org
> > Cc: servletapi-feedback@eng.sun.com
> > 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-
>