When exporting request headers to HTTP_* environment variables, drop variables

whose names contain invalid characters. Describe in the docs how to restore the
old behaviour.

Submitted by: Malte S. Stretz <mss apache org>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1053353 13f79535-47bb-0310-9956-ffa450edef68

CHANGES

@@ -2,6 +2,10 @@
 
 Changes with Apache 2.3.11
 
+  *) core: When exporting request headers to HTTP_* environment variables,
+     drop variables whose names contain invalid characters. Describe in the
+     docs how to restore the old behaviour. [Malte S. Stretz <mss apache org>]
+
   *) core: When selecting an IP-based virtual host, favor an exact match for
      the port over a wildcard (or omitted) port instead of favoring the one
      that came first in the configuration file. [Eric Covener]

docs/manual/env.xml

@@ -140,6 +140,13 @@
           not be a number. Characters which do not match this
           restriction will be replaced by an underscore when passed to
           CGI scripts and SSI pages.</li>
+          
+          <li>A special case are HTTP headers which are passed to CGI
+          scripts and the like via environment variables (see below).
+          They are converted to uppercase and only dashes are replaced with
+          underscores; if the header contains any other (invalid) character,
+          the whole header is silently dropped. See <a href="#fixheader">
+          below</a> for a workaround.</li>
 
           <li>The <directive module="mod_env">SetEnv</directive> directive runs
           late during request processing meaning that directives such as
@@ -423,6 +430,33 @@
   <section id="examples">
     <title>Examples</title>
 
+    <section id="fixheader">
+      <title>Passing broken headers to CGI scripts</title>
+      
+      <p>Starting with version 2.4, Apache is more strict about how HTTP
+      headers are converted to environment variables in <module>mod_cgi
+      </module> and other modules:  Previously any invalid characters
+      in header names were simply translated to underscores.  This allowed
+      for some potential cross-site-scripting attacks via header injection
+      (see <a href="http://events.ccc.de/congress/2007/Fahrplan/events/2212.en.html">
+      Unusual Web Bugs</a>, slide 19/20).</p>
+      
+      <p>If you have to support a client which sends broken headers and
+      which can't be fixed, a simple workaround involving <module>mod_setenvif
+      </module> and <module>mod_header</module> allows you to still accept
+      these headers:</p>
+      
+<example><pre>
+# 
+# The following works around a client sending a broken Accept_Encoding
+# header.
+#
+SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1
+RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
+</pre></example>
+      
+    </section>
+
     <section id="misbehaving">
         <title>Changing protocol behavior with misbehaving clients</title>
 

docs/manual/howto/cgi.xml

@@ -352,11 +352,6 @@
 
       <p>Make sure that this is in fact the path to the
       interpreter.</p>
-
-      <p>In addition, if your CGI program depends on other <a
-      href="#env">environment variables</a>, you will need to
-      assure that those variables are passed by Apache.</p>
-
       <note type="warning">
       When editing CGI scripts on Windows, end-of-line characters may be
       appended to the interpreter path. Ensure that files are then
@@ -365,6 +360,21 @@
       unrecognized end-of-line character being interpreted as a part of
       the interpreter filename.
       </note>
+    </section>
+
+    <section id="missingenv">
+      <title>Missing environment variables</title>
+
+      <p>If your CGI program depends on non-standard <a
+      href="#env">environment variables</a>, you will need to
+      assure that those variables are passed by Apache.</p>
+
+      <p>When you miss HTTP headers from the environment, make
+      sure they are formatted according to 
+      <a href="http://tools.ietf.org/html/rfc2616">RFC 2616</a>,
+      section 4.2: Header names must start with a letter, 
+      followed only by letters, numbers or hyphen. Any header
+      violating this rule will be dropped silently.</p>
 
     </section>
 

docs/manual/new_features_2_4.xml

@@ -109,11 +109,20 @@
       authentication or authorization.</dd>
 
       <dt><module>mod_include</module></dt>
-
       <dd>Support for the 'onerror' attribute within an 'include' element,
       allowing an error document to be served on error instead of the default
       error string.</dd>
 
+      <dt><module>mod_cgi</module>, <module>mod_include</module>,
+          <module>mod_isapi</module>, ...</dt>
+      <dd>Translation of headers to environment variables is more strict than 
+      before to mitigate some possible cross-site-scripting attacks via header
+      injection. Headers containing invalid characters (including underscores)
+      are now silently dropped. <a href="env.html">Environment Variables
+      in Apache</a> has some pointers on how to work around broken legacy
+      clients which require such headers. (This affects all modules which
+      use these environment variables.)</dd>
+
     </dl>
   </section>
 

server/util_script.c

@@ -67,11 +67,14 @@ static char *http2env(apr_pool_t *a, const char *w)
     *cp++ = '_';
 
     while ((c = *w++) != 0) {
-        if (!apr_isalnum(c)) {
+        if (apr_isalnum(c)) {
+            *cp++ = apr_toupper(c);
+        }
+        else if (c == '-') {
             *cp++ = '_';
         }
         else {
-            *cp++ = apr_toupper(c);
+            return NULL;
         }
     }
     *cp = 0;
@@ -175,8 +178,8 @@ AP_DECLARE(void) ap_add_common_vars(request_rec *r)
             continue;
         }
 #endif
-        else {
-            apr_table_addn(e, http2env(r->pool, hdrs[i].key), hdrs[i].val);
+        else if ((env_temp = http2env(r->pool, hdrs[i].key)) != NULL) {
+            apr_table_addn(e, env_temp, hdrs[i].val);
         }
     }