Re: HTTP REQUEST_METHOD flaw

[chris () NETMONGER NET (Christopher Masto)]

On Wed, Jan 06, 1999 at 09:30:43PM +0100, Sevo Stille wrote:
> > Even Control characters are allowed. Consider the following:
> >
> >  ^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1
[...]
> Quite so. Nonetheless it would be desirable if the common CGI libraries
> would perform a somewhat more strict method check. The paranoid may want
> to pipe their log through a filter which replaces control chars with
> some associated symbolic value.

The paranoid may want to reconsider their logging entirely.  Apache's
"raw" logging of the request can result in more serious problems.
Consider:

  $ telnet www.foo.com http
  Trying www.foo.com...
  Connected to www.foo.com.
  Escape character is '^]'.
  GET / HTTP/1.0" 404 -9999999 "

This results in the following (combined format) log entry:

aaa.bbb.ccc.ddd - - [07/Jan/1999:14:07:41 -0500] "GET / HTTP/1.0" 404 -9999999 "" 200 751 "-" "-"

In the "combined" log format, the same technique is possible with the
referer and user-agent, such that you can construct completely
unparseable log entries.  I made a small modification to the logging
module to allow me to insert newlines to separate fields in the
LogFormat string, as it seems to be that newlines are the only
characters you can't weasel into a request.

Sending a null, by the way, results in this interesting effect:

209.54.21.199 - - [07/Jan/1999:14:35:27 -0500] "ÿôÿý" 501 - "-" "-"

(Perhaps that will be mutilated by non 8-bit mail transport.. it's the
four characters ff f4 ff fd)

To be fair, I should point out the following comment in the source code:

 "[...]                                                   Note that
 * there is no escaping performed on the strings from %r, %...i and
 * %...o; some with long memories may remember that I thought this was
 * a bad idea, once upon a time, and I'm still not comfortable with
 * it, but it is difficult to see how to "do the right thing" with all
 * of '%..i', unless we URL-escape everything and break with CLF."

In case anybody cares, here is the patch I am using to "break with CLF":

--- mod_log_config.c~   Tue Sep 22 05:19:59 1998
+++ mod_log_config.c    Wed Nov 18 01:39:25 1998
@@ -126,6 +126,7 @@
  *                 sent to the client.
  * %...l:  remote logname (from identd, if supplied)
  * %...{Foobar}n:  The contents of note "Foobar" from another module.
+ * %N:     newline
  * %...{Foobar}o:  The contents of Foobar: header line(s) in the reply.
  * %...p:  the port the request was served to
  * %...P:  the process ID of the child that serviced the request.
@@ -364,6 +365,12 @@
 {
     return ap_table_get(r->notes, a);
 }
+
+static const char *log_newline(request_rec *r, char *a)
+{
+    return "\n";
+}
+
 static const char *log_env_var(request_rec *r, char *a)
 {
     return ap_table_get(r->subprocess_env, a);
@@ -472,6 +479,9 @@
     },
     {
         'n', log_note, 0
+    },
+    {
+        'N', log_newline, 0
     },
     {
         'e', log_env_var, 0

I then use this butt-ugly LogFormat directive:

LogFormat "A %v%NB %h%NC %l%ND %u%NE %t%NF %r%NG %>s%NH %b%NI %{Referer}i%NJ %{User-Agent}i%N" combinedplus

The log entries come out as follows:

A www.netmonger.net
B 209.54.21.140
C -
D -
E [04/Jan/1999:17:16:59 -0500]
F GET / HTTP/1.0
G 200
H 5094
I -
J mon.d/http.monitor

I ran into this issue when I decided to nightly read the log files and
send them to a database.. when writing a parser, one starts thinking
about field delimiters, and I decided to check to make sure that I
could actually rely on them.. I was rather started to find that I
couldn't, but I didn't have time to write a proper bug report, so it's
waited until this similar issue reminded me of the problem.
--
Christopher Masto        Director of Operations      NetMonger Communications
chris () netmonger net        info () netmonger net        http://www.netmonger.net

    "Good tools allow users to do stupid things." -- Clay Shirky