httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: sigh. iis...
Date Sun, 04 Jan 1998 06:41:51 GMT
On Sun, 4 Jan 1998, Chuck Murcko wrote:

> Marc Slemko wrote:
> > 
> > Looking at IIS some more,
> > 
> > http://myserver/cgi-bin/mycgi.exe/../../foo/ will access the same thing as
> > http://myserver/foo/
> > 
> > That's kinda broken, no?
> > 
> > Only problem is that Apache does it too.
> > 
> > With Apache, it logs it as /cgi-bin/mycgi.exe/../../foo (IIS doesn't).
> > This means that anyone can sneak around any billing based on logfile
> > analysis.
> > 
> Are you saying it does this even without a ScriptAlias directive? That's
> not good.

No, I wasn't saying that since I didn't bother looking.  But yes, it does
that without a ScriptAlias.  

There are two different problems here.

The problem with doing it for a ScriptAlias is that it is yet another
messed up CGI thing; the whole concept of the PATH_INFO mapping to the
filesystem makes me unhappy but, obviously, some of it has to be done to
make it CGI.  What is in the PATH_INFO should not allow /../ to go above
the CGI.  This is, however, hard to parse in the current structure.

The second issue is messing up logs.

Why does Apache need to resolve /../ at all?  If it does, I really think
it should do a substitution and not just a parsing.

Even worse: http://site/~user/../~otheruser/

I would be willing to bet that nearly any log parser would end up
attributing the hits to user insted of otheruser.  Where hits are billed
or restricted, this can be deadly.  Obvious if you look at the logs, but
not if they are just automatically summarized.

> > NS enterprise 3.x seems to just deny all requests with a /../ in the
> > request anywhere.
> -- 
> chuck
> Chuck Murcko            The Topsail Group             West Chester PA

View raw message