tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Saegesser" <marc.saeges...@apropos.com>
Subject RE: URI handling in tomcat 3.2.3
Date Fri, 21 Sep 2001 15:23:25 GMT
DOH!  I don't believe I did that.  I cut&pasted the URI from the wrong spot.
Here's the real trace.  Note that Apache 1.3.19 does decode the %2f
characters but now returns a 404 error instead of sending the decoded string
as PATH_INFO.  I've attached two traces, one that demonstrates a working
PATH_INFO test and a second that uses %2f and fails.

---------------------------
GET /cgi-bin/dumpenv.bat/pathinfo

COMSPEC=C:\WINNT\system32\cmd.exe
DOCUMENT_ROOT=c:/program files/apache group/apache1.3.19/htdocs
PATH=C:\Apropos\Sybase\Adaptive Server Anywhere
6.0\win32;C:\Apropos\java\bin;C:
\Apropos\java\bin\classic;C:\Apropos\bin;C:\Apropos\tcl\bin;c:\java\jdk1.4\b
in;c
:\java\jdk1.4\bin;D:\Apropos\Sybase\Adaptive Server Anywhere
6.0\win32;C:\Progra
m Files\Sybase\Adaptive Server Anywhere
6.0\win32\win32;C:\WINNT\system32;C:\WIN
NT;C:\WINNT\System32\Wbem;C:\ClearCase\bin;.;C:\Program
Files\Symantec\pcAnywher
e;c:\tools\rebol;C:\Program Files\Support
Tools\;C:\IMNnq_NT;C:\PROGRA~1\TCL\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS
PROMPT=$P$G
REMOTE_ADDR=127.0.0.1
REMOTE_PORT=1269
SCRIPT_FILENAME=c:/program files/apache
group/apache1.3.19/cgi-bin/dumpenv.bat
SERVER_ADDR=127.0.0.1
SERVER_ADMIN=marc.saegesser@apropos.com
SERVER_NAME=msaegesserlpt
SERVER_PORT=8081
SERVER_SIGNATURE=<ADDRESS>Apache/1.3.19 Server at msaegesserlpt Port
8081</ADDRE
SS>

SERVER_SOFTWARE=Apache/1.3.19 (Win32) mod_jk
SystemRoot=C:\WINNT
WINDIR=C:\WINNT
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/0.9
REQUEST_METHOD=GET
QUERY_STRING=
REQUEST_URI=/cgi-bin/dumpenv.bat/pathinfo
SCRIPT_NAME=/cgi-bin/dumpenv.bat
PATH_INFO=/pathinfo
PATH_TRANSLATED=c:\program files\apache group\apache1.3.19\htdocs\pathinfo


Connection to host lost.
---------------------------

---------------------------
GET /cgi-bin/dumpenv.bat/http:%2f%2ffubar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
                                                  <HTML><HEAD>
                                                              <TITLE>404 Not
Fou
nd</TITLE>
          </HEAD><BODY>
                       <H1>Not Found</H1>
                                         The requested URL
/cgi-bin/dumpenv.bat/
http://fubar was not found on this server.<P>
                                             <HR>
                                                 <ADDRESS>Apache/1.3.19
Server a
t msaegesserlpt Port 8081</ADDRESS>
                                   </BODY></HTML>


Connection to host lost.
---------------------------



Marc Saegesser

> -----Original Message-----
> From: Jason Hunter [mailto:jhunter@acm.org]
> Sent: Thursday, September 20, 2001 5:13 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: URI handling in tomcat 3.2.3
>
>
> You only use http:// in the GET request if you're talking to a proxy
> server.  That's probably why you got the bad request error, not because
> of the %2f.  You should try:
>
> GET /cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1
>
> -jh-
>
> Marc Saegesser wrote:
> >
> > Oops, minor correction.  Apache actually returns 400 Bad Request
> >
> > Here's the telnet session
> >
> > GET http://localhost:8081/cgi-bin/dumpenv.bat/fu%2fbar HTTP/1.1
> > server: msaegesserlpt
> >
> > HTTP/1.1 400 Bad Request
> > Date: Thu, 13 Sep 2001 13:51:21 GMT
> > Server: Apache/1.3.19 (Win32) mod_jk
> > Connection: close
> > Transfer-Encoding: chunked
> > Content-Type: text/html; charset=iso-8859-1
> >
> > 18b
> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> >                                                   <HTML><HEAD>
> >
> <TITLE>400 Bad
> > Req
> > uest</TITLE>
> >             </HEAD><BODY>
> >                          <H1>Bad Request</H1>
> >                                              Your browser sent a request
> > that th
> > is server could not understand.<P>
> >                                   client sent HTTP/1.1 request without
> > hostname
> > (see RFC2616 section 14.23): /cgi-bin/dumpenv.bat/fu%2fbar<P>
> >                                                              <HR>
> >
> > <ADDRESS>Apache
> > /1.3.19 Server at msaegesserlpt Port 8081</ADDRESS>
> >                                                    </BODY></HTML>
> >
> > 0
> >
> > Connection to host lost.
> >
> > Marc Saegesser
> >
> > > -----Original Message-----
> > > From: Marc Saegesser [mailto:marc.saegesser@apropos.com]
> > > Sent: Thursday, September 13, 2001 8:48 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > Cc: bernd.eilers@sun.com
> > > Subject: RE: URI handling in tomcat 3.2.3
> > >
> > >
> > > I agree that this URI handling sucks.  I'm the one that committed
> > > the change
> > > that made it happen and I still think it sucks.  However,
> allowing these
> > > encoded characters opens some very large security problems.
> > >
> > > Also, even if TC 3.2.x allowed these characters, the resulting
> > > URL wouldn't
> > > be portable because several other web servers impose the same
> > > restrictions.
> > > In fact we lifted our restriction on encoded special
> characters straight
> > > from Apache HTTPD.  In your example URL, if /app/UCB was a
> CGI script then
> > > you would still get a 404 on Apache (at least on Apache 1.3.19
> > > which is what
> > > I tested with).
> > >
> > > If you need to pass this sort of data to a servlet (or CGI) the most
> > > portable way is to simply use a query string.
> > >
> > >
> > > Marc Saegesser
> > >
> > > > -----Original Message-----
> > > > From: Lars Oppermann [mailto:lars.oppermann@sun.com]
> > > > Sent: Thursday, September 13, 2001 5:00 AM
> > > > To: tomcat-dev@jakarta.apache.org
> > > > Cc: bernd.eilers@sun.com
> > > > 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


Mime
View raw message