httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: sigh. iis...
Date Sun, 04 Jan 1998 11:34:21 GMT
Marc Slemko wrote:
> 
> 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?

Otherwise people can avoid security.

>  If it does, I really think
> it should do a substitution and not just a parsing.

That I'd agree with. It should also figure out what is path and what is
path info.

Actually, I seem to remember that .. should be resolved by the client,
so perhaps the simple answer is to ban it altogether.

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

Umm. Yes. That is rather difficult to deal with.

> 
> 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.

Very sensible.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Mime
View raw message