httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Lounge" <i...@apachelounge.com>
Subject Re: Rethinking "be liberal in what you accept"
Date Thu, 08 Nov 2012 10:47:31 GMT
What about mod_security, has a lot of similar checks and even more.

-----Original Message----- 
From: Stefan Fritsch
Sent: Wednesday, November 7, 2012 12:26 Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Rethinking "be liberal in what you accept"

Hi,

considering the current state of web security, the old principle of "be
liberal in what you accept" seems increasingly inadequate for web servers.
It causes lots of issues like response splitting, header injection, cross
site scripting, etc. The book "Tangled Web" by Michal Zalewski is a good
read on this topic, the chapter on HTTP is available for free download at
http://nostarch.com/tangledweb .

Also, nowadays performance bottle necks are usually in other places than
request parsing. A few more cycles spent for additional checks won't make
much difference. Therefore, I think it would make sense to integrate some
sanity checks right into the httpd core. For a start, these would need to
be enabled in the configuration.

Examples for such checks [RFC 2616 sections in brackets]:

Request line:
- Don't interpret all kinds of junk as "HTTP/1.0" (like "HTTP/ab" or
   "FOO") [3.1]
- If a method is not registered, bail out early.
   This would prevent CGIs from answering requests to strange methods like
   "HELO" or "http://foo/bar". This must be configurable or there must be
   at least a directive to easily register custom methods.  Otherwise, at
   least forbid strange characters in the method. [The method is a token,
   which should not contain control characters and separators; 2.2, 5.1]
- Forbid control characters in URL
- Forbid fragment parts in the URL (i.e. "#..." which should never be sent
   by the browser)
- Forbid special characters in the scheme part of absoluteURL requests,
   e.g. "<>"

Request headers:
- In Host header, only allow reasonable characters, i.e. no control
   characters, no "<>&". Maybe: only allow ascii letters, digits, and
   "-_.:[]"
- Maybe replace the Host header with the request's hostname, if they are
   different. In:
  GET http://foo/ HTTP/1.1
  Host: bar
   The "Host: bar" MUST be ignored by RFC 2616 [5.2]. As many webapps likely
   don't do that, we could replace the Host header to avoid any confusion.
- Don't accept requests with multiple Content-Length headers. [4.2]
- Don't accept control characters in header values (in particular single 
CRs,
   which we don't treat specially, but other proxies may. [4.2]

Response headers:
- Maybe error out if an output header value or name contains CR/LF/NUL (or
   all control characters?) [4.2]
- Check that some headers appear only once, e.g. Content-Length.
- Potentially check in some headers (e.g. Content-Disposition) that 
key=value
   pairs appear only once (this may go too far / or be too expensive).

Other:
- Maybe forbid control characters in username + password (after base64
   decoding)

As a related issue, it should be possible to disable HTTP 0.9.

The dividing line to modules like mod_security should be that we only
check things that are forbidden by some standard and that we only look at
the protocol and not the body.  Also, I would only allow to switch the
checks on and off, no further configurability. And the checks should be
implemented efficiently, i.e. don't parse things several times to do the
checks, normally don't use regexes, etc.

What do you think?

Cheers,
Stefan 


Mime
View raw message