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


> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Friday, August 24, 2001 11:50 AM
> To: 'tomcat-dev@jakarta.apache.org'
> Cc: servletapi-feedback@eng.sun.com
> Subject: RE: Tomcat 3.2.3 and getPathInfo
> 
> 
> On Fri, 24 Aug 2001, Larry Isaacs wrote:
> 
> > 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.
> 
> That's the only point I disagree with.
> 
> We are able to allow %2F and other encoding. This
> is however risky ( 3.3 had this behavior - we changed it
> only for consistency with 3.2 and 4.0 ).

I had forgotten this behavior is configurable, though
I should have known.  I had not tried the internal test
before with this behavior turned off.  On Windows, all the
tests for this vulnerability pass except for one, where
/test/jsp/HelloWorld%2Ejsp serves the JSP normally (i.e it
doesn't serve the JSP source).  Still safer to leave the
behavior on.

I'll have to remember to document this.

Larry