Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <764CA2FF49EC054BA086FC8253A52DD7432C22@merc09.na.sas.com>
From: Larry Isaacs <Larry.Isaacs@sas.com>
To: "'tomcat-dev@jakarta.apache.org'" <tomcat-dev@jakarta.apache.org>
Subject: RE: URI handling in tomcat 3.2.3
Date: Thu, 13 Sep 2001 14:10:18 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Be aware that setting this false will open Tomcat 3.3 to
the vulnerability it is intended to prevent. Serving JSP
source and bypassing security constraints are among the
problems.

Detecting potential URL trickery early in the handling
provides the most reliable fix.  Allowing unsafe URL's
past this point means that many modules would need to
be updated to detect the trickery.  StaticInterceptor,
which serves static resources, would only be the first,
and perhaps easiest module to fix.  Our assessment was
that this approach wasn't practical to implement.

Cheers,
Larry

> -----Original Message-----
> From: Bill Barker [mailto:wbarker@wilshire.com]
> Sent: Thursday, September 13, 2001 12:36 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: URI handling in tomcat 3.2.3
> 
> 
> While 3.3 has this behavior as the default, it can be 
> disabled in the config
> by:
> <DecodeInterceptor safe="false" />
> 
> Since the release is scheduled to happen by the end of the 
> month, you might
> consider jumping straight to 3.3.
> ----- Original Message -----
> From: "Lars Oppermann" <lars.oppermann@sun.com>
> To: <tomcat-dev@jakarta.apache.org>
> Cc: <bernd.eilers@sun.com>
> Sent: Thursday, September 13, 2001 3:00 AM
> Subject: URI handling in tomcat 3.2.3
> 
> 
> > Hi everyone,
> >
> > we were in progress of moving our project to tomcat 3.2.3 
> when we came
> > accross the new handling of URIs (release-notes sec. 7.2).
> >
> > Since we are using the URI to transport other hierarchical 
> information
> > then filesystem paths, we have the feeling, that this kind of
> > functionality belongs to the default servlet serving filesystem
> > requests. Especialy the fact that %25, %2E, %2F and %5c 
> inside an URI
> > lead to a 404 error seems to somewhat strange.
> > For Example:
> http://server/app/UCB/vnd.sun.star.hier:%2F/address/myresource
> > would be rejected, before app has teh possibilty to look at 
> the request
> > and ...hier://address/myfile... would be normalized to 
> hier:/address.
> >
> > We are perfectly aware of the security concerns behind 
> these changes.
> > However, they only apply when serving resources from the 
> filesystem. A
> > URL's path-components however are in no way bound to the 
> representaion
> > of filesystem paths.(After all, the U in URL stands for universal :)
> >
> > RFC 2396 states that '/' in an URI has another semantic 
> meaning then %2F
> > in an URI. The '/' seperates path-components, while the %2F means a
> > slash character in a path-component. When such an URI is mapped to a
> > filesystem this would denote a filename that contains a 
> slash. When the
> > system does not allow for such names, it is the responsebilty of the
> > filesystem servlet to report an error (404 since such a 
> file must not
> > exist on unix for example).
> >
> > What are your opinions on this?
> >
> > Cheers
> > -Lars
> > --
> > 
> ----------------------------------------------------------------------
> > Lars Oppermann <lars.oppermann@sun.com>               Sun 
> Microsystems
> > Software Engineer - Sun ONE Webtop                       
> Sachsenfeld 4
> > Phone: +49 40 23646 959                                
> D-20097 Hamburg
> > Fax:   +49 40 23646 550                      
> http://www.sun.com/webtop
> >
> >
> 
> 
> *----*
> 
> This message is intended only for the use of the person(s) 
> listed above 
> as the intended recipient(s), and may contain information that is 
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
> you may not read, copy, or distribute this message or any 
> attachment.  
> If you received this communication in error, please notify us 
> immediately 
> by e-mail and then delete all copies of this message and any 
> attachments.
> 
> 
> In addition you should be aware that ordinary (unencrypted) 
> e-mail sent 
> through the Internet is not secure. Do not send confidential 
> or sensitive 
> information, such as social security numbers, account 
> numbers, personal 
> identification numbers and passwords, to us via ordinary 
> (unencrypted) 
> e-mail. 
>