httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sutton <p...@ukweb.com>
Subject Re: [linux-security] Security Hole. Appache. (fwd)
Date Thu, 04 Sep 1997 14:30:23 GMT
On Thu, 4 Sep 1997, Dirk.vanGulik wrote:
> > On Thu, 4 Sep 1997, Dirk.vanGulik wrote:
> > 
> > > Flush, blush ; I knew this; there is even some old patch for pre 1 ?
> > > which gave a protocol error :-( It came in after the limit extension.
> > 
> > But it isn't a bug, and the script is doing exactly what they told it to.
> 
> Hmm, I'd strongly argue the case that anything other than PUT/GET/POST/HEAD
> etc in eactly that case; should be flagged as a protocol error (especially
> as the reqeust comes in with HTTP/1.0 and HTTP/1.1; so it should stick
> to that); Though I have to admit that I locally do use INFO and META for
> just that extra dimension.

No, I'd go the other way and say Apache should make it easier to implement
additional methods. Remember that GET/POST/PUT/HEAD are just the "common" 
methods from HTTP/1.0 and HTTP/1.1 and *any* additional methods can be
defined for a particular resource. 

Of course there is a security risk for CGI authors who don't both to check
REQUEST_METHOD, but if they don't check it then they aren't even
processing HEAD vs. GET correctly, or reading any POST data, so their CGIs
are wrong. 

That's not to say that this isn't a serious issue, and places which
describe CGI authoring should be careful to point out the (many) security
risks in writing CGI programs, of which checking the request method is
just one. To attempt to prevent any fallout from bad cgis hitting Apache
perhaps there should be warning on the mod_cgi documentation.

//pcs



Mime
View raw message