httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Can we be less forgiving about what we accept?
Date Mon, 28 Nov 2011 00:37:42 GMT
Hi,

while browsing a bit through Michael Zalewski's new Tangled Web book, 
I was reminded again that we are very forgiving about what we accept 
as a request. Is this really a good idea in the time of lots of web 
security issues?

Examples include:

* in the request line, the protocol may be arbitrary garbage 
(including control characters) and the request will be interpreted as 
HTTP/1.0. r->protocol will be set to that garbage.

* the request method may contain arbitrary garbage (including control 
characters), as long as it does not contain white space, and is sent 
as method to a backend server by mod_proxy

* We still accept HTTP/0.9 for incoming requests. Is this necessary? 
Do we want to make this configurable?

* Mod_proxy_http will accept arbitray garbage sent by the backend 
server as HTTP/0.9 response. I think this one is also pretty bad from 
a usability point of view because it makes it more difficult to 
diagnose if a backend server sends some body that does not match the 
length information in the headers. Is accepting 0.9 responses really 
necessary? Do we want to make this configurable? Even disable by 
default?

* headers may contain control characters

* With 'ProxyRequests off', we accept absolute urls like 
http://hostname/path for local requests, but we don't check that the 
hostname contained in it actually matches the Host header if there is 
one. The hostname from the URI is then used for vhost matching and put 
into r->hostname. This is mandated by RFC2616 but I guess there are 
quite a few buggy webapps that always look into the Host header. A 
workaround may be to set the Host header to the hostname from the URI 
in this case.

* We accept multiple headers with the same name even where it makes no 
sense, e.g. Host and Range

* We accept unescaped control characters in the URI

In all cases where I mention control characters, this does not include 
NUL-bytes but it includes carriage returns which are considered end of 
line on some systems.


Changing this is of course too late for 2.4. But options to disable 
HTTP 0.9 for incoming requests and for mod_proxy would be nice, at 
least for 2.4.1. And maybe we could have a 'unforgiving' option that 
catches the other things I mentioned and whatever else we find. Or do 
you think that such checks should be the sole responsibility of 
mod_security and the like?

Cheers,
Stefan

Mime
View raw message